OTOY Forums

Hi all,

I plan to start working on a new build with properly grouping objects so exporting to OctaneStandalone and exposing visual nodegraph editor in standalone will make sense. I need your input on how to group geometry objects and materials. I need volunteers to help. If you already have ideas here I would love to hear them.

Cheers,
Bro

Hi Fuzzybro

Here to help if i can.
But i am not really sure i understand what you are talking about.
You mean that you want to know how a scene exported from SU will look inside octane standalone????
Before everything was ordered / organized by material in the left side window, what for me make sense as that is what you would need to adjust in an imported SU model.
Maybe if you could give some examples it would be easier to understand what you need...

Something like scatter nodes with materials grouped maybe? Or if the geometry nodes had the materials embedded instead of connected so we have less nodes (like the obj files of the Tig exporter, or every obj mesh we import)

Hello mate, I think Smicha pointed some cool suggestion in this post.

viewtopic.php?f=31&t=41560&hilit=perfect+exporter

My thoughts :

1- Scenes exported as Render targets
2- Layers - now we have it in StandAlone

cheers
resmas

Fuzzy,
I have more questions than answers at this point, I'm afraid. I'd like to understand a bit better exactly what you have in mind. You plan to expose the Standalone interface to SU, right? So it's more like a live link than an export situation - just like the current plugin but with the node structure available. Is that correct? Would the node structure be reverse-compatible with SU - i.e. if we change something in the plugin nodes, does that change port back to SU? Or is the node structure only visible in SU but when exported the structure is retained? Also, with Tig's exporter, I liked exporting an OBJ to texture in Standalone, then making changes in SU and exporting again by simply overriding the previous OBJ file, mening my texturing was intact. I probably won't have a great need to go to standalone a lot as long as all nodes & pins are available in the plugin, but I'm just curious how you see the workflow.

My initial thoughts:
1. I'm with Resmas - this is critical.

resmas wrote: 1- Scenes exported as Render targets.

2. Components should be instanced if possible since that's the way SU treats them to save memory;
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?

As always, I am available for testing and can't wait to get a working 64bit solution here...!

Best,
Seeker

clausgs
Try 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_gr
Sort 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.

resmas
I'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.

Seeker
I guess I owe you a more robust explanation of my roadmap vision.
Step 1
I 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 2
Replacing 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 3
I 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

Thanks Fuzzy. Good to see you back on the job.

I have been working extensively in Sketchup 2014 and the Octane plugin recently. Besides 32bit performance limitations of SU and the continuing bug of some materials still losing their scale, I have really enjoyed the powerful combination of SU & Octane.

Specifically, regarding moving the material editor to node editor, may I request that one link, controllable from SU's material editor is retained? The 'global' material scale in the SU material editor, which saves us from having to manually adjust UV's for every pin individually on poorly created LiveDB materials... Ironically, I think this feature is buggy right now with some materials losing scale like I reported many times before, so it needs a bit of attention. But when it works it's brilliant. Incidentally, I personally don't have a need for trying to port Octame materials back to SU and I think it caused more hassles than it solved. Just my take on it.

It would be good to allow your beta group early access to the proposed structural changes for feedback - it would be good to make sure we don't lose any of the strenghts of the current offering, but rather build on them.

Best,
Seeker

Global scale is here to stay, don't worry

Seekerfinder wrote:Thanks Fuzzy. Good to see you back on the job.

I have been working extensively in Sketchup 2014 and the Octane plugin recently. Besides 32bit performance limitations of SU and the continuing bug of some materials still losing their scale, I have really enjoyed the powerful combination of SU & Octane.

Specifically, regarding moving the material editor to node editor, may I request that one link, controllable from SU's material editor is retained? The 'global' material scale in the SU material editor, which saves us from having to manually adjust UV's for every pin individually on poorly created LiveDB materials... Ironically, I think this feature is buggy right now with some materials losing scale like I reported many times before, so it needs a bit of attention. But when it works it's brilliant. Incidentally, I personally don't have a need for trying to port Octame materials back to SU and I think it caused more hassles than it solved. Just my take on it.

It would be good to allow your beta group early access to the proposed structural changes for feedback - it would be good to make sure we don't lose any of the strenghts of the current offering, but rather build on them.

Best,
Seeker

hi there,

me too is for what smicha suggested in theh other thread linked in the second or third post...

that would be the way to go=)

I'm experimenting with grouping and the way smicha pointed is pretty hard to implement. I'll start with an easier way and then go from there.