AWS Thinkbox Discussion Forums

Radius / voxel size for repopulation

Does it make sense to offer a separate control for the voxel size independent of the radius? Right now, if we make really puffy particles with a large radius, we can see more voxel artifacting. It seems that the voxel size and the radius are linked. Do they need to be, and can we get them separated?

Repopulation does not have a voxel size parameter. Are you referring to the global voxel length for rendering in “voxel” mode? There is no link between the radius and a voxel size parameter. What kind of artifacting are you seeing? Are there black spots? We have recently fixed a bug in the repopulation that fixes a “black spots” artifacting issue.

Are you using the C++ API or the Python module?

The documentation wasn’t originally included with the Python module, but it is available now. This is the section on repopulation:

Multiplication of existing particles

The "PointsFileMultiplication" function can take an existing particle file (PRT, BIN, CSV) and multiply the particle count by filling particles within a radius around the original particle positions. This function has the potential to take a long time to compute because it will read all the original particles and generate a level set representation to seed from.

PointsFileMultiplication parameters and usage:
Parameter 1: Particle Filename (string): The path to the source particle file.
Parameter 2: Fill Radius (float): The radius around each particle to seed new particles.
Parameter 3: Fill Radius Subdivisions (integer): The number of seeding subdivisions. Increasing this number will exponentially increase output particle count.
Parameter 4: Number of Particles per Subdivision (integer): The number of particles placed in each subdivision. Increasing this number will linearly increase output particle count.
Parameter 5: Density Falloff Start (float): A value between zero and one that defines the start (between the center and outer radius) of the linear falloff of density. Zero being no falloff, one being a linear falloff from the center of the original particle to the outer radius. Setting a larger falloff creates a "softer" particle cloud effect. ri.PointsFileMultiplication( "my_particles.prt", 0.75, 1, 2, 0.0 )

I’m referring to the voxel-shaped artifacts. :slight_smile:

I’m rendering out some pics to post…

EDIT: We’re using the C++ API

Oh, I see what you’re referring to. I misunderstood what your original meaning.

Here’s how it works:

  • A level-set is created from the original particles.
    —The levelset resolution (voxel length) directly corresponds to the user radius. They are essentially the same (sorry for the confusion earlier).
  • Particles are seeded from the levelset in roughly 2^numSubdivs * numParticlePerVoxel per voxel.

So, if you provide a radius that is disproportional to the scale of your particle set. You will see voxel artifacts. The intended use for repopulation is to seed particles around the original particles to produce a softer, more “filled in” look. The intent was not to expand the original particles outwards beyond the original particle set to create a cloud effect. In doing so, you will start to see the underlying voxel grid in action.

Are you looking for something that can take a single particle, and allowed you to create a user-defined sized spherical volume of particles around that particle? (similar to creating a frost mesh, then filling that mesh with particles?). This would be a significantly more time-hungry operation, but it is something we can consider.

Ah, but that assumes I have a uniform inter-particle spacing. Often times with particles you don’t have that. :slight_smile:

I’m not trying to expand the particles outward, it’s just that at the top of the particle system, the spacing is just worse than at the bottom.

The Frost workflow makes sense, but I’m thinking that instead of filling the mesh with particles with PRT Volume (or even making a mesh at all), you’d just do the sphere (or ellipsoid) splatting to a voxel array (with the density of the splats based on the particle density channel), filter those voxels, then spawn a bunch of particles and then test them against those voxels. So no, it’s not a case of 1 particle makes N particles (like what PRT Cloner does) but something where you consolidate the particles and even remove redundant ones while you do empty space filling.

You say it would be slower, but I’m not sure why. Oh wait… So you make a grid based on the radius, then, since you don’t care about a density or radius channel, you just test if ANY particles exist in that cell? So you don’t spat at all, you just make off if the cells are occupied or not? And then you subdivide (filter?) that, and set the density of the output particle based on the distance (the falloff parameter).

Privacy | Site terms | Cookie preferences