ORBX export limitations & documentation urgently needed... Tweet

[renderingz]

There is practically zero information on the ORBX export limitations in the documentation, or how to optimise or do practically anything with this. Can we please update this?

I'm having a nightmare trying to export a scene with a packed alembic which is about 900mb on disk. When I try to save the scene to ORBX with only this alembic inside, it turns into a 14GB file and takes about half an hour to save. This has been a long standing problem and I'm surprised this hasn't been addressed properly.

Does exporting animated houdini scenes as an ORBX just not work?

[juanjgon]

The .orbx exporter only mirrors in a file the Octane scene that is rendered if the export option is disabled, including the texture files or other assets inside. It is hard to know why the exported file is so big or why it takes so long to be exported, but you could enable the Octane log file and check where the plugin is spending the time to have a clue about it. The big size can come from the size of texture assets embedded in the file or from huge mesh data assets due to the motion blur samples that are computed while extracting the scene.

You can even analyze the content of the .orbx file by uncompressing it from Standalone (File->Unpack Package). This can help to know what's going on. One of the planned features for the future is the rendering of alembic files as references without extracting them on the plugin side, but I don't have any ETA about this feature yet.

Thanks,
-Juanjo

[renderingz]

The problem is it's taking alembic caches and rather than just applying the transforms to the rest geometry on export, it's unpacking every single frame, baking millions of polygons unnecessarily. Is this the expected behaviour? How can I set it this up so that it just transforms the packed rest geometry on export instead? It's inefficient to the point of being unusable in it's current state.

Do you have a workflow guide or example scene that shows how to approach different types of geometry export efficiently for ORBX? Preserving instance attributes etc.

[juanjgon]

I'm afraid that currently, this is the expected behavior. Without referencing the alembic file itself, the plugin extracts each frame adding it to the .orbx file. The main problem is that when the .orbx file is huge, adding a new frame takes a lot of time, which is probably why the scene export time is so large (this is something done by the Octane core and is not very efficient)

To be honest, creating a single .orbx file that includes animated sequences while working on complex production scenes is not a good idea at all. As happens in other renderers, each frame should be exported to a single file to avoid these problems. You could try that yourself rendering the scene frame by frame using PDG, a custom render script, or perhaps even an external controller like Deadline.

As I've said, referencing as external assets the alembic or USD files is probably the right solution for this issue (like what happens now with the OpenVDB files, for example). We hope to be able to work on this feature throughout this year.

Hope it helps,
-Juanjo

[renderingz]

Writing an ORBX for each frame still wouldn't reduce the overall file size, just the individual. The intention is sending this to RNDR, which basically sounds impossible with anything more than simple scenes? A simple packed geo sequence that's 1gb on disk would expand to 60gb+ over 300 or so frames.

Does RNDR even support the rendering of single frame ORBX files as a sequence?

[juanjgon]

Does RNDR even support the rendering of single frame ORBX files as a sequence?

I'm not sure if RNDR has been designed to render single-frame ORBX files, to be honest. Perhaps an intermediate solution exporting batches of .orbx files including 10 or 20 frames each one could help. I know that there isn't any ideal workaround to improve the rendering of this type of scene from animated .orbx files until we have proper support for alembic or USD files as proxy objects. We'll try to work on this feature ASAP.

-Juanjo