Hello,
Simple question: Pflow system with spin operator active and rolling doesn’t send it’s spin information into PRT Saved in Krakatoa, even if orientation channel, normal, tangent channels are set to be saved in prt file. When I load this file via prt loader to use it with frost mesher and I want my custom particles (or small planes) to be oriented along orientation vector to mimick the original pflow spin, nothing happens or particles dissapear. Only valid values are normal, texture coord, velocity and position. Most of them do not offer any good rotation effect.
Is there a way to apply some random spin to a PRT Loader via magma flow? To create a spin from scratch that would be usable within frost? Velocity isnt the best channel to rotate particles, because they can rotate abrubtly when particle changes direction. It is not suitable for small light pieces like paper debris and so on.
I forgot I can instance the rotation by adding noise rotation to an xform gizmo in a reference objects and turn on a random timing of animation in frost. This solves the problem faster than recreating orientation in KCM (if possible at all). Only thing I am not sure is: does xmeshing any animating custom object and instancing it by frost makes things faster? Does using vray instancing over animated custom geometry makes thing faster?
It depends on the animated mesh. For each instance, the mesh will need to be evaluated at a different time. If that stack evaluation of that frame takes longer than reading that data from disk, then XMesh would be faster. If the stack does not take several seconds to update (for example due to a heavy Turbosmooth or other type of subdivision modifier), then using an XMesh to trade off CPU for IO performance would be an overkill and likely slower.
When not using VRay instancing, one huge mesh is being created and rendered as a single entity. This eats a lot of memory, and can take a while to build. When using VRay Instancing, any shape that is reused between particles will be loaded only once, and instanced during rendering. This results in both faster preparation before rendering starts, and much less memory usage during rendering.
However, we recently discovered that the Random Offset option of Frost itself produces a unique time for each particle, thus causing every particle to create a whole new VRay Instance, and eat up memory as fast as custom geometry without VRay Instancing. The workaround there is to use the GeomTime Magma channel for controlling the time offset, and make sure it goes through a ToInt->ToFloat conversion to round it off and produce full frame offsets. The real solution would be to add a checkbox to Frost to “Generate Integer Frame Offsets”. It has been logged as a Wish already.
Spin in PFlow is not a channel. It is an operator that affects the Orientation. The Orientation saved by Krakatoa is not a Vector, but a Quaternion (an angle rotation around an arbitrary axis), so it has 4 components instead of 3. Thus, it does not show up in lists where Vectors are expected.
If I set up a Spin in PFlow and save a PRT sequence, I get an Orientation channel with 4 components that is changing over time according to the spin settings. If I then create a Frost from that PRT sequence, select Geometry mode and set it to “Use Orientation Channel” (which is a separate option next to “Use Vector Channel” in the list), my shapes match perfectly the spin of the PFlow without any extra magic required.
You CAN recreate an Orientation from Normal, Tangent and some cross products using Magma if you forgot to save the Orientation itself, but you don’t really need that.