Been watching the development of Krakatoa MY for a little while now, and I was curious about a few things:
First, I’m just an independent guy that mostly works for the small’ish indies, and my principle 3D apps have pretty much been Maya and or Lightwave, so any 3DS Max / MX pipelines are a relative unknown to me. Please forgive me if I’m asking a painfully obvious question.
Are particles generated by Krakatoa MY available to Maya’s Dynamics / Fields / Procedurals and so forth? Say I create a VOL PRT based on polygonal geometry. Are these particles then able to be influenced by any of Maya’s forces, or would I approach this the other way by generating the particles via Maya’s tool-sets, animating them and so on, THEN using Krakatoa to increase the particle count to the desired ratios?
Which leads me to my next question. When Krakatoa creates these jittered, offset duplicates, is it aware of the vector relationship of the originating particles and applying the duplications cohesively, or will I get a random offset / jitter per frame? Think of an arrow arcing. Will I get new particles that respect the trajectory and behave similar to a flocking algorithm, or will I get completely random offsets that greatly deviate from the original arc?
Is Krakatoa capable of generating particles from the cached vertices of an animated / deformed polymesh (geocache, alembic, MDD, etc…)? Or even nParticles that are cached?
I see that you’ve got Maya fluids on your priority to-do list, and I can certainly attest that just being able to get vector motion information from a voxel fluid, without having to convert it to a mesh, or parenting a legion of nParticles to it would probably be reason enough to get KMY. (I really really hate generating these vectors in post, and most methods almost always break stereo comps… Stereo fire element + Furnace + Nuke = Disparity much of the time). I sure hope a vector pass is on the list of things to implement when dealing with fluids.
PRT Volume particles are not dynamic. In all incarnations of Krakatoa, they are meant to be used for quick creation of large and dense point clouds that should appear in the Krakatoa rendering, but are more or less static (background objects etc.) They are also very useful when learning the features of Krakatoa since you can get several million particles in almost no time to test lighting and shading tricks. The latest build of Krakatoa MY from April 30th also respects the mesh velocities and creates correct motion blur on the particles, so deformed meshes can be used to create “moving” particles. PRT Volume particles will also be becoming more useful in the future as more channel editing features are added to the Maya version, and potentially play a role as emitters if Stoke makes it to Maya.
If you want to work with Maya dynamics, you have to use Maya particles. You can then either save multiple variations using the Partitioning tool, or use the render-time Repopulation feature (which was also improved significantly in the latest build) to produce millions out of thousands.
The Krakatoa MY Partitioning tool only affects newly born particles on their initial frame. The particles will then behave according to the fields set to affect them, and thus do whatever the settings require. They will have no knowledge of what happened to the same particle on previous iterations. If the jitter amount is selected small enough, the trajectory will be very similar, but different enough to produce a denser cloud with the same shape when combining them all.
When the particles have no Initial State but a Seed parameter, we just modify that. If you create multiple wedges with different seeds in Maya, you will get about the same general look, with the actual particles emitted at different locations. If you prefer not to use the Seed, or there is an Initial State involved, you can elect to jitter either the initial position, the initial velocity, or both. In many cases, this approach might produce variations that are much more similar because they use the same base setup and only a minute offset at Age 0.
As mentioned, we also have a completely different approach to particle multiplication which we call Repopulation. It creates new particles within a given range of influence for each particle and distributes the particle data like Color, Density etc. to the new particles to represent the old ones. It works pretty well for fluids, and with the latest changes for other kinds of particle clouds that did not work that well in the initial release.
Funnily enough, Maya users complained that nMesh vertices appeared as particles in Krakatoa, and we removed them explicitly. We should probably add them as an option. Right now regular vertices of geometry objects are not accepted as particles, although in the Max version of Krakatoa they are supported. In most cases, the density of vertex clouds is not high enough for Krakatoa rendering, but if there is interest, we should probably support that in Maya, too.
We will be exploring this in the future, but I cannot comment on the actual implementation because it has not been done yet. We have some serious experience with advecting particles through velocity fields from all kinds of sources (see our Stoke MX project), so we hope to find good ways to simplify the life of Maya users in the future.
OK, I think I understand the nature of how Krakatoa works now, except maybe the finer details and functionality of partitions (other than just as replicates). If, as you mentioned, the motion of repopulated particles works well enough for fluids, then that’s good enough for any usage scenarios that would appear on my desk.
Yeah, I can see how having nMesh vertices appear as particles could be an issue if you didn’t actually want them. It was mostly of interest if Krakatoa did, in fact, use Maya’s dynamic forces, and thereby eliminating the steps of generating those mesh-born particles via Maya altogether. No biggie, I get that doing the principle particle emission in Maya, then repopulating a thousandfold of the original particles, while only having a fraction of the render-time is the real boon.
Just checked out your Stroke MX… Now that is kind of what I was envisioning in the first place!! Sigh, Max only… guess I need to rethink this year’s software budget.