OTOY Forums

I start a new thread with the idea to give an overview of all the different Material Conversion issues that were present in the "last beta" build 2.23.

face_off wrote:

02 Materials Conversion - problems converting materials from Daz to OcDS (Iray materials not supported, materials not converting, mesh-plain collision causing artifacts and blotches, issues related to creation of 'Mix Material' (such as Normals Map defaulting to 2, which causes Toon textures in Daylight Environment), etc.)

Can you pls provide sample scene which demonstrate the material conversion issues.

Thanks

Paul

How did Materials Conversion in OcDS work before?

In general to get familiar with the material loading and converting workflow in OcDS it can help to read trough:

FAQ - Loading and converting DAZ Studio materials

viewtopic.php?f=44&t=41543


Auto Conversion of materials is triggered

When a checkmark is placed in the box placed in the box "Automatic material updates after content loads" in the Preferences Tab

- at scene load by default

When no checkmark is placed in the box placed in the box "Automatic material updates after content loads" in the Preferences Tab

- when using the button Missing - Create as Auto Materials in the Materials tab

This would autoconvert all materials in the scene of surfaces that were not yet edited.

or
when right clicking on any material and selecting "Create as new material - Auto material" in the Materials tab.

- - -

OcDS 2.1 PRE RELEASE 5th

OcDS 2.1 PRE RELEASE 5th had a simple but working auto materials conversion.


OcDS would convert standard 3Delight default shaders into a diffuse material with diffuse maps and bump maps.
OcDS would convert metallic 3Delight default shaders into a glossy material with diffuse maps and bump maps.

Sometimes OcDS would take Displacement maps and add them to the bump channel.

Normal maps, SSS maps, Reflection maps, Specular maps and other DS specific custom maps were ignored.
3Delight specific shader bricks were mostly ignored unless they had a close match in an OctaneRender node. (Tiling etc.)


"last beta" build 2.23

Some users like to custom create OctaneRender materials starting from a basic diffuse material. Those were mostly happy with the basic Prerelease 5th autoconversion.
Other users asked for a more advanced auto conversion.

As a result In the "last beta" build 2.23 a more complex material conversion was introduced.
Instead of creating a basic diffuse material as before now a Mix material was created.

Unfortunately that had several side effects.
- Experienced users now had actually more work to get started because they first had to manually remove unwanted extra nodes created with the Mix Material to get back to a simple diffuse material node layout.

- The Mix Material node setup was not creating good looking materials and seemed in an unfinished state
User noticed several errors like issues with Normals Map, artifacts and blotches

- - -

Iray Conversion

DAZ Studio 4.8 introduced Iray as a new default render engine.

Currently most artists provide both 3Delight and Iray shader versions for products sold in the DAZ3D store.

It is unclear if in the long run products may only include Iray shaders with 3Delight becoming less supported.

Currently for OcDS the recommendation is to use 3Delight materials and use auto conversion to OctaneRender.

Nevertheless OcDS users hope to get better results with an Iray to OctaneRender auto conversion workflow in the future.

The hope is that Iray nodes are more similar to OctaneRender nodes to make it possible to also convert some Iray specific shaders.

- - -

Advanced Auto conversion Features

Different user groups have different needs how simple or advanced material auto conversion should be.

The hope was that an updated OcDS build would add more settings to the OcDS Parameters tab to customize how auto conversion works:

- Import Bump maps: yes - no
- Import Normal maps: yes - no
- Import Displacement maps: yes - no
- Import SSS maps: yes - no
- import Reflection maps: yes - no

- create mix material: yes - no

- use 3Delight shaders as source for autotranslation: on - off
- use Iray shaders as source for autotranslation: on - off


- - -

I guess that sums up some of the points related to Auto Conversion as far as I can recall them.
Please add your own points of view to provide an overview of the different needs and expectations towards Material Conversion in OcDS.

Not really adding to the summary, as I'm pretty sure you've covered it quite nicely, I have always wondered about this particular issue. In my mind, it would always have made more sense to give the users all of these options, even if it was only through a config file. It would make pinpointing issues with which nodes are doing what so much easier for anyone wanting to spend the time to do it (like I would have, had I been able to).

Off the top of my head, it also occurs to me that occasionally, one can auto-convert materials, which come out incorrectly, as described above, then use the manual "From active maps" something or other option, and that has about a 60% chance of fixing the weirdness. Annoyingly, it must be done on each material, so if there are a lot of surfaces that got screwed up, it can be a major time sink, with a not impressive success rate. Seems weird that it ever works, though, since it should just be puling the same maps it tried to use before, but it's a thing I came across several dozen times before kinda abandoning OcDS until it gets to a point where it's more usable.

It is unclear if in the long run products may only include Iray shaders with 3Delight becoming less supported.

Iray is NVidia only - so I would have thought 3Delight would always be supported by product vendors.

Nevertheless OcDS users hope to get better results with an Iray to OctaneRender auto conversion workflow in the future.

I am reluctant to re-write the material conversion system. I would prefer to tweak the rules in the current system. If there are specific "rules" you need added, or changes make, pls let me know. For instance, the current Poser plugin does not support conversion of Superfly physical materials - it only converts the legacy Poser materials. At some point physical material conversion may be added, but after all bugs are resolved, and Octane 3 is implemented.

- Import Bump maps: yes - no
- Import Normal maps: yes - no
- Import Displacement maps: yes - no
- Import SSS maps: yes - no
- import Reflection maps: yes - no

I am reluctant to add this. Users can simply disable the Normal map on the DS material, then re-convert to an Octane material. Seems very low priority to me.

Paul

face_off wrote:

It is unclear if in the long run products may only include Iray shaders with 3Delight becoming less supported.

Iray is NVidia only - so I would have thought 3Delight would always be supported by product vendors.

To provide some more information:

It is possible to run Iray with CPU only. Users reported that this is at least as fast as 3Delight but offers a higher image quality.
Known is that DAZ3D considers Iray as the new main render engine since DAZ Studio 4.8 was released.
Known is that the contract between 3Delight and DAZ3D is still valid for some time.

There is still a user base that for some reasons prefers to use 3Delight over Iray.
Users did pay thousands of dollars for products that only have 3Delight materials and will want to keep using them.
There is an auto conversion from 3Delight to Iray.
In the end it is up to the artists that create products to deceide how long it is profitable to include material presets for 3Delight in the future.

But yes, this change is long term and the time to look into Iray to OctaneRender material auto conversion is after all bugs are resolved and Octane 3 is implemented.

- Import Bump maps: yes - no
- Import Normal maps: yes - no
- Import Displacement maps: yes - no
- Import SSS maps: yes - no
- import Reflection maps: yes - no

I am reluctant to add this. Users can simply disable the Normal map on the DS material, then re-convert to an Octane material. Seems very low priority to me.

Paul

Users understand that now in the very limited time before OctaneRender 3 is released it is not the right moment to make major new changes.
Nevertheless it has been an issue for quite some time now that in OctaneRender it is not advised to mix bump, normal and displacement maps on the same surface. Therefore to add switches to choose which map types are loaded with auto conversion has been a frequent request.

- - -

I add some more information to maybe better illustrate how switches could be used in batch conversions:

DAZ3D artists create material setups for either 3Delight or Iray.
Each product in a scene has multiple surface zones.
You may end up with 100+ different materials on 300+ surface zones in a scene.

If it is not advised in OctaneRender to load bump, normal and displacement maps on the same surface zone it seems important to have a switch to actually choose which map type is loaded in material auto conversion.

There are multiple threads in the forum describing issues that happen when in OctaneRender bump, normal and displacement maps are mixed on the same surface zone.
Unfortunately a lot of DAZ3D content artists create products that mix such maps on the same surface zone because in 3Delight and to some extent also in Iray it is not such an issue to mix maps on the same surface zone.

Therefore when converting such products to OctaneRender it seems very important to have a way to select which map types are loaded and which are ignored.

Examples:

- If there is a hero object in the foreground users may want to automatically load only the displacement maps by default while all the bump and normal maps will be ignored and not added.

- If there are background objects that are still visible the user may only want to load the diffuse and bump maps.
- Other users may prefer to load only diffuse and normal maps.

- If there are background objects that are all blurred because of camera focus the user may only want to load the diffuse maps to save further VRAM space.

This means:
It is not a time efficient solution to go trough 100+ materials manually adding or removing bump, normal or displacement maps.
It is not a time efficient solution to go trough 100+ materials manually to remove nodes created for mix materials if the user wanted that a simple diffuse material is created with only the diffuse map loaded.



We cannot expect auto conversion to be a miracle solution. It is an important part of the workflow to manually adjust key surface zones especially on objects clearly visible in the foreground.

But what could be done in the long term is to make the auto conversion as efficient as possible to get rid of as many tedious workflow steps as possible.


- - -

If it is not advised in OctaneRender to load bump, normal and displacement maps on the same surface zone it seems important to have a switch to actually choose which map type is loaded in material auto conversion.

What about if there is a displacement map, don't connect the normal or bump. If there is no displacement, but a normal and a bump, use the normal. Otherwise if there is only a bump map - use it?

face_off wrote:

If it is not advised in OctaneRender to load bump, normal and displacement maps on the same surface zone it seems important to have a switch to actually choose which map type is loaded in material auto conversion.

What about if there is a displacement map, don't connect the normal or bump. If there is no displacement, but a normal and a bump, use the normal. Otherwise if there is only a bump map - use it?

If you can implement those rules in combination with a simple diffuse or glossy material instead of the mix material setup that would already be a huge leap forward.

Anyway I got carried away a bit giving feedback. I will try to stay quiet for a while and let other users share their opinions.

If you can implement those rules in combination with a simple diffuse or glossy material instead of the mix material setup that would already be a huge leap forward.

OK, I will look into implementing that.

Paul

The longer I think about it the more I realize how difficult it must be for developers to either find the rules that fit the most cases or to give a choice when possible.

- - -

Rule set A: Normal map priority:

face_off wrote: - What about if there is a displacement map, don't connect the normal or bump.
- If there is no displacement, but a normal and a bump, use the normal.
- Otherwise if there is only a bump map - use it

- - -

What about:

Rule set B: Bump map priority:

- if there is a displacement map, don't connect the normal or bump.

- If there is no displacement, but a normal and a bump, use the bump.

- Otherwise if there is only a normal map use it

- - -

The benefit of the Bump map priority is that it prepares a workflow to add a bump map to the displacement slot.
The map node is already created. Now the user can just move the pin to a displacement node and adjust the values.

- - -


Would it be possible to give the users a choice if the plugin uses

Rule set A: Normal map priority

or

Rule set B: Bump map priority

?

Yes, sorry. My brain simply fails to stop thinking about such possibilities.
But I guess it is better to ask such questions now before the work is done than after?!

Rule set B: Bump map priority:

This should be doable. I will see if there is a simple way to have the priority an option.

Paul

Not sure if the problem I am facing belong here or not. Posting the link here as it is related to materials. viewtopic.php?f=44&t=51398&p=255893#p255893

Best Regards
Rajib