OctaneRender™ 2020.1 RC3 [superseded by 2020.1 RC4] Tweet

[mojave]

Happy to see there is a lot of progress for both OOC and NVlink in this release.

I am testing with two scenes
Scene 1, contains a supper mesh (one single mesh with 20M triangles), the entire scene with 44M triangles, on the master side there are 2xquadro 6000 and 2x2080ti both pairs with nvlink applied and actived under nvidia control panel.
Scene 2. with a lot of 4K and 8K textures

Conclusion is both Nvlink and ooc are working now, though there is still limitations:
1 for super mesh senario,combination of RTX+nvlink+ network rendering could work quite stablely, ooc will be low priority for this senario, (when head room is not big enough ooc will fail, RTX and ooc still conflict in some cases though less than before)
2 for super texture senario, nvlink may fail, yet ooc works.

Thanks for the team, It is a great progress!

Jim

Hi Jim,

Can you provide specific details about how to reproduce the issues you mention in your post? It would be useful if you could share your exact settings and a repro scene we can use as reference via PM.

Thank you.

[Notiusweb]

Hello, this happened in RC2 but also now in RC3 too:

(1) in Standalone I had a scene where I was adding Material layers to a same single Universal material, and at 7 Material layers my GPUs would go red (crash needing restart of Octane).
And I could repeat this - at 6 good, 7 bad.
And no matter how I added then 7th - within a Layer group, as a single layer, with or without added Material Cache in Preferences - it always caused the red-GPU-crash.

But, then to test if this was caused by # of layers I created a very primitive scene with a primitive RGB-color Universal Material and was able to add 9-10-11 Material layers to that same-single Universal material, with no problem.
So I am thinking it was not the # of layers itself, rather something more generic that must be causing the red GPU-crash.

Would it be memory load on a single material? Or basically, what part of a scene - specific to a single material instance- is related to GPUs going Red requiring Octane restart. (ie cumulative Memory load, # textures, # nodes, etc...)


Also an idea...
(2) What was scary was, for this same 7 Material layer scene, I had a Baked Image Texture in, which loads at Scene build.
Now, the first time the 7-Material Layer Red-GPU crash happened, I saved a version of the scene, with 7 Layers, in an attempt to next reload and retry again.
But, I found this saved-7-Material layer scene could no longer load because when the load processes, it would do baking of the baked image texture, and the GPUs would go red (I am thinking again for the 7 Material layers, which had caused the red GPU crash before). This red-GPU on load halted the completion of the load. So I could no longer get into the scene at all on the Graph node.

Luckily, I had also saved a 6 layer one and thus I could continue to work around it, no problem.
But if hadn't had this, I would have lost the scene.
So, my idea
perhaps an emergency rescue 'do not build baking textures on load' could be added somewhere in preferences, to rescue a scene with a sort of Octane 'Safe Mode'?
I don't know how often this might happen, but could be a nice redundancy in case a scene goes crash and won't load anymore.

[Notiusweb]

On the 2040s thing with holograms - 6 markets not mentioned you could now seek early private investment on:
1A-medical/pharmaceutical - real-time holographic laboratory scans, surgery visuals, cellular, viral, cancer enlargements in realtime
1B-virtual therapist
1C-hologram of in-utero fetus....Moms would love this!
2-farming - use holograms to maintain control over livestock locations, horses, etc...
3-Audio plotting modules- hologram's visual location coordinates are key to plotting the respective realistic holographic audio coordinates
4-restaurants - virtual holographic menus for the dishes
5-home security - holographic humans to trick thieves into not coming into your house while you are away

BUT - here is the biggest $$$$$$
6-MILITARY/POLICE - decoy enemy forces with holographic troop, weapon, vehicle movements

Pressure these venture capatalists to not 'miss the boat'. Say "you need to give Otoy money NOW.."
And show them a literal hologram of a boat sailing away with $-bills moving away.

Which is part of # 7 - Advertising -
Have several Jules holograms speaking to the prospective investor at the same time - all at his blazing fast speech rate - they will be so overwhelmed and shocked they will hand you $!!!!
Do that at the next GTC - a Jules hologram next to real then Jules!...
$$$$$$$$$$$$$$$

[linograndiotoy]

RTX on is making GPUs fail in this very simple scene as you try to move the primitive.

RTX_Crash.ocs

(73.98 KiB) Downloaded 159 times

[mojave]

RTX on is making GPUs fail in this very simple scene as you try to move the primitive.

RTX_Crash.ocs

Hi Lino,

Thank you for reporting this. We have actually come across this same issue and fixed it already in an internal build so it'll be included in the next build.

[linograndiotoy]

Awesome, thanks!

[Notiusweb]

Hello, this happened in RC2 but also now in RC3 too:

(1) in Standalone I had a scene where I was adding Material layers to a same single Universal material, and at 7 Material layers my GPUs would go red (crash needing restart of Octane).
And I could repeat this - at 6 good, 7 bad.

I am finding it is # active nodes on a single Universal material, not # textures or # layers.
Because in my case (which already is not simple, it is Universal having a load of active textures), plus 6 Material Layers on the Universal....if I then adjust some unused outside node - ie Sheen, Metallic, or Coating - it crashes Red GPU.

If I then reduce to 5 Material Layers, I can adjust 1 of the 3 outside nodes, but then on 2 of 3 outside nodes it crashes Red GPU.
If I then reduce to 4 Material Layers, I can adjust all 3 of the 3 outside nodes, no crash.
But then when I add in the 5th Material Layer again, with all 3 of the 3 outside active nodes, it crashes Red GPU.

There is some upper limit to the amount of active nodes within a single Universal material.
Workaround is to subtract active node right below the crashing threshold. It does not matter which is reduced, it can be any active material node.

The Substrate/Material Layer system is limited at some point on a single Universal Material, it will not go on indefinitely, even if texture memory is not exceeding GPU memory limit.

[J.C]

VDB fire blackbody emission is not working:
viewtopic.php?f=23&t=74466&p=380804#p380804

[linograndiotoy]

VDB fire blackbody emission is not working:
viewtopic.php?f=23&t=74466&p=380804#p380804

You should always use Texture Emission with volumes. Blackbody Emission doesn't carry any VDB Emission information.

[J.C]

VDB fire blackbody emission is not working:
viewtopic.php?f=23&t=74466&p=380804#p380804

You should always use Texture Emission with volumes. Blackbody Emission doesn't carry any VDB Emission information.

In that case the option to add Blackbody emission to VDB should be removed. Now it's available and this is misleading.