OTOY Forums

That seems to fix that problem.
Normal should be set at disconnect if not used, not at 0.0
Thanks!

The Cuda 700 error seems to occur when you have the viewport open and rendering and you then change materials (in my case loading a white leather materials from LiveDB)
Render stops and cuda errors appear and you have to restart Poser

Now I have no idea how that happened, as I hardly use Normal maps, but matter of fact is, when actually disconnecting them, the materials are rendering correctly again. As far as I can tell.

FYI - I have reported this to Otoy, so hopefully there will be a fix in the next Octane 3.06 release. I think that the 0, 0, 0 value in the normal map might be an invalid normal vector, so perhaps having a 0 Greyscale texture in the Normal pin should have have worked.

Paul

Thanks for reporting it, Paul.

It's kind of interesting, that even the oldest, or randomly loaded materials I have stored locally, or load from the LiveDB, now all have the Normal pin with a Greyscale Color set to 0.0 attached to them, when applying them to a mesh.
So in between all the betas, test builds and whatnot, this must have sneaked in totally unnoticed

wimvdb wrote:The Cuda 700 error seems to occur when you have the viewport open and rendering and you then change materials (in my case loading a white leather materials from LiveDB)
Render stops and cuda errors appear and you have to restart Poser

I can confirm this on my end, too.
Thanks for finding it out.

It's kind of interesting, that even the oldest, or randomly loaded materials I have stored locally, or load from the LiveDB, now all have the Normal pin with a Greyscale Color set to 0.0 attached to them, when applying them to a mesh.
So in between all the betas, test builds and whatnot, this must have sneaked in totally unnoticed

I could not reproduce this issue at all. I loaded a bunch of LiveDb materials and none exhibited this issue. Can you pls tell me a LiveDb material name which causes this issue? Can you also post you OctaneDefaults.py file and a screenshot of your plugin configuration/setup screen.

Thanks

Paul

The only ones which normal at 0.0 are my older local poe and poc files. Could it be that at some point the Normal disconnect was introduced and 0.0 was used before that?
Some of the older LiveDB might have that too.

The redspec v4 skin shader definitely has it at 0.0. The newer redspec hair shader has it at disconnect.

We never noticed that since the pre 3.06 render engine treated them as the same

face_off wrote:

It's kind of interesting, that even the oldest, or randomly loaded materials I have stored locally, or load from the LiveDB, now all have the Normal pin with a Greyscale Color set to 0.0 attached to them, when applying them to a mesh.
So in between all the betas, test builds and whatnot, this must have sneaked in totally unnoticed

I could not reproduce this issue at all. I loaded a bunch of LiveDb materials and none exhibited this issue. Can you pls tell me a LiveDb material name which causes this issue? Can you also post you OctaneDefaults.py file and a screenshot of your plugin configuration/setup screen.

Thanks

Paul

I could reproduce the same issue with the Bump channel as well.
I disconnect both, Bump and Normal
Then very 1st LiveDB mat "amethyst marble" (some pink-ish stone mat.) "LiveDB - Organic - Stone - amethyst marble"
After loading it, the Normal has the Greyscale at 0.0.

Loading the material "Red Brick", "LiveDB - Absolute Textures - Brick - Red Brick", puts a Greyscale into the Bump channel at 0.0. It was disconnected before.

I could reproduce the same issue with the Bump channel as well.

Bump channels are not a problem. They can be 0 instead of Not Connected. It's only Normal pins where it is an issue.

Then very 1st LiveDB mat "amethyst marble" (some pink-ish stone mat.) "LiveDB - Organic - Stone - amethyst marble"

I do not get a 0 Normal value if I load Amethyst Marble. I get the following.

Loading the material "Red Brick", "LiveDB - Absolute Textures - Brick - Red Brick", puts a Greyscale into the Bump channel at 0.0. It was disconnected before.

What does the last sentance mean pls? When was "before"? Which plugin version pls?

Paul

So that you can't reproduce the issue, it's on my end. That's good to know.

Sorry for not being clear, in the last sentence. It was really confusing =)
I added two more screen caps to show what I tried to say (on left: how it was initially converted from Poser -> OR plug in; right side is after loading the mat. from the LiveDB)
The plug in version I'm currently using is 3.5.3.80
I happen to have older versions, back to 3.4.0.78 on my hdd, which I quickly installed and tried. The result was the same as described above.


To be honest ... I'm not losing any sleep over this. I just disconnect the pin(s), save the materials back to my local DB/hdd and all is good