OTOY Forums

Here it is: In HSV space:
H = 0.666
S = 0.5
V = 0.5

ciao Beppe

bepeg4d wrote:Here it is:

EDEF95F3-B969-4526-A4FA-9BCF7DC93228.jpeg

In HSV space:
H = 0.666
S = 0.5
V = 0.5

ciao Beppe

That's exactly the setup I had in mind but it didn't work with bump. Strange.

mitchino wrote:I want to do the same thing with a normal map i.e. use a fall off node to control the normal map so at direct angles there is a normal effect and at glancing angles there isn't. How would I set that up? If I do it the way I did it with bump where I used a 50% grey, what is the equivalent with a normal map?

You can do the same basic setup. There does seem to be a funny quirk where if you pipe an RGB color into the second Texture pin in the MixTex node, it can generate some odd Normal mapping artifacts. I've found it works just fine if you use a GaussianSpectrum node, though, and it doesn't seem to matter what the value of that GaussianSpectrum node is.

Here you can see the problem on the right. You'd think it would work fine with an RGB node set to 127,127,255, the Normal Map equivalent of 50% gray, but nope, that causes problems. Instead, just swap that RGB node with a Gaussian and it works.

great tip, that's me sorted for fall off with bump and normal!

Hi frank,
interesting find, in fact, if you pipe the RGB node into a Baking Texture, everything is working as expected: ciao Beppe

@bepeg4d @frankmci

The whole normal map discussion is a bit off topic but since I've been looking into this (I'm about to post a OSL tool that blends normal maps and handles X-Y flip) after Chad Ashley's topic I've learned a few things about how normal maps are 'handled' by Octane.

It appears that the Normal input is 'automagically handling' (normalizing?) the colors into a format that Octane 'understands'. This is why "Power" slider in the ImageTexure node actually reduces strength, for example. And this is why you can't use a Color Correction node on normal maps.

Also normal maps must always be linear without any gamma 'baked in'.

So:

In my experience, the correct RGB values for a neutral normal map are scene linear float values: R: 0.5, G: 0.5, B: 1.

Using HSV is a bad idea (but I'm not saying that it couldn't work) because the conversion to sRGB is done by C4D color management and you might get wrong values. I've only had success with RGBSpectrum. Gaussian spectrum trick is nice and faster to setup but it's still a kind of a hack and you never know when this might stop working (or being "handled").

With that said, those specific HSV values in fact don't produce R: 0.5, G: 0.5, B: 1 (somewhat correct values would be H: 0.666667, S: 0.5, V: 1) in Octane and that's where those artifacts come from and why normals are wrong in the example on the right. There are also other scale related 'factors' I've seen that produce artifacts like that.

@mitchino

Regarding bump maps, there is also one more factor to consider -> resolution. Because bump maps, in general, are kind of a hack (emphasis on "in general" - please DO NOT go posting Octane bug reports based on this, I'm begging you) blurring a bump map can give you the appearance of stronger bump map. Adjusting the brightness of pixels might not work on something like text, for example. You should experiment with mixing a blurred and non blurred map too.

Texture on the right has higher resolution and, as a consequence of that, the edge of the circle is less blurred. Cheers
Milan

bepeg4d wrote:Hi frank,
interesting find, in fact, if you pipe the RGB node into a Baking Texture, everything is working as expected:

Capture_13.PNG

ciao Beppe

Hmm. Interesting... It seems like one of those nodes isn't passing quite the data it should be. Is the RGB Spectrum node also passing a hidden alpha value or something that's throwing off the Mix? Or perhaps the Normal channel needs some UV coordinate data that a RGB Spectrum node does not provide? The Baking node must either be adding info that is otherwise missing, or filtering out something extraneous.

This is one of those situations where I wish Octane nodes were more explicit about what data they are passing back and forth. I'd love to flip down the output pin on a node and see, "Red, Green, Blue, Alpha, U Coordinates, V Coordinates," etc. Lacking that, some kind of color coding system that clearly indicates which output pins are compatible with which input pins would be nice.

(Edit) Looks like @milanm has a good handle on the actual problem, although I can't pretend I fully understand it. Perhaps this is an issue that can be bumped up to the OctaneRender developers?

frankmci wrote:Perhaps this is an issue that can be bumped up to the OctaneRender developers?

It's not a bug, it's a feature! Life would have been much harder if Octane didn't do that. It's actually pretty cool that it does that. (I'm referring to the "handling" here)

Normals are special case. Some render engines expect them to have values that go between -1 and 1.

Cheers
Milan

milanm wrote:

frankmci wrote:Perhaps this is an issue that can be bumped up to the OctaneRender developers?

It's not a bug, it's a feature! Life would have been much harder if Octane didn't do that. It's actually pretty cool that it does that. (I'm referring to the "handling" here)

Normals are special case. Some render engines expect them to have values that go between -1 and 1.

Cheers
Milan

Milan, I didn't mean how things are actually working under the hood are a bug or a problem, I meant more specifically and as an example, the way mixing an RGB Spectrum node with an otherwise standard RGB ImageTexture node and piping the results into the Normal channel does not work at all they way any reasonable person would expect it to. I think there needs to be more transparency to the user about what kind of information is being passed between nodes.

It doesn't seem too uncommon that there's a fix for something, but it's not at all clear why that fix works, such as this one. There's no reason why anyone would expect that piping the RGB Spectrum node through a Baking node would work when the straight RGB Spectrum node does not. Similarly, there's no clear reason why using the Gaussian Spectrum node works. Obviously there is a reason, and it may be a very good one, but as things stand most of us will never know or understand that reason.

I'm suggesting that the core developers consider exposing more of what's going on under the hood, so that those of us whose jobs involving solving problems and making stuff work can more easily accomplish our goals.

And thanks, Milan, for your always insightful contributions!

- Frank

Oh, I misunderstood your post, sorry Frank. Yes, I agree, and the missing info would have saved me a day of doing research and it's the whole reason for the wall of text I just wrote above.

I'd love to see some more info about the format of the input that Normal pin expects or the way the conversion is done in the user manual. Or, at least, a reminder that there is a conversion process happening there.

Also, I changed "-" into ":" next to RGB values in my post above to avoid confusion with negative values.

Cheers
Milan