Being new to the beta team on Frost here is my 2 cents i already mailed to Paul Rondeau but forgot to post here.
I was using the krakatoa mesher at frantic and loved it, i missed zhu/bridson!!! ParticleMesh size by age is something i like and use a lot in PWrapper that i haven’t found int frost yet. its great so shrink or grow water dripplets etc. over time. Is that something that could be build in or are channels the way to achieve that?
What i like it the ability to use the particle geometry “as is”. That way it’s easy to cache it out like a MesherCompound but with more comfort. I use Supermesher usually. By teh same token, are there any plans to add a cache to Frost for the Mesh? XMesh maybe even?
Some of these are covered in the FAQ (on top of the forum).
*XMesh saving was available in the PRT Mesher but was removed from the UI of Frost because it would require the XMesh loader itself, which is pretty much a separate (potential) product. If the XMesh gets released some day, it would make sense to enable the direct caching of Frost to XMeshes.
*Particle size by Age is easily achievable using a KCM on the source system, assuming you are using a PRT Loader. To do the same with PFlow without caching to PRTs, you would have to use a Box #3 or wait for Krakatoa to add a PRT PFlow object to convert a PFlow to a PRT stream that supports KCMs. The alternative would be to allow KCMs on Frost itself, but my feeling is they should not operate on the particle streams but on the mesh channels.
In short, you would take a PRT Loader that has Age and LifeSpan values (or just Age), add a KCM to it, convert Age and LifeSpan to Floats, divide Age by LifeSpan, subtract from 1.0, output as Radius channel (float16[1]). In Frost, enable the Radius channel and you will get particles fading off in size over time. In the KCM, you can drop a Power operator to change the curvature and a Multiply operator to scale the result beyond 0.0-1.0 range. Or you can even introduce a Curve Operator to tweak the Radius over time with free-form curves! Good luck doing that in pWrapper
I just feel frost should be more independent from Krakatoa. People might want to mesh particles as true alternative to PWrapper due to lack of it’s support which is unfortunate but will surely drive people toward Frost me included. The what-if case no box3 and no Krakatoa can happen. I know how to do it with box3 and krakatoa, i just think other cases.
would it be hard to implement it in the fashion pwrapper has it? It has it very straight forward and does a great job!
This is on our wish list, but it won’t be in the first release.
I’ll need to think about the “radius from age” controls. (Thanks for the demonstration, Bobo! ) If it’s a beloved feature in pWrapper, then there may be a lot of demand for it…
An alternative would be a radio to chose between Scale and MXSFloat. So you could screw around with the radius using a Script Operator.
Even without the Script Operator, box#3, or a KCM, you can modify the scale of a particle based on it’s age with a Scale operator. Just sync to particle age, or just have relative scaling.
There are different schools of thought here I guess
Yes, the pwrapper implementation is simple and works if you want LINEAR falloff over time. The only reason why we wouldn’t want it in Frost is UI clutter I am coming from the Krakatoa side of things were we implemented a lot of features in the early days of the PRT Loader which we are now struggling to remove since they are so much more powerful when done on the stack with KCMs, like color display, copying of channels, culling particles etc.
Frost works with the FREE EVAL. version of Krakatoa. Buying Frost and not installing the Krakatoa Evaluation would be a waste of money, if you look at the things you could do with the two (e.g. Animation timing control of Instanced Geometry based on Selection or Maps or whatever; Shape Instance index control via dedicated channel; full Radius control and much more). I even think we should be shipping the Krakatoa installer with Frost. In fact Frost was originally intended as a component of Krakatoa itself, but it made more business sense as a stand-alone product. Feature-wise though, Krakatoa and Frost are two sides of the same pipeline IMHO. That’s why I feel reluctant to add simple features that are already possible with the available toolset, and orders of magnitude more powerful - what if I don’t want linear falloff?
On the other hand, it makes more business sense to cater to the lowest common denominator - the average Joe user who wants easy to use checkboxes and is happy with the pwrapper functionality, but not with the speed. So from that point of view, adding a simple scale up/down feature AND still allowing the advanced controls possible through KCMs makes sure that both hobbyists and pros can benefit from Frost.
So I see where you are coming from and I would be ok with it if Frost had a set of simple controls for changing radius by age. It is Paul’s call I guess
Let’s look at the example case though… Are we REALLY trying to make the particles shrink with age, or are we just trying to fake particles shrinking based on density, just without all the calculation needed to sample that? For that matter, maybe what we REALLY are doing is setting the mesh to so space filling in high density areas to reduce the need for density, and should have a “tighter” mesh on the low density particles. If that’s what the end result is, maybe Frost should be recording the spatial density to the level set and using that to assist in the surface fitting.
Shrinking by age sounds REALLY arbitrary, like a hack.
The easy checkbox for the “average joe” or let’s just call em worker bees is perfect for the tighter productions imo! There is the two extremes, you have 3 month and go through around 100 iterations of a shot for a movie or you crank out 20 shots in 3 weeks for a commercial or cinematic. Sometimes you just need to DO, not develop. I heared that from alot of artists(not TDs) e.g. from Blur about KCM and Box#3 in general, places where schedules are super tight: “That’s all nice and cool to have that much options and control but i just need to get it done ASAP.” Therefore a “hack” is an great option i think.
I am with anselm about wanting this option. It would be nice to have as curve for changing/controlling radius. Also would like to see feature to stretch mesh over age?
But so far I tested, it’s very very fastest than pwrapper. It took me like 15 mins to generate pwrapper mesh wherease with frost it was just a min and less.
my first impression is allso very good i love the Radius channel and Zhu/Bridson and its options,
also for me the biggest advantage over pwrapper is that, as far as i tested for now, frost creates very consisten meshes for particles that already settled in the animation and do not move any more
also like the others i think it would be great to have options to affect the mesh based on the velocity of the particles
I like option B. It solves most issues I had with the “simple checkbox” approach (allowing for non-linear or custom curve-based falloffs) which still keeping it very simple to the end user (Ansi would approve, I hope).
As for the stretching, yes, they are all asking for non-uniform scaling along the velocity vector for a cheap simulation of motion blur (e.g. rain streaks using simpler geometry) where the scale is proportional to the velocity but never less than 1.0. Some of the legacy pre-PFlow particle systems in Max had that option and it is quite useful.
Allowing for non-uniform scaling of Geometry Instances instead of uniform Radius via PRT channels would be very cool, too. Or at least allowing for the Radius to be applied non-uniformly (e.g. retaining two dimensions and applying the Radius channel only to the velocity axis). Note that PFlow has a ScaleXYZ Vector channel which is different from the Scale float channel. Might be worth supporting both (with an option to specify which one to use when using instanced geometry).
Yes, I meant to stretch by velocity (I was kinda misinterpreting by age) as mentioned by bobo and chad. It would be nice to stretch mesh for something like water explosion, burst, splash, emitting lava?
I realized my suggestion for an Age to Radius control (add “Sync by”) won’t work in general – it will only work if you’re using the radius control, but I’m sure people would want it to affect the radius channel too. So we’d either need to add a new “radius scale” parameter that affects both the radius control and radius channel, or just go with the simpler controls that Ansi suggested.
) If it’s a beloved feature in pWrapper, then there may be a lot of demand for it…
I am coming from the Krakatoa side of things were we implemented a lot of features in the early days of the PRT Loader which we are now struggling to remove since they are so much more powerful when done on the stack with KCMs, like color display, copying of channels, culling particles etc.