OcDS Setup v2.2 (last Beta)

[SiliconAya]

Hello! I am seeing a strange texture issue when rendering certain characters through the current OcDS plugin. Almost looks like a 'Cartoon Shader'
The following characters from L to R are Zahara 6, Mei Lin 6, Belle 6....Look at the difference in textures for the L and R models between each rendering utility (1) OcDS Plugin 2.23, vs (2) IRay, vs (3) Octane Render Standalone 2.23

(1) OcDS 2.23

Octane Texture1.jpg

(2) Daz 4.8 IRay

IRay Texture1.jpg

(3) Octane Render Standalone 2.23

Octane Standalone Texture1.png

Interestingly, Mei Lin 6 (in the center) comes out clean in each render. But the other 2 on L and R look pixelated and toon-textured.
Sample rate same on each, I used default sun and sky environment on each...I did not tweak any texture settings between the 3.

To developer, or anyone, any ideas what may be causing this in the plugin...Thanks!

This question keeps coming up so it seems like a general problem. The solution (at this point in time) is to check that the skin material "amount" is set to 1 and not 0.85. For some reason OcDS is converting the textures of certain figures so that the amount is less than 1. The consensus is that the conversion method now addresses more material parameters but this improved complexity isn't always as accurate as in the past. But itou31 has a point, if you gave your TitanZ's to us then this problem would go away.

Please stop telling people this, because it's wrong!

I posted here what the amount settings does and why you shouldn't set it to 1.

The real cause is an error in the auto-conversion of materials in regards to normal maps, as found out by Hubby72 and posted about several times in this thread by him.

Most characters don't have normal maps, but the material conversion always includes it with the Power set to 2, but the image blank. To FIX IT set the power to 0 or disconnect the normal node! This is why Mei Lin 6 works while Belle 6 and Zahara do not, ML6 has/comes with normal maps, the other 2 do not.

Here's a list of Daz Figures/Characters that have normal maps and work with auto-conversion:
Gia 6
Lilith 6
Mei Lin 6
Monique 6
Ninive 6
Olimpla 6
Stephanie 6
Victoria 6

Here's a list of Daz Figures/Characters that have do NOT normal maps and will NOT work with auto-conversion:
Aiko 6
Base Female
Belle 6
Callie 6
Girl 6
Giselle 6
Keiko 6 (don't have this one, so guessing)
Teen Josie 6

99% of all other characters for G2F, Genesis, V4, etc do not have normal maps so will not work either.

[itou31]

oops, yes that's right, I read it but forget it somewhere in my brain ... as I always use Redspec tgx on my figure...
Sorry for the confusion.

[hamer66]

There is an easier way if you want the "old" way of skin textures (ok i find it easier )

- Select Genesis 2 in the scene surfaces list (all textures)
- Right Click, select Create as new materials -> Blank Materials (shortcut: ctrl+shift+B)
- Again Right click, Select textures for octane materials -> Take and connect all maps

Now only the textures are applied and not the new standard template. I prefer this methode as a starting point (when i'm not using redspec shaders, they are way better than anything i can make )

(Left new template, right above methode)

[vortex3d]

I can't say I've had the issues others have reported. If i press "pause" which I have a habit of doing, it stops rendering. I don't close the window myself however. (I might be misunderstanding the issue)

Some joints become extremely slow (neck, head, limbs) after the viewport is opened.
Pause does stop the rendering but not the geometry updates or it messes up something in DS.

[Spectralis]

Hello! I am seeing a strange texture issue when rendering certain characters through the current OcDS plugin. Almost looks like a 'Cartoon Shader'
The following characters from L to R are Zahara 6, Mei Lin 6, Belle 6....Look at the difference in textures for the L and R models between each rendering utility (1) OcDS Plugin 2.23, vs (2) IRay, vs (3) Octane Render Standalone 2.23

(1) OcDS 2.23

Octane Texture1.jpg

(2) Daz 4.8 IRay

IRay Texture1.jpg

(3) Octane Render Standalone 2.23

Octane Standalone Texture1.png

Interestingly, Mei Lin 6 (in the center) comes out clean in each render. But the other 2 on L and R look pixelated and toon-textured.
Sample rate same on each, I used default sun and sky environment on each...I did not tweak any texture settings between the 3.

To developer, or anyone, any ideas what may be causing this in the plugin...Thanks!

This question keeps coming up so it seems like a general problem. The solution (at this point in time) is to check that the skin material "amount" is set to 1 and not 0.85. For some reason OcDS is converting the textures of certain figures so that the amount is less than 1. The consensus is that the conversion method now addresses more material parameters but this improved complexity isn't always as accurate as in the past. But itou31 has a point, if you gave your TitanZ's to us then this problem would go away.

Please stop telling people this, because it's wrong!

I posted here what the amount settings does and why you shouldn't set it to 1.

The real cause is an error in the auto-conversion of materials in regards to normal maps, as found out by Hubby72 and posted about several times in this thread by him.

Most characters don't have normal maps, but the material conversion always includes it with the Power set to 2, but the image blank. To FIX IT set the power to 0 or disconnect the normal node! This is why Mei Lin 6 works while Belle 6 and Zahara do not, ML6 has/comes with normal maps, the other 2 do not.

Here's a list of Daz Figures/Characters that have normal maps and work with auto-conversion:
Gia 6
Lilith 6
Mei Lin 6
Monique 6
Ninive 6
Olimpla 6
Stephanie 6
Victoria 6

Here's a list of Daz Figures/Characters that have do NOT normal maps and will NOT work with auto-conversion:
Aiko 6
Base Female
Belle 6
Callie 6
Girl 6
Giselle 6
Keiko 6 (don't have this one, so guessing)
Teen Josie 6

99% of all other characters for G2F, Genesis, V4, etc do not have normal maps so will not work either.

I suggest that if you want to instruct us in how to officially fix this problem then post an separate thread like they do at DAZ and other forums instead of expecting people to dig up random posts that get lost in this thread. That way everyone encountering this problem has accessibility in the forum to the correct info. I really hope that this is the way any future problems are going to be addressed. Instead of the slip shod way of conveying info we get from the developer we can at least be a bit more organised and systematic.

[danhale]

Thank you VERY much. So far, this version works like a charm.

[larsmidnatt]

I suggest that if you want to instruct us in how to officially fix this problem then post an separate thread like they do at DAZ and other forums instead of expecting people to dig up random posts that get lost in this thread. That way everyone encountering this problem has accessibility in the forum to the correct info. I really hope that this is the way any future problems are going to be addressed. Instead of the slip shod way of conveying info we get from the developer we can at least be a bit more organised and systematic.

They already took the time to explain the issue. It's only logical they responded in this thread where the issue was presented...

Everyone has access to this thread. I don't know why you assume anyone is getting anything from the developer. We figure stuff out on our own and share it :/ Nothing official about it.

Even though people took the time to share their knowledge you are still negative.

[birdovous]

OK, I'm playing with the plugin and I encountered a little issue with IES based lights.

It looks like that no matter what I try the light does not follow the angle of the normal of the emitting polygon . Which worked in v1.2 of the plugin.

Is this a bug of 2.2, am I doing something wrong, or is it simply as it is implemented in the Octane engine itself and IES based lights can't be rotated at all (making them basically useless)?

[Spectralis]

I suggest that if you want to instruct us in how to officially fix this problem then post an separate thread like they do at DAZ and other forums instead of expecting people to dig up random posts that get lost in this thread. That way everyone encountering this problem has accessibility in the forum to the correct info. I really hope that this is the way any future problems are going to be addressed. Instead of the slip shod way of conveying info we get from the developer we can at least be a bit more organised and systematic.

They already took the time to explain the issue. It's only logical they responded in this thread where the issue was presented...

Everyone has access to this thread. I don't know why you assume anyone is getting anything from the developer. We figure stuff out on our own and share it :/ Nothing official about it.

Even though people took the time to share their knowledge you are still negative.

What I'm suggesting is that instead of getting snippy with people like me who don't carefully pore over every post in a long thread why not give any problems like this a separate thread with a clear title so that anyone visiting this forum can either see the thread or search for a solution more easily. If you've ever tried to search for info on this forum it becomes apparent that we need a systematic way of sharing information instead of the random way of finding out how to solve problems like this that seems to be a legacy of the the way information is shared (or not shared) officially. Not only that, there has been another suggestion by hamer66 about how to solve this problem so it's not as if there is only one way to fix this.

What I find surprising is that this way of converting materials was not tested first by the closed beta and seems to have been introduced at the last minute.

UPDATE: I've started the thread myself.

[linvanchene]

OK, I'm playing with the plugin and I encountered a little issue with IES based lights.

It looks like that no matter what I try the light does not follow the angle of the normal of the emitting polygon . Which worked in v1.2 of the plugin.

Is this a bug of 2.2, am I doing something wrong, or is it simply as it is implemented in the Octane engine itself and IES based lights can't be rotated at all (making them basically useless)?

Otoy changed how IES lights work sometime between 1.2 and 2.1.

There is a thread about it here:

Version 2,1 and IES lights not working as before

http://render.otoy.com/forum/viewtopic.php?f=44&t=44053

Nevertheless I also have not yet figured out which projection mode to use so the light rays in the scene look exactly as in the preview images.

If anyone, user, moderator, staff, admin can add any information how it was officially intended to use projection with IES please share that information.

Update / Edit:
Since this does not seem to be a bug bug more a question how to do things in OctaneRender I will post the rest in that thread.

- - -

Nevertheless while experimenting with this I found:

In standalone you also find Mesh Projection.
There is XYZ to UVW Projection.
In OcDS UVW Projection does not have any Coordinate Space selection.

Are those differences intended or did some internal references get mixed up?


- - -