clausgsTry exporting SU scene to .ocs/.orbx, it looks like a huge mess. Trillions of nodes connected to each other. Exporting feature was never planned in the beginning and was added later so it exposes how SU objects are mapped to Octane which is not user friendly. Since I plan to add more Octane UI to the SU plugin you will work with visual nodegraph editor. I plan to reorganize internal structure of nodes to group them and reduce clutter so you can either export SU scenes to Standalone and work with them from there or have more comfortable editor inside SU.
neo83_grSort of. It's not quite possible to group materials to object groups because objects reuse materials. It's easy to do this on export, but it's impossible to make them internal inside of editor.
resmasI'm looking into layers now. Not sure how they can save the problem but that's only because I don't quite get it how to use them.
SeekerI guess I owe you a more robust explanation of my roadmap vision.
Step 1I change how things work internally by regrouping the node spaghetti, moving materials to a separate nodegraph (group) and grouping all the objects in a smart and clean way. This step also implies fixing SU2015 stability bugs and adding recent SDK 2.21 features to OctaneRender window along with adding scenes(pages) as render targets. At this stage node grouping gives you ability to continue working in Octane Standalone in a clean and hopefully simple way.
Step 2Replacing material editor window with Octane's visual nodegraph and node editor. I guess that was one of the most awaited features. Here all scene materials will be located.
Step 3I plan to expose nodegraph editor for all the nodes in the scene. Here sync should already work for material nodes and I'll have to add sync for rendertargets etc. This is the hardest part and I might never implement it, will see.
--
As for your questions:
2. Components should be instanced if possible since that's the way SU treats them to save memory;
It's already so.
3. I thought that groups in groups (or components within components) should somehow repeat that order in the node structure with geometry groups. But I am not so sure that it critical simply because, as long as the plugin works well and is stable, with 64bit and the Octane node structure exposed, would we still need to resort to Standalone at all?
I haven't found a proper way to group nodes yet. Still working on it.
Cheers