Another materials problem? Tweet

[Graphichandyman]

I wasn't sure if to start a new topic or not, but as this is my first post (hello everyone) I thought I'd start a new one.

My problem is I'm afraid I don't seem to be having the same experience with materials as others. At least I'm suprised that no one is reporting problems as serious as I'm having.

Simply put...the material settings from octane save fine, if I just intend to reopen the scene file at a later date, but if I make any changes to a scene in blender and I'm re-rendering, (or on the few basic animations I've tried) all of the material changes made in octane are lost and replaced with freshly exported blender materials.

I do make sure I click on 'use exisiting project' which seems to just ask me to confirm the path to the project but doesn't stay highllighted. (is that right?)

If I make no changes in blender and just export the obj/mat then the octane materials are preserved if I manually restart the project in octane.

If I change anything and use the exporter (still or animation) all my octane material changes are lost and return to the basic exported blender materials.

Am I missing something? because it doesn't seem right. Surely it's normal to make last minute changes to a scene having seen an initial render (without having to redo the scores of materials in the scene each time)

Thanks in advance and apologies if I'm being dim!

Giles

[face]

It´s since pre 2.3v3
I think Octane preferred the materials in the obj-mtl file.

If you load the ocs in Octane manual, the materials from the ocs file are used.

face

[matej]

This has nothing to do with your material making abilities, it's a bug that has already been posted in the current version testing thread. A workaround (as I do it) is to create material macros for all your materials, instead of just tweaking the settings in the node inspector. Macros are saved properly even if you re-export from Blender.

[Graphichandyman]

Thanks guys. All I'd seen in the testing thread about materials were more about nodes not connecting properly during animation ect. I didn't think this was the same issue.

face..even with reopening the scene manually I'd lose the materials 'if' i'd made changes in blender. Without changes it was fine but then re-exporting having not made changes was silly, just a test really to see what happened.

Anyway, I'll try it with macros...thx matej

and sorry for starting an unnessesary new thread, although it's no bad thing to have this issue in plain sight. I spent a fair while both trying for a solution and looking for an answer.

Anyway...I'm loving octane!

Thx again

Giles

[Graphichandyman]

I've just done some testing, and although this might be known to the developers and others, i've not seen it posted. It might be an easier workaround for the time being for others.

I was finding that making macros for all my textures was really time consuming with lots of extra clicks to set them up.

Having tested those times when I had gone back to make changes in blender and then lost my material settings when I re-exported, I noticed the following.

If I want to make changes to the mesh and add new materials in blender then upon re-exporing my materials in octane would be messed up, as per my first post above.

I was testing different changes and had kept a copy of the 'working' obj, mtl and ocs files to one side and would repaste them back everytime something went wrong.

so...By keeping the original 'working' .mtl file open and then opening the newly created mtl associaled with the messed up export I noticed that for some reason the materials in the messed up mtl file were in a different order.
I had previously wondered why I could reopen a working project and the 'blender' materials in the mtl file wouldn't mess up the reopened ocs file, but that on re-export they did.

Well it appears that if octane doesn't get them back in the same order it 'reassigns' the materials based on the blender originals in the mtl file.

So I reordered the materials in the new .mtl to match the old, putting any new materials at the end of the list and the new exported mesh then opened with all my 'octane' materials intact.


Again I'm sure the Dev's know this but I havn't seen it posted anywhere, sorry if it has.

If i had a scene of 6 or 7 materials it was much better doing this than making macros.

Sometimes its just one material that gets reordered, so it's a few seoconds work.

Cheers

Giles

[matej]

You don't have to create texture macros, just material macros - load every needed tex in there and create the nodes you need.

I found out that Octane messes up the connections of mat.macros when I re-export (and maybe add new materials in Blender), so I have to re-connect everything.

The .obj/.mtl workflow is really messy, hopefully Refractive will soon integrate geometry & material data into the scene file and get rid of .obj

[Graphichandyman]

yeah where i mention texture above, read 'material'...anyway I still find it a pain, but what i'm really saying i guess is that if there was a way of introducing consistency into the order the materials are exported, the problem I mention in this post wouldn't be a problem anymore.

I doubt blender keeps a record of when a material is created so chronological ordering wouldn't work, and alphabetic order wouldn't work either because that would change when new materials were added, but it seems that materials wouldn't get messed up if they always get exported in the same order.

I'm no coder but perhaps some sort of array that was fixed from the first time the exporter was used, and where new materials only get added to the end.

Tell me to shut up if this is waaaaay off the mark

Giles

[matej]

Probably could be done something along those lines, but IMO it's a waste of work. The .obj workflow is a mess because you need to keep 3 files consistent and at the same time respect the .obj specification (which is a limiting one). I don't know what the devs have exactly in mind, but hopefully they will get rid of .obj. A single .ocs file that would keep all data will be a better solution. The exporting & parsing times would also be shorter and the whole thing would be easier to manage.

We will see...