Is it common that retiming a PRT Loader with (or without) interpolate Sub-Frames causes a pulsing effect for the retimed particles instead of a smooth movement? I’m curently trying to retime a Realflow particle file. Or is there some specific way to achieve smooth retimed animations?
I’m currently using 3dsmax 2017 with Krakatoa 2.5.2.
It shouldn’t cause a pulsing effect. There might be an issue with the velocity channel, or the way we’re handing the frame rate.
Would you be able to share two samples of your Realflow particle files? Two side-by-side frames that show the effect.
I’ve sent you a message with a link to part of the particle sequence.
Thank you. I was able to download the file. We’ll take a look.
Ok, we’re able to reproduce the issue on our end. Thank you for the sample files.
It is looking like this may be a bug in the way we do interpolation. If that’s the case, we’ll fix it on our end and let you know.
Thanks, I look forward to it. This would be a very useful alternative to retiming the sims in Realflow everytime.
One workaround you could use is to apply a constant scale to the “Velocity” channel using Magma.
But of course, we’ll be looking at fixing it on our end.
It is unclear to me what caused the issue, but the Velocities in your sample file seem to be significantly larger than they should be. I don’t know why this happened.
To use Krakatoa normally with these files, you can add a MagmaModifier on the particles, then create an “Output>Velocity” node. Attach it to a “Divide” node, and divide by 30.
You could resave the particles out to PRTs to fix the velocities, or just use them as-is.
Does that work on your end?
I’m revisiting this thread as a current project is giving me problems possibly related. I’m importing an rpc sequence simulated from Realflow into 3dsmax 2018 with Krakatoa and meshed with Frost. The particles are randomly rotating on some frames so I’m trying to apply your solution with Magma, but am not sure if I’m applying it correctly. Could you post an image of the setup for Magma to change the velocity?
Hi Lee,
This will be a bit (or quite) challenging. Here is why.
Two weeks ago, we received a report from a customer that our RPC handling is broken. It appears that we read channels incorrectly, resulting in data assigned to the wrong particles. The user was trying to assign Color gradient by Age, and once the particles were colorized, it became obvious the Age channel was not assigned correctly. We suspect this might be true for all channels, not just Age. But having a nicely interpolated Age would be very useful in your case, so that’s a no go.
In addition, around the same time, another customer asked us about interpolating Orientation of particles, and we realized it was not possible. Before I address this, some info on interpolation.
By default, a PRT Loader will load the Position and Velocity of the nearest sample, and perform LINEAR interpolation from that Position along the Velocity vector based on the current time. This results in a straight motion, and a jump whenever the next sample comes into play, as the Velocity vector and the reference Position change abruptly.
So the PRT Loader has the option to interpolate particles that have a valid ID channel. If the option is enabled, the PRT Loader will read TWO Positions on both sides of the current time, and two Velocities, and will perform cubic interpolation to produce a smooth curve.
In Krakatoa MX v2.4 we also added sub-frame interpolation of the Age, Normal, Color, TextureCoord and Density channels to avoid abrupt changes as you retime your particles without the need to massage anything with Magma: thinkboxsoftware.com/krakato … e-log.html
At some points in time, some of these interpolation options were broken, producing pulsating Density, backwards motion, or infinite Positions under certain circumstances. We believe to have fixed these issues.
However, a few channels that would be nice to have interpolated at sub-frames are currently not supported. Coming back to the rotation question, these channels include both Orientation, and Tangent.
The Orientation channel in 3ds Max PFlow, and by extension in Krakatoa MX, is a Quaternion value. While it would be nice to have it interpolated on sub-frames, it might not help you as I am not sure whether an RPC would contain a usable Quat value we could use. Assuming the RPC bug I mentioned in the beginning wasn’t an issue…
The alternative would be to produce a new Orientation Quat value in Magma using two axes of the particle’s Transformation Matrix. By default, Krakatoa assumes that Normal is the X axis, and Tangent is the Y axis (for example when saving a PRT from a PFlow simulation). So if both were interpolated, once could take the Normal, the Tangent, and the CrossProduct of the two and build a new Quat value from them to output as Orientation that would reproduce the original rotation of the particles.
But, as I mentioned earlier, even if you had a Tangent channel in an RPC (which you don’t, AFAIK), it is currently not being interpolated on sub-frames. Only the Normal is. So this approach would not work either in the current build.
We have logged bugs against these issues, and hope to
Until these bugs are fixed, I am afraid you won’t be able to perform smooth rotation of any Krakatoa/Frost particles. 
We are very sorry for the inconvenience 
Whew, I need to take a breath after that one 
Thanks for the full rundown. For this project, I’m perfectly happy with no rotation at all. I’ve simply set up Frost with an orientation divergence of 50 to give the particles some randomness. But even then, some frames were sporadically rotating, so I assume this is related to your explanation? Is there at least a way to keep the particles from rotating during a sequence but still maintain an initial random orientation? Maybe there’s a way to simulate the particles from Realflow out with the necessary channels/information ?
What is the Orientation channel in Frost based on?
If you select some vector channel like Velocity, Frost has to build a matrix using that vector as Z. It needs to figure out the two other axes orthogonal to the vector. So it takes the Vector Cross Product with the up vector [0,0,1] to produce the X, and then the result get crossed with the reference vector again to produce the Y. As the angle between the reference vector and the up vector changes, you might get some adjustments in the resulting matrix, and a Divergence on top of it could cause surprising results.
You can select “Specify Orientation” which ensures the same fixed base value for every particle. Then you can set the Divergence relative to that. As the particles move around, they will never change orientation. However, they won’t follow the Velocity either, so that behavior might be unwanted…
It’s already at Specify Orientation with x,y,z all at 0 and a Divergence of 50 with a Custom Geometry for the Particle Geometry.