Hi.
I need your help.
I'm studying poser now.
And I applied displacement map in material room.
But, there is no effect.
Could you tell me what proublem is it?
Model is Prop > primitives > HiRes ball
Texture is New Node > 3D Textures > spots
Please help me.

(I used poser pro)

have you turned on "use displacement" in the render settings ?

No.
I'll see now.
I'm sorry about my foolish.
Thanks to FrankT.
You give me great help.

하나를 사용해야합니다, 회색, 검정과 변위에 대한 백인.
레드 화이트와 같은 변위 값을 갖습니다.

Thanks to Miss Nancy.
You are so kind.
Fantastic! Amazing!
Thanks!

Also check your Display Units under General Preferences. If your scale is set to meters, the displacement will become very exaggerated and distorted.

Thanks to hborre.
I thank you from the bottom of my heart.

Hi smalll...

Where there is black in a displacement map, it gives zero displacement, and white gives maximum displacement, as determined by the value on the Poser Surface node. (I think I have this the right way round - someone please correct me if I am wrong).

Displacement uses a single (greyscale) value, so your bright red (RGB value 127,0,0) would give one-third of your maximum displacement.

So if you use red as the base colour for the Spots node you are applying one-third of your maximum displacement value over those parts of the surface, and maximum displacement where the white is.

You might get some weird effects from this, so it's probably better to start with black as the base colour, and white to give the required displacement.

Izi

"If I were a shadow, I know I wouldn't like to be half of what I should be."
Mr Otsuka, the old black tomcat in Kafka on the Shore (Haruki Murakami)

Actaully, middle gray is the base non displaced color. Black (or darker) displaces inward, and white displaces outward.

Way too many people take way too many things way too seriously.

Oh.. thanks for the correction Gareee. I was wondering about negative displacement as I typed. I should have wondered a bit further.

In that case, by my calculation smalll's full red in her displacement map would give an inward displacement of one-third of the maximum.

"If I were a shadow, I know I wouldn't like to be half of what I should be."
Mr Otsuka, the old black tomcat in Kafka on the Shore (Haruki Murakami)

Quote - Actaully, middle gray is the base non displaced color. Black (or darker) displaces inward, and white displaces outward.

NOOOOOOO!

That is other programs. In Poser, black = 0. To produce no displacement, you send a ZERO to the displacment channel.

I have written about this many times. I wrote an extensive thread with many pictures - don't know where that is now.

Red 255 would produce 1/3 displacement. Red 127 would produce 1/6 displacement.

To produce negative displacement, you must send a negative number. THESE ARE NOT COLORS PEOPLE. They are numbers. It just so happens you can "see" numbers between 0 and 1 as gray scale, but you limit your thinking (in fact you muddle your thinking) by insisting that the data is a gray scale image. It is not an image. It is a two-dimensional array of numbers.

Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)

Completely unmuddled now... thanks bb.

"If I were a shadow, I know I wouldn't like to be half of what I should be."
Mr Otsuka, the old black tomcat in Kafka on the Shore (Haruki Murakami)

Attached Link: Masking into the Dissplacement Node?

Found the thread - follow the link

If you want Poser to behave like other programs, where gray (.5) is neutral, black (0) is inward (negative displacement), and white (1) is outward (postiive displacement), you must subtract .5 from the data.

Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)

I was referring to how it looks to the eye.

Here's my warcow displacement map, for example.

And yeah I did use the math node as well. since you have to get the displacement map out of a program like zbrush or mudbox, we have to get things like that to work in poser itself. I can't imagine trying to say, paint a displacement maps for a figure in a 2d program.

Way too many people take way too many things way too seriously.

> Quote - I was referring to how it looks to the eye.

: GRIN :

Click for full size.

If your "field", i.e. the majority of your displacement map, is white, than anything less than white, including "neutral gray" looks like a negative displacement.

I would accept the notion that you think of black as an indentation, when used against a non-black field. But it is very confusing to people if you tell them that gray causes no displacement. It is really important that people understand this. It is why you get bloat on a figure when you plug a gray-neutral displacement map into a Poser figure. It's fine to say you intend the black area to be a negative displacement, or and indentation of the field, but to actually say that black is or causes a negative displacement is incorrect, and many Poser users get very confused by the strange behavior they end up with.

Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)

Quote - we have to get things like that to work in poser itself

If you plug that straight into your figure, you will get bloat. If you intended the gray field to be neutral, and you did not subtract .5 from that, you messed up.

Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)

Oooh - it's even worse with your warcow displacement map.

Your neutral field value is RGB 149. Which means even subtracting .5 doesn't work with that map. For that one, you must subtract 149/255.

Here is your warcow map applied to M4's torso. Notice how all of the torso, even the "neutral" parts are displaced and separated from the rest of the figure.

Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)

This time, I subtracted 149/255 from your map value, because the neutral field on YOUR map is neither black nor mid-gray, but RGB 149, 149, 149.

Now the shoulder area is un-displaced like it's supposed to be with that map.

Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)

@ Baggingsbill,

Do you know if poser accept 16bit greyscale files, like tiff-files or does it convert back to 8bit bitmaps?

I've tried it to make a smoother displacement because when you use a big displacementscale you actually see steps, but as a matter of fact I didn't see much difference.

Thanks,

Bopper.

-How can you improve things when you don't make mistakes?

I can never thank you enough.
I have no words to express my gratitude.
I can´t find the words to thank you.
It's amazing!

That wasn't the exact map, BB.. I scaled it down, sharpened it, and kicked up the contrast on it to make it a bit more visible what was going on, but with a smaller image size.. ;)

But year, peopel do need to know not only how poser handles it, but also how to use exported displacement maps from zbrush, Mudbox, hexagon, or anything else that exports displacement maps.

I don't actually think anyone has compared them, or included how they need to be used in thier various aspects anywhere though.

Way too many people take way too many things way too seriously.

Quote - Do you know if poser accept 16bit greyscale files, like tiff-files or does it convert back to 8bit bitmaps?

Yes Poser 7 does support 16-bit precision TIFF files for displacement. The original Poser 7 had a bug in it where it misbehaved by always reading a 1 value in the blue channel of the TIFF, but I reported that bug and they fixed it.

There was quite a long thread about that here, where I gave a way to ignore the bad data from the blue channel. We don't need to worry about that any more, but the thread is still interesting to read.

It's here at runtimedna

http://www.runtimedna.com/mod/forum/messages.php?ShowMessage=386252

Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)

LOL I totally forget who I talk to and about what. Gareee, in that thread I linked to about the blue-channel bug and displacement, you were talking about warcow bloat!

The last shader you posted there had the bloat because you used the Comp node to extract only one channel, but you didn't also subtract .5 there.

Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)

@bagginsbill:

Now I have finally understood how displacement works. Thank you very much!

But what about Bump channel? Does it work like displacement or in the "traditional" way, that is, 50% gray means "no change" while white/black are positive/negative elevations?

Giorgio

giorgio_2004 here, ksabers on XBox Live, PSN and everywhere else.

Yeah BB.. I figured you'd recall that sooner or later.. LOL!

It'd be nice if doisplacement paint programs like zbrush just had some default settings you could choose for output maps, like poser, vue, lightwave, ect, to put out the best displacement map for how the target application actually wants it.

It's just hell to learn for a beginner, or even someone expereinced just looking into it.

Way too many people take way too many things way too seriously.

Thank you all of you!
It was great help to me.
You are so kind!

Quote - But what about Bump channel? Does it work like displacement or in the "traditional" way, that is, 50% gray means "no change" while white/black are positive/negative elevations?

Great question. Bump works the same way, which means that everybody for all of Poser history has been using bump maps incorrectly. However, almost nobody believes me. Mostly this is because the nature of bump mapping often does not reveal a problem. The surface doesn't actually move, so you don't see the "bloat".

But, if you have two surfaces opposed to each other very close together, the virtual bloat becomes evident. Bump mapping does not actually move the surface, but it does calculate things as if it did move it, then retains the changes in surface normal. As a result, if you have two surfaces very close together and facing each other, if you bump them past each other, you will get virtual crossover, and the render will have an artifact.

Most bump maps have sufficient dynamic range (difference between highest and lowest points) that people are able to use a very small bump value as a multiplier. So the overall field value, which is usually .5, does not appear to cause a bloat artifact.

However, if you have a very low dynamic range bump map, i.e. one that is almost entirely mid gray, then you will need to crank up the bump value. This means, for example, that if you have the bump value at .5 inch, and your field is .5, then you are performing an overall virtual displacement of .25 inch.

I will now demonstrate this problem to you, using the lo-res textures that come with M4.

Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)

Here is a very simple shader for M4, using the color map, but not the bump map yet.

Look at the bump map - it is almost entirely mid-gray, or .5. The variations are tiny.

(Note that this is a terrible bump map - practically useless in fact. But I find it useful here to demonstrate the bump bloat problem.)

In this image, I show you the shader and the render.

Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)

BB, while we are on (sort of) the subject, have you ever found any evidence that using the new poser pro normal mapping is any better then displacement?

Way too many people take way too many things way too seriously.

Now I attach the bump map the way everybody (but me) does it.

I have to increase the bump amount to .2 to even be able to see the bump at all. (Again, this is a terrible bump map - too low resolution, no dynamic range, and just bad shapes in general. But whatever.)

Look at the render. Wherever there are two surfaces in close proximity, opposite in orientation (facing each other) we see a rendering artifact. These are in the eyelid creases, the nostril crease, and the corner of the mouth.

If you fail to understand the bloating, you might think that decreasing the bump value would solve the problem. And it would, but you'd also cause the bump map to have almost no visible effect. So decreasing the bump value is not the right approach.

Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)

Here is the correct solution - identical to how you should handle displacement maps.

You must subtract the "field value" from the image value. In this case, the field is .5, so I subtract .5. This means that across the image, the mid-gray field yields a numerical value of 0 which means no change across most of the surface.

Only where the value is slightly more than .5 or slightly less than .5 do we get a peak or valley on the surface.

This is the correct way to handle mid-gray field bump maps and displacement maps. Again, we almost never see this problem, so it is safe to ignore 90% of the time. But why take the risk? Also, even if you have a pretty good bump map with nice dynamic range, you are still getting a small difference in the rendered output. If you load a good bump map, zoom in close and render with and without the .5 offset. You will often see a difference. It is usually not a difference you would notice unless you do a direct comparison, but it is there nonetheless.

Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)

Quote - BB, while we are on (sort of) the subject, have you ever found any evidence that using the new poser pro normal mapping is any better then displacement?

No. I got into several little fights with people about this. Several times, somebody makes the claim that normal maps render faster, or are more detailed, or more accurate, or some other measure of superiority that I have never verified.

Every time we got to the point of me saying "Look - stop making unsubstantiated claims. Produce - using any tool you like - a matching set of bump map and normal map. Use both in a render. Show me the render, and show me the render time differences."

Every time I have said this, the thread would end. Nobody would ever come back and answer. I take that to mean that they were just making stuff up or repeating stuff they heard, and had no actual proof.

On the other hand, I have demonstrated that a normal map, by its nature, does not let you adjust the intensity of the bump effect the way you can so easily do with a bump map. Furthermore, I have demonstrated several times that Poser Pro has a serious BUG with normal maps that make them useless.

All of the specular effects IGNORE THE NORMAL MAP. Some developer forgot to add the support for normal maps into the specular functions. Only the diffuse functions pay any attention to normal maps.

In my opinion, this makes them utterly useless. While there is some importance to the direction of surface normal in diffuse reflections, the primary impact is on specular reflections. Poser Pro's failure to include the normal map in specular reflection calculations means you just shouldn't use them at all.

Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)

That's pretty much what I figured.. I'll have to send a message to SM, to see if someone is looking into that as a bug fix.

Way too many people take way too many things way too seriously.

Quote - Oooh - it's even worse with your warcow displacement map.

Your neutral field value is RGB 149. Which means even subtracting .5 doesn't work with that map. For that one, you must subtract 149/255.

Here is your warcow map applied to M4's torso. Notice how all of the torso, even the "neutral" parts are displaced and separated from the rest of the figure.

the grey color in the zbrush displacement map is not the same grey as in poser. i opened a thread about this.

Thank you very much bagginsbill!
I had always used the bump channel in the wrong way.... although it seems I am in good company. Now things are much clearer!

Giorgio

giorgio_2004 here, ksabers on XBox Live, PSN and everywhere else.

i think people are using hte normal maps only when they have a specific texture made in mudbox or in zbrush. for normal maps it was never meant to use different settings.

p.s. i am doing some custom displacement maps for apollo maximus
http://www.contentparadise.com/forums/showthread.php?t=10527&page=4

Quote - > Quote - Do you know if poser accept 16bit greyscale files, like tiff-files or does it convert back to 8bit bitmaps?

Yes Poser 7 does support 16-bit precision TIFF files for displacement. The original Poser 7 had a bug in it where it misbehaved by always reading a 1 value in the blue channel of the TIFF, but I reported that bug and they fixed it.

There was quite a long thread about that here, where I gave a way to ignore the bad data from the blue channel. We don't need to worry about that any more, but the thread is still interesting to read.

It's here at runtimedna

http://www.runtimedna.com/mod/forum/messages.php?ShowMessage=386252

do i need SP3 for 16-bit TIFF support?
i have only SP2. on poser 7

SP2 will work but you will need to use a Math:Component node to pull out only the red channel - because the blue channel won't read correctly.

It's in that thread I linked to RDNA.

Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)

Thank you all for the info/tips/tutorial! Always helpful!

The dust settled, thinking "what a fine home, at least for now" not realizing that doom would soon be coming in the form of a vacuum cleaner.

Wow. thank you I've been looking for this myself. Another question. (Don't throw rotten fruit guys, as I have asked this several times, including dedicated threads and haven't actually gotten an answer). Obviously the face isn't the same scale as the limbs or the torso. What is the ratio ... or how do the different maps on the DAZ generation 4 figures scale relate? (I suppose I should ask about the native Poser figures as well (i.e. Roxie/Rex, Alyson/Ryan, G2's, etc.) This way when creating generic bump maps, texture overlays and such the maps will be scaled consistently.

Boni

"Be Hero to Yourself" -- Peter Tork

If you're using 3D procedural patterns, the UV scale does not come into the calculation at all. For example, when I use a Turbulence node to make the small-scale bumpiness of tiny skin wrinkles, the UV mapping has nothing whatsoever to say about how that's going to look on the figure.

As for patterns that are driven by the UV mapping (such as when using an image for a height map) there is no such answer. The UV mapping is not only different for each figure's "islands" (look at the arm/leg map to see what I mean) but it's different within each island. For example, the V4 leg mapping is so distorted that if you were to put a circle on the knee, it looks nothing like that on the thigh or buttock. It's impossible to even specify the scale in a situation like that.

Your question is like asking "How high is Colorado." I can give you an average, but if you try to blindly land a plane at that height you're very unlikely to find your wheels just touching the ground instead of being inside a mountain or still 1000 feet above the ground.

Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)

Here's a demonstration. This is V4 with with a 2D circular tile pattern applied.

The two red disks are identical in size and matched to the same size as a white dot on the back of the knee.

Yet just a small distance away, the scale of the dot on the calf is much larger than the red disk.

This shows you that it's impossible to say what "the scale" of the UV map is - there's no single answer that suffices.

file_a97da629b098b75c294dffdc3e463904.jp

Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)

More examples.

file_5f93f983524def3dca464469d2cf9f3e.jp

file_1ff8a7b5dc7a7d1f0ed65aaa29c04b1e.jp

Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)

However, if you're interested in the size ratio between the red (knee) disk and the green (nose) disk, it's about 2.5x.

Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)

The ratio between the green (nose) disk and blue (cheek) disk is about 1.4x.

file_cfecdb276f634854f3ef915e2e980c31.jp

Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)

Using these ratios, I can get the shoulder and the cheek roughly the same.

But the arms, ears and chest are too small, and the nose, lips, and chin are too large.

file_4c5bde74a8f110656874902f07378009.jp

Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)

UV stretching during the unfolding process, a little is unavoidable even in the most meticulously mapped organic forms. The process of minimizing this can be a hair pulling experience. Also, the size between images projected onto each island/shell can be tweaked during the mapping process through various means in order to minimize the size difference. E.g. Wings3D/Scale/Normalize Sizes.

Creating textures for models with images is largely dependant on the model itself, as BB stated with his Colorado analogy. You have to use your judgement, experience with that model's UVs, and a lot of test rendering. Eventually, with practice, you'll arrive at a consistant texturing workflow for a particular model.

...In general, with contemporary humanoid Poser figures, the mapping on the face region is always larger in order to allow for more detail in the textures of that area I imagine... at least with Daz figures where the head region is usually a separate map from the body.

Also, you won't really be able to create a universal overlay system that will accommodate every figure. Each has their own peculiarities and mapping, in this I mean an overlay designed for Miki is not going to work on V4 without some scaling and adjusting in an image editor. You can create a generalized texture creation kit for details, make ups, etc, on their own layers that can be manipulated in an editor to fit a particular template. The Edit/Transform and Filter/Liquify Photoshop functions are useful tools for this.

Thank you so much folks ... I finally can ... er ... wrap my mind around this and understand it. Sorry, sometimes I can't resist a good pun ... ;)

Boni

"Be Hero to Yourself" -- Peter Tork

i've bought quite a few characters for V4 and M4 that plug the image map into diffuse and the bump channel.

does a color texture map in the bump channel make bloat?

I had no idea that bloat was happening in my renders.

Thanks.

♥ My Gallery Albums ♥ My YT ♥ Party in the CarrarArtists Forum ♪♪♪ 10 years of Carrara forum ♥ My FreeStuff

MistyLaraPrincess posted at 3:14PM Sun, 08 May 2016 - #4208598

does a color texture map in the bump channel make bloat?

Long time no reply... But now there's a discussion over in cgBytes linking to this thread. So...

A diffuse colour map fed into the bump channel will create overall outward displacement of the mesh, which can be described as 'bloat'. Whether this becomes obvious to the eye depends on the brightness of the colour map, the value of the bump channel input, and the shape of the base mesh itself, as BB demonstrated above. But as he said, there's no point taking risks when it's so easy to do it right.

For human skin I would say just don't use the diffuse map for bump, ever. The brightness of a decent diffuse colour map simply doesn't represent variations in skin height due to pores, veins, wrinkles, etc. - so it doesn't belong in the bump channel at all. For example, protruding veins are usually darker than the surrounding skin, but plugging this data into the bump channel would render them as depressions.

If you don't have a good, purpose-built bump map for your figure, I would suggest using procedural bump.

"If I were a shadow, I know I wouldn't like to be half of what I should be."
Mr Otsuka, the old black tomcat in Kafka on the Shore (Haruki Murakami)

Forum: Poser - OFFICIAL

Subject: Question about displacement