Using Nvidia's Normal Map plugin

[kobaltkween]

Thanks, is that the same for Superfly too?

So, I'm assuming Glitterati3D has answered this question based on using the Poser and Physical root nodes for Superfly, so I'm going to answer for using the Cycles root with an actual Cycles material (which has many advantages). Where the answer is, no, not at all.

Many nodes in Cycles have a Normal input. Shading nodes, Fresnel and Layer Weight, etc. This is where you'd want to plug in your Cycles > Vector > NormalMap (or Bump) node. And then you'd plug your map into the Color slot of the NormalMap node (or the Height of the Bump node).

And the thing to keep in mind with all of this is that normal maps are exactly the same as bump maps _except_ they have individual direction. So if all you're doing is making maps things go up and down, you're not getting any more detail by using normals instead of bump, though you're making them a bit harder to create. Where they add significant information is surfaces with overhangs or x/y direction.

Also, you can easily make a 16bit (per channel) color bump map in image editing software (just like displacement), giving you _much_ more detail. I don't know of any apps that generate a 16bit normal map, but that's probably just my ignorance.

And for all those Blender users out there, if you use the Multires modifier and sculpt like you would in Zbrush, you can bake out a normal map in a similar fashion as you do in Zbrush. IIRC, you have to switch to Blender Internal renderer to bake displacement out, but both do work well. You can even use Zbrush alpha maps as brush textures in Blender. Blender isn't nearly as robust in terms of sculpting and 3D painting as Zbrush, but you can really do a fair amount in it.

 

[caisson]

There are a number of apps that can make 16 bit normal maps, they are generally used to avoid banding on gradients. Poser doesn't read them in the Poser root, never tried through the Cycles nodes. Would take up more memory in file size & rendering; not sure of the advantages - different with 8 bit vs 16 bit bump/displacement where the height can be varied.

Got to add that a normal map is computer code that just happens to look like a texture map; the different renderers in Poser - preview, Firefly & Superfly - each decode tangent space maps using a different tangent basis. In some circumstances this can lead to visual differences between them.

 

[Glitterati3D]

Thanks, kobaltkween and caisson for adding to this discussion.

I know Caisson has been dealing with this stuff a lot longer than I have as he was setting up Poser materials for Octane long before Superfly arrived.

 

[phdubrov]

One last question, (I hope), can you use a bump map along side a normal map? I ask because I just worked out that every time I plug in a bump map it is negating the normal map

Yes in Superfly with Cycles root. and if I remember correctly, yes with PhysicalSurface root since last SR.
How? Bump node has Normal input too.

Also you can combine different BumpMaps with different projections, scales, rotations...

 

[Glitterati3D]

Yes in Superfly with Cycles root. and if I remember correctly, yes with PhysicalSurface root since last SR.
How? Bump node has Normal input too.

View attachment 29551
View attachment 29552

Also you can combine different BumpMaps with different projections, scales, rotations...

I thought I read that somewhere, but didn't want to supply bad information (which I did anyway, LOL!).

Nice!

 

[Dreamer]

Ok thanks every one, I'll try to get some screen grabs for you @Bonnie2001 a bit later. I have got a touch of flu that is not helping the thinking process

Huh just went to get screen grabs for you and what ever it was that I was seeing last night is now gone

 

[kobaltkween]

There are a number of apps that can make 16 bit normal maps, they are generally used to avoid banding on gradients. Poser doesn't read them in the Poser root, never tried through the Cycles nodes. Would take up more memory in file size & rendering; not sure of the advantages - different with 8 bit vs 16 bit bump/displacement where the height can be varied.

Good to know!

It has the same advantages it would with plain bump: you get more range for detail. It varies height, it just varies x and y as well as z. Personally, I've never gone the 16bit route on bump, but I've never seen the need for more detail with my bump, either. But I've seen a whole lot of people claim that normal maps are better because bump didn't give them the detail they wanted. Either way, I've done a lot of making my own bump for cloth, and I can imagine running out of ranges you want to be in. For instance, I have my stitches, that's essentially one range. But then I have embroidered effects or velvet areas, and that should probably go higher than the stitches. Add in something like sequins, and that should probably go even higher. So I essentially want 3 different ranges, though you could just consider it one range with two sub-ranges. Oh, and of course the basic texture of the cloth (lower than stitches) and fine wrinkles (higher than stitches, lower than velvet or embroidery). So to give each of those significant range/gamut while still spacing them out as they should be, I could see wanting to go to 16bit. I never have before, but I could understand it.

 

[caisson]

Yes, normal maps code the slope of the high-poly mesh per pixel so vary x, y & z. As bagginsbill has pointed out, height maps are easier to work with & adjust. I still think that normal maps can be useful if a PITA to troubleshoot & adjust once made. I reckon it all comes down to what you want to achieve - if the end result works well for its intended use, how relevant is the technique used to get there?

Anyone interested & looking for info on normal maps will find that the Polycount wiki covers just about everything - normal maps & technical details.

Just a note on bit depth 'cos I came up with (IMHO) a good way to visualise it a while back, & why waste an opportunity (!) -

Imagine a staircase that joins two floors. The bottom floor is black; the top floor is white. An 8 bit staircase starts from 0 (black), ends at 255 (white), & goes from 0 to 1 to 2 etc - so there are 256 steps between the lowest & highest points.

A 16 bit staircase has the same range, black/low/0 to white/high/255. Instead of 256 steps though it has 65,536. From a distance it looks like a smooth slope rather than a staircase; you'd have to get pretty close to see the tiny steps.

For the sake of completion, a 32 bit staircase has over 16.7 million steps ... (source is the article on the Cambridge in Colour website).

 

[kobaltkween]

I like that analogy and imagery, though I'd set white at 1 rather than 255. In part because the 255 is wed to 8 bit color, and therefore your monitor (and there are now more than 8bit monitors). 1 is more agnostic and mathematically correct. The other reason, though, is more pertinent to this conversation. It's _really_ important to understanding shader math that 0 is black and 1 is white. It's the primary reason that Poser doesn't make 0.5 into 0 for random maps, or random inputs, just because it's easier to think of it that way if you're painting. It's also the reason you have to watch certain equations, because they can easily take input above white and below black if you don't design them to be clamped. For instance, if you decide to add together two displacement maps, or subtract one from the other, your highest point is probably above 1 (white) in the first, and below 0 (black) in the second.

To be further clear, because this is annoyingly confusing, what is often called 32 bit color is only 8 bit "mode" in something like Photoshop. So far, we've been talking about the number of bits per channel, where normally you talk about images and monitors in total number of bits. An image that allows 32 bit color has 8 bits per channel: R, G, B, Alpha. That's 4 different scales, not one scale that's 4 times as long. It's _really_ easy to get banding in full color images with subtle shading, and sometimes banding is basically hidden by shifts in hue rather than shifts in value.

Point being, while going from grayscale to full color makes for an image that has more information, what it doesn't have is a greater scale. Regular normal maps are technically 24 bit color, to a regular bump map's 8 bit grayscale, but they don't give you more detail in terms of height. To use Caisson's excellent analogy, normal maps have 3 staircases while bump maps only have one, but each staircase has the same number of steps. And if all you want to do is get up and down, the extra staircases don't do anything for you. They only help if you want to move around laterally.

 

[caisson]

0-1 does make more sense - I have 0-255 on the brain from Photoshop (histograms especially). Although I am bad with numbers in general & would prefer film base & paper base ...

I always assume bit depth is per channel unless stated otherwise - the articles/books etc I've read by photographers or 3d artists always refer to it that way. I consider it one of those times when terminology & convention matter - this can be a confusing enough subject as it is!