Re: OctaneRender™ for Blender 1.52 - 4.8 beta Win [TEST]
Posted: Tue May 06, 2014 11:51 am
@Resmas : Thank you ! I am glad that some misunderstanding of someone can lead to better understanding for someone else 
@jimstar :
What I had in mind would not (at first glance) require exchange of data between nodes inside Blender, and the server.
I didn't thought to connect with a real node inside blender, but rather try to emulate a basic node by a unique static block of data written inside the plugin code itself or in a text file.
It is just an idea as I have no idea of how the whole system works, and unfortunately it may not be compatible with what you said above about a kind of symmetry between Blender and the server. This could also explain that :
When comparing obj export and alembic export, there is a thing that looks paradoxal from a user point of view :
when exporting in obj, by the blender built-in exporter as well as with community addon, material data are exported in obj (mtl) regardless to the kind of material : Blender regular material, Cycles node, Octane node...
When exporting in alembic, materials data are not exported, but the export process is sensitive to the nature of the material source !
As you suggested, a Python script/addon would be of a good solution to assign a basic material to all material output nodes (while keeping the original material names)... Any Python coder in the room ?
@jimstar :
I am hopeless at coding. I did only few little programs in Quick basic almost 30 years ago, so it remains me only a little bit of theory. I have absolutely no knowledge or skill in any modern coding language.You can not have some object on the server which do not have their counterpart inside Blender, and vice versa.
So, you must create any node inside Blender which you want to see synchronized with the server, no matter for image rendering or for any data export.
What I had in mind would not (at first glance) require exchange of data between nodes inside Blender, and the server.
I didn't thought to connect with a real node inside blender, but rather try to emulate a basic node by a unique static block of data written inside the plugin code itself or in a text file.
It is just an idea as I have no idea of how the whole system works, and unfortunately it may not be compatible with what you said above about a kind of symmetry between Blender and the server. This could also explain that :
When comparing obj export and alembic export, there is a thing that looks paradoxal from a user point of view :
when exporting in obj, by the blender built-in exporter as well as with community addon, material data are exported in obj (mtl) regardless to the kind of material : Blender regular material, Cycles node, Octane node...
When exporting in alembic, materials data are not exported, but the export process is sensitive to the nature of the material source !
As you suggested, a Python script/addon would be of a good solution to assign a basic material to all material output nodes (while keeping the original material names)... Any Python coder in the room ?