Octane scene loading

Is it an useable way for medium and high complex models? So far I remember me this way caused a very high disk usage and exporting to the disk need some time too. This way should be available for the demo.

If I remember me right for my animation test - I was not happy and finally I used the trick to start three Rhino tasks, so during the loading time an other task was rendering.

hey paul,
I wanted to export 150 frame bongo animation to standalone, it seems to have allowed me to export only 100, is this an actually limitation when exporting?

thanks,d.

I’m not aware of any limitation on frames. Is it possible you ran out of disk space during the export?

Is it an useable way for medium and high complex models?

Yes, of course.

So far I remember me this way caused a very high disk usage and exporting to the disk need some time too.

Yes, it will be saving a lot of info to disk. That is the nature of the Alembic format. An SSD will be useful in this situation.

This way should be available for the demo.

Exporting from the Rhino plugin to ORBX/OCS will not be made available from the demo - sorry.

Paul

Hi paul, it seems like a limitation to me. Even if I type 101 frames it than shortly show 100 in the dialog and exports only 100 to standalone. I have also made new test scene with only one box moving, again exports only 100 frames max.
I have 12 GB free space on C and 674 GB on D where animation is saved. Could you test it on some simple scene, and bongo animation that exceeds 100 frames?
thnx

I guess I can make all animation to span over 100 frames and than increase fps in the standalone to render them longer, let´s see if that is going to work.

also to that:

watch the video closely Rhino - Animating the Sun
this is not sun study, but there are actual sun key frames in bongo timeline (they appear in light green on my pc)

Can you send me the scene pls. paul at physicalc-software dot com.

Thanks

Paul

The Octane plugin is picking up the sun position from the Rhino light panel - which may not be receiving the Bongo sun position updates. If you send me a sample scene I can take a closer look.

Paul

Quote from the Sergenti forum - Paul wrote: “Micha - I am reluctant to undertake the work required to write a C# wrapper for the C++ Bongo SDK. Firstly, it’s going to take a lot of time (for something with only 2 users of the Octane plugin so far have requested), and secondly, this is really a job for the Rhino/Bongo dev team.”

A request of two users doesn’t mean it’s a request that can be ignored. I payed 440,-€ and feels me like a beta tester. Will it be more users if the problems of the early adopters are not solved? It’s quite unfair if features are great looking at the paper only. New users will spend a lot of time with problems known by the developers. So, if the problem is known and can’t be solved than tell it to your potential users, write it at the feature list - only basic animation support of very simple scenes.

Back to the suggestion to use the Octane export function for animations. Today I tested the export of the animation again. My short animation of a technical device is a 60 ticks bongo animation. The Rhino file was created some weeks before. First problem, the env HDRI path isn’t found ( I changed the file location in the past and saved the Rhino file). OK, I set the path again and start a rendering - HDRI path error again, but render looks ok. I started an export of the animation - approx. every 1 minute the Bongo slider jumps one tick - so, the export will need approx. one hour (in this case the Alembic file will be finally 300MB, so a SSD wouldn’t help). One hour for export only! I want to stop the export - now way, I need to kill Rhino at the task manager. That’s my impression of my Octane session today.

I think if a company decides to sell a software, than it doesn’t matter how much user bought it, the quality must be right. Features that work with small test scenes only are useless. As pro user I like to get what I payed for. Yes, developing a new software cost a lot of time and the invest of money will come back over the time only (if the quality is right). In the past I was impressed by one Maxwell plugin developer, he implement a lot of nice new features to Rhino within a short time (with a nice polished UI).

A request of two users doesn’t mean it’s a request that can be ignored.

Two users is a very small subset of the plugin user-base. And I would gladly resolve an issue for a single user - however this problem is not in the scope of the plugin - it needs to be resolved in the RhinoCommon API.

approx. every 1 minute the Bongo slider jumps one tick

If you have a specific scene which is causing you problems in the plugin, pls send it to me and I will take a closer look.

Paul

I will try to send you the scene. Scene update after moving the slider needs a few seconds.

Micha - thanks for sending through your scene. On my PC is takes 20 seconds per frame on my i7 laptop with 16GB RAM, Win10 and very slow hard disk. There are 1.2 million polygons on the scene, so I think 20 secs is quite reasonable to write all those vertices to disk in Alembic format. Your 60 secs per frame is either an exaggeration, or you are running on inadequate hardware. I also checked the code - and only Rhino meshes which has Live Geometry enabled get updated between frame (the whole scene still gets exported to the Alembic file though).

I will see if an Export Cancel button can be added to the next version. I will also add an option to export the Bongo animation to ORBX with only the camera track animated (ie. geometry will only be exported for the first first).

Paul

I have just released a new version on the Otoy forums…

3.0.4.59

  • Added “Camera Animation Only” when exporting a Bongo animation, to only animate the camera (and leave the geometry static) for fast exporting of Bongo fly-thrus
  • Added “Cancel” dialog to the “Export Bongo Animation to OCS/ORBX” process
  • Fixed issue where only 100 frames could be exported from a Bongo animation

The “Camera Only” option won’t help you Micha on the scene you sent me - since there are animated meshes in the scene. For this you either need to a) get some real hardware, b) reduce the polygon count of the scene (1.2 million polygon for such a simple scene seems overkill), or c) request McNeel add the ability to access mesh transforms from RhinoCommon.

Paul

1 Like

a) my hardware is a DualXeon 3.2GHz (3.6GHz turbo mode if not all threads are used), 32GB RAM, Win7 64, GTX780 6GB - the whole Alembic file could be written to the HDD in 3 seconds. Also I did a new test and set the output to the RAM disk (speed some GB/s) - the file should be written within a fraction of a second. Inadequate hardware? The CPU usage is very low, around 10%. The Octane export isn’t faster.

b) the simple scene is a technical device and technical data need some polygons. Around 1 million polygons isn’t a high polycount, we could call it a medium or low polycount. 10 millions are a high polycount for Rhino.

Also I optimized the scene for Octane usage … now it will be interesting … if I move the animation slider during the Octane viewport is open, than it needs approx. 5s to see the updated viewport. That’s ok for today :wink: and should be the reference time. If I let run an animation rendering than it need 15…20s to get the update of the new frame (at the Rhino framebuffer). Here is something wrong, the output per Rhino frame buffer is 4 times slower.

Export time - my animation is approx. 60 ticks long, output is set to 600 frames. So we have 10 frames per Bongo tick. Fastest update time is 5s x 10 -> 50s per exporting on tick. So, that’s approx. the time I have seen for exporting the animation. It’s not the harddisk, it’s the Octane time to update the Octane viewport (exporting the 315 elements and voxelizing).

Why is the update so slow, if the Rhino frame buffer is used by Bongo? Couldn’t the Octane viewport be used for rendering animations?
A general optimization of updating the Octane engine is needed to keep the viewport update and export times shorter.

Thank you for the plugin updates.

PS: The strong artifacts caused by motion blur will be fixed by the core team?

One more test - I did a quick test with Vray RT - update time of moved objects is 3s. So this is the new reference time. Paul, please try to get this time for a Bongo animation. It would help a lot. The transformation data thing could help to be faster than this 3s, but get down the scene update time from 20s to 3s, that should be possible at Rhino now without help.

EDIT: I found that updating the Octane viewport after manual moving is faster or faster like the VrayRT update. So, looks like Bongo and the Rhino frame buffer cause the longer loading times. Paul, please find a solution, avoid to use the Rhino frame buffer and find a way to get the update times of the manual scene edit.

So, it’s not a hardware problem. It’s a software problem.

Micha - I am a bit lost in a sea of numbers and statistics :-/

if I move the animation slider during the Octane viewport is open, than
it needs approx. 5s to see the updated viewport. That’s ok for today
and should be the reference time. If I let run an animation rendering
than it need 15…20s to get the update of the new frame (at the Rhino
framebuffer). Here is something wrong, the output per Rhino frame buffer
is 4 times slower.

When you move the slider, I suspect Rhino is firing a “mesh changed” event for meshes that have moved, so only those with Live Geometry enabled would be being loaded in the Octane viewport - so that would be quicker than the entire scene reload needed each frame when rendering the animation via the Rhino Render panel. Keep in mind the Settings->Living Update combobox will influence this behavior.

Export time - my animation is approx. 60 ticks long, output is set to
600 frames. So we have 10 frames per Bongo tick. Fastest update time is
5s x 10 → 50s per exporting on tick. So, that’s approx. the time I
have seen for exporting the animation. It’s not the harddisk, it’s the
Octane time to update the Octane viewport (exporting the 315 elements
and voxelizing).

Why then does the animation export 3 times quicker on my low-spec laptop with ultra-slow hard disk?

Couldn’t the Octane viewport be used for rendering animations?

Yes, however Rhino is designed so that when rendering an animation, you select the renderer you want to use, then use the Rhino Render panel. This is the intended workflow supported by RhinoCommon and the RDK. I cannot re-write the animation system to work in a non-Rhino way to save you 2 sec per frame.

A general optimization of updating the Octane engine is needed to keep the viewport update and export times shorter.

This is no further optimisation possible. The exporter is using the fastest method to export to Alembic/ORBX format within the constraints of the Rhino and Octane API’s.

PS: The strong artifacts caused by motion blur will be fixed by the core team?

Have you reported this issue to the Otoy team?

The transformation data thing could help to be faster than this 3s, but
get down the scene update time from 20s to 3s, that should be possible
at Rhino now without help.

As I have stated many times, this is not possible without an enhancement to the RhinoCommon API to support providing object transforms.

Paul, please find a solution, avoid to use the Rhino frame buffer and
find a way to get the update times of the manual scene edit.

The plugin works within the constraints of RhinoCommon and the Octane API. I can only implement what is possible with those API’s. If a feature is not available from one of these API’s, I cannot magically conjure up solution.

So, it’s not a hardware problem. It’s a software problem.

I think the problem is that you are using the wrong software for animation. You are at the point where you need to use a software product more targeted at animation (3ds ma, Maya, C4d, etc). Rhino is one of the very best modelling apps available, but it’s not an animation app. RhinoCommon is not targeted at animation, and does not support the methods needed to implement animation support at the level you are after.

Paul

Hi Paul,

I will try a short conclusion:

  • scene update time during a RT session based on the Octane/Vray viewport is ok, approx. 3…5s are needed by Octane/Vray
  • Octane: scene update time during a Bongo animation is much slower (approx.20s), the Rhino frame buffer is used
  • Vray: scene update time during a Bongo animation is the same like for stills, the Vray frame buffer is used
  • Octane scene update time during a Bongo seems to be dependent from the used computer, but it’s not the harddisk (super fast RAM disk doesn’t help)

Yes, however Rhino is designed so that when rendering an animation, you select the renderer you want to use, then use the Rhino Render panel. This is the intended workflow supported by RhinoCommon and the RDK. I cannot re-write the animation system to work in a non-Rhino way to save you 2 sec per frame.

That’s not right. We don’t save 2s per frame only, the loading time could be bring down from 15…20s to 5s. (The render time per frame is 15s. So, I could render the animation in the half time, if the loading time could come down to 5s. The long loading time is wasting the animation time.)

What’s doing Vray and Bongo? No RT support, only standard rendering, but per Vray framebuffer! And the loading time is 5s only. Vray show us that fast loading times are possible.

I understand now what the problem is - during a Bongo animation you do a complete restart of Octane at every frame, not a refresh only (like during a Octane render sesssion). I test it - the scene needs 20s for a full cold start. Here is the first problem that could be solved by you - Vray needs 5s for a complete cold start.

So you have two ways to bring the full speed to the animation:

  • cut down the cold start time (very usefull for complex scene and non-animation-rendering) or/and
  • use the light scene refresh for animations too, avoid the Rhino frame buffer
    OK, that maybe some coding work, but that’s live. The Vray developer did the job. :wink:
    For me the great advantage of Octane is that in biased mode it’s impressive fast for product shots. In full HD my scene (with a lot of glossy metal) needs minutes at Vray and 15s at Octane. So, Octane could be great for animation rendering, if the loading times would be better.

Motion blur bug - do you not have a short connection to the Octane core team and send the bug report directly?

Micha

1 Like

Hi everyone,
when I started this thread I was new to octane. This is where it took me so far: https://vimeo.com/155001255
Still lots more to do, but so far I am impressed with octane.

Fly-through

Animation exports are almost flawless. When “camera animation” is checked, export to .ocs happens very fast. Only after last frame there is cca. 2-3 minutes halt. Not sure weather this is intended but still I can live with that.

Nice feature would be to be able to select a range of frames to be exported (50-99 instead of always starting from 0)

We already talked about this: option to export information with animated sun position from bongo would be superb. This is possible when rendered directly from Rhino (cloud part of the video I shared) (I am not referring here to “sun study”)

Possibility to export position of rhino´s camera target as focal depth would be great. Right now in standalone you either go with auto focus or manual static focal depth. Not the end of the world, but still.

Moving objects

Now I do not suggest rhino should be used for animation in Hollywood, there are far better tool for that. However there are many project of smaller scale spanning from architecture to industry design. It seems like a waste of money to buy Maya or 3dmax to make simple animations (e.g. opening doors, windows, moving static low poly cars/people etc.) where bongo does just great. Never mind the inconvenience of exporting/importing between applications.

If Vray seems to be fine with reading infos from Rhino file, it could be a feasible task. Actually since this is McNeel forum, perhaps someone from them could give a statement about the issue that Paul brought up. Unfortunately I have little knowledge with programming and development.
@marika_almgren
cheers,d.

Yes - post the bug to the Octane 3 Standalone alpha 4 release thread. OTOY Forums • View topic - OctaneRender™ Standalone 3.00 alpha 4 .

For me the great advantage of Octane is that in biased mode it’s
impressive fast for product shots. In full HD my scene (with a lot of
glossy metal) needs minutes at Vray and 15s at Octane.

Yes, Octane is a very fast renderer. Regarding animation, I think I’ve said everything there is to say to the issue. There is nothing more I can add.

Nice feature would be to be able to select a range of frames to be exported (50-99 instead of always starting from 0)

I think if you start the animation with the Bongo timeline slider at 50, it will start the export from that frame.

We already talked about this: option to export information with animated
sun position from bongo would be superb. This is possible when rendered
directly from Rhino (cloud part of the video I shared) (I am not
referring here to “sun study”)

Possibility to export position of rhino´s camera target as focal depth
would be great. Right now in standalone you either go with auto focus or
manual static focal depth. Not the end of the world, but still.

Both these are probably possible - and I will see if they can be implemented in the next release or two. There is a lot of other Octane 3 work on my list of things to do prior to that though.

Paul

Hi paul, I get this after exporting camera only animation to osc. Then Rhino crashes, any spontaneous ideas? I am working with several worksession files and .osc instances, could it be those instances?

The german part says: Object reference was not set to an object instance.

There is one more thing I noticed, I hava a scene with distorted perspective so I ticked perspective correction. In rhino´s octane viewport it corrects it fine. During export to ocs it is corrected. When opened in standalone perspective correction stops working:(

Have you had this issue?

Hi paul, I get this after exporting camera only animation to osc.
Then Rhino crashes, any spontaneous ideas? I am working with several
worksession files and .osc instances, could it be those instances?

Can you send me a scene which causes this problem pls.

There is one more thing I noticed, I hava a scene with distorted
perspective so I ticked perspective correction. In rhino´s octane
viewport it corrects it fine. During export to ocs it is corrected. When
opened in standalone perspective correction stops working:(

Perspective correction requires the Up vector of the Octane Camera to be 0, 1, 0 in order to work. So it is possible that your animation is exporting with the up vector changing a little. Again, if you can send me a Rhino scene which demonstrates this problem, I will try to fix it.

Paul

hi,
strange thing that perspective correction, during export it is all fine. only once .ocs is opened in standalone, up vector is different for each frame. Changing to 0,1,0 was valid only for one frame of the animation the rest of the frames were still distorted. I changed the node to sun direction and than to float value again, typed 0,1,0 and now its fixed for all frames. So that one is figured out. Thanks

For the crashing issue, it is not that frequent, I will observe it a bit more to see what it could be before sending you my gigantic files.

Thanks a lot for now