The GeoVolume has been interesting, we’ve had some problems with it that we’re trying to track down.
But…
It would we so swell if GeoVolumes could be added to PRTLoaders. So the PRTLoader could load from disk and/or from GeoVolumes in the scene. That way we could DO things the points after they are made, like deformation modifiers and culling objects, or view them in the viewport, or (in the near future) swizzle channels on them.
What do you think?
We are investigating the best way to implement this. Extending the PRT Loader to deal with all things Krakatoa does not sound like the best way to go. We’d rather make the right design decisions, so give us some time to think about it…
Thanks for the ideas! (GeoVolumes were a very cool idea indeed!)
Agreed 
I am curious, you guys seem to think it a good idea, could you explain a possible scenerio?
You can write the GeoVolume particles to PRT then load them, what am I missing?
Chad are you saying add the whole GeoVolume Object to a PRT? So it acts as a Birth Operator of sorts.
The problem is just that we need a LOT more functionality in the GeoVolume. Like a way to see the points, or perform other operations to it. But adding all that sounds like a lot of work, considering that it’s a modifier. So I thought, hey, those features are already in the PRTLoader, so what if, instead of just loading from disk, you could also get from the scene. That’s something the PRTLoader can’t do now, so it’s not trivial, but it’s just an idea. I’d probably be fine doing an either/or option. Like have a PRTLoader that could either do PRT’s or GeoVolumes (and whatever else we can think of), but not both.
Yeah, it’s a lot like a birth operator, but we’ve been trying to avoid the overhead of particles, especially for animations.
Gotcha. 
thanks for the explanation.
Coming from a different angle, how about a “anti-clip” object in the PRT loader? You would pick objects or sets, just like the clip object, but it would ADD the particles from the GeoVolume. Just a different idea, dunno how practical it is.
Chad,
We would prefer going the opposite direction - instead of dumping more new features into the PRT Loader, we’d like to modularize it into dedicated modifiers, so all it does is loading PRT files. This would mean that culling could be a separate modifier on the stack, and GeoVolume mod could produce visible particles in the scene that could get deformed by KSW and so on.
This is the way we would like to go, but it will require some testing and planning, so no promise.
That sounds great, I’d love to have a more modifier based approach, but I didn’t want to ask for anything that complex. That just sounds like a lot of work.