OTOY Forums

Notiusweb wrote:

Postby sixb0nes » Sat Nov 28, 2015 4:02 pm

Notiusweb wrote:
But it's almost like you are using the previous OcDS where the Grey Image for the Iray lashes, hair, and eye moisture weren't coming over. But for you the other eye components and hair work, like its just exclusively the lashes?

Here is a demo of, really, both issues. You can overcome most with the Redspec presets, aside from the eyelashes. Again, presets are not the solution - but I wanted to demo TR's issue since I had noticed this as well:

https://www.dropbox.com/s/a3ovrh8lus40m ... 5.mp4?dl=0

Then, It's the Redspec shaders that then introduce an issue. We clearly see the issue appear once the Redspec shader is applied. But it is not there before that. I am not saying the issue is with the Redpec Shader per-say, but rather that the initial conversion of the default mats showed the eyelashes rendered correctly. Paul would not be able to reproduce that unless, like in your video, he applied the Redspec shader.

This is my assumption as well. I can't seem to reproduce what TR is saying. I tried a bunch of different G3F characters and they all came across with Grey Image each time - which confirms what you outlined in your post above.

sixb0nes wrote:This is my assumption as well. I can't seem to reproduce what TR is saying. I tried a bunch of different G3F characters and they all came across with Grey Image each time - which confirms what you outlined in your post above.

I may have found out "how" ...

Under texture settings on preferences, if you choose "image" under "Opacity Map", you get an RGB Image result for the Eyelashes conversion. Perhaps? By default mine was "auto type".

@TR is that what you are seeing, (1) an issue once you then apply the RedSpec shaders, or (2) an actual issue with the initial conversion, previous to the shaders being applied?

Neither of those two options, actually.
The underlying problem (no pun intended ) is, that the hair figure geometry intersects with the figures head geometry.
Due to the different shading approach of RedSpec in comparison to the "standard" materials, they "distortion" is rendered differently - that's all.

To fix this, slightly enlarge the hair figure (something around 100.200 % should work fine) - Oh, and try not to use it under "Daylight Default Environment" conditions - the shaders work best in an HDRi-only environment

As in regard to the Eyelashes not carrying over the opacity map - I'm sure this must be a material conversion issue, as the templating node is set up correctly and should carry it over that way. It works well with the 3Delight materials, so it has to be connected to the Iray materials.

I'll investigate the opacity map problem with DAZ Studio - I've been using version 4.8.0.59.

*EDIT*: Changing the conversion method of opacity maps in the OctaneRender menus preferences tab to "floatimage" positively fixes the "RGB image" problem, but still doesn't carry over the actual opacity map, in the shader set-up.
I will investigate this together with Paul, and will let you guys know, once we have found a solution, as I'm sure, more important features await implementation, respectively bugs need fixing. These two things should be prioritized above everything else at the moment

Hi - I have just put through a new release (see the TEST thread for details). It will hopefully resolve a lot of the issues posted in this thread. If you have posted a problem in this thread, can you pls re-test with the new release (2.24.2.3), and if the problem persists - pls provide details in this thread.

NOTE: The bump/normal/displacement priority rules have not yet been implemented, but will be put into the next release if the above material conversion rules work correctly for people.

Thanks

Paul

- Basic material conversion working much better for Iray. Ran through 5-6 different characters successfully where they failed before. Great start! Good testing & feedback by all
- Tested 3DL conversion for same models, all working great
- Tested "transform" changes with Live button disabled fix - working as described!
- Bad label "Qick Edit" back (was fixed in .2)
- Still having issue with Redspec Eyelash conversion on Iray, but it sounds like we've provided enough information for you and/or TR to work through the problem

THANKS!

Still having issue with Redspec Eyelash conversion on Iray, but it sounds like we've provided enough information for you and/or TR to work through the problem

Yup, thanks for all the input. Paul and I are already working on this. Will let you guys know, once we're good.

TRRazor wrote:

Still having issue with Redspec Eyelash conversion on Iray, but it sounds like we've provided enough information for you and/or TR to work through the problem

Yup, thanks for all the input. Paul and I are already working on this. Will let you guys know, once we're good.

I own your Gen2/3 skin materials. How do we receive updates? Are we usually informed via email?

I had another look how auto conversion works with the latest version:

2.24.2.4

2.24.2.4
- Suppressed "One or more GPU(s) don't occupy the highest Power State (possible degradation)!" log message
- Fixed issue introduced in 2.24.2.3 where prop translations were not being applied when opening the Viewport with Live disabled
- Improved conversion of Iray materials with opacity maps
- Removed the creation of material mix nodes when there are both normal and bump maps. Normal map is used if there is one, otherwise the bump map is used (if there is one)

It seems

Removed the creation of material mix nodes when there are both normal and bump maps. Normal map is used if there is one, otherwise the bump map is used

is applied with non figure objects.

Side Note:
I did not test enough figures to come to a conclusion but it seems that:
When OcDS detects figures in the scene like G3F, G2F etc a special set of auto conversion rules is applied.
The "normal map priority rule" does only seem to be applied to non figure objects (for now).

What does this new "normal map priority" auto conversion rule mean in practice?

Tested with 3 Gate Pass

http://www.daz3d.com/3-gate-pass

By default this product uses both Bump and Normal maps.
What the new 2.24.2.4 auto conversion rule does is:
- it only takes the normal map and does not anymore create a node for the bump map when both map types are available
- a mix material is not anymore created
- only when there is no normal map a bump map is used as replacement

3 Gate Pass - OR Auto Conversion - Normal Map Priority
To better see what kind of detail the normal map added I used a white image node in the diffuse slot in this version:
- - -

3 Gate Pass - Bump Map Priority
Now how would this image look like if instead of the "Normal Map Priority" a "Bump Map Priority" auto conversion rule would be used?

Removes the creation of material mix nodes when there are both normal and bump maps. Bump map is used if there is one, otherwise the normal map is used

As you can observe this is not a trivial change.
The image does look quite different with only the bump map details than with the normal map details.

Bump map used in the displacement slot

One benefit of bump maps is that they can be used in displacement slots.
Sometimes you can achieve interesting effects without the need to use photoshop to even edit the maps.
- - -

For the sake of it lets have a look at

Normal and Displacement mixed together
and

The same Bump and Displacement mixed together
and

When both bump and normal maps are applied manually on the same surface zone the normal map seems to have priority over the bump map.
This result stays the same if bump and normal maps are on separate diffuse materials and combined in a mix material.
To summarize:
Mixing Bump and Displacement maps can work.
Mixing Normal and Displacement may yield unwanted effects.
Mixing Bump and Normal ignores the effect of the bump map.

- - -

What is the underlying main issue:

DAZ Studio artist often use a mix of normal and bump maps in their products.
Each artist may have a different preference to place some details in the bump maps and other details in the normal maps.

Best case scenario:
Of course the best option would be if in OctaneRender there would be no negative side effects at all when

- mixing bump and displacement
- mixing normal and displacement
- mixing bump and normal

Can any developer share if mixing different map types will be fixed or less of an issue with OctaneRender 3?

- - -

So for now we seem stuck with the unfortunate situation that

- If we use an auto conversion rule that by default places only normal maps in the scene we loose all the details captured with the bump maps
- If we use an auto conversion rule that by default places only bump maps in the scene we loose all the details captured with the normal maps
- if we use the past 2.23.2.3 auto conversion rule that applies all available maps and mixes them there may be unwanted side effects in some cases

This means no matter which auto conversion rule we use there may always be a case when another auto conversion rule would have yielded better results.

That is why I suggested instead of having just one auto conversion rule it would be great to have a choice between three different auto conversion rules so users can test for each individual case which rule offers the best result.

The open question is:

Is it possible to give the user the option to select between the three different auto conversion rules?

- - -

@TRRazor - if we find specific one-off issues with a Redspec shader applied to a hair or skin do you want to see it here or in your product announcement threads. I know some anomalies could be twined within the current state of the plugin, however others could be a unique issue of the shader talking to a product, so just want to check. Sorry to be a bother in posting this question here. Thx!

Side Note:
I did not test enough figures to come to a conclusion but it seems that:
When OcDS detects figures in the scene like G3F, G2F etc a special set of auto conversion rules is applied.
The "normal map priority rule" does only seem to be applied to non figure objects (for now).

That is correct. The MIX for non human figure materials was totally breaking the conversion rules - so I removed it. The MIX for human figure skin materials does not actually appear to be breaking things - so I left it. I removed the MIX for non human figure materials because other maps were being lost - not because if the unwanted effects of bump mixed with normal maps.

Is it possible to give the user the option to select between the three different auto conversion rules?

I'd rather not add this - because it is just adding yet more functionality to something which is already IMO overwhelming for new users to understand.

Also - tweaking the material conversion process inside the plugin is not trivial - and often one change breaks something else. I worry that there is no one perfect set of conversion rules with suit all users. DAZ Studio has the capacity for a number of different shader types - all of which have different conversion rules - and users can write their own shaders too! For example, in G3 there are omUberSurface, AoA_Subsurface, and omHumanSurface...and they are all different. The current plugin code does not differentiate between these different shaders - yet they have different conversion rules. Getting a perfect material conversion into Octane from these different shaders is not something that can be achieved in a small amount of time.

Paul