OctaneRender™ Standalone 1.35

[abstrax]

Hi,

This release fixes a few fairly critical bugs of 1.34.


Changes since version 1.34

• Added octane.image.getProperties() and octane.image.getBuffer, renamed octane.image.create() to octane.image.load(), to provide support for loading LDR/HDR mono/RGBA images.
• Changed exposure scale for untonemapped images: The scale matches now the white point of tonemapped images with gamma 2.2.
• Fixed an error in scene graphs that have unconnected transform input linker nodes.
• Fixed broken loading of IES files.
• Fixed incorrect memory allocation for LDR images, using too much memory on the host.
• Fixed incorrect loading of images for alpha image texture nodes if the image files doesn't contain an alpha channel or has no transparency.
• Fixed auto-alpha option in the OBJ/MTL import.
• Fixed wireframe rendering for GPUs of compute model 2.1.

Download:

Windows
ZIP archives:
- 64-bit
- 32-bit

MacOS X
ZIP archive:
- 32-bit and 64-bit

Linux
ZIP archive:
- 64-bit

Happy rendering,
Your OTOY NZ Team

[Tugpsx]

Wow ! Fast and Furious. Lots of great scripting add-ons.

[Jaberwocky]

Marcus

Any chance that the next version will give support to running the maxwell gpu's

Just bought a 750ti , primarily to run my new 27" dell Monitor, it might be handy to get the 750ti to do some rendering as well...might as well put it to work.

as soon as it can i'll do some performance tests on it

[funk]

[*] Changed exposure scale for untonemapped images: The scale matches now the white point of tonemapped images with gamma 2.2.

Thanks for this change guys. This is giving me the results I expect!
I often use an additional imager node set at linear with gamma 2.2 so I can see what my EXRs will look like.

I was thinking about this last night and the best solution would be to have sRGB/rec709/cineon/etc "responses" listed along with the other camera responses. This would probably be a lot more work though

You could then revert this white point change (I think?). We could then use a 1.0 gamma in octane along with an "sRGB response" (roughly the same as using gamma 2.2)

Have you ever considered doing this?

[face]

The problem is, the render result looks now different from what Modo and Softimage exports as exr.
So i have to revert it in my plugin to get the same result with what artist can work to composite images from different software packages together...

face

[funk]

The problem is, the render result looks now different from what Modo and Softimage exports as exr.
So i have to revert it in my plugin to get the same result with what artist can work to composite images from different software packages together...

face

Hmm I'm not sure whats going on, but for me, this new change now matches my modo exports much closer. This is one of the reasons why I complained in the first place, because octane and modo exports werent matching

Maybe we are using different workflows? Can you maybe show some examples?


NOTE: I also use the lightwave plugin, and since 1.30 this "broke" the lightwave export for exr's compared to 1.20. This change should fix things again.

[face]

Hmm I'm not sure whats going on, but for me, this new change now matches my modo exports much closer. This is one of the reasons why I complained in the first place, because octane and modo exports werent matching

Maybe we are using different workflows?

I mean, when i export an exr from Modo or Softimage with a gamma of 2.2 it looks like the one in Octane 1.34.
I can make it look like a png output with gamma 1.0 by using a gamma of 0.4545 on the exr in Photoshop.
This is now not possible, or maybe i miss something...

face

[funk]

Hmm I'm not sure whats going on, but for me, this new change now matches my modo exports much closer. This is one of the reasons why I complained in the first place, because octane and modo exports werent matching

Maybe we are using different workflows?

I mean, when i export an exr from Modo or Softimage with a gamma of 2.2 it looks like the one in Octane 1.34.
I can make it look like a png output with gamma 1.0 by using a gamma of 0.4545 on the exr in Photoshop.
This is now not possible, or maybe i miss something...

face

You are doing this incorrectly. You should be saving out the exr from modo with a gamma of 1.0. You should only be using 2.2 for display while previewing otherwise the 2.2 gamma is "burned" into the image and you need to invert it in photoshop (as you are doing). You can set up 2 render outputs for this (1 at 2.2 for preview and one at 1.0 for saving. See http://community.thefoundry.co.uk/discu ... 804#723804)

When Photoshop opens an EXR it automatically adds a 2.2 (srgb) gamma for display purposes. So opening an EXR should look "correct" without having to change the gamma to .4545

[face]

You are doing this incorrectly. You should be saving out the exr from modo with a gamma of 1.0. You should only be using 2.2 for display while previewing otherwise the 2.2 gamma is "burned" into the image and you need to invert it in photoshop (as you are doing). You can set up 2 render outputs for this (1 at 2.2 for preview and one at 1.0 for saving. See http://community.thefoundry.co.uk/discu ... 804#723804)

When Photoshop opens an EXR it automatically adds a 2.2 (srgb) gamma for display purposes. So opening an EXR should look "correct" without having to change the gamma to .4545

Ah ok thanks, will test it out.

face

[funk]

Ah ok thanks, will test it out.

face

You should be doing the same thing in softimage too (I dont own it so not sure how to save a 1.0 EXR). Just to confirm what I'm saying a quick google search brought this up: http://www.workshop.mintviz.com/tutoria ... explained/

Here is a quote from that page:

Gamma correction summary

If you want to save the rendered image as a 32bit file format for compositing then don’t burn in the gamma, save at gamma 1.0 (linear). Gamma correction will be automatically applied when opening the file in post for the majority of software applications including Adobe Photoshop.