Motion blur different when rendering velocity render element

Discussion and Support of Krakatoa Volumetric Particle Rendering, Manipulation and Management Toolkit
Toon03
Posts: 4
Joined: Wed Jun 13, 2018 11:07 am

Motion blur different when rendering velocity render element

Postby Toon03 » Thu Jun 14, 2018 6:41 am

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.

User avatar
Bobo
Posts: 6128
Joined: Tue Nov 15, 2005 10:26 am
Location: Vancouver, Canada
Contact:

Re: Motion blur different when rendering velocity render element

Postby Bobo » Thu Jun 14, 2018 10:17 pm

What are you using to apply the motion blur in post?
Borislav "Bobo" Petrov
Product Specialist
Thinkbox Software Inc.

Toon03
Posts: 4
Joined: Wed Jun 13, 2018 11:07 am

Re: Motion blur different when rendering velocity render element

Postby Toon03 » Fri Jun 15, 2018 4:39 am

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.
Attachments
Test01.jpg
Test01.jpg (267.68 KiB) Viewed 205 times
Test02.jpg
Test02.jpg (982.8 KiB) Viewed 205 times

User avatar
Bobo
Posts: 6128
Joined: Tue Nov 15, 2005 10:26 am
Location: Vancouver, Canada
Contact:

Re: Motion blur different when rendering velocity render element

Postby Bobo » Fri Jun 15, 2018 12:37 pm

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:
kmx_velocity_renderelement_v001.png
kmx_velocity_renderelement_v001.png (218.79 KiB) Viewed 195 times


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:
kmx_velocity_renderelement_v002.png
kmx_velocity_renderelement_v002.png (231.18 KiB) Viewed 195 times


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...
kmx_velocity_renderelement_v003.png
kmx_velocity_renderelement_v003.png (199.12 KiB) Viewed 195 times


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.
kmx_velocity_renderelement_v004.png
kmx_velocity_renderelement_v004.png (237.21 KiB) Viewed 195 times

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).
Borislav "Bobo" Petrov
Product Specialist
Thinkbox Software Inc.

Toon03
Posts: 4
Joined: Wed Jun 13, 2018 11:07 am

Re: Motion blur different when rendering velocity render element

Postby Toon03 » Fri Jun 29, 2018 8:39 am

Wow!!! :D 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. :)

User avatar
Bobo
Posts: 6128
Joined: Tue Nov 15, 2005 10:26 am
Location: Vancouver, Canada
Contact:

Re: Motion blur different when rendering velocity render element

Postby Bobo » Sat Jun 30, 2018 12:56 am

Toon03 wrote: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. :)


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. ;)

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...
https://docs.thinkboxsoftware.com/produ ... era-motion
Borislav "Bobo" Petrov
Product Specialist
Thinkbox Software Inc.

Toon03
Posts: 4
Joined: Wed Jun 13, 2018 11:07 am

Re: Motion blur different when rendering velocity render element

Postby Toon03 » Sat Jul 07, 2018 6:10 am

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?

User avatar
Bobo
Posts: 6128
Joined: Tue Nov 15, 2005 10:26 am
Location: Vancouver, Canada
Contact:

Re: Motion blur different when rendering velocity render element

Postby Bobo » Sat Jul 07, 2018 11:59 pm

Toon03 wrote: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?



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:
kmx_velocity_custom_renderelement_v001.png
kmx_velocity_custom_renderelement_v001.png (287.72 KiB) Viewed 46 times


- 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:
kmx_velocity_custom_renderelement_v002.png
kmx_velocity_custom_renderelement_v002.png (279.71 KiB) Viewed 42 times
Borislav "Bobo" Petrov
Product Specialist
Thinkbox Software Inc.


Return to “Thinkbox Software - Krakatoa for 3ds Max”

Who is online

Users browsing this forum: No registered users and 4 guests