We have posted some preliminary information on the upcoming Grid and Random particle distribution we are adding to the PRT Volume in the upcoming 1.5.2 update (scheduled to start Beta testing in the following weeks):
Really interesting, so subdividing the the voxel, basically you could have the teapot encompassed in a single voxel with a high subdivision and create a uniquely looking particle cloud, huh…cool
No, a single voxel would not be able to define anything remotely resembling the original mesh. As the voxel resolution decreases, the volume enclosed becomes more and more degenerated. Since we check the particle positions relatively to the Level Set Mesh, there is a certain Spacing value after which you cannot get anything usable. But you can use VERY low resolution voxel grids and high particle counts which will remove the long wait necessary when converting a simple object into a very dense particle cloud. In 1.5.0, you had to live with a very dense level set just to get some more particles into the volume, now the two resolutions are decoupled.
P.S.
Posting this from my brand new Gateway FX with i7 920, 12GB RAM and GeForce GTX285. Just finished installing Max and hope to start benchmarking Krakatoa any minute now 
Haha I suppose so, you would certainly need a few more voxels to retain the base geo shape 
Dude, Fun! What more fitting the “FX” edition 
Unless the PRT volume voxel array is oriented to the halfangle, or the voxel rendering array has an intermediate sampling array that is oriented to the PRT volume array, you’re going to get artifacts in both regular and random distributions.
You mention the noise being tilable, so you don’t see periodic clumping or gaps, but is it a uniform “blue noise” or “Poisson sphere” type of distribution?
- Chad
I implemented Poisson Sphere noise generation using the Corner Cube technique of Lagae and Dutre, but its not really feasible to generate a reasonable number of cubes on the fly. It would require having the points pre-computed somewhere on disk, and I don’t really want to deal with that headache just yet.
I ended up going with a sub-set of samples from a single Poisson Sphere corner cube, so they have a guaranteed minimum spacing. This isn’t really a Poisson Sphere, buts its a half-decent sampling.
Understood. Additional complexity. But would it make more sense to just embed the cubes in the plugin and skip the disk I/O entirely? The data has to be small, right? Less than 1 MB, if you stop at say, 128 particles per voxel?
A set of precomputed corner cubes or Wang tiles as .PRT’s stored on disk would be interesting for use in a PRT Birth operator in Pflow… Something like Recursive Wang Tiles for Real-Time Blue Noise by Kopf et al could be used to affect spatial density based on distance to camera and view frustrum, so you could fly through a particle system without it breaking apart. But I suppose a Birth Operator with just the precomputed tiles could be it’s own plugin as well.
- Chad
EDIT: Regarding the size of the data to embed in the .dll, you could get away with half float, right? Cut down the size a lot, and you wouldn’t see a difference.