So I am playing with the Geometry Particle feature in hopes of overcoming some of pflow’s animated geometry instance drawbacks.
First I have a supermeshed crab who’s walk cycle is 30 frames. The IN/OUt range types are set to loop so they keep walking (lol although forward and not sideways like most crabs walk ) I have a pFlow system that controls the walk cycle playback speed with the vector length and the crabs have varying scales.
So how can I control the playback speed as not all of the crabs travel at the same speed? I am guessing this is what the GeomTime channel is for? Is this channel a vector length? or what is it? How do you control it?
How does Radius relate with Pflow particle scale? I get a “Radius” channel found but I have no idea what the data is or where it is coming from other than it is being interpreted as huge! So same thing here? Where is this data coming from the particle system or the object? Can I overwrite it with particle system data?
First, the GeomTime is a Float channel. It specifies the FRAME to be played, either absolute or relative.
Here is how it works: By default, the Frost Custom Geometry timing is set to “Use Current Time”. This means that on each frame, the current time is used to determine what frame to load the geometry from.
When you switch the option to “Use Time 0”, all particles will stop advancing their animation with the current time and display their static geometry from frame 0.
Now if you enable the GeomTime channel, if the “Use Time 0” is active, the GeomTime specifies the ABSOLUTE time to be played. In other words, if you specify that channel via a KCM, you can tell each particle what frame to show, either a static offset (if the value is the same on all frames), or an animation (if the value is changing over time). For example, if you save the Age and LifeSpan of a particle, you could divide the Age by LifeSpan in a KCM to normalize between 0 and 1, multiply by the number of frames the animation takes and you will have your animated geometry synchronized to the life of the particle.
If “Use Current Time” is selected, you can use the GeomTime channel to ADD to the current time value - if you add a constant value per particle, you can get an offset of the animation but all animations will advance with the same constant speed of 1 frame per frame. If you add a changing value, you can speed up or slow down the animation.
In all cases, just like with Krakatoa and KCMs, you are operating HISTORY-INDEPENDENT, unless the GeomTime channel was produced through history-dependent calculations in the PFlow itself. For example, if you know the world units per frame speed of your crab, you could accumulate the velocity vector’s length per frame in a Float channel in PFlow to figure out how far it has traveled. You could save that Float channel to a PRT file sequence, then in the PRT Loader convert the Float Channel to GeomTime channel and define which frame of the animation to show as time progresses, with “Use Time 0” selected. So if your crab mesh is animated to crawl 1 foot per 30 frames, but your particle covered only half a foot in 30 frames, the GeomTime channel will contain values like 0.0,0.5,1.0,1.5,2.0…15.0 for the 30 frames and the shape animation will be running at half speed accordingly.
In the future, a dedicated PRT PFlow object might allow you to do this live by picking the PFlow, adding some KCMs to convert the data and then picking the PRT PFlow as the Frost particle source. RIght now, you have to go through PRT files…
The Radius of the PFlow particles is taken from the Size and Scale, divided by 2. For example, a Standard PFlow has a Shape set to Cube with Size 10.0 and Scale is not set (so it is 100%). Picking this flow will produce a Radius of 5.0 (which is the same as the default Frost radius, not by accident). If you change the Shape operator’s Size, the Frost particles will change. If you check “Scale” and enter 200% and variation of 100%, you will get particles between 100 and 300% or Radius between 5.0 and 15.0 units. This is a special case handling of the native PFlow channels because they don’t contain a channel called “Radius”.
When using SphereGizmos, the Radius property will affect the particles. When using PRT Loaders / PRT Volumes / PRT Fumes etc, you can add a KCM and specify your own Radius channel of type Float16 to provide explicit data.
This will be of course documented when the docs are done.
The Radius is a bit weird with Geometry meshing – it’s treated as a scale instead of a radius.
If you want to get the original size of the object, you need to set Radius = 1 in the Frost controls, or set Size = 2.0, Scale = 100% in Particle Flow.
I have to wait until I get home tonight test all this out, very helpful.
As for the latter question, the thing I have to check is the Scale, I need to see what the true scale of the original animated crab was before I SuperMeshed it (I know that I didn’t scale the SuperMesher). Something may be wonky.
Currently, I have a Shape Instance Operator in the flow with a size of 10.0 and a Scale of 100% with 50% variation maybe this should be a standard Shape Op instead? Seems to make some sense, for previewing the flow itself it doesn’t but for using it with Frost it does.
As of now when I enable the Radius channel the Frost crabs are more like 1000%, so they aren’t matching the size/scale of the pflow system, hence the question. I will double check some things and get back.
PRT PFlow would be absolutely epic, all the custom data you could generate via Box#3 or script, gees, Darcy! How many steak cheeseburgers would that cost
Yeah, I’d use a standard Shape Op. Unfortunately you won’t be able to get them to match using a Shape Instance operator. (I don’t really like how the radius works for custom geometry but I can’t think of anything better.)
Well Can get the PRT Loader version to work as expected For obvious reasons stated above the Pflow version will not directly work without writing Radius (scale average) and Age data to a PRT seq.
IMO the main thing right now is that it works! Adding shapes to cached PRTs is something I have been in a battle (if not war) with since a voxel type animation project months ago.
Being a little faster is just a bonus. I have a couple more things I need to try, for one SuperMesher is single threaded so that maybe a possible bottleneck, I’ll test it with a multi threaded animated shape, simply because I did notice that the TaskMan 3dsmax.exe process was behaving more like it was single threaded
thanks, the collision avoidance is pretty weak especially when going greater than 20 or so crabs (it works well with less), I have a 1000 crabs too, it looks pretty crazy, I didn’t have enough time to create a preview last night, I will post it later.
Do you have Box#3? We’ve been caching out the variables for the Shape Control suboperators in PRT’s, and it works great. We use it for molecular and cellular animations where each particle gets a completely unique shape. In your example, you could have some of the crabs be missing a random leg, some with various growths on their backs, etc.
Based on how the Shape Control works, something similar might be possible in a future version of Frost.
Keep in mind you can control which shape from the “Custom Geometry” list is used on which particle using a ShapeIndex Integer channel. Pick a bunch of crab animated objects in the list, then switch Cycle Shapes to “Use ShapeIndex Channel”. You could write to the Script Integer channel in Box #3 and convert to ShapeIndex in a KCM… Alternatively, you could change the index of particles as they move between events to switch shapes in Frost. For example, a crab hits a wall and breaks a leg, you send it to a new Event and change its Integer from 1 to 2, then in Frost the shape will switch from 1 to 2 and the model will be replaced… Just like in PFlow, just in Post.
hah, that is sweet as frosting! Will definitely try that.
Straying a bit off topic here:
So I had to try this voxelization thing real quick, it works super, well epic in fact Although it did seem like there was a memory leak (I can send you the file if you like) the process was up to 4.5 gigs after messing around with it for a little bit, I restarted max opend the file made a preview and it hung right around 900mb, so something strange was happening. For all I know it could have had something to do with Krakatoa too.
Also I had to use a Custom Geometry instead of box, there was some strange behaviour in relation to the matrial ID’s, I was unable to grab the matID I setup in a KCM on the PRT Volume using the ID from MtlIndex Channel. Here is the error thrown
ERR: BuildMesh: trimesh3.add_face_channel: Tried to add face channel "MaterialID", with data type uint16. This could not be done, because the face channel already exists with data type int32.
Thanks! The problem with Box geometry should be fixed in the newest build.
I looked at your scene for resource leaks. I didn’t see an increase to anything like 4.5 GB, but I did see an increase on the order of tens of MB. I’ll look into this further.
) I have a pFlow system that controls the walk cycle playback speed with the vector length and the crabs have varying scales.
Although it did seem like there was a memory leak (I can send you the file if you like) the process was up to 4.5 gigs after messing around with it for a little bit, I restarted max opend the file made a preview and it hung right around 900mb, so something strange was happening. For all I know it could have had something to do with Krakatoa too.
