OTOY Forums

I've had the problem before when you merge a scene that the material surfaces get lost to the octane plugin. I don't understand why this can't be fixed by saving the file without the plugin enabled to get rid of the octane data, and then reopening it and starting from scratch with materials.

Instead octane still is missing a ton of surfaces. it doesn't add up.

I today experienced this issue but without merging. I am working with Victoria6 and added a regular genesis figure to scene as well. After a while I noticed that V6 had lost all but two of her surface areas to the plugin. I don't know what caused this. I turn off the plugin, restart daz and open the file. I save it again. I turn on octane and restart. Open file and surfaces are still gone.

Because I often do not work with surfaces open, and often I keep the render paused I sometimes don't notice issues until too late. This is just a test project so nothing serious lost, but it is confusing.

i think i uncovered part of todays issue, it's has to either do with material presets, or having genesis and v6 in the scene at the same time with the same material preset.


EDIT: Also applying a material preset to V6 that is for S5 will cause this issue. While S5 textures do not work on V6, they should not cause the scene surfaces to disappear from the octane plugin. the only scene surfaces that remain are ears and eyereflection, and I think that is because they are new zones.

EDIT2: looks like only user created material presets cause this issue. All i'm doing is applying daz presets (some prior to DUF format) to genesis 1, then saving material preset in DUF so it can be used on V6. (yeah i know S5 isn't meant to work but had to try lol).

Even applying a V4 material preset causes issues. If you have both genesis and v6 in a scene apply the v4 preset to V6. Things are ok. Then apply to genesis, both figures lose their scene surfaces (with the exception of ears and eyreflection for V6)

if you just have genesis in the scene it will happen to her alone.

if you apply aiko 5 texture to genesis no problems. Save that as a material preset and it works...So its not all user made presets. I'm confused and opened a can of worms. Exiting stage left now.

i'm currently rewriting the way how materials are collected, using .duf, .dsf, .ds, .dsa, or .dsb material sets; trying to find new ways to react on changes and judge how they were meant (since some of these formats don't actually tell the plugin about load operations).

this should solve the following problems:

* applying dz mat sets while having multiple figures in a scene causing the plugin to loose track of (existing) dz surfaces (most probably this is a big part of what you seeing here).

* avoiding the creation of completely new octane mat sets, if only a partly dz mat set was loaded.

* maybe(!) - i'm not completely sure if get this done right now - allowing auto updates for maps only, while keeping octane materials.

if the latter is ever included, it'll be definitely an optional feature as the plugin will _never_ know for sure if it is ok to replace a specific map against something that is loaded (or applied ny editing the dz material directly)...

ok thanks.

But how come I can't get rid of the octane data so that it forgets about the problem? I thought daz got rid of plugin data if the plugin was not active?

is there still data put into the duf I can remove?

larsmidnatt wrote:ok thanks.

But how come I can't get rid of the octane data so that it forgets about the problem? I thought daz got rid of plugin data if the plugin was not active?

is there still data put into the duf I can remove?

imo we are speaking of two different problems here, which appear to look identical, because the result looks similar (missing surfaces);

the plugin adds an identifier (a guid) to any dz node and dz material - this "element data" is never removed even if a scene is saved without the plugin. the other side - the connections to octane data (which rely on this identifier) and the octane data itself is saved as database as "extra scene data" into the scene - for whatever reason studio won't keep this if nothing keeps track to insert it again on every save.

if you merge stuff (either by dropping user saved presets, or simply by using "merge"), the plugin needs to transpose all these identifiers (in its own database and for any dz node/material correspondingly), since they might already exist. and at this point something gets wrong that is indeed also part of the .duf/.dsf load handling (which i'm rewriting).

putting it short: if this procedure works correct and under all circumstances, it will of course not only causing problems for new saved stuff, but will also allow adding previous saves without the need to clean something by hand.

sadly there is now way to manually remove this identifier.

what would help me to see if the solution works for stuff that did undergo a lot of save/load cycles is to have 2 files (say a scene and a user preset) which mess up if combined...

ps: there was a part of the explanation missing: the plugin never removes these identfiers, but only updates them. so even if saved without the plugin, the scene elements keep them, and the next load with the plugin active causes the problem again, since the plugin always uses existing ids and now stumbles over the same duplicate ids which it isn't able to resolve...

This probrem caused by redundancies of "ouid".
If you save material presets or charactor presets or scene subsets, .duf file includes "ouid" data.

How to fix
1. Save your presets without "Compress File(s)".
2. Open file with notepad.exe or other text editor.
3. Search section "name" : "OctaneRender_data"
4. Delete or rename all of them.
Easily way is to replace all "OctaneRender_data" to "OctaneRender_data_bak"

shadowgenic wrote:This probrem caused by redundancies of "ouid".
If you save material presets or charactor presets or scene subsets, .duf file includes "ouid" data

wow - congrats for digging that deep ... and my apologies for still not having the update out which will (of course) fix this...