Hi Guys,
Sorry if this question has been answered already, I didn’t find it here. Is there a way to render out a velocity pass? I’m in need of altering the speed of the element I’ve created and having a seperate velocity channel would help.
Thanks in advance,
Stephen Lebed
Visual Effects Supervisor
p.s. I hope I get a chance to meet you guys in person at Sig
Hi Guys,
Sorry if this question has
been answered already, I
didn’t find it here. Is there
a way to render out a velocity
pass? I’m in need of altering
the speed of the element I’ve
created and having a seperate
velocity channel would help.
Hi Stephen,
There is no built-in capability yet (we hope to add more advanced shading capability in future updates to allow you to visualize any channel you want from any source and even more).
Currently, it is potentially possible using PFlow and Beta 17/18, best with Box #3, but it could work with Scripted Operators, albeit slower.
Basically, you can dump the Velocity channel into any UV channel or even better the Vertex Colors channel. Then you can render in Krakatoa using a Vertex Color Map in the diffuse slot, or in Beta 18, shade the Vertex Color channel by enabling the No Material color override which is a lot faster. The result will be a velocity pass where the RGB colors represent world space vectors.
Not sure how that would help you alter the velocity of an already rendered element though - usually it is a better idea to rerender with the new speed. If you have saved to PRT files already, you can retime the sequence using the Playback Graph feature which now also scales velocity vectors and does subsampling too.
More info might be needed to fully answer your question…
“If you have saved to PRT files already, you can retime the sequence using the Playback Graph feature which now also scales velocity vectors and does subsampling too.”
Thanks for the reply. I didn’t realize that the prt files can be retimed. I see the Playback Graph[a] spinner, but what does the value represent? It’s defaulting to 0.0
Edit: Never Mind. I just realized that the [a] means animate (I’m guessing), meaning that I can animate the particle frame that is loaded against the current keyframe. Unless I’m completely wrong here 
Stephen Lebed
Visual Effects Supervisor
“If you have saved to PRT
files already, you can retime
the sequence using the
Playback Graph feature which
now also scales velocity
vectors and does subsampling
too.”
Thanks for the reply. I
didn’t realize that the prt
files can be retimed. I see
the Playback Graph[a] spinner,
but what does the value
represent? It’s defaulting to
0.0
Edit: Never Mind. I just
realized that the [a] means
animate (I’m guessing),
meaning that I can animate the
particle frame that is loaded
against the current keyframe.
Unless I’m completely wrong
here
Completely correct.
There are a few values that have [a] for Animatable - the Render %, the Modifier Gizmo Box Size and the Playback Graph.
The Playback Graph works just like in the PointCache modifier - you can define what frame of the PRT sequence will be played at a specific scene time. When set to 0, it shows frame zero on each frame. When animated from 0 to 100 over 100 frames it just plays straight. But you can use it to speed up, slow down, ping-pong, reverse, bullet-time (!) and so on your particles.
It uses floating point values, so you can request sub-frames - in that case, the closest full frame is taken and the particle positions and velocities are extrapolated smoothly. So if you play back a sequence twice as slow, each second frame will display extrapolated positions based on the closest frame. The velocities will also be half as long as your particles would be moving twice as slow.
Hope this helps.
Thx again. I can’t find where I would set subsampling. My tests are looking ‘steppy’ at the moment.
Stephen Lebed
Visual Effects Supervisor
Thx again. I can’t find where
I would set subsampling. My
tests are looking ‘steppy’ at
the moment.
Hmm, they shouldn’t look steppy since beta 17. The interpolation should happen automatically. Are you speeding up or slowing down?
I’m slowing down. I have a 240 frame sequence that I’ve keyframed from 0 to 30, with a 48 frame offset. (does this make any sense?)
I’m using build 0.9.18.2766 eval
Stephen Lebed
Visual Effects Supervisor
I’m slowing down. I have a
240 frame sequence that I’ve
keyframed from 0 to 30, with a
48 frame offset. (does this
make any sense?)
I’m using build 0.9.18.2766
eval
This means you are showing every 8th frame.
If you are using motion blur, the particle velocities should be scaled up to be 8 times longer because the particles are moving 8 times faster. But the positions will still be every 8th frame.
If you were scaling the other way, making 30 frames play back in 240 frames, Krakatoa would interpolate 7 intermediate positions by projecting the closest position and velocity vector, thus smoothing the motion (in Beta 16, it would have shown each position 8 times instead).
I am not sure if there is anything to fix choppiness when speeding up.
If you were scaling the other way, making 30 frames play back in 240 frames, Krakatoa would interpolate 7 intermediate positions by projecting the closest position and velocity vector, thus smoothing the motion (in Beta 16, it would have shown each position 8 times instead).
This is what I’m trying to do, but the result is each position 8 times. It doesn’t seem to be interpolating. Is there a subsamples button somewhere or is the interpolation supposed to be automatic?
Stephen Lebed
Visual Effects Supervisor
If you were scaling the other
way, making 30 frames play
back in 240 frames, Krakatoa
would interpolate 7
intermediate positions by
projecting the closest
position and velocity vector,
thus smoothing the motion (in
Beta 16, it would have shown
each position 8 times
instead).
This is what I’m trying to do,
but the result is each
position 8 times. It doesn’t
seem to be interpolating. Is
there a subsamples button
somewhere or is the
interpolation supposed to be
automatic?
So you have a 30 frame sequence you want to play for 240 frames… :o)
Yep, there is a bug here and I can see it - the particles are scaling the velocity correctly, but when interpolating the position, there is a significant jump in the position when the particle crosses the half frame. The position interpolation is wrong as far as I can see. Not that there is no interpolation (I can see them moving slowly), but the interpolated value is incorrect. Will pass it to the developer, should be fixed early next week.
Sorry for the inconvenience and thanks for catching the bug (that’s the goal of this forum, after all)
After a closer look, it seems that the interpolation incorrectly uses the already scaled velocity vector for determining the particle position. So the fix should be trivial.
For example, if you have a particle that moves 1000 units per frame and keyframe it to move 10 time slower, it should move 100 units per frame and its velocity magniture should also be reduced from 1000 units/frame to 100 units/frame. But the PRT Loader takes the already reduced 100 units/frame velocity and divides again by 10, resulting in 10 units/frame motion which is of course wrong.
“Sorry for the inconvenience and thanks for catching the bug (that’s the goal of this forum, after all)”
Cool, thats one for me! At least now I feel like I’m contributing to the cause…
Stephen Lebed
Visual Effects Supervisor