OctaneRender™ 2020.1 RC2 [superseded by 2020.1 RC3] Tweet

[karl]

Hi Karu,

Thank you for the explanation. I hope the UI can be improved in this case so that we as users know why it is happening and can edit the scene / materials to make it fit. May I know once nvlink is supported 100% will this issue go away as linking 2 RTX 2080 Ti should double the VRAM to 22GB and that should help load the scene ? If not, time to start saving for the Titan RTX.... 4 x that will cost a pretty penny or two ....

Btw. I did provide a scene file that crashed the standalone too to Paride as soon as it starts rendering (Loading no issue). Hopefully that helps you all to debug it further.

Regards,
Rajib

As we support NVLink for more types of data, the situation will improve. We plan to prioritise NVLink support for the kinds of data that usually take up the most space (that's why textures are next on the list). However there will always be some overhead - a single card with 22 GB of VRAM will always allow for more total data than two cards with 11 GB each. So the effective VRAM won't double, but it should get closer to that.

[Elvissuperstar007]

https://fex.net/ru/s/lrpsxy1
https://fex.net/ru/s/st1zffk
https://fex.net/ru/s/mba1flc all Jpg texture 2019.5 work
if you turn on more than one video card, a crash occurs

[funk]

I also reported this in the RC1 thread. Octane is rendering this HDRI incorrectly.
viewtopic.php?p=377892#p377892 (orbx attached to that post)

This is currently a limitation of Octane's HDR texture support - values are clamped to 65504 which is the maximum value of a half-float. We plan to support full 32-bit float HDR textures in a future version.

Thanks Karu. I thought some kind of clamping was going on, but switching the texture import settings (spanner on RGB image node) to "16-bit float" instead of auto/32-bit float, actually gives me a slightly darker image.

With the info you just posted, I would have thought the render would be identical (eg both clamp to 65504).

I hope to see full 32 bit support soon, because I've noticed quite a few of the textures at hdrihaven.com render incorrectly.

[noldo]

I also reported this in the RC1 thread. Octane is rendering this HDRI incorrectly.
viewtopic.php?p=377892#p377892 (orbx attached to that post)

This is currently a limitation of Octane's HDR texture support - values are clamped to 65504 which is the maximum value of a half-float. We plan to support full 32-bit float HDR textures in a future version.

Thanks Karu. I thought some kind of clamping was going on, but switching the texture import settings (spanner on RGB image node) to "16-bit float" instead of auto/32-bit float, actually gives me a slightly darker image.

With the info you just posted, I would have thought the render would be identical (eg both clamp to 65504).

I hope to see full 32 bit support soon, because I've noticed quite a few of the textures at hdrihaven.com render incorrectly.

+1 for solving this limitation.

[jimho]

there is an issue with alembic format support

frames are lost,
though all the frames of the abc file can be correctly shown in the viewports if it is imported into 3dsmax, part of the frames cannot be rendered neither in 3dsmax plugin nor in the octane standalone, (same frames are lost in both two software)
.
all the abc frames are generated by realflow and then stitched into one big file,all the seperated frames (one frame per abc file) are renderable in octane but after they combined together many frames are just lost,

attached is a sample

test1.rar

(3.26 MiB) Downloaded 189 times

Jim

[SSmolak]

Is there any ETA for nvlink memory pooling support for textures too ?

[mojave]

Just a heads up for everyone this build has now been superseded by 2020.1 RC3 so please report any issues in the latest build thread.

Thank you for your support.

[vijay]

I'm seeing an issue with the denoiser when combined with upscaling and volumes. The denoiser doesn't denoise the edges of the volume with upscaling enabled.

Jason

Hi Jason,

Thanks for sending me a sample scene. This is currently a limitation with octane volume denoiser. We record volume data in volume, volume mask and volume emission passes. The current volume denoiser model denoises volume and volume emission passes but not the volume mask pass, due to which the edges around volumes look a bit noisy on the denoiser output and combining it with the upsampler the issue look more obvious. Sorry, we will improve the volume denoiser in future. Until then please render more samples. While looking at this issue, I found another issue where the upsampler adds dark/black outer layer around bright/light objects. We are looking into that and hopefully fix it soon.

Thanks,
Vijay