Feature request : retain texture maps

[Pschelfh]

I also have the Poser plugin and there's a nice feature when applying an Octane shader : retain texture map.
It's a bit like in DAZ Studio where you can apply a shader while holding Ctrl, this keeps the textures in place and only updates the shader settings.

Don't know if this is possible because the material management is a bit different than in the Poser plugin.

Peter.

[sikotik13]

Up through OcDS versio 1.2, (and I think 1.55), texture maps were retained. The current dropping of textures (which should be transferring to relevant texture nodes through autoconversion), is considered a bug, and has been reported. The dev has acknowledged the bug, stating it is caused by the way DS 4.7 changed the way materials link. He is working on it, according to his response.

[t_3]

in addition to what sikotik13 wrote:

i was never to keen about trying to do exactly this stunt, because there is imo no 100% way to replace the maps to always get exactly what you would expect; that the poser plugin can do that rather easily has (as far i know it) to do with the fact that materials there are always "flattened" - means no explicit grouping whether for materials nor internal nodes. and maybe it's easier to retain particular info from the poser api than it is to get the same info from the daz api (don't know).

2 reasons i stayed away from that until now:

1st: in ocds the a single octane material can be linked to multiple surfaces; if maps were change differently within the linked daz materials, there is no longer a similar set of maps for the single octane mat; so there isn't any longer a simple replacement rule like replace all A's with B's.

common example: the torso daz mat was changed to now use a diffuse map with a tattoo imprinted, but the neck mat did keep the original torso map (lips and face are also pretty common to behave like that) - initially there was only 1 octane mat for both surfaces (because they did initially use the same set of maps and settings). since there are now different sets (torso original, torso with tattoo), they can't be easily replaced... most probably it would be ok for the neck surface to also use the tattoo map (usually such a map is overall the same, with only some particular details changed) - but the plugin can't know that - it can't judge the maps by their content... only a human is able to do that.

the only proper answer to this is to split the previous single octane material into 2 new materials, and then replace the maps.

2nd: the material can be pretty complex; maps might be used with several mappings for different aspects within the octane material; i.e. a diffuse map to also serve as scatter map with color correction and inversion, and also as bump map (maybe because there was no particular bump map in first place). when such a material is created, you usually have the map as single image node, connected to different other (mapping) nodes, finally reaching one or multiple material node(s). if the changed daz mat now contains an additional bump map, it should be most probably used, but simple replacing maps won't achieve that since the octane mat originally didn't contain a reference to a specific bump map.

and apart from that it isn't exactly easy to find out what the previous map of a daz texture was - what i of course need to know since i need to do replace "filenameXYZ.jpg" to "filenameABC.jpg" but studio only tells me that there is now a "filenameABC.jpg" and not what the previous map was - so a replacement isn't exactly easy without this information

and you need to take into account that these changes can come from everywhere; copy and paste in the surface pane, browsing disk, or loading mat scripts that replace stuff with or even without the plugin being explicitly notified.

so far so ~~~ simple wish, but to execute it in a way that gives the expected results for at least most cases is far from simple.

i have meanwhile refined my internal handling of texture maps (because of other needs) and currently track any changes in studio regarding maps (at least so far technically possible). so i'am able to keep (and compare) before/after states for most changes (what studio doesn't provide for almost none of its internals). means one aspect of the problem is solved.

in addition i store masses of meta information about changes, where they did come from, why they did (most probably) happen, and what the expected results should most probably be, which solves another bit of the initial problem.

...

my first answer to allow _controlled_ replacements of maps within octane mats, while keeping structure/settings of any complexity was to implement templates; on one hand they allow to exactly tell an image node where it should take maps from (with fallbacks), and applying templates also regroups (splits or joins) octane materials according to the needs of the new map sets that are found when a template is applied (given they work as intended )

but finally... making use of the new code stuff (i.e. tracking of map changes) and methods from templates (split/join oc mats) a generic "replace maps / keep settings" method is going to be possible - in a way it works always for auto created materials, and almost always also in rather complex wired octane materials. can't say for sure if it is coming already with the next update, but most of implementation is done already...