OctaneRender™ Standalone 2.05.2

[abstrax]

Since the change in the gamma settings of the imager node didn't find much love and caused too much confusion, we reverted it. We also fixed the displacement crash reported by smicha (and hopefully the one from Roubal, too). You can get those changes by downloading the release 2.05.1.

Apologies for the hassle.

[ROUBAL]

Thank you very much. Unfortunately, I discovered this morning that I encounter GPU crashes even without any displacement enabled. It seems to occur on scenes with a foreground, and a backgound out of focus with many foliages with alpha. Positionning the camera somewhere else seem to render without trouble. I have two GPUs, and one is always 3-4°C warmer , but it is not always the warmer one which stops running first.

Log screen :

Started logging on 01.08.14 12:16:25

OctaneRender version 2.05 (2050000)

CUDA error 999 on device 0: An unknown internal error occurred.
-> kernel execution failed (pt)
device 0: path tracing failed
CUDA error 999 on device 2: An unknown internal error occurred.
-> kernel execution failed (pt)
device 2: path tracing failed

I have updated my Nvidia Driver from 335.23 to 340.52 with no change.

I have packed an orbx file, but I can't upload it as it weights 3.5 GB and I have only a 100 Kb/s internet connection in upload direction.

I test 2.05.1 ASAP.

[enricocerica]

Thank you very much. Unfortunately, I discovered this morning that I encounter GPU crashes even without any displacement enabled. It seems to occur on scenes with a foreground, and a backgound out of focus with many foliages with alpha. Positionning the camera somewhere else seem to render without trouble. I have two GPUs, and one is always 3-4°C warmer , but it is not always the warmer one which stops running first.

Log screen :

Started logging on 01.08.14 12:16:25

OctaneRender version 2.05 (2050000)

CUDA error 999 on device 0: An unknown internal error occurred.
-> kernel execution failed (pt)
device 0: path tracing failed
CUDA error 999 on device 2: An unknown internal error occurred.
-> kernel execution failed (pt)
device 2: path tracing failed

I have updated my Nvidia Driver from 335.23 to 340.52 with no change.

I have packed an orbx file, but I can't upload it as it weights 3.5 GB and I have only a 100 Kb/s internet connection in upload direction.

I test 2.05.1 ASAP.

Hi Roubal,

I also experimented many crashes with Octane 2.0 until I migrate to a complete new system and now everything seems stable and the main difference with the previous system is that now my Cubix expansion is on a 16x PCIe port, as I know that you have one of those boxes too, maybe this could be the origin of the problem. Just a thought ...

[ROUBAL]

@Enricocerica : Thank you for the idea... but I rendered recently many times a big scene with my Lotus Elan without problem, and many shots of my current Milton Manor scene as well, until I came to this specific shot.

I can't change anything about my Cubix connection as my machine is 7 years old and has no more than 1 available slot for the cubix box. I would have to change the Workstation and I can't afford it now. It is planned... but always postponed due to lack of money.

I tested with priorities disabled, increased the GPU fans speed , adjusted the voltage of the warmer one that was at 1013mv instead of 1000mv (I should test the opposite), but it seem very camera view specific.

@ Abstrax : I finally deleted all unused objects in this camera view, and verified that the crash still occurs. I reached 448 MB once zipped. I am currently uploading on my website and it will take theorically more than one hour. If everything goes well, I will send you a link in PM when it is done. Thank you in advance. The camera showing the crash (often after rendering around 45 samples/pixel, often less) is the one connected by default when you render the render target.

Thank you in advance.

[abstrax]

@ Abstrax : I finally deleted all unused objects in this camera view, and verified that the crash still occurs. I reached 448 MB once zipped. I am currently uploading on my website and it will take theorically more than one hour. If everything goes well, I will send you a link in PM when it is done. Thank you in advance. The camera showing the crash (often after rendering around 45 samples/pixel, often less) is the one connected by default when you render the render target.

Thank you in advance.

Awesome, thank you!

[ROUBAL]

@Abstrax : I sent you a PM and the scene for testing.

I put here a copy of my PM describing my recent surprising discovery in case someone would have an idea :

Since my last post, I discovered something very weird : as moving a heavy scene to place a camera is very slow and tedious when working on a huge scene, I often set to Direct Lighting , low resolution and subsampling to adjust the framing before coming back to the desired parameters for rendering.

My usual render resolution for display on my website is Full HD : 1920x1080, and I downscale at 1280x720 for the preview. So I rendered these days at 1920x1080, as usually, when I encountered the described GPU crash with this scene.

So, for faster camera placing, I decreased the resolution down to 720x405, and noticed that I didn't get any more the GPU crash. Usually at 1920x1080 it occured for the first failing GPU always before 58 s/px the maximum I reached, and soon after for the second GPU.

At 720x405, with no other change than the resolution, I got no crash and stopped the render by hand around 160 s/px.

After that I had the weird idea of testing with an higher resolution : At 2560x1440 : I had to go out some hours, and I am just back and the two GPUs are still rendering fine, and the current s/px amount is 397 ! An other thing : the temperature is higher than this morning, and it seems to have no peculiar effect.

So, at first glance it is not a matter of resolution, but rather imho a matter of memory management. Maybe other resolution values would crash the GPUs ?

Then I enabled displacement on the large ground surfaces and after around 10 seconds, one GPU crashed, followed by his brother few seconds later...

[smicha]

Since the change in the gamma settings of the imager node didn't find much love and caused too much confusion, we reverted it. We also fixed the displacement crash reported by smicha (and hopefully the one from Roubal, too). You can get those changes by downloading the release 2.05.1.

Apologies for the hassle.

Marcus,

Thank you for quick turnaround.

s

[prodviz]

Hi Abstrax,

cheers again for the update.

I'm not sure exactly what has been changed and then changed back, as far as the gamma.

The untonemapped .exr now looks much more like the render view, which is cool.

The only query I have now is which colour space should I assign to the .exr when I open in photoshop?
When I assign sRGB the colours do not match.
The Adobe RGB colour space is closer, but not always matching the render view.

cheers,

Steve

[blobbybarack]

*Each time i edit .abc settings a new camera output is created. (not specific to 2.05) Same deal with file replacing.

*Orthographic Camera coming from .abc are not imported correctly. (i ve no idea if it s coming from alembic or octane) the camera is far away. Hard to tell if it s a focal problem or position problem.


*Each time i try to use rounding edge it doesn t work (i ve got nothing, the geo explode, or some artefact appear on point)....since the first 2.0 release. Even on simple mesh, subdivided or not. Did somebody use this with success since 2.0 release ?
/////EDIT : in fact the result really looks like a real real geometry beveling not an render bevelling. I'm correct ? I though it was a render bevelling. It could explain why the bevel setup go with the subdivision option tab. So sorry it work but not like i was thinking. it could do the trick in many scenario but not extreme one /////
///EDIT 2 : no it doesnt...a moving geometry i have heavy jitterbugging on the bevel.


*not really a bug i guess but i want to check : now every time i switch to shader ball or coming back to render target Octane recompute the scene. I guess you did this because of displacement mapping right ? Octane need to recompute the mesh for displace i guess. Of course it painless on simple scene but it´s really a pain in the A** with heavy mesh scene. It would be great to go back to 1.5 compiling methodology if no shaders with displacement are present in the scene.

[abstrax]

Hi Abstrax,

cheers again for the update.

I'm not sure exactly what has been changed and then changed back, as far as the gamma.

The untonemapped .exr now looks much more like the render view, which is cool.

The only query I have now is which colour space should I assign to the .exr when I open in photoshop?
When I assign sRGB the colours do not match.
The Adobe RGB colour space is closer, but not always matching the render view.

cheers,

Steve

In Octane you have to set the camera response curve to "linear/off" and the gamma to 2.2 and in Photoshop you would have to set the color space to sRGB, then you should get a similar result. It wouldn't be 100% the same, since sRGB is actually not a simple gamma 2.2 curve, but a gamma 2.4 curve with some offset and a linear part for the shadows.