OTOY Forums

Hey,

Trying to work out if I can have Octane load geometry cached to disk files at render time, without needing to load the instances into Houdini.

I've got it working using a point wrangle to add per-point "instancefile" attribute (as opposed to "instancepath" to point to another Houdini OBJ node).
ie: s@instancefile = "C:/pathToFile/instanceGeo.obj";

...and that appears to work, but it also appears to go through a process of loading the obj temporarily into Houdini when the render is launched.

Is there a file format that can passed natively to Octane so that it can load the geometry straight from disk? If so, would I still use "instancefile" to pass it the path?

The reason I want to do this is for animated frame-sequences as instances - I really don't want to have it loading hundreds of different instances through Houdini each time if possible.
To that end, would it be possible to just pass an Alembic file as an instance, containing a complete animation, along with a time attribute to tell it which frame of the instance to render for each point?

Hmm, actually, it doesn't seem too bad just having it reference bgeo.sc files and letting Houdini handle loading the instances, provided I just leave it as raw path strings on points, and avoid letting Houdini load them into the scene as packed disk primitives.

Would still be nice to know if there's a way to pass paths to some kind of native geometry format though, skipping out the middleman is usually a good idea with heavy instancing...

Octane can load alembic files (and probably usd files soon) at the render time, like what happens now with the OpenVDB files, but this feature is not supported by the Houdini plugin yet. I want to work on it in this Octane 2022.x dev. cycle, so I hope to have good news about it soon.

Thanks,
-Juanjo

Ah, thanks for the info Juanjo! Sounds promising. I think the way it works now is enough for my current project, but I'll certainly stay tuned for developments.

For my part, I tend to prefer doing everything by Wrangle, so I wouldn't need much of an interface - just to be able to slap an alembic path string and a instance anim time attribute on the points, and have Octane interpret them correctly.


On the matter of alembic instances... I presume the memory/speed benefits of instance-reuse would only apply when significant numbers of points were sharing the same exact time/frame as each other. I'm guessing each frame of an alembic would need to be "unpacked" into a separate copy of the geometry at render time... sound about right?

Yes, while instancing all the instances must share the same base mesh, so if the mesh is animated, a copy of each frame must be stored in the memory.

-Juanjo