texture path problem

[v-cube]

Hi Paul,

As you have probably already noticed, I am spending a lot of time now exploring the possibilities of the Node Graph editor, hence the large number of bug reports - sorry ...

This one resulted after I moved the test scene from my desktop to my archive. After opening the scene again after the relocation, I started octane to see what happened.

first I got this error message:

unfortunately unlike the normal octane material without graph editor, I do not get prompted with the possibility to search for the missing maps.

then I opened the graph editor:

As you can see the place where the image file path is supposed to be is completely empty.


All in all this means that the use of my new beloved NodeGraph is very dangerous, since every broken link results in the inability to repair it due to the lack of any usable information.
This is a real showstopper for professional use IMHO.

I guess you remember my constant lamentation about getting an asset manager... while I almost lost hope for this, we need at least the "search for missing texture feature" like in the regular octane material.

best

Andreas









another thing

[v-cube]

... Just a little thing, despite all the bug reports I am sending, I would like to say that I really enjoy working with this SW!
Especially now with the implementation of Rhino Nature and my latest exploration of graph node and OSL, I have the feeling that the overall quality of our work improved significantly!
I think sometimes when reading through the treads one might get a kind of "negative bias" how good the SW runs overall, so this is just to show my appreciation for the work you guys are doing.

this is just a test scene, where I tried out OSL scripts for multi textures, chaos node, combining different displacement maps and decal placement... works pretty neat I have to say...

this one is an old file I used to casually test the latest Rhino Nature release. This is a real gamechanger and I am soooo happy that octane for Rhino is one of 2 render engines to support this fantastic approach.

so:
THANK YOU !

[face_off]

All in all this means that the use of my new beloved NodeGraph is very dangerous, since every broken link results in the inability to repair it due to the lack of any usable information.
This is a real showstopper for professional use IMHO.

Yes, this is a problem. When the .3dm file is loaded by Rhino, the nodegraph materials are simply XML text - not Octane Image nodes (where the existence of the file is checked). There is a hook in the Octane API to capture the event of missing assets, however it is not working, and I have reported the issue to OTOY. If this is fixed, it might be possible to come up with a solution (however it may not be simple - as the Octane "missing asset" event hits the interface layer between RhinoCommon and the Octane API, so it may not be possible to pop the standard "search for missing texturemap" dialog. I would need to investigate more once the Octane API end is working correctly.

The other solution could be that the plugin parses the XML strings that contain the filenames and check for their existence.

In the meantime, yes, it's an issue that you need to carefully manage.

Thanks

Paul

[v-cube]

well, that does not sound good, this is so frustrating, for everything I learn there seems to be a major setback.
I really thought Node Graph could solve the limitations of the old Material Editor and now this road is also blocked...
Not being able to move the file is not an option.

[face_off]

The other solution could be that the plugin parses the XML strings that contain the filenames and check for their existence.

I have been able to implement a version of this, which will be in the next release of the plugin.

Paul

[v-cube]

OK this is awesome and extreme fast... I am sorry, but in your last post it sounded to me like this was very hard to implement ... however this is great news!