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