Export ORBX and Alembic - some issues

[jamnique]

Hi,

I'm having some issues with the export archive module:

The basic problem:
1) It works and then suddenly it doesn't (nothing gets written to disk), it seems random.
2) One thing I can always reproduce is not being able to export the scene when Full Scene reload mode is on.

When the scene gets exported successfuly:
1) Performance of the same scene after export in standalone is a hundred / thousand times slower than in the plugin. I go from 25 to 0.005 Megapixels per second.
2) Depth of field is wrong and there's no control to fix it (correct me if I'm wrong).
3) Shutter speed is off too.

I attach a Houdini scene with several Output ROPs with different settings. Only one of these works for me. System specs are inside the file as well.

A. Operating System - WINDOWS 7
B. Graphics Card(s) - GTX 960 + GTX 980 Ti
C. RAM Capacity - 64GB
D. Nvidia driver version - 359.00
E. OctaneRender Standalone version - 3.00
F. OctaneRender plugin version - 3.00.20.0
G. Host application version - Houdini 15.5.480

[juanjgon]

Thanks, I'll check this problems as soon as possible.

Anyway, currently the ORBX export feature only works in update mode because an ORBX file only can have one state of the scene with animated parameters. You can't store for example a scene where the objects don't have a constant topology among all the frames. I short: if a scene can't be updated, it can't be stored in only one ORBX file, you will need a ORBX file for each frame.

-Juanjo

[jamnique]

Thanks, I'll check this problems as soon as possible.

Anyway, currently the ORBX export feature only works in update mode because an ORBX file only can have one state of the scene with animated parameters. You can't store for example a scene where the objects don't have a constant topology among all the frames. I short: if a scene can't be updated, it can't be stored in only one ORBX file, you will need a ORBX file for each frame.

-Juanjo

I see, but I'm not sure I understand why completely.

In Full Scene reload mode all the geometry is being saved to an Alembic alongside the ORBX, right? Why can't the ORBX just read the Alembic as usual? Is it unable to remember which frame of the Alembic it should be reading at a given time? Same thing with animated textures. Can't the imported scene contain little Script nodes that tell the animated textures to update every frame?

[juanjgon]

The alembic file is inside the ORBX file. In fact you can remove the .abc file written by the plugin if you want, you don't need it to use the ORBX file.

The ORBX is a container. It has all the objects and texture maps inside. It only can have one root scene with animated parameters. The mesh deformation can also be animated, but only in objects with a constant topology. This is how ORBX works. I am not sure what can be done with scripts inside the ORBX file, but from the plugins the ORBX is written using an API that only supports objects with constant topology.

I can add a feature to export the scene to multiple ORBX files (one for frame) if the scene is set to full scene reload, but generate only one ORBX file with a scene that can be updated, is not possible currently.

What workflow are you using to need full scenes exported as ORBX files?

-Juanjo

[jamnique]

Thank you for the explaination. What I would like to do is export the scene in a format that allows for rendering on another machine that has a standalone license.

I don't really need the whole scene to be encapsulated in one file. It could just as well (or even better) be an Octane Scene that replicates my setup from the plugin and holds a reference to an external Alembic archive or archives. I need full scene update because I often have changing topology. Multiple ORBX won't work for me, unless there is an automated way to render the sequence of ORBX in standalone.

I have access to two 8-GPU machines with Standalone Licenses. With network rendering the benefit isn't that great - 2,5 times faster on 2x8-GPUs than on my 2-GPU local machine... I guess at some point it's impossible to get lower rendertimes, since loading the scene to memory and saving to disk takes time. I tend to get 2600-frame scenes (then 2600 frames for the other eye) that render quite fast, but load slowly, so voxelising time is the biggest bottleneck. That's why it would be beneficial to split the rendering between two or three machines.

It would be even more beneficial to render 8 frames on 8 GPUs simultaneously, but I don't think that's possible now.

I have some more bugs. Should I post them here or start another thread?

[juanjgon]

I can add to the plugin the feature to export an .orbx file per frame, that should support any kind of scene, but the problem is that currently an .orbx file can't reference external alembic or texture files. All the scene information (meshes, textures, etc.) is encapsulated inside the .orbx, so the files can be really huge. But later it is true that you could render them from Standalone (I suppose that using a render controller or a script) to get better rendering performance in your render nodes.

Other solution can be try to support the .ocs file export from the plugin. The .ocs files at least should reference the texture files, so the whole exported scene can be smaller. Let me think about it.

Do you have a Houdini license in these render nodes? Of course with Houdini and an additional plugin license you could render the scenes without problems, but I suppose that they are render nodes without Houdini licenses available.

Feel free to report all your issues with the plugin here, no problem at all.

Thanks,
-Juanjo

[jamnique]

Thank you Juanjo. Unfortunately Houdini licenses are in high demand, and it would be too expensive to buy new ones with Octane plugins just for that purpose.

As for the bugs:
- Color RGB has wrong type of output (white) and doesn't work
- Emission BlackBody doesn't work in MediumVolume
- One I've mentioned elsewhere, but I think is very important - Rendering multiple ROPs Frame by Frame doesn't save any frames, while it seems to be rendering normally and doesn't give any warnings. it's the default mode, so it's very easy to make a mistake. I think this should be at least mentioned in the documentation. A warning would be better.

Some minor things that probably can't be helped now but would be nice to have:
- Octane VopNets don't show up in the Material Palette
- Dragging and dropping Octane VopNet in the viewport doesn't work

Sorry for nagging, thank you for the amazing job you've been doing.

[juanjgon]

Thanks for the feedback about the plugin.

Yep, it is true that the RGB texture node output has a wrong type, probable due to a bug in the Octane API. I'll check it, but anyway the node should work, even with the error shown in the Octane node, as you can see in the attached image.

The emission blackbody in the volumes works using the emission grid data as color temperature, so usually you need to scale the emission grid to have values in the range of a blackbody emitter. For example if the emission grid has values from 0.0 to 1.0, try to scale it by 5000 to get right values for the emitter temperature (in this example, from 0.0 to 5000.0).

-Juanjo

[juanjgon]

One I've mentioned elsewhere, but I think is very important - Rendering multiple ROPs Frame by Frame doesn't save any frames, while it seems to be rendering normally and doesn't give any warnings. it's the default mode, so it's very easy to make a mistake. I think this should be at least mentioned in the documentation. A warning would be better.

The next plugin build should support rendering multiple ROP nodes frame by frame. If you find problems with this feature, please let me know.

Thanks,
-Juanjo

[jamnique]

Cool, thank you! Is it in 3.02, or the next upcoming version?