Poke through issues in Octane renders?

Forums: Poke through issues in Octane renders?
DAZ Studio Integrated Plugin (Integrated Plugin maintained by OTOY)

Moderator: BK

Forum rules
Please keep character renders sensibly modest, please do not post sexually explicit scenes of characters.

Re: Poke through issues in Octane renders?

Postby t_3 » Thu Apr 04, 2013 11:04 pm

t_3 Thu Apr 04, 2013 11:04 pm
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...
The obvious is that which is never seen until someone expresses it simply

1x i7 2600K @5.0 (Asrock Z77), 16GB, 2x Asus GTX Titan 6GB @1200/3100/6200
2x i7 2600K @4.5 (P8Z68 -V P), 12GB, 1x EVGA GTX 580 3GB @0900/2200/4400
User avatar
t_3
 
Posts: 2871
Joined: Tue Jul 05, 2011 5:37 pm

Re: Poke through issues in Octane renders?

Postby SimonJM » Thu Apr 04, 2013 11:36 pm

SimonJM Thu Apr 04, 2013 11:36 pm
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.
SimonJM
Licensed Customer
Licensed Customer
 
Posts: 198
Joined: Tue Mar 19, 2013 12:28 am

Re: Poke through issues in Octane renders?

Postby linvanchene » Fri Apr 05, 2013 12:41 am

linvanchene Fri Apr 05, 2013 12:41 am
edited and removed by user
Last edited by linvanchene on Sat Sep 06, 2014 11:47 pm, edited 2 times in total.
User avatar
linvanchene
Licensed Customer
Licensed Customer
 
Posts: 783
Joined: Mon Mar 25, 2013 10:58 pm
Location: Switzerland

Re: Poke through issues in Octane renders?

Postby t_3 » Fri Apr 05, 2013 12:59 am

t_3 Fri Apr 05, 2013 12:59 am
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...
The obvious is that which is never seen until someone expresses it simply

1x i7 2600K @5.0 (Asrock Z77), 16GB, 2x Asus GTX Titan 6GB @1200/3100/6200
2x i7 2600K @4.5 (P8Z68 -V P), 12GB, 1x EVGA GTX 580 3GB @0900/2200/4400
User avatar
t_3
 
Posts: 2871
Joined: Tue Jul 05, 2011 5:37 pm
Previous

Return to DAZ Studio


Who is online

Users browsing this forum: No registered users and 6 guests

Thu Mar 28, 2024 10:23 am [ UTC ]