Octane 1.5 features revealed!

[FrankPooleFloating]

Okay, I just did a quicky test.. DOF does indeed affect M/s of render... but very little. I never even thought it affected render time because the difference is so negligible - from what I can tell. It does add a little more noise, if you have specular and glossy is pretty shiny.. but still...

So do we have an idea of how much render time it is going to add? If it is going to take twice or three times as long to render MB, dudes will want to know. I just don't remember this coming up before.. and I am the bloke that started The Wishing Well...

[TBFX]

Okay, I just did a quicky test.. DOF does indeed affect M/s of render... but very little. I never even thought it affected render time because the difference is so negligible - from what I can tell. It does add a little more noise, if you have specular and glossy is pretty shiny.. but still...

So do we have an idea of how much render time it is going to add? If it is going to take twice or three times as long to render MB, dudes will want to know. I just don't remember this coming up before.. and I am the bloke that started The Wishing Well...

Just like DOF it won't be a consistent speed hit and will depend on how much blur, transparency and specular is in the final frame. I have been using multi sub frame renders in Octane for Maya recently and averaging them to get MB (JimStar has just added a coded feature to the Maya plugin to do this which is awesome!) and so far I have gotten away with just dropping the Max samples per sub frame by the same factor as the number of frames I am going to average. In theory that would mean an integrated MB algorithm would give me the same result with no extra render time as compared with a still frame, though in reality there would probably be a slight hit just to sample through time and update geo etc. Also there will definitely be cases where you will need to up the max samples to get an acceptable result.

In an animation you can usually live with a little more noise in MB than DOF though as by it's very nature MB is most often in a different position every frame but DOF often just sits there and sizzles.

T.

[JimStar]

I've just measured it in Maya with stopwatch in hands:
So, the test scene is 57'775 tris, rendering 10 frames of animation (light moving in the scene), 10 subframes motion blur. As only the light source is moving in this scene, only this object is set as "Movable proxy", so only this object is reloaded by Maya plugin every frame, all others objects are loaded in the first frame only.
So, the results are:

- Animation without Motion blur enabled - 3:20 min for 10 frames animation.

- Animation with Motion blur enabled - 5:25 min for 10 frames animation.

So, it depends on exact scene settings, but anyway - the dependency is not linear. So for example for 10 subframes motion blur of 10 frames it is not 10 times slower, but less than just 1.64 times...
And the rendering itself it not longer at all - as each subframe renders the "samples per pixel" value divided by number of subframes. So, the resulting image's "samples per pixel" is the same as in "non motion blured" animation...

[FrankPooleFloating]

Thanks Jim

To be clear though, is your sample using an actual dev branch of Octane?... and not some fancy gizmo you came up with for the Maya plug (you are the Maya dev, right?) that kind of fakes MB or something? I am very curious if this is real Octane MB we are seeing - because this would be the first sample I am aware of.

Edit: Sorry, I just re-read TBFX's post again above.. it is a fancy gizmo.. oops. I was actually hoping that wasn't an Octane mo-blur... My guess (and hope) is that the Octane mo-blur is going to be silky smooth...

[JimStar]

Edit: Sorry, I just re-read TBFX's post again above.. it is a fancy gizmo.. oops. I was actually hoping that wasn't an Octane mo-blur... My guess (and hope) is that the Octane mo-blur is going to be silky smooth...

Here is your "silky smooth". Just depends on the motion blur settings in Maya. I've set the very simple variant for above posted testing, not even using the ability to set it differently for different frames and cameras...

[FrankPooleFloating]

Um, okay. Thanks again Jim.

So real Octane MB will be... huh?.. never mind... We will see some day, I have no doubt...

[matej]

So real Octane MB will be... huh?.. never mind... We will see some day, I have no doubt...

I've done a test in Cycles. The added render time (overhead) by enabling motion blur is:

* 0.6% for the highest shutter speed (ie. no noticeable motion blur)
* 15% for the slowest shutter speed (max. blurriness)
* 10% for a mid setting

This still doesn't tell you anything about Octane, but I expect equal or less overhead, or else...

Then you have to add the probable increase of samples because of additional noise.


I have another question: is the planned API scripting language 100% decided to be Lua?

[FrankPooleFloating]

Jim, sorry to bug again.. Is there anything you can pass on to Juanjo, so he can get similar MB in LW?.. Or perhaps he is a competitor of sorts - and that would be a conflict of interests. I am just thinking that if Octane mb is another year or more out, any mb is better than none. And for all we know, your mb (sorry I called it a fancy gizmo - I'm sure it is fantastic) is exactly as good as Octane MB is ever going to be... please advise.

[stratified]

So real Octane MB will be... huh?.. never mind... We will see some day, I have no doubt...

I've done a test in Cycles. The added render time (overhead) by enabling motion blur is:

* 0.6% for the highest shutter speed (ie. no noticeable motion blur)
* 15% for the slowest shutter speed (max. blurriness)
* 10% for a mid setting

This still doesn't tell you anything about Octane, but I expect equal or less overhead, or else...

Then you have to add the probable increase of samples because of additional noise.


I have another question: is the planned API scripting language 100% decided to be Lua?

Yes, the scripting language for the API will be Lua.

cheers,
Thomas

[JimStar]

So real Octane MB will be... huh?.. never mind... We will see some day, I have no doubt...

I've done a test in Cycles. The added render time (overhead) by enabling motion blur is:

* 0.6% for the highest shutter speed (ie. no noticeable motion blur)
* 15% for the slowest shutter speed (max. blurriness)
* 10% for a mid setting

This still doesn't tell you anything about Octane, but I expect equal or less overhead, or else...

Then you have to add the probable increase of samples because of additional noise.[/b]

Not so sweet, as it seems here.

It is not enough to just write "15% overhead" without other important details. You have not mentioned, that such a small overhead in Cycles is the consequence of limited motion blur in Cycles - in comparison to Maya plugin's full geometry motion blur, Cycles can not blur the geometry (mesh deformation motion blur), and just blurs only the changed transforms of objects. So, in this case there is no need for Cycles to rebuild the geometry's BVH and the speed of such a "MB" is higher, but no geometry shape changed between frames is blured at all. So, sure you can blur most scenes which have some transformed but not deformed shapes, but any blured animation of complex changable between frames mesh-shape is impossible in Cycles. This is the biggest reason of differences in overhead here, not that "Cycles does it better". If you need to rebuild the BVH for geometry between subframes (as Maya plugin now does), you get the true full MB, but you spend some more time to get each next delta. Perhaps I will just add later this additional setting - to just reload the transforms only, without the mesh geometry, it will speedup MB if the mesh-shape itself is not deformed between frames...

So, yes, using such a simplified approach Cycles can do it with such an overhead: just checked it on THIS scene taken from Blender motion blur WIKI and got 18% overhead with Shutter = 1.0 value.