OTOY Forums

linvanchene wrote:What is the negative side effect of using interactive update?
Nevertheless on some other occasions when playing with DS I noticed that switching on interactive update can cause the viewport to become very unresponsive.

To put it different:
When there is not much smoothing needed or when all the smoothing values are at default having "interactive update" switched on may not cause that much issues. But as soon as one has a scene in which one item for some reason needs more extreme smoothing there is the risk to make the viewport almost unresponsive with interactive update switched on.

the plan is:

• the plugin itself sets this to "on" as soon animation rendering starts, and back to the previous setting as soon animation rendering stops. this will make sure that every frame starts rendering after every smoothing (or collision?) iteration has stopped.
• it will be set the same way if you click "final" to "on" and back if final rendering ends.
• every other situation it will be left alone to let the user decide. doing normal work you may always do full or partial reloads (the rightmost viewport picker tool), to update the geometry if something isn't quite right.

so in the end, you will use it like you are used to (usualy having it off), but when it is important to have it on, because you can't just reload (whil animations or final renderings), the plugin will take care about the right setting.

i'm currently working on a few different things and fixes; managing this switch is also already implemented, but not finally tested. but most probably it will be in the next update - was aiming for today, might come tomorrow, in any case before the weekend...

A quick comment about collision - not sure how wholly accurate this is but, between the current release (4.5.1.56) and the previous release the default/usual settings for collision/smoothing have changed, with Smoothing Iterations for newer items being set to 2 (instead of 20). It is often quite acceptable to set this back down to 2 which will cut down a fair bit of work for the CPUs.

linvanchene wrote:On one occasion I noticed that the "Final" rendering finished faster than letting the viewport render finish. Which was unexpected because I assumed "Final" equals higher quality equals longer render time. Unless there are other optimizations going on when doing final renders? For example are precalculations automatically done to speed everything up?

Are there more obvious differences / advantages in the pathtracing or PMC kernels when using "Final" mode?

the speed is the key. normally the plugin creates masses of special geometry nodes (internally) which allow to update single objects in a scene only, either by building the geometry new, or even faster by only sending pos/rot/scale updates to octane.

this mode causes already a speed drop if only one single object is in a scene, because of the additional geometry handling, that happens inside octane. and it will cost more speed, the more objects there are.

"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...