Why is 'Final' better than preview?

[rojharris]

Hi t_3,

Seems like a dumb question but I am finding that when I hit 'final' to do my final render, the scene gets significantly better than it was in the previews?
This is not necessarily a bad thing but it does mean I can't accurately preview materials etc as they change quite a bit at render time.
Just done this now (making sure render settings were on Path tracing) and went through and changed my characters skin material to glossy with low spec and high roughness to get a more
'real' feel, then when I was happy I hit 'final' and bam! The skin got much brighter...

Is this intentional or have I found a bug... Or is it just me? I've tried reloads and restarts etc. but it seems to happen quite often.

If necessary I can post some grabs but I'm out now until tomorrow.

Many thanks
Roger

[katura]

i believe, you can find an answer to that here:
http://render.otoy.com/forum/viewtopic. ... 49#p132549

"final" collapses them all into one single big mesh and can therefore lower render times, by 10,20% or even more. on the other hand most of the updates won't work any longer, or would need other ways to work, so this is also locked away. it will also keep the rendering from accidental changes.

the idea is to have quick updates as long as tweaking a scene, and faster speed to bake the final image. also animation rendering switches from multiple to one single mesh since updates will of course only happen once per frame at the start.

there is no difference regarding the used kernel or other settings, any optimization which is possible by tweaking kernel settings will also add to the speed of "final" rendering.

there is actually one drawback, which i'm currently searching a solution for: octane doesn't recalculate the emission power if a emitter object is scaled internally. (by these geometry nodes). this will let the emission get brighter/darker, if the mesh is recombined, and the triangles are sent to octane already scaled down or up. imo octane should take care about that, but i hope i can find a workaround myself...

[rojharris]

Ah yes, Its the emitter problem that's causing the brightness changes.

Thanks For that. I'll be sure to test in final mode from now on.

[t_3]

update regarding the emitter power in "standard" vs. "final" rendering:

this problem is also solved - very straight forward:

geometry scaling is no longer applied using octanes' geometry nodes, but is directly included in mesh building. thus the mesh scale is no longer different between these two modes.
position and rotation changes* on the other hand will still use fast updates, which don't require additional mesh building. this will of course not need any user interaction.

since the relation between scaled surfaces (or even material zones on a surface) and emitter materials is not fixed (means you can use one emitter material for multiple objects, having different scales applied) even an already complex surface area calculation to normalize the emitter power would not have been sufficient, so i couldn't go that route.

the drawback of the current (final) solution is, that scaling something will result in mesh rebuilds (for that single object only, and only in standard rendering mode of course). since changing the scale of a particular scene object usually happens not all to often while working on a scene, and i.e. bone mesh changes require figure/skeleton mesh rebuilds in any case, this is imo pretty negligible.

much more important is, that emitter intensities are equal whatever render mode is used, also equal for animation rendering of course, and still the same if exporting to the standalone

ps: if this is at some point done by octane itself, it will be no problem at all to include scaling into fast updates again.

*) note about fast pos/rot/scale updates in the current version: while implementing this fix, i found out that these fast updates are broken since one of the last updates. you may have noticed, that positioning/rotating/scaling props will need rebuilds to update them correctly. this is of course also fixed...