Octane scene loading

Hello to all octane enthusiasts, possibly makers,@paulphysicalc @Micha @BrianJ @Ben

I was really looking forward to render my diploma animation with octane. I got convinced by the superb rendering times and bought me two hydrocooled 980Ti.

Unfortunately there are two reasons why I am absolutely down after one day of using Octane demo.

1. Disappointment:
Bongo Animation with some few objects and camera moving:

I discovered that unless you make “camera-only” animation octane has to load the scene each time again. Even though live mesh is turned on only for objects that move each frame needs almost a minute to load. (1982 elements, 3 000 000 triangles). With some of the scenes even more heavier.

2. Disappointment:
Scene loading generally takes simply too long. It is insane waste of worktime. Also is it normal that if all meshes are turned on to be live you can load only few objects? already with 300 elements - all live meshes - I get out of Memory RAM ( which is 32GB!!)

My last hope would be that this has been taken care of in some of the updates, as I only use demo for it. Also could this be Rhino specific or is it the issue with other 3d programs too?

Hi Daniel,

I am sorry if I influenced your decision simply based on my own use of
Octane, which includes only occasional and not very complex animation,
ie static scenes that don’t need reloading.

Have you posted your questions on the Octane Rhino user forum?

I wonder how Blender handles it with its Cycles renderer, which also uses
CUDA.

Dan,

You don't mention whether you are using the Octane Standalone or are using Octane for Rhino which greatly simplifies matters. I rarely go back to Standalone since Octane for Rhino came out. Not sure if this would have any effect on your issues but please clarify just which version you are using.

Hello Jody,
I use last build of Octane for Rhino Demo, which if I am not mistaken is at 2.0. I was wondering if using commercial either 3.0 or higher version of 2.0 would solve/speed up these two issues. I also thought maybe in stand alone you do not have to load each frame of animation/geometry update is faster, on the other hand I cannot test exporting the animation from bongo to standalone as this is not supported in the demo version.

Hey Ben,
I didn´t mean to say this by adding you to the discussion :slight_smile:

There are indeed many good opportunities to utilize cuda, alone in rhino for still scenes and walk-throughs. Yes, I also asked the otoy community in forum.

Beside object-moving-animation, do you also have problem loading all-mesh-live scenes as I described? That seems to me like a some sort of bug.

Hi Daniel,

I can’t help you to much. I used Octane for special cases some times only. My impression is that the usage is to cumbersome and the Rhino integration isn’t the best. Your case is an example for limited use of Octane of Rhino, some features sounds good on the paper but in real projects … . One developer is working on different 3D integrations and Rhino seems to be not the favorite application. For my taste as pro render the often the user or Rhino is the problem.

Loading scenes was my problem too. Render times can be quite short, but loading the scenes needs some times longer than the rendering. But for Bongo there is a workaround. I posted it somewhere at the Octane forum. You need to start several Rhino tasks (3 tasks was fine) and to start the Bongo animation at all tasks. So I got a nearly 100% GPU usage.

Micha

Hi Daniel

The OctaneRender for Rhino plugin does a complete reload of the entire scene each frame when rendering from Bongo. This is because the plugin cannot access the individual geometry object transforms from within the RhinoCommon API (in fact, RhinoCommon provides all geometry in world coordinates, not local coordinates with an object transform). It may be possible in the future to incorporate Bongo API access to obtain the geometry transforms each frame, however I believe (and I might be wrong) that there is a Bongo API, and it is C++, which is going to be a problem with the Octane plugin being done in the C# RhinoCommon API.

So in summary, if there was a way to access the actual Bongo geometry positions each frame from the RhinoCommon API, a scene reload would not be needed, and animation would be very fast. This is the way it works on most of the other Octane plugins.

Regarding running out of memory with all meshes being live - I’m not aware of any issue with this, and it has possibly been corrected in the latest version (there have been over 20 releases since the demo version that you are using). If you send me a scene which gives you this problem, I can check for you.

Paul

Why does’s Andy from the Bongo team believe it’s possible to work with transformation infos only? If I understand Andy right than the transformation info can be extracted from Rhino, only it’s not direct available, some extra work needs to be done. My impression is, so flong Andy believe it’s possible nothing will be changed on the Rhino side. Paul, could you and Andy not find a solution?

http://discourse.mcneel.com/t/bongo-animation-sending-object-transformation-info-only/23861/4

1 Like

Hi Paul,
I hope there will be some workaround this Bongo issue, maybe only live mashes could load instead of all the geometry, would surely speed up things in simple animations.

As far as crashing is concerned, I am quite puzzled. It still crashes with octane paid version 2.24.2.56 after loading 2041 elements (all meshes live) I first get message “out of physical memory RAM” and than get this message:

Afterwards I either get blue screen or have to restart the PC because graphic card driver crashes.

I have tried two drivers, currently I have version 361.43. Nothing changed
Could it be windows 10 issue? have you tested octane on windows 10? I sure wouldn`t be the first one to use W10.

I still send you scene, but i think it is not related to it, it crashes with all other ones too.
https://www.wetransfer.com/downloads/749e288cb37d532fbcd52f6cabe5206320160126144403/bd5c3a66c48b4748033b34777343178f20160126144403/71d365

Yes, that may be possible. Might be a bit un-intuitive for the user though, since they would need to know to turn on Live Geometry for the meshes they want to reload - but perhaps it could be an option you turn on in the Config. I will investigate this for the next release.

As far as crashing is concerned, I am quite puzzled. It still crashes
with octane paid version 2.24.2.56 after loading 2041 elements (all
meshes live) I first get message “out of physical memory RAM” and than
get this message:

That scene render fine for me (16GB RAM, 2GB VRAM). You are running out of VRAM, not RAM. The scene you supplied takes roughly 1GB of VRAM. It is also possible you are hitting the plugin geometry limit - so set the Settings->Max Number Of Polygons to 5 million. I suspect a fix was pushed through for this after the demo version you are running was packaged.

Also, Nvidia driver 361.* appears to be very buggy. I had to go back to 358.50.

Paul

Yes, that may be possible. Might be a bit un-intuitive for the user
though, since they would need to know to turn on Live Geometry for the
meshes they want to reload - but perhaps it could be an option you turn
on in the Config. I will investigate this for the next release.

Actually - this is not possible - because it is the Rhino render panel controlling the animation, so the Octane plugin does not even know that it’s a Bongo animation that is being rendered. So a complete scene re-load is required.

However another option exists where you can export the entire animation as Alembic via the plugin “Export Bongo Animation to OCS/ORBX”, which you can then render in Octane Standalone (and this will render will camera, object and vertex motion blur). This option is disabled on the demo version of the plugin.

Paul

Is it however possible to have bongo animations rendered from Octane render window? Vray was working like that. Correct me if I am wrong but it also means that rendering passes in bongo are not available now? At least they do not save. I am also now running full version.

I have 6 GB of vram, I do not think that should be it. Also prior to the message I posted before I get message saying this:

That is very awkward , It cannot be it as I have 32 GB of memory and the Rhino usage does not come near it before crash. I have 80 000 000 Polygons enabled.

Have you given a thought to the windows 10 issue?

Daniel

Is it however possible to have bongo animations rendered from Octane render window?

This might be possible - but it’s a very un-Rhino’ish way to do it. (And it’s a hacky solution to something which should be implemented inside the RhinoCommon SDK). In effect, the Export Bongo Animation to OCS does exactly this - it bypasses the Rhino render panel and simply iterates through the timeline exporting the data to the OCS file. You can then import this into Octane Standalone and render. May I suggest you try this option.

Correct me if I am wrong but it also means that rendering passes in bongo are not available now?

You are correct - the Rhino render panel only saves the Beauty pass - not all the other passes (although I think if you have the viewport already open and select an info pass, then render the animation, it will save that info pass - you would need to try to confirm this). Again, exporting to OCS will resolve this problem.

Out of memory (system RAM)

This is a warning that the RhinoCommon C# environment ran out of memory allocating the buffers for the geometry. You probably have the Settings->Max Number Of Polygons too high. What is it set to? I also recall that there is a maximum amount of RAM that a C# .NET app can allocate - and it is less than your total 32GB RAM (I’m unsure the exact amount).

I have 80 000 000 Polygons enabled.

The maximum TRIANGLES that Octane 2.24.2 will render is 19 million. If you go over that, it’s not pretty. However Octane 3.0.3 onwards lifts this restriction. However you will need to ensure you don’t go over the .NET memory limit. I have not done any testing with the Rhino plugin with scenes > 19 million triangles yet (since 3.0.3 has only been out a couple of weeks). You can reduce the number of polygons via the Properties->Custom Mesh->Settings dialog in Rhino.

Have you given a thought to the windows 10 issue?

Unsure which issue you are referring to - sorry. I’m running Windows 10 and everything is fine.

Paul

I have decreased the number to 10 000 000, still got black screen and had to hard-restart. I guess this one remains mystery. Again it is the same scene that you have successfully loaded … with half Ram and third vram

Hi Daniel,

A bit late to the party here but I thought I’d add what I can. I’m just a user though and not one of the developers so those posters like Paul will have the best technical info. I personally have only used Octane for Rhino for stills and not animation. I have however done a bunch of animation in Blender and rendered out through Cycles using GPUs so I know what you’re talking about regarding mesh transfer times to the VRAM on the GPUs. Blender has an option for a static BVH which can help speed this up but again only if meshes aren’t moving between frames. I’m not sure if there is a similar option for Bongo to Octane. At a guess, it sounds like that happens automatically unless objects move. It sounds like @paulphysicalc has gone into this already too so I won’t assume too much though @andy may have more to add as the lead Bongo developer.

I don’t have your file here to test but one more thing to look at is what textures including environment HDRI textures are present. I’ve found these can add a memory hit too when GPU rendering. You may have sent a file without these textures which is why the test is successful on other machines.

Keep in mind too that VRAM is not cumulative… so you have 6GB total not 12. I’ve also found that SLI slows things down but that may be Cycles related. Lastly, customizing render bucket sizes instead of progressively rendering each frame is way faster. I’m not sure if Octane lets you do this but for instance if your frame is 1920x1080, set the render tiles/buckets to 256x256.

I have decreased the number to 10 000 000, still got black screen and
had to hard-restart. I guess this one remains mystery. Again it is the
same scene that you have successfully loaded … with half Ram and third
vram

I just tried your scene with Max Triangles set to 10 million, and it rendered fine (max’d out at 4GB RAM usage). What graphics card are you running? How much VRAM does it have? Which version of the plugin are you using (X.X.X.X format)? Which Nvidia driver version do you have installed? It is also worth running the Octane Standalone EXE installer, which will optimise some of the Nvidia time-out settings during the install.

Paul

Hi Brian,
thanks for your reply, Octane for Rhino has an option for camera fly through type of animations, in that case scene loading is only few seconds. The problem is only with moving meshes. Octane standalone is however a workaround this issue as you can load your whole animation and render it from there without the delay. I would wish octane would be more integrated with octane, i have to settle for this solution for now.

Many time i thought of switching to other 3d packages for animation, but staying in “one house” has also its advantages.
Looking forward to sharing the final work.

The scene has no textures (I was aiming for paper style) and i use 2x 6gb 980ti without sli. This is not performance issue, it must be some strange glitch.

Daniel

Hi Paul
thanks a lot for caring for this issue.

I have installed Standalone prior to Rhino plugin. I have two 6gb EVGA 980Ti without SLI. I now use 3.0.3.58 before I also had 2.24.2.57 with same result. After your advise I now run on nvidia 358.50 driver.

I tried exporting bongo to ocs format, works very nice! Bigger scene get me into freeze again, probably same cause as loading static scene cuz live meshes need to be used.

Also when i render bongo fly-throughs with octane directly inside rhino, I can add sun animation to it too: http://bongo.rhino3d.com/page/rdk-sun
This oddly works only when the rhino sun tab is active (means it is separated from other tabs). This sun animation is unfortunately lost when exporting to ocs, would be nice to have in standalone too.

Thanks a lot for lots of taken time.
d.

Yes. When Rhino renders a camera flythru, it call the renderer OnBeginRender (where the scene is loaded), and then for each sun position it calls ContinueModal() to render that frame.

Whereas for a Bongo render, the OnBeginRender() gets calls at the start of each frame, so the plugin needs to load the full Rhino scene into Octane. For a rendering plugin like Octane, there is no way for the plugin to tell if it’s rendering a single frame, a sun study or a bongo animation.

I tried exporting bongo to ocs format, works very nice! Bigger scene get
me into freeze again, probably same cause as loading static scene cuz
live meshes need to be used.

I just checked the code. When you export a Bongo animation to OCS, the plugin opens the Viewport, then saves that frame to the Alembic file, then progresses the Bongo timeline, then only refreshes the Rhino geometry with Live Update ENABLED, and saves that frame to the Alembic file, etc. So you can just set the geometry you need to animation with Live Update ENABLED, and then only those mesh items will be reloaded into the Octane Viewport. I take it you are getting a freeze when first opening the Viewport. Is it possible to send me that scene pls, and I can take a closer look.

Also when i render bongo fly-throughs with octane directly inside rhino, I can add sun animation to it too: Rhino - Animating the Sun
This
oddly works only when the rhino sun tab is active (means it is
separated from other tabs). This sun animation is unfortunately lost
when exporting to ocs, would be nice to have in standalone too.

Yes, the export to OCS process is simply iterating through the Bongo timeline, extracting the relevant geometry. As I understand the RhinoCommon RDK, the actual sun position from a sun study is not available to a plugin unless the sun study is actually rendering. The sun timeline is not necessarily the same as the Bongo timeline.

Paul