I'm having a big issue for some reason in Poser Pro 2012 doing a simple displacement map. I've attached the image here...

What I've done is added a color subtract node to my zbrush displacement map. Now, Zbrush exports based on 50% grey non-displaced, so I add the color subtract and use the color picker and select the grey portion to give me a black base for non-displacement (In pro 2012 I must now drop the gery by an additional 1-4 luminosity to get black but that's not the issue here)....

What is now happening is that a color that should now be lower than 0 (black) is now becoming a positive number and displacing OUT instead of IN. You can see the result clearly in the color match node when I open the eye tab to see the color information results.

I will submit a SM ticket.... maybe.... I am NOT f'ing with my drivers for them, not ever again. This MUST BE a poser issue. Please let me know Renderosity if there is a different way to do this to make it all work.... or if anyone has had the same issues. I've done tons of displacement maps in the past... using THIS method, never had an issue before today.

did your try to switch the colors in the math node? use the lower color for grey and up color for white?

Why would I do that????!!?!?!?!!?!?!?!?!??!?!!? That doesn't make any sense to me. Can you explain your rational? If I did that I would be toning down the information from the displacement map and the subtracting 1 from it...

Nevermind All............... closed poser.... opened poser.... no longer an issue..... Everyone, as you were...

Your math node is inverting the displacement. You're subtracting displacement from gray where you should be subtracting gray from your displacement. 

But you can clearly see it is not inverting it. White is still white, grey is now black, but black is now grey.... Anyway, like I said... I closed poser, hooked it up exactly the same, and now it works fine. Just a bug that sorted itself out.

Sometimes, a quick Close/Re-Open is all it takes ;)

I tried to walk away, I really did. But I can't stand to let statements like this go.

What do you mean white is still white? It most certainly is not. It is now negative grey, a color which appears to be black in preview.

Here is the math you did:

grey - map

or

.5 - map

Allowing for the moment that your grey is not quite .5, let's just look at the general case.

Black = 0, so when the map is black, you get

.5 - 0 = .5

Areas of the map which are black become grey, or positive displacement. In ZBrush this is supposed to be a negative (inward) displacement.

Grey = .5, so when the map is grey, you get

.5 - .5 = 0

So grey becomes black, or no displacement.

White, which on the map means positive displacement, is a 1.

.5 - 1 = -.5

This is a negative grey, indicating a negative displacement.

Clearly your render shows that all displacement has been flipped. Where the map has black grooves, the object has ridges.

Subtraction, or negation, is the same as forming a negative image, which in displacement terms means reversing everything.

Whether or not you subtract from black, from grey, or from white, doesn't matter. That simply changes the offset of the whole thing.

The correct means to offset the map, where higher numbers should still be higher than lower numbers, is to simply subtract the neutral grey value from the map.

This is correct:

map - .5

Now consider:

white (1) - .5 = .5 (a positive displacement)

grey (.5) - .5 = 0 (no displacement)

black (0) - .5 = -.5 (a negative displacement)

Glad to see you got your issue solved with something nice and simple, regardless of long winded opinions to the contrary.

Long winded?

I answered this:

Quote - Why would I do that????!!?!?!?!!?!?!?!?!??!?!!?

Do you see all the punctuation? Clearly a simple statement like "use the lower color for grey and up color for white" didn't cut it, even though this is the correct way.

Just because the OP thinks they got it figured out, doesn't mean they did. I've seen at least a dozen posters in the last week demonstrate that they do things they're not aware of, or don't do things they said they did. Other people read these and get confused. Then we get memes going containing second-hand falsehoods.

Frankly, your post, Steve, looks like it is made to stay just this side of the TOS line, while being an insult.

Pot. Meet Kettle!

Attached Link: http://www.renderosity.com/mod/forumpro/showthread.php?thread_id=2837749

it's not just for Daz.

Now, how Stewer and Bagginsbill tried to explain, the math in the original image wasn't right. If Firefly's programmer and the shader guru agree, I'm sure they are right. No need to get unfriendly here.

I don't have a problem with lengthy explanations either. But please, do not get personal.

The shader pictured above will produce the render pictured above. BB just explained why. 

Glad to see we kept it civil....

I see what everyone is saying about switching the white and grey in the math nodes. I just took for granted the order. I thought that 2-1=1 would be the same thing as 1-2=1, but it's not, it would be -1....... I get it... even if my example doesn't fit this scenario, it makes sense to me now.

When Iceboy said to switch, he didnt say to plug the image to the white when doing so... it was late(4am i think) and I should have turned everything off and hit the sheets. Things always look different the next day. By closing and opening the program, it forced me to re-make the shader node, and I made it correct the second time without even knowing, hence BB's statement of making a second false statement without even knowing it.

Sometimes it takes a fresh eye to see the mistakes, that's the reason I come to the forums....... Thank you everyone!

ps: Now can someone point me to a thread on SSS and tell me if lighting has anything to do with seeing my SSS effects? I know about the backlighting and all (coming from a mental ray background) but I can't seem to get the look right.... I remember reading BB's thread on it at rdna, but see nothing about the lights (though i'm sure i missed it).

Quote - I tried to walk away, I really did. But I can't stand to let statements like this go.

What do you mean white is still white? It most certainly is not. It is now negative grey, a color which appears to be black in preview.

 

Here is the math you did:

 

grey - map

or

.5 - map

Allowing for the moment that your grey is not quite .5, let's just look at the general case.

Black = 0, so when the map is black, you get

.5 - 0 = .5

Areas of the map which are black become grey, or positive displacement. In ZBrush this is supposed to be a negative (inward) displacement.

Grey = .5, so when the map is grey, you get

.5 - .5 = 0

So grey becomes black, or no displacement.

White, which on the map means positive displacement, is a 1.

.5 - 1 = -.5

This is a negative grey, indicating a negative displacement.

Clearly your render shows that all displacement has been flipped. Where the map has black grooves, the object has ridges.

Subtraction, or negation, is the same as forming a negative image, which in displacement terms means reversing everything.

Whether or not you subtract from black, from grey, or from white, doesn't matter. That simply changes the offset of the whole thing.

The correct means to offset the map, where higher numbers should still be higher than lower numbers, is to simply subtract the neutral grey value from the map.

This is correct:

map - .5

Now consider:

white (1) - .5 = .5 (a positive displacement)

grey (.5) - .5 = 0 (no displacement)

black (0) - .5 = -.5 (a negative displacement)

 

0..0

What he said.
because ...I use Zbrush/Poser all the time...and you know you can actually export a 16bit TIFF and use that in Poser now(8 onward...dunno about 7). Just set your zero displacement depth in Zbrush to black. No fuss, no muss:D  Then inside Poser just use "1" displacement for inches or a "0.02" for feet or...such.

Math Node>Subtract: 1(displacement map plugged here)-0.5
This should work if you're using inches as your Poser units and you've exported a "50% gray equals zero depth" map from Zbrush.  

http://www.runtimedna.com/forum/showthread.php?63200-SSS-on-Human-Figures/page25
I'm not sure if anyone discussed the displacement/SSS thing...but I know it seems to be an issue with things I'm working on. Could just be that my node setup is lighting the meshes wront. We'll see!

Hi corinthianscori,

I don't want to mess with the Zbursh export options cause I might want to use them in maya/mentalray in the future, but thanks!

I'll check the link!!