In some programs normal maps can be seen in real time, which is fairly impressive for a quick simulation of the high poly look. In Poser 8 you can render a normal map, but you can't see it in the preview. Since you could render a bump map or even a displacement map, I'm wondering if there is any good reason to use a normal map in Poser 8?

A Bump map and Normal Map do essentially the same job in terms of adding a depth effect to your model.

However with a bump you have to guess the strength and key it in, so you either get too weak on too string an effect.  However with a Normal the strength is always 1, so you get just the right effect with a Normal.

John.

Quote - A Bump map and Normal Map do essentially the same job in terms of adding a depth effect to your model.

A bumpmap is 2-D (B-W), a normalmap is 3-D (R-G-B).

Quote - > Quote - A Bump map and Normal Map do essentially the same job in terms of adding a depth effect to your model.

 

A bumpmap is 2-D (B-W), a normalmap is 3-D (R-G-B).

That is true, but they achieve the same effect.

Minor correction, apropos nothing, but a black and white (B-W) bump map is 1-D, not 2-D. Black and white are the two ends of the only dimension it records. RGB has three black and white maps in it.

The chief performance advantage of a normal map, as the OP pointed out, is speed. The delta to the normal is directly available from a normal map. From a bump map, the delta to the normal must be derived by computing gradients from neighboring pixels. In Poser, this speed advantage is unmeasurable.

The chief usability advantage of a normal map, as Fugazi pointed out, is that the perceived depth is always the same, and cannot be screwed up by the user. For example, if every V4 texture came with normal maps instead of bump maps, nobody would ever get the advice "I think you have the bump set too high."

If you're not starting with the premise of some known geometry being simulated, then the notion that the depth is fixed is actually not an advantage. It's a flaw. If I want to re-purpose a bump map to make an object appear more or less bumpy, I have the simple freedom to change the bump depth. Not so with normal maps.

For procedural shader work, a bump map is far more flexible. I can read the height out of a bump map and use that info to drive other things, such as color or shine. The most common and familiar use case is ceramic tile. A bump map for that tells me whether I'm drawing the tile or the grout and can be directly deployed in a Blender node. The normal map version of the same surface is unusable for this purpose, since both the tile and the grout have places where the normal is unchanged, i.e. pointing straight. Thus they have the same data and are indistinguishable.

Quote - In some programs normal maps can be seen in real time, which is fairly impressive for a quick simulation of the high poly look. In Poser 8 you can render a normal map, but you can't see it in the preview. Since you could render a bump map or even a displacement map, I'm wondering if there is any good reason to use a normal map in Poser 8?

Normalmaps are used with low-poly objects to save memory and rendertime. Using a normalmap is not the same as using a bumap. See the blender documentation for a detailed description with samples.

In Poser normalmaps may be used with animations. Typically (for Poser users) not for the main characters but for highly detailed backgrounds and other props.

For animations rendertime per frame is very important. Using "flat geometries" with normalmaps as proxies insteed of highly detailed meshes can save a lot of rendertime.

BB.. have you ever decided if you prefer normal maps over displacement maps? I recall a debate about them a while back, but not the end results.

Sorry I took a couple days to answer. I wanted to do some research first so I have some data from which to make a judgement.

SHORT ANSWER: Bump map wins, hands down. Normal maps are less detailed and the time savings versus bump map is tiny. I have the option to use a bump map as displacement. Bump maps are adjustable, normal maps are not.

LONG ANSWER:

I rendered a Fractal Sum node to produce a 300x300 bump map image which I saved. 

I loaded the bump map, and using the N node and a little math, I rendered an equivalent normal map. I saved that as normal map image.

I then made two squares, one with the bump map, one with the normal map, and rendered them side by side, to verify that they produce the same appearance.

While they look similar, the normal map looked softer. The attached images shows the results - bump is on the left. Perhaps the results would be different if I had generated the normal map from the procedural directly, instead of from the first bump map. But when I'm given a bump map, this is the only method possible, so it's not valid to justify some other tactic for producing the normal map.

So my first tentative conclusion is that pixel-for-pixel, a bump map is more detailed in Poser. Perhaps that's due to my method, but here you have the information about what is the outcome using this workflow and can judge for yourself. I will not be converting bump maps to normal maps for the purpose of an improvement in detail, since the opposite happens using this workflow.

Now all that remains to justify the normal map is speed. What's the speed difference?

I fill the preview with the square and render at 600 x 600 on my MacBook Pro in Poser Pro 2010. I used two lights - an IBL with no image and no AO, and a single infinite with raytraced shadows. I used the Render Firefly script for timing the render. I rendered three cases - using the bump map as displacement, using it as bump, and using the normal map.

Displacement - 18.4 seconds

Bump - 14.7 seconds

Normal - 14.2 seconds

The displacement surely takes longer, and for brick walls and other such generally flat things, is not visually different enough to justify the time. However, if something really sticks out, this is what I use.

Obviously, the normal map saved 1/2 second.

Now in my typical render, I am not just rendering a stucco or brick wall, and the render is usually bigger. But in this test, 360,000 pixels (360 KP) were of the wall, and we can presume that in a larger image with other stuff, we still might have about 300 to 500 KP of normal-mapped content being rendered. So in such an image, I will still save about 1/2 second on the render, even if the rest of the stuff makes the render take a couple minutes.

Is this worth the effort? Not in my opinion. If conversion of a single bump map to normal map format takes me just 2 minutes, I have to render the image 240 times just to get back to even.

When I also take into account that the quality of the details is somewhat reduced, and that I no longer have the ability to tweak the bump depth when using normal maps, my conclusion is I will never use them unless they already are given to me.

Edited to add:

Sometimes people say normal maps save a lot of time, but when they say this, they do not mean save a lot of time compared to bump maps. They mean save a lot of time versus using real geometry. Bump also saves a lot of time versus using real geometry. Keep the comparison clear in your mind when reading posted opinions. Displacement is much faster than geometry. Bump is slightly faster than displacement. Normal is just a tiny bit faster than bump.

I'm actually surprised it's measurably faster at all, good to know.  Worth noting that when you're rendering an animation, any time saving is good, even a tiny one like this, but yeah for stillframe I think bump maps make so much more sense.

IMHO bump maps and normal/displacement maps should really have two different uses.

Bump maps I'll use for small detail.. skin pores, woodgrain, cloth textures, that sort of thing.

Normal maps and displacement maps I see being more useful for enhancing mesh detail sculpting level without adding polygons. (Similar to what they do in most games now.)

That said, is there any clear advantage/disadvantage you see when comparing just normal maps and displacement maps? If I recall, Daz studio did not support normal mapping, but thats ben added since then, so that was a disadvantage to normal maps in poser content back then.

I think another big issue back then, was displacment mapping needed a tricky node setup to get properly, and normal mapping just needed a simple 1.0 setting, so normal mapping was easier for end users to create.

But I recall someone saying the normal mapping was an improvement over displacement mapping for some reason, be it speed, final render quality, shadows, or something along those lines. (One thing I reall was creating normal maps in external utilities like zbrush was easier then creating displacement maps, since you could get the proper 3d displacement amount easier than with actual displacement maps.)

It might have just been someone's personal preference, or the fact that normal maps are a more portable format, since game engines could also take advantage of the normal maps, vs the more common poser displacement maps, which could not be used in a game engine.

So my question was more normal map vs displacement maps. Odds are I'd still use a bump map for small details in combination with one or the other. Or just keep the small detail in the superior displacement map, vs using a combo of normal maps and bumps maps to reduce memory overhead, since the displacement maps retains that small detail better.

Quote - That said, is there any clear advantage/disadvantage you see when comparing just normal maps and displacement maps?

Displacement will actually change a model's profile, but bump and normal mapping won't.  This actually adds geometry (at render time) and pretty significantly increases render time, but if it's the effect you want, it's the effect you want.

http://en.wikipedia.org/wiki/Displacement_mapping

I think the saving of time refers more to the handling of the normal map, rather than render-time. When using bump or displacement maps and you want to use large or even unknown displacements, you cannot use 8 Bit pngs or jpgs anymore, otherwise you would get distortion due to colorbanding (see image, left normal; right bump). And the  whole process of rearranging, cutting and pasting texture maps is usually more inconvenient with 16 bit or hdr images, than with 8 bit images, simply because it is not so broadly supported by tools. With normal maps you just can use 8 bit pngs in most cases, which is a bonus in my opinion.

Another aspect in favour of normal maps is that when making materials, you can actually think in terms of the surface normal. Sometimes you just want to say: "For this piece of brushed metal, the polisher brushed counterclockwise, and so all normals should point slightly left". With bump maps you always have to come up with a geometry  (i.e. height-map) that would generate the normals you want to have.

I thought normal mapping does change the model profile, like displacement does?

just as an aside, in trying large-displacement maps in poser 8, I get banding and artifacts whether I save the displ.tiff in APS as 8-bit, 16-bit or 32-bit.  I thought 16-bit would eliminate the banding, but maybe P8 is not interpreting the APS-exported img as 16-bit for some reason.

Here is a comparison Teyon did a couple of years ago.

http://www.renderosity.com/mod/forumpro/showthread.php?message_id=3378876&ebot_calc_page#message_3378876

     OK, this is new to me, so bear with me.  I would have thought that normal mapping assigned normal vector direction & magnitude, which may be different from the normals as defined in the OBJ.  And while each geometry facet has one normal, a map could assign a myriad of normals across the area of that facet.

     Could a normal map be used along with a displacement map, so as to control the direction of displacement?

     I could see beaucoup uses for such a thing, using a normal map to adjust the direction of displacement.  Using displacement can make stubbly quills on a hedgehog, but they all stick straight out.  With a normal map added, you could make the quills lay in their proper orientation.

     I frequently use displacement to cover large areas of ground with grass.  With an animated normal map added, you could make the grass sway in waves as if in response to wind.

     Same technique could roughly simulate partial derivatives to guide a teardrop streaming down a face.

     Is this feasible? 

     But this would only work -at least work easily- if the normals could be mapped in 2D as with a UV map.  If the Poser normal map is 3D, is it object coordinates or world coordinates?

Quote - I thought normal mapping does change the model profile, like displacement does?

Nope.

edit: I understand now why normal maps are the standard for 3D computer games - framerate.  Thanks for clearing up that little mystery for me Bagginsbill.

BB, my question would be what app did you use to create the normal map? Zbrush, Nvidia, nDo, xNormal??

I have found that there is a big difference in the final result. And no, normals do not change the profile.

Quote - BB, my question would be what app did you use to create the normal map? Zbrush, Nvidia, nDo, xNormal??

I have found that there is a big difference in the final result. And no, normals do not change the profile.

Poser. Did you not read how I used the N node and some math?

I exported the actual normals by rendering the N node.

Specifically, I rendered

.5 * N + .5

ahhh, sorry didn't see that.

It's weird I have found simular results with normals and bumps, sometimes the normal wins and sometimes the bump wins. I really haven't been able to determine a pattern yet as to why one over the other though...so I just create both and see which is best.

Do you know, do we still have to do a tricky node setup to use displacements? Haven't tried it yet with P2010.

Quote - For procedural shader work, a bump map is far more flexible. I can read the height out of a bump map and use that info to drive other things, such as color or shine. The most common and familiar use case is ceramic tile. A bump map for that tells me whether I'm drawing the tile or the grout and can be directly deployed in a Blender node. The normal map version of the same surface is unusable for this purpose, since both the tile and the grout have places where the normal is unchanged, i.e. pointing straight. Thus they have the same data and are indistinguishable.

Ooo, try UDK:procedurale normal map and "derive Z axis",

Normal map

r=((X+1)/2)*(increase or decrease value)

v=(Y+1)/2*(increase or decrease value)

B=(Z+1)/2 or occlusion zdepht

by default, poser use only red and green

In poser

ex:for z axis

Normal map--->hsv(color:blue,saturation=0)--->*2--->Substract 1=Diffuse value

sorry for my bad english :SAD

I have thought of a use for conversion of displacement to normal maps now that we have comic book colour and render in preview mode. eg scars on the face, M4 muscle maps etc.

My friend Wim taught me this trick. You convert the displacement map to a normal map using photoshop-> filter-> 3D and there you go. this is the cartoon preview mode in poser Scar on left cheek and veins are displacement maps applied as normal maps after conversion in photoshop.

I have no idea whether it produces normal maps which are properly compatible with Poser, but I have converted height2bump.py to run in Poser Python. PIL comes with Poser by default since P8, so we can have image processing scripts now.

The script seems to work for me in PPro14 with no hassles. I dunno if I can attach files here nowadays, so I've uploaded it to my Morphography page: http://www.morphography.uk.vu/~cagepage/2016/ppy_height2bump/ppy_height2bump.py

does it convert bump to normals or vice versa. I need my bumps and displacement as normals or they won't show up in preview and then I can't make my comic using poser's comic colour feature.

Oh by the way if you click the little key next to the normal map part of the material node it makes a little dial in the parameters for the body so I could make his veins stick out when angry and damp them down when he isn't weight lifting etc. so that is a very nice poser 11 feature.

Height2bump takes in a grayscale Poser-style bump or displacement map and produces a normal map. See the attached image. I know the script name is confusing, from our Poser POV. I've retained the confusing naming of the source script, to honor that source. But... confusing. I assume the way he uses the terms "height map" and "bump map" reflects some kind of industry standard or other, somewhere out there in the 3DCG world. And to them, we would be the weirdos! So it's like Bizarro World and everything.

I really am babbling now. Hmm.

Thanks - awesome!!!

I tried to run the script and got his error

File "/Volumes/Promise Pegasus/convertgreyscaletonormal.py", line 1 {rtf1ansiansicpg1252cocoartf1404cocoasubrtf340 ^ SyntaxError: unexpected character after line continuation character

Can you give me more context on the error? They usually start with a chain of script references, revealing where the error was thrown. My guess offhand would be that PIL is being finicky about something in the file naming or path listing, but I can only guess about what's happening without more information. PIL throws some weird errors, I've noticed.

Okay, second guess. There's something PIL considers odd about your file's internal formatting. Maybe.

More information would help me figure out what's going on.

I copied the whole text and pasted it into a text document, saved it and then renamed it as a .py instead of .txt can I attach or copy it here so you can see? Or you could email me at esther@pacefiction.com

seachnasaigh posted at 5:19PM Mon, 15 February 2016 - #3766829

     Could a normal map be used along with a displacement map, so as to control the direction of displacement?

There is something similar to this called "vector displacement". Would be great to have in Poser but I've no reason to believe we'll get it. Development seems to favor the most vocal users, and those are the people who want Poser to chase D|S feature additions (which favor ultra realism). Personally, I'd prefer the devs chase iClone instead...

Here a video showing vector displacements being adjusted/displayed in real-time in iClone. Go to the 2:20 mark: https://www.youtube.com/watch?v=CM7328frqSI

Jeepers, moogal. That video makes me feel sorta bad for Poser. We have SSS, but they have a whole lotta whizwhams in iClone Land.

With some prompting from estherau, I've improved that script a bit. It doesn't work on Mac, sadly, because the Poser installation of PIL on Mac is incomplete, lacking the .jpg encoder. Bummer. Hoping the Poser Team can fix that, as PIL is very useful.

The script, with instructions, is here: http://www.morphography.uk.vu/~cagepage/2016/ppy_height2bump3.zip

Cage posted at 7:52AM Wed, 17 February 2016 - #4255405

Jeepers, moogal. That video makes me feel sorta bad for Poser. We have SSS, but they have a whole lotta whizwhams in iClone Land.

Wow! And it's pretty cheap, too...

Which node is the correct place to plugin normal maps? Is it the bump node?

If using the PoserSurface root node, plug into the gradient_bump socket and set the mode to tangent space normal map.

The PhysicalSurface root node has a socket dedicated to normal map.

For the CyclesSurface root node, use a normal map node and a mix node.

OKCRandy posted at 10:55PM Fri, 25 November 2016 - #4290948

Which node is the correct place to plugin normal maps? Is it the bump node?

On the Poser root you would plug a normal map into the Gradient_Bump port and turn Gradient Mode to "Tangent Space Normal Map."

Seachnasaigh is one fast typist!

Thank you all I asked the same question months ago over at RDNA and got no help at all. I am trying to learn how to use the Physical surface for materials I have yet to find an example for human skin.

OKCRandy posted at 8:39AM Sat, 26 November 2016 - #4290966

Thank you all I asked the same question months ago over at RDNA and got no help at all. I am trying to learn how to use the Physical surface for materials I have yet to find an example for human skin.

Snarlygribly and bopperthijs have a script and plug-in for this.

there is a good thread at the Smith Micro forums about it.

https://forum.smithmicro.com/topic/595/cycles-based-plugin-s-for-ezskin3?page=1

here is an example using this:

ghostship2 posted at 10:30AM Sat, 26 November 2016 - #4290985

OKCRandy posted at 8:39AM Sat, 26 November 2016 - #4290966

Thank you all I asked the same question months ago over at RDNA and got no help at all. I am trying to learn how to use the Physical surface for materials I have yet to find an example for human skin.

Snarlygribly and bopperthijs have a script and plug-in for this.

there is a good thread at the Smith Micro forums about it.

https://forum.smithmicro.com/topic/595/cycles-based-plugin-s-for-ezskin3?page=1

here is an example using this:

Yes I know about that but that is not using Physical Surface it uses Poser Surface. Besides that I am trying to learn more about using Physical Surface most examples I see of Poser Superfly materials are all Cycles Surface (and then they do not explain where all the nodes used are found). Not sure why that is.

OKCRandy posted at 5:19PM Sat, 26 November 2016 - #4290993

Yes I know about that but that is not using Physical Surface it uses Poser Surface. Besides that I am trying to learn more about using Physical Surface most examples I see of Poser Superfly materials are all Cycles Surface (and then they do not explain where all the nodes used are found). Not sure why that is.

Smith Micro (Chris Taylor and Teyon) did a "Explore the Power of the Poser Physical Root Node" Webinar. A video of it can be found on the Smith Micro Graphics channel on YouTube. It does include a discussion on SSS (about an hour into the video I think).

OKCRandy posted at 11:08AM Sat, 26 November 2016 - #4290993

ghostship2 posted at 10:30AM Sat, 26 November 2016 - #4290985

OKCRandy posted at 8:39AM Sat, 26 November 2016 - #4290966

Thank you all I asked the same question months ago over at RDNA and got no help at all. I am trying to learn how to use the Physical surface for materials I have yet to find an example for human skin.

Snarlygribly and bopperthijs have a script and plug-in for this.

there is a good thread at the Smith Micro forums about it.

https://forum.smithmicro.com/topic/595/cycles-based-plugin-s-for-ezskin3?page=1

here is an example using this:

Yes I know about that but that is not using Physical Surface it uses Poser Surface. Besides that I am trying to learn more about using Physical Surface most examples I see of Poser Superfly materials are all Cycles Surface (and then they do not explain where all the nodes used are found). Not sure why that is.

bopperthijs's plug-in uses the Cycles root and cycles nodes for the shader it is 0% Poser nodes. The physical surface root is most likely a compound node that uses Cycles nodes inside so basically the same thing.

ironsoul posted at 12:13PM Sat, 26 November 2016 - #4291001

OKCRandy posted at 5:19PM Sat, 26 November 2016 - #4290993

Yes I know about that but that is not using Physical Surface it uses Poser Surface. Besides that I am trying to learn more about using Physical Surface most examples I see of Poser Superfly materials are all Cycles Surface (and then they do not explain where all the nodes used are found). Not sure why that is.

Smith Micro (Chris Taylor and Teyon) did a "Explore the Power of the Poser Physical Root Node" Webinar. A video of it can be found on the Smith Micro Graphics channel on YouTube. It does include a discussion on SSS (about an hour into the video I think).

Thank you I will check it out.

you might want to check out this tute by Blender Guru on Cycles shaders. https://www.youtube.com/watch?v=V3wghbZ-Vh4&t=749s

I made my shader based on that tutorial.

http://www.sharecg.com/v/86231/gallery/7/Material-and-Shader/Poser-11-Superfly-Uber-Shader-1

Does anyone know. how to contact SnarlyGribly? She did such a fine script in EZMat

Banaman posted at 1:27AM Sun, 12 January 2020 - #4376284

Does anyone know. how to contact SnarlyGribly? She did such a fine script in EZMat

He. Snarly is a guy. IM him here. He often stops by.

As a much belated response to @Cage's observation that PIL in Poser Python on macOS is borked, there is a way to correct that. Most unfortunately, due to the deprecation and shutdown of repository server support for the TLS1.0 protocols available to older Python 2.7 installations such as Poser uses, it's almost impossible to directly update PIL within Poser. It is possible, though, if your macOS is old enough to have shipped with Python 2.7 installed, to use pip to install Pillow, which is a drop-in replacement for PIL (the Python Image Libraries) that fixes the JPG export bug, and then bypass Poser's own PIL with the system Python 2.7 Pillow package.

Hopefully (though do not hold your breath) this could get fixed in Poser 11.3, though much more likely in Poser 12, even though that may leap into Python 3.x territory and unleash a whole new can of Kryptonite Worms (TM) on your friendly, neighbourhood snake-heads.?

an0malaus posted at 2:11AM Mon, 13 January 2020 - #4376311

As a much belated response to @Cage's observation that PIL in Poser Python on macOS is borked, there is a way to correct that. Most unfortunately, due to the deprecation and shutdown of repository server support for the TLS1.0 protocols available to older Python 2.7 installations such as Poser uses, it's almost impossible to directly update PIL within Poser. It is possible, though, if your macOS is old enough to have shipped with Python 2.7 installed, to use pip to install Pillow, which is a drop-in replacement for PIL (the Python Image Libraries) that fixes the JPG export bug, and then bypass Poser's own PIL with the system Python 2.7 Pillow package.

Hopefully (though do not hold your breath) this could get fixed in Poser 11.3, though much more likely in Poser 12, even though that may leap into Python 3.x territory and unleash a whole new can of Kryptonite Worms (TM) on your friendly, neighbourhood snake-heads.?

Why not use wxPython? Can be mixed with PIL: https://wiki.wxpython.org/WorkingWithImages

My starting point for PIL was attempting to use ShaderWorks' Postwork Manager script, bundled with Poser. Unfortunately, it uses PIL and thus cannot save JPG files on macOS due to reasons. Getting code to work by replacing a broken library is a lot simpler conceptually than learning how to rewrite the necessary functions in a completely different environment. Neither way is bad, but the solution I found was far easier and quicker for me, at the time. Since then, the accelerating decrepitude of Poser's current Python bundle is giving me fever dreams of what might happen next, to take the pain away ?