OctaneRender™ Standalone 2.16

Forums: OctaneRender™ Standalone 2.16
VIP Information, news and announcements regarding new Octane Render commercial products and releases.

OctaneRender™ Standalone 2.16

Postby abstrax » Tue Dec 23, 2014 10:29 am

abstrax Tue Dec 23, 2014 10:29 am
Hi all,

This the first stable release of the 2.1x development cycle. A lot of things have changed, so if you haven't followed the development please read the list of major changes since the last stable release. If you followed the development builds, please read the change log below the major changes.


Major Changes since Version 2.06:

Render Passes

Render passes are exposed via a new pin in the render target node which you can connect with a render passes node. In the render passes node you can then enable render passes you want to render. In the render view you can then select the pass you want to view, save them all out as separate images or as layered OpenEXR file. The animation render scripts also can be configured to save the frames as separate pass or layered OpenEXR images.

We distinguish between "beauty" and "info" passes. Beauty passes are rendered together with the main beauty pass (the normal rendering). I.e. each one of these requires its own film buffer that needs to be stored additionally to the main film buffer on the device. The info passes are rendered one by one using only one additional film buffer either at the end or when needed. We do this to save GPU memory and because they are fast to calculate.

Render Performance

We improved the sampling in the direct lighting and path tracing kernels. In most scenes this should reduce the number of samples to get to a similar noise level than in older version. And the sampling is now more optimized in a multi-GPU environment and in network rendering.

We also implemented a new path termination strategy controlled by the pin "Path term. power" and which is a bit tricky to explain: In the past the there was this ominous pin "RR probability" which in most cases only worked good when set to 0. With the new algorithm we try to provide a system where you can tweak samples/second vs. convergence (how fast noise vanishes). Increasing the value will cause the kernels to keep paths shorter and spend less time on dark areas (which means they stay noisy longer) but may increase samples/second a lot. Reducing the value will cause kernels to trace longer paths in average and spend more time on dark areas.

The direct lighting and path tracing kernels also have a new option "Coherent ratio". Increasing this value will increase the render speed but introduce low-frequency noise (aka "blotches") which may require minimum of a few hundred or even a couple thousand samples per pixel to go away. This is of course dependent on the scene and the selected coherent ratio.

Texture Changes

  • Added pins "hue", "saturation" and "contrast" to the color correction node to control hue, saturation and contrast of the input texture. Since Octane textures are sampled spectrally, hue and saturation don't work perfectly, but as long as you use them not too aggressively they should do the trick.
  • We had to remove the pins "brightness scale" and "black level" since we ran out of fields in our color correction shader node. The version conversion takes care of the "brightness scale" by multiplying it into the texture connected with "brightness", but "black level" is hard to convert automatically, so we don't do it. We had a look at the materials in the LiveDB and only 13 materials are affected by the loss of "black level" and in all cases its effect can be approximated by modifying "gamma".
  • Added new noise texture node which currently has 4 noise types: "Perlin", "Turbulence", "Circular" and "Chips". "Perlin" is like the turbulence node with "use turbulence" disabled. "Turbulence" is like the turbulence node with "use turbulence" enabled. "Circular" is a Worley noise and "Chips" is a Voronoi noise.
  • Added new texture node "polygon side" which renders white on the front face and black on the backface of a polygon. You can use this to do backface culling (by putting this texture into the opacity channel) or to allow double-sided materials (placing it into a mix material) and textures (placing it into a mix texture).

Other Rendering Changes

  • Added highlight compression option to camera imager node. Using this option, you can reduce burned out highlights by compressing them (which decreases their contrast). This works similar to the Reinhard tone mapping.
  • Added new option in the network settings dialog (enabled by default) which turns on automatic port configuration on the master. If enabled, multiple masters can be used on the same computer which wasn't possible before because only one master could use the specified socket.
  • Added option "static noise" to the direct lighting and the path tracing kernels, which is disabled by default. When enabled, the noise is static, i.e. doesn't change between frames. Well, currently it still changes a bit, because some parts are still using random sampling, but we will improve it in the future. For now, we want to bring back the possibility to have dynamic noise, i.e. noise that changes every frame.
  • Added full support of Maxwell 2 GPUs. This required us to switch to CUDA 6.5, which has some effect to render performance. Scenes can be slightly slower or faster than before, but it depends.
  • Added option "static noise" to the direct lighting and the path tracing kernels, which is disabled by default. When enabled, the noise is static, i.e. doesn't change between frames. Well, currently it still changes a bit, because some parts are still using random sampling, but we will improve it in the future.
  • Added new option "AO alpha shadows" to info channel kernel. If enabled, opacity is now taken into account in the AO calculation.
  • Added diffuse roughness which allows you to simulate very rough surfaces like sandpaper or clay. It works similar to Oren-Nayer.
  • Added option "Cast illumination" to emitter nodes. Disabling this option will disable emission, i.e. it won't be visible in diffuse reflections, but still be fully visible in specular reflections. It will also be excluded from the direct light calculation.
  • The emission sampling rate can now be set to 0, which means that the emitter will be excluded from the direct light calculation.
  • Added option "Surface brightness" to emitter nodes. Enabling this option will cause emitters to keep the surface brightness constant independent of the emitter surface area, i.e. the total emitted power will be dependent on the emitter surface area. The scaling is done in a way that a texture emitter will produce the same colour in the rendering (if the diffuse channel is black), when the camera response curve is set to "Linear/off", exposure to 1, gamma to 2.2 and vignette to 0. Disabling the option will keep the total emission power constant, i.e. the surface brightness will become dependent on the emitter surface area.
  • Removed the pins "Fstop" and "ISO" from the camera imager node, since they only control exposure which is done already by the exposure pin. The only thing these two pins added was confusion, since some people expected the ability to control the depth of field with Fstop. You can find a Lua script graph that emulates the old behaviour here: viewtopic.php?f=73&t=43944
  • Scaled exposure in the camera imager so that a texture environment produces the specified colour in the rendering, if the camera response curve is set to "Linear/off", exposure to 1, gamma to 2.2 and vignette to 0. The exposure of older scenes will be converted automatically.
  • Reduced the brightness of the daylight environment by a factor of 0.6 for the new daylight model and 0.8 for the old model. This way there is a better match between the texture environment and the daylight environment. Or in other words: Exteriors rendered with the default exposure settings are less overexposed than before. Older scenes will be converted automatically and should render the same.

Standalone UI

  • We added an undo system to OctaneRender Standalone. To undo the last change press CTRL-Z and to re-do the last "undone" change press CTRL-Y or CTRL-SHIFT-Z.
  • Improved node inspector by providing a compact view of uncollapsed node pins. Also changed the default expansion logic to reduce the clutter.
  • Switched to a current version of our UI toolkit and application framework. Versions up to 2.06 were using a toolkit version from 2009... The switch also allows use to use more modern UI features like support for high resolution displays.
  • Added application preference to switch between the native file chooser or the version of our UI toolkit (useful for Linux users that don't use Gnome).

Lua Script Graph

In short: A Lua script graph is a new node graph type that stores a script that gets executed at various points and which defines some inputs and outputs. Every time one of the inputs changes, the scripts gets re-evaluated can then do interesting things, like calculate new values or set up a totally new node graph inside the graph.

You can find more information about it in the Lua API browser under the module octane.scriptgraph, but it's best to check out the introduction from Roeland and the available examples in the Lua forum, like texture animation, old school exposure, EV compensation, cam calculator and a special gem the metal material script.

Statistics

To make informed decisions for future developments it's important to understand how Octane is used. So we added the ability to Octane to send some statistics to a server where we can analyze them. This functionality is enabled by default and can be disabled in the application preferences under File -> Preferences... -> Application -> Enable statistics.

The statistics we gather are anonymous and independent of the OctaneLive license server. For all people who are still skeptical, we added the ability to log what's going on via the log flag "stats". To enable the logging, please copy the attached a flags file
octane_log_flags.txt

into the directory where your OctaneRender Standalone is installed. After starting Octane it will log into a file "octane_log.txt", which will contain the messages Octane has sent during that session.

Again, feel free to disable the statistics, but since we will make future decisions based on those statistics, keeping them enabled will allow you to influence future developments at least a little bit.


Changes since version 2.15:

  • Reduced the brightness of the daylight environment by a factor of 0.6 for the new daylight model and 0.8 for the old model. This way there is a better match between the texture environment and the daylight environment. Or in other words: Exteriors rendered with the default exposure settings are less overexposed than before. Older scenes will be converted automatically and should render the same.
  • Changed the default turbidity of the daylight environment to 2.4 to reduce the contrast between the sun and sky light.
  • Improved object motion blur on objects with translation + rotation and only two key frames.
  • Fixed broken UV transform when texture nodes share the same projection node (see viewtopic.php?p=215810#p215810).
  • Fixed broken undo when different files were loaded via the mesh/image/scene/script graph node UI.
  • Fixed bug that caused slaves "to lose samples" (see viewtopic.php?p=215713#p215713).
  • Renamed distribution pin of the emission nodes back to "Distribution" since "Emission pattern" is causing too much confusion.
  • Fixed matte material which ignored the "shadow visibility" of object layer nodes (see viewtopic.php?p=209329#p209329).
  • Improved turntable and daylight animation to make them work with animated scenes.
  • Fixed refresh of OpenGL viewport when moved or resized.
  • Fixed deadlock when OpenGL viewport is maximized on Mac OSX.
  • Fixed broken undo of connections to node graph inputs.
  • Fixed 3 places, where the file chooser didn't remember the selected directory.
  • Fixed missing render update when a bump or normal texture is connected to a material via some linker node.
  • Fixed broken auto-focus if focal depth is set to 0.
  • Fixed importance sampling if environment texture is connected via linker nodes.

Downloads:

Due to the switch to CUDA 6.5 you will need a current graphics driver of version 344.x or higher. On Mac OSX you will need a CUDA driver of version 6.5 or higher (see http://www.nvidia.com/object/mac-driver-archive.html). The minimum supported version of Mac OS is 10.7.

Windows
- 32-bit commercial version (installer)
- 64-bit commercial version (installer)
- 32-bit commercial version (ZIP archive)
- 64-bit commercial version (ZIP archive)
- 32-bit demo version (installer)
- 64-bit demo version (installer)
- 32-bit demo version (ZIP archive)
- 64-bit demo version (ZIP archive)

Mac OS X
- 64-bit commercial version (DMG image)
- 64-bit demo version (DMG image)

Linux
- 64-bit commercial version (ZIP archive)
- 64-bit demo version (ZIP archive)

Happy rendering,
Your OTOY NZ Team
You do not have the required permissions to view the files attached to this post.
In theory there is no difference between theory and practice. In practice there is. - Yogi Berra
User avatar
abstrax
OctaneRender Team
OctaneRender Team
 
Posts: 5091
Joined: Tue May 18, 2010 11:01 am
Location: Auckland, New Zealand

Re: OctaneRender™ Standalone 2.16 [latest 2.1x]

Postby smicha » Tue Dec 23, 2014 10:46 am

smicha Tue Dec 23, 2014 10:46 am
Thank you.
Win7, Modo 10.1, Octane for Modo and Sketchup, nVidia latest, TITAN+3x780 6GB, 2600K, P8P67WS, 32GB, 1350W
SMH10, EK, Airplex_480, SR1_560, 20xNB_PL2, 2xD5, Aquaero 6XT
build-log http://render.otoy.com/forum/viewtopic.php?f=9&t=42540
User avatar
smicha
Licensed Customer
Licensed Customer
 
Posts: 3145
Joined: Wed Sep 21, 2011 4:13 pm
Location: Warsaw, Poland

Re: OctaneRender™ Standalone 2.16 [latest 2.1x]

Postby FrankPooleFloating » Tue Dec 23, 2014 10:57 am

FrankPooleFloating Tue Dec 23, 2014 10:57 am
Thanks M!

erm.. maybe Render Layer Passes as a stocking stuffer?.... before xmas?...

timbot_passes.jpg
You do not have the required permissions to view the files attached to this post.
Win10Pro || GA-X99-SOC-Champion || i7 5820k w/ H60 || 32GB DDR4 || 3x EVGA 980Ti Hybrid || EVGA Supernova G2 1300W || Tt Core X9 || ̶B̶l̶e̶n̶d̶e̶r̶ ̶P̶l̶u̶g̶ ̶|̶|̶ ̶L̶i̶g̶h̶t̶W̶a̶v̶e̶ ̶P̶l̶u̶g̶ || Blender E-Cycles
User avatar
FrankPooleFloating
Licensed Customer
Licensed Customer
 
Posts: 1654
Joined: Thu Nov 29, 2012 3:48 pm

Re: OctaneRender™ Standalone 2.16 [latest 2.1x]

Postby grimm » Tue Dec 23, 2014 11:18 am

grimm Tue Dec 23, 2014 11:18 am
Thanks Markus! :D

I'm still getting the OpenGL deadlock when I try to maximize the viewport. Also does this version fix the issue of the script nodes locking up Octane if you try to access the node graph from the oninit function?

Jason
Linux Mint 19 x64 | Nvidia GTX 980 4GB (displays) RTX 2070 8GB| Intel I7 5820K 3.8 Ghz | 32Gb Memory | Nvidia Driver 435.17
User avatar
grimm
Licensed Customer
Licensed Customer
 
Posts: 1144
Joined: Wed Jan 27, 2010 8:11 pm
Location: Spokane, Washington, USA

Re: OctaneRender™ Standalone 2.16 [latest 2.1x]

Postby abstrax » Tue Dec 23, 2014 11:25 am

abstrax Tue Dec 23, 2014 11:25 am
grimm wrote:Thanks Markus! :D

I'm still getting the OpenGL deadlock when I try to maximize the viewport.

True. If I remember correctly, we can currently fix it only on OSX, because the deadlock on Linux happens somewhere deep in the NVIDIA graphics driver. -> Fixed the release notes.

Also does this version fix the issue of the script nodes locking up Octane if you try to access the node graph from the oninit function?

Jason

I don't know. What exactly is the problem?
In theory there is no difference between theory and practice. In practice there is. - Yogi Berra
User avatar
abstrax
OctaneRender Team
OctaneRender Team
 
Posts: 5091
Joined: Tue May 18, 2010 11:01 am
Location: Auckland, New Zealand

Re: OctaneRender™ Standalone 2.16 [latest 2.1x]

Postby grimm » Tue Dec 23, 2014 11:41 am

grimm Tue Dec 23, 2014 11:41 am
No problem on the viewport, I just set it to software.

The other issue is from this thread: viewtopic.php?f=73&t=43842

As Thomas explained it to me, if you try to access the node graph or the project properties (in this case it was the number of frames per second) from the onInit function, Octane will lockup. It's because the script node tries to read and setup these values before they exist in the graph. It happens if you save the script node in the scene and then try to load it fresh into Octane. Currently I have all these lookups running in the onEvaluate function, it works but it's not ideal. Probably slows down the script a bit I think.

Jason
Linux Mint 19 x64 | Nvidia GTX 980 4GB (displays) RTX 2070 8GB| Intel I7 5820K 3.8 Ghz | 32Gb Memory | Nvidia Driver 435.17
User avatar
grimm
Licensed Customer
Licensed Customer
 
Posts: 1144
Joined: Wed Jan 27, 2010 8:11 pm
Location: Spokane, Washington, USA

Re: OctaneRender™ Standalone 2.16 [latest 2.1x]

Postby abstrax » Tue Dec 23, 2014 11:49 am

abstrax Tue Dec 23, 2014 11:49 am
grimm wrote:No problem on the viewport, I just set it to software.

The other issue is from this thread: viewtopic.php?f=73&t=43842

As Thomas explained it to me, if you try to access the node graph or the project properties (in this case it was the number of frames per second) from the onInit function, Octane will lockup. It's because the script node tries to read and setup these values before they exist in the graph. It happens if you save the script node in the scene and then try to load it fresh into Octane. Currently I have all these lookups running in the onEvaluate function, it works but it's not ideal. Probably slows down the script a bit I think.

Jason

I see. I don't think we made any changes in that area. So do these look ups during the evaluation. The speed difference is negligible. Lua script graphs are meant to be self-contained, like closures or pure functions. Accessing anything outside of the script graph is always potentially dangerous.
In theory there is no difference between theory and practice. In practice there is. - Yogi Berra
User avatar
abstrax
OctaneRender Team
OctaneRender Team
 
Posts: 5091
Joined: Tue May 18, 2010 11:01 am
Location: Auckland, New Zealand

Re: OctaneRender™ Standalone 2.16 [latest 2.1x]

Postby grimm » Tue Dec 23, 2014 11:55 am

grimm Tue Dec 23, 2014 11:55 am
Cool, I will keep doing what I have been doing. Thanks Markus. :)
Linux Mint 19 x64 | Nvidia GTX 980 4GB (displays) RTX 2070 8GB| Intel I7 5820K 3.8 Ghz | 32Gb Memory | Nvidia Driver 435.17
User avatar
grimm
Licensed Customer
Licensed Customer
 
Posts: 1144
Joined: Wed Jan 27, 2010 8:11 pm
Location: Spokane, Washington, USA

Re: OctaneRender™ Standalone 2.16 [latest 2.1x]

Postby aLeXXtoR » Tue Dec 23, 2014 12:47 pm

aLeXXtoR Tue Dec 23, 2014 12:47 pm
Thanks! Guys, can you please return back the "Aperture" pin to the Alembic node (among "camera inputs") to make aperture value adjustment possible inside the Standalone? It is very handy for the scene final setup.
Win 10 Pro 64bit | GeForce GTX 1660 Ti | AMD Ryzen 7 3700X | 32GB RAM
WebSite
Showreel
User avatar
aLeXXtoR
Licensed Customer
Licensed Customer
 
Posts: 273
Joined: Sat Oct 29, 2011 5:38 pm
Location: Russia, St. Ptetersburg

Re: OctaneRender™ Standalone 2.16 [latest 2.1x]

Postby shawnfrueh » Tue Dec 23, 2014 9:07 pm

shawnfrueh Tue Dec 23, 2014 9:07 pm
Reduced the brightness of the daylight environment by a factor of 0.6 for the new daylight model and 0.8 for the old model. This way there is a better match between the texture environment and the daylight environment.


I think this is a bad idea especially when "Should" is used, in a studio's perspective.

We ran into this problem back when the C4D plugin was starting to get developed where moving an old scene to the latest Octane version would require frame blending between the old frames and the new ones due to one being "Brighter" or "Darker" than the other. Sometimes the difference would be to much and the shot would need to be completely re-rendered.

I Would like to suggest that values stay at their first released state. This way if a client comes back in 6 months for a small change we can be confident that the newly rendered frames will match the original frames and not have to deal with any sort of post correction.

Edit: Even though older scenes will be updated, I do not believe the plugin side of things work as such. I have asked Aoktar to add version-ing to materials and tags for this very reason, but it never gets implemented.
User avatar
shawnfrueh
Licensed Customer
Licensed Customer
 
Posts: 157
Joined: Thu Jan 31, 2013 10:29 pm
Next

Return to Commercial Product News & Releases (Download here)


Who is online

Users browsing this forum: Zay and 0 guests

Sun Oct 20, 2019 9:28 pm [ UTC ]