AWS Thinkbox Discussion Forums

Memory consumption / voxel count in log?

There isn’t anything in the log for memory consumption or voxel array count. Not a huge deal, so put it way down on the wish list, but without a combination of explicit sampling sizes and a limit to the extent of the voxel array, I have a hard time figuring out the memory usage.

I’ll add this to our wish list.

I got distracted while writing a reply to the “Voxel Size Controls” post that touched on this. Here’s the relevant quote: “We use a limited amount of memory to store density samples, and I think the maximum is under 100 MB. As far as I know the mesh is pretty much always the limiting factor.”

If you have a problematic data set that you are willing and able to share, then I would be happy to take a look.

Haven’t tested it (and without the log, can’t conclusively), but if the radius is small and the meshing dense, so you have tiny voxels, wouldn’t a particle source with two points that are very distant in X,Y,Z produce a huge volume?

  • Chad

When I said the sampling grid is uniform, I meant in the sense that we use a constant voxel length. Typically we don’t hold the entire volume in memory at once, and we can skip empty space. For example with voxel size 1 you can place a small particle at (-100000,-100000,-100000) and another at (100000,100000,100000) with no problem.

To put this in historical perspective, what Chad was afraid of was actually the case about a year ago - and the memory allocation was causing severe slowdowns. So much that Frost was falling behind pWrapper on tests with few particles with small sizes separated by large distances.

So an optimization was added first as an option, and later as the only (current) mode where Frost is working on sub-sections of the final volume, generating the respective mesh fragments and then welding them together into the final mesh. So the memory usage should never exceed the limit mentioned by Paul, and the total bounding box extents of the source particle system play no role.

Neat. That encourages me as to how the relates to possibly doing arbitrary PRT channel sampling output to UVW channels. We won’t have to worry about having a huge chunk of memory available.

Privacy | Site terms | Cookie preferences