max 2011 krakatoa 1.5.2.42948
*edit tried on latest Beta 10 RC1 and still got the bug
i did not even know that its possible to interpolate the in between frames, thats very very awesome if there was not that one little bug for me, it seems when the current re-timed frame passes the ,5 mark there is a little spike happening, i dont know whats going on there exactly but you can see what i mean on this video:
on the parts where the particles are slowed down a lot you see the little spikes
so for example the re-timed frames are fine from 44,35=> 44,42 => 44,49 but from 44,49 => 44,56 the spike happens 44,56 => 44,63 … is fine again, any idea why this happens ?
The retiming works by linearly extrapolating positions based on the saved position of the closest full frame and its velocity.
So for example if you have frame 0001 with Position P1 and Velocity V1, then a sub-frames before frame 0001.5 will extrapolate positions by adding a fraction of the V1 to P1. The moment the time to extrapolate at passes the half-frame distance between the two existing samples, the positions will switch to extrapolating from P2 and V2 taken from frame 0002. At that point, you are bound to get a slight difference (a jump in position) because P1+V10.5 does not necessarily produce the same as P2-V10.5, especially if the particle is not moving linearly and at constant speed.
I am not 100% sure the effect you are seeing is caused by the above mechanism, but that’s the first thing to keep in mind.
Also be sure to check out this thread and the included illustrations and script - it shows how to save a sub-sampled PRT sequence (basically saving multiple PRT files per frame interval to be able to produce much finer retiming): viewtopic.php?f=22&t=3879
ye i am sure the effect i am seeing is caused by the mechanism you described, also i had a look at the thread, i used the script trying to retime a particle flow simulation driven by fume velocity, that seemed not to work properly, i think it would be really cool to have another option for retiming that requires the ID channel and then blends based on the particle position and velocity of the previous and next frame, so you had 2 positions and 2 velocitys to interpolate and for particles that are deleted in the next frame just using the old method so you would not see that jump for them anyway, do you think that could work ?
What is the render-time integration step of your PFlow? It might be worth it setting it to the same step the script was set to, e.g. 1/4 frame if using a step of 4. If that does not work either, then it is Fume’s fault
Using both frames would require reading two PRT files and also valid IDs as you mentioned. Not sure that’s optimal, but we will discuss it.
Ouch!
In the other thread, we had discussed the possibility of saving the interpolation data with the PRT file, so it would cause a hit once at saving time but not at loading time. Thinking about it some more, it could be prototyped using some scripting and KCM love. Will play with the idea and will let you know how it goes…
