I really need a way to write krakatoa data channels without going through a loader or volume or particle system.
What do you mean exactly - create particles on the fly into memory with a script or plugin?
A step by step description of your envisioned workflow would be great.
I have my own plugin that can generate points with color, density and normals, extra channels. I’d rather use that to pump point into krakatoa than save out .prt files, or particle system etc.
It’s an object plugin.
The cheapest possible way to make this happen is for me to create a PRT object that reads its data from a socket. You could transmit particle data in the PRT file specification via the socket and I wouldn’t have to change much except make a PRT Loader that takes URIs instead of Windows paths.
On the other hand, this doesn’t use the 3dsMax reference system so you would lose change notifications and reference-loop prevention. I could make a simple subclass of BaseInterface that offers a stream object (possibly via a std::ostream subclass) that I could use to extract the data from.
I like the concept of transferring data via the PRT file spec, since it’s an established interface that isn’t going to change.
Thoughts?
so I would still have to make a prt loader in the scene? but point it to a stream instead of a file? Does it require changes to the krak core? How quickly could we make a demo to see how feasible this would be?
B.
I would probably see it consisting of two scene objects. Object A would be your scene object, and object B would have a reference to your object via a scene INode. When object B went to evaluate its particles it would call INode::EvalWorldState(t) on the INode pointing at object A. The result in the ObjectState would support GetInterface( KrakatoaPRT_Extension_Interface ) returning a simple class that has a std::istream& which I can use to extract the particle data.
My current schedule suggests that this could be prototyped for the next-next beta release. Ie. I’m working on a beta release now, and then it should fit into the one after that. A couple weeks maybe?
I see having extra objects as a downside. The user would get confused about materials, visibility/renderablity settings and extra transforms/ names of objects. I’m not sure what the advantage would be for adding another object. I’d rather krakatoa enumerate objects that register (streams). This could be done via an interface that my plugin talks to.
Also, extra object or no, would this support kcm’s?
Thanks again…
Your biggest fan,
Ben.
Can you elaborate on this? I assume you mean that your object would pass a pipeline object up the stack that I could get the stream from.
To expand on this, our current plan is to introduce stand-in objects for various systems we currently support “live”, including FumeFX and possibly PFlow. Since our object (and yes, YOUR object too) would support KCMs and deformations, we could thus turn FumeFX or PFlow into a particle system we can modify any way we want (similar to how you make a Mesher to do stuff to PFlow particles, but in our case it would be at the particle level).
The user would have to deal with two objects instead of one, but you wouldn’t have to know anything about KCMs and deformations and Krakatoa Particle Streams to implement what you want as you would be still using the PRT specification that you already have implemented. So it is less work for you, A LOT less work for us and there is no need to create an SDK for creating Krakatoa particle streams so everybody would be happy.
In short, having a generic PRT Stream Object that other plugins can talk to and feed it with particles would be along the lines of where we are going anyway. (And it might be possible to feed it with MAXScript too).
ok. Just make sure we can add multiple streams in this new object. This way we can only add one per scene if we want to. And have an option not to display anything in the viewport (except an icon).
I wouldn’t write off making a real interop sdk. Since all developers would have to support the ostream technique anyway.
B.
Exciting 
Sorry for such a meaningful eleaborate post… this sounds real yummy, almost better than ketchup on burritos
Yes, we hope to allow the same controls as in the PRT Volume, so you could create a grid or a bunch of random particles per voxel in a lower res. sim to produce denser clouds. And of course applying KCMs and deformations to Fume particles without saving to PRT would be quite useful…