AWS Thinkbox Discussion Forums

Motion blur different when rendering velocity render element

Krakatoa for 3ds Max
#1

Hello everyone,

I have a PRT cache of one frame with a velocity channel. I render this normally using motion blur. But I want to try to render with using render element and do the motion blur afterwards. I tested this yesterday and it looks pretty good but the directions of the motion blur is different when rendering direct in 3D. I was wondering if there is a solution to fix this? For example in one part of the image the motion blur when rendered in 3D goes from right bottom to left top. But when rendered with render element it goes from right top to left bottom.

By the way I also render using clipping planes. So a slice will be rendered. I hope someone can help me with this.

Thanks.

#2

What are you using to apply the motion blur in post?

#3

I use After Effects and tested this with RSMB. Maybe you know a better plugin to achieve this better? But I noticed in the velocity image also a direction difference. I attached two images. One image direct rendered in 3D and one with the velocity element image. In these images you see the difference in directions. I hope this makes it more clear.

#4

If you look at the Krakatoa Velocity RenderElement, you will notice that it has different options to store its data.
It always saves data in Camera space with R representing the X, G representing the Y, and B representing the Z (where -Z is along the camera viewing axis, and +Z is towards the viewer). But the value ranges are different depending on the Use Max Velocity checkbox’s state.

When the checkbox is unchecked, the values are stored As Is, in the range from -Infinity to +Infinity. So if a particle is moving with a Velocity magnitude of 100.0 per frame parallel to the X axis of the screen to the left, it will have an RGB value of [-100,0,0] stored in the image.

But if the checkbox is checked and the Max. Velocity is set to 100.0, the value will be [0.0,0.0,0.0], because 0.0 presents the normalized value of -1.0 moving at 100.0 units/frame to the left, 0.5 means 0.0, and 1.0 means Max velocity to the right! This makes sure that all RGB values are in the 0.0 to 1.0 range, with 0.5 representing no motion along that axis! If the colors were represented in the 0 to 255 range, then 127 would represent 0.0, this a mid-gray color of [127,127,127] means a stationary particle with no motion.

The difference between these two modes might explain why your post-production filter would show incorrect blurring direction - you will have to consult its documentation to figure out what input data it expects, and in what range. Does it use unclamped data in the range from -Infinity to +Infinity? Or does it expect normalized data in the range from 0.0 to 1.0 where 0.5 means no motion?

In the case of RSMB, it actually expects a 2D vector in screen space and in the 0.0 to 1.0 range in RG, and B equal to 0. I am not sure if a B > 0 would have a negative effect on it, but in the examples I saw, the motion data was more or less yellowish, meaning there were positive values for Red and Green, and nothing in the Blue channel. Thus a particle with no motion should have a value of [0.5,0.5,0.0].

In theory, if you enabled the Use Max Velocity checkbox in the Krakatoa Velocity Render Element, and entered the maximum possible velocity per frame in the Max. field to normalize by, then the resulting pass should blur correctly in RSMB. You could also multiply the B channel by 0 before using the pass just in case.

In the following example, I created a Geosphere, covered with a PRT Surface, dumped the Normal into Velocity, and multiplied it by 300.0 to produce 10.0 units of motion per frame.
In the following image, you can see the left VFB showing the unclamped motion, while the right one shows the Max. Velocity of 10.0 result:
[attachment=3]kmx_velocity_renderelement_v001.png[/attachment]

If we look at the actual pixel data, the unclamped pixels that appear to be blue on the left side actually contain a negative value of almost -10.0 along the X, but Max VFB has no idea how to draw that, so it clamps it to 0:
[attachment=2]kmx_velocity_renderelement_v002.png[/attachment]

In the Max. Velocity pass though, that same pixel has a Red value of nearly 0.0 because that denotes full speed along -X. A pixel in the center of the image would have 0.5 for Red and Green, but 1.0 for Blue because it is moving full speed towards the camera…
[attachment=1]kmx_velocity_renderelement_v003.png[/attachment]

Here I disabled the Blue channel to display the clamped image that RSMB would expect as a 2D vector image in the 0.0 to 1.0 range for Red and Green.
[attachment=0]kmx_velocity_renderelement_v004.png[/attachment]
You can achieve this in post before using the image by multiplying the Blue channel by 0.0. Of course we assume that Red goes from 0.0 to 1.0 from left to right, and Green goes from 0.0 to 1.0 from bottom to top. If the filter expects the Green to move from top to bottom, we would have to invert the Green channel, but I would not expect that to ever be the case, because Camera space is generally Y up.

Knowing this, try to figure out whether RSMB is being confused by the Blue channel. Looking at the second picture you posted, it appears that you used the Max. Velocity checkbox, and any yellow streaks you see are supposed to be moving to the upper right corner (lots of red, lots of green).

#5

Wow!!! :smiley: You are a live saver! Thank you so much for your great explanation. It really works. Yes, I just needed to test it more. I see now that 10 units works great for me.

I only have a follow up question. Now I have a camera animation but I want to exclude the camera motion blur from the velocity pass. Is that possible if yes how can I do this? Thank you again for all the help. :slight_smile:

#6

The Krakatoa Velocity Render Element outputs the particle’s Velocity channel as read from the particle. It does not know anything about the camera’s motion, and thus would not include the camera motion blur anyway (I just tried just to be sure and the camera motion has no effect on the render element).

So the question would be rather “I have a moving camera, how the heck do I include its motion in the Render Element when I want it?” I am not sure what the answer is, but since you don’t want the camera motion included, you should be good. :wink:

Of course, when rendering with the Krakatoa’s native multi-pass motion blur, you get an option to control whether the camera produces blur or not. But that option has no effect on the Render Element…
docs.thinkboxsoftware.com/produ … era-motion

#7

Thank you again so much Bobo! I had a feeling that the camera motion blur has no effect.

But I was really wondering how the magma flow will look like if you do this using emmision. So make a seperate render for the velocity pass. Of course velocity input to emission output. But I want to recreate the option in render element to clamp it between 0 to 1 with 10 units. How would the magma flow look like with these settings?

#8

First of all, you would not be rendering Emission, you would be creating a Krakatoa CustomData RenderElement that also uses Magma, but draws solid points just like the Krakatoa Velocity.

Below is the Magma that matches exactly the Krakatoa Velocity RenderElement:
[attachment=1]kmx_velocity_custom_renderelement_v001.png[/attachment]

  • We take the Velocity channel, convert ToCamera space in Vector mode (as Velocity is a Vector with direction and magnitude that does not depend on where in space it is located - the default mode of ToCamera as “Point” which transforms Positions!)
  • We then divide it by the maximum velocity per frame, multiplied by the FramesPerSecond value (10*30 in this case) since the Velocity Magnitude is in units per second. To create an FPS node, just hit the ` key (or CTRL+SPACE) and type in “FPS”, then hit Enter.
  • The resulting vector is then clamped between -1.0 and +1.0 for all 3 components to remove any outliers where the Velocity magnitude might have been higher than the desired maximum. The ClampVector BLOP ships with Krakatoa and can be found under the BLOP category, Vectors sub-category.
  • We Add [1,1,1] to that vector whose components used to be in the range from -1.0 to +1.0 to shift it to the range from 0.0 to 2.0.
  • We then Divide by 2.0 to make the range the desired 0.0 to 1.0, with 0.0 being equivalent to full speed along the negative axis, 0.5 being no motion, and 1.0 being full speed along the positive axis.
  • The output goes to a RenderElement node which outputs the value to the render element image.

On top of the screenshot, you can see on the left the custom data element, and on the right the original Velocity Render Element. They are identical!

As discussed before, if you don’t care for Z axis motion, you can kill the 3rd component by multiplying it with 0:
[attachment=0]kmx_velocity_custom_renderelement_v002.png[/attachment]

#9

Thank you again so much Bobo for the explanation! I have tried it but it seems that the result is quite different from rendering with velocity element. I have done exactly like you said but the direction of the motion blur is way different. The first image is rendered with velocity element and the second with dataelement. I hope you can help me what I am doing wrong. By the way I didnt use your second setup: removing the z axis.

#10

I cannot help you without seeing the Magma setup you used to run the Custom Data Element. Please post a screenshot, or save the flow and upload the preset.

That is funny because the one thing your Custom Data Element output lacks is a Z component. So somehow you managed to remove the Z component, otherwise the second image looks to me to match the first image.

Privacy | Site terms | Cookie preferences