We have updated the documentation pages with some new material, including:
*Krakatoa SkinWrap WSM Usage:
software.primefocusworld.com/sof … ations.php
*Density By Age using MagmaFlow:
software.primefocusworld.com/sof … by_age.php
(contains a preview of an upcoming 1.5.1 feature!)
nice one…yay on the curve op! and btw does this :
software.primefocusworld.com/sof … ooey_Blobs
Mean the PRT Mesher will be included in the future ?? Or is it just a cruel tease? 
Regards,
Thorsten
We are not THAT cruel. 
We had a discussion at Siggraph about starting a Beta for it to see if people want it, like it or need it (since there are a couple solutions out there already).
It might not be part of the Krakatoa package though.
Stay tuned.
Great to hear! and thanks for the info!
Regards,
Thorsten
mmmnn mesher 
mmmnnn curves
I am still clicking on 'periods" looking for Easter Eggs 
There are none, you can read clearly what we are doing for 1.5.1 here:
software.primefocusworld.com/sof … _notes.php
The Fading Density topic was updated once again with some examples of using KCMs to turn the Density By Age value into Texture coordinates to look up into a Gradient Ramp map or any other texture:
software.primefocusworld.com/sof … ent_By_Age
a mesher would be realy gorgeous!, meshing them in realflow is nice too but somewhat tedious
And incredibly slow…not even the meshing itself (wich is slow too as it is not multithreaded at all) but alone selecting the mesh takes AGES as it has the slowest viewport ever 
Regards,
Thorsten
I have never tried to do a benchmark of the RealFlow meshing, but I have done some of PWrapper and Max Blob Mesh to see how we compare.
software.primefocusworld.com/sof … chmark.php
While nobody here has signed an NDA, please keep this page for yourself and don’t spread the URL around.
i thought i did sign an NDA…maybe i just signed to many to keep em apart lol.
Back on topic…you TEASE lol…that looks absolutely FANTASTIC!
/me sits tight!
Regards,
Thorsten
i realy thought pwrapper is lightning fast, but compared to prt mesher … . Would be an incredible extension of krakatoa
Good Lord, I guess I should have expected that to be the case, that is just ridiculous, the scaling is mind boggling. it is crazy to see blobmesh out do pWrapper in the first test at 40K and 80K
Keep in mind that these tests are a bit biased. 
PWrapper was never designed to deal with a million dense almost overlapping particles.
Since Krakatoa tends to produce millions, we had to test how it does (and we used about 300K on the characters in Dragonball:Evolution without problems).
When the distribution of the particles is more SPH-like, the differences between PWrapper and PRT Mesher become less obvious (except of the multi-threading, I think I heard PWrapper is getting multi-threaded too). Also, when the particles are too far away from each other, all 3 get slower because each particle turns into a separate ball and the face count goes up a lot.
On the other hand, the number of meshing algorithms and additional controls in PRT Mesher make it even more interesting.
still some interesting numbers, and when I start seeing ???, reminds me of all the out of memory at rendertime errors i’ve gotten with pwapper 
although a multi-threaded pwrapper would be great, folks have been asking about that for years, and really as it is the only modestly priced option available (other than Becrons Metaball for vray, which BTW is really pretty amazing, thats another story)
I saw that and immediately begin to salivate 
Is there an intermediary caching available for the levelset? Like breaking it into two steps, one for the particle-to-levelset conversion and one for the levelset-to-mesh conversion. Seems for very dense (spatially) particle systems, the levelset would be smaller, reducing network bandwidth for renders, and you could tweak the actual meshing faster (though this is probably minor). You’d also have the side benefit of accessing the levelset data for other purposes (new particle channel, even?). I’ve done renderings with box#3 where ‘surface’ particles are treated differently than ‘subsurface’ particles. Specular, density, color, etc.
In our in-house system, the PRT mesher can be saves as .RLS Level Set or as an XMesh (our geometry caching system).
The Level Set format is the one used in Flood. (The full internal name of the tool is “Flood PRT Mesher”).
For obvious reasons, these features might not be in an eventual commercial version of the tool.
Publishing specs for the file format that wouldn’t be terrible, would it? Ben and Mark already presented the concept of RLE compressed levelset data at SIGGraph, and it’s not like you’re publishing Flood itself. Alternatively, you could use a public format like Field3D, http://code.google.com/p/field3d/, and while you would have to add that to your mesher, at least you wouldn’t have to provide support, the way you do with .PRT’s.
The mesher directly saves the XMesh data? That’s pretty interesting, but it makes sense. If the meshing is just a step in the pipeline for a final shot, and not being used interactively, no need to pass the mesh to 3ds max and use a modifier to save the data out to disk.
The PRT Mesher meshes particles. It does not read RLS files, it just has the option to write them. There is a separate tool for loading and meshing level sets, and yet another for loading them (for example to drive particles in PFlow). Chances are these features won’t be in the final product, IF there is a final product.
Right, I was just saying that the levelset data used in the middle of the PRT meshing could be reused for texturing the mesh, or populating channels in Pflow, etc.