I recall using zbrush before, and having to make some setting adjustment to get it to output properly to be used in poser.

I also recall a discusion about using normal maps vs displacement maps, but displacement maps were the favored option.

Does anyone have the output setting for zbrush to get a proper working displacement map in poser, and can you take a screen cap of the node setup with its settings?

I just output a test displacement map, and got someing looking "bloaty" in poserpro 2012 compared with the zbrush preview.

I think BB had a displacement node setup, but that was for one of the older poser versions, I think.

This looks like the most recent best setup:

Anything newer and improved?

That's the right setup for any map where 50% gray is supposed to be no displacement.

Second rule is the gamma on that image_map node must be 1.0. Gamma didn't matter at the time I published that setup.

Be sure the V-direction of the displacement map in Zbrush is right way up. I made that mistake several times. You can check that in UV-mapper.

Best regards,

Bopper.

I just upgraded so my workflow is dated.

I'll have to check the gamma settings when I look at it again. Good to know about that.

The general consensus was that normal maps were inferior than displacement maps. Is that still the case?

My understanding is normal maps "displace" x/y/z, while displacement maps only displace "in/out".

Can't ZBrush also make Normal Maps? Normal  Maps are sadly lacking for Poser content.

lmk

Quote - I'll have to check the gamma settings when I look at it again. Good to know about that.

The general consensus was that normal maps were inferior than displacement maps. Is that still the case?

No, normal maps and displacement maps do different things. Normal maps modify the normal (as the name says) and do not displace anything. You can apply both at the same time, usually with bad results unless you created them specifically for this kind of usage. If zbrush can export them both, they are most likely not to be used together (i actually do not have zbrush but 3dcoat, which is probably the same). Personally i do not believe that they are inferior and even less that there will be any general consensus about it :-)

Quote - My understanding is normal maps "displace" x/y/z, while displacement maps only displace "in/out".

Normal maps only modify the normal of an object and are applied to the material (shader) of an object, while displacement maps modify (displace) the geometry of a surface. They are applied to the material, too, but only because there is no other place to put them. They are more similar to a morph than to a texture actually. Displacement maps only do the "in/out".

Because it is most often the normal which affects the interaction of a material with light, use normal maps to modify the look of a material. When you need to modify the geometry, e.g. to get self shadowing or a different outline, use displacement maps. Or use displacement maps for close-ups and normal maps elsewhere.

I'll try outputting the normal map, plugging it in, and see how it looks side by side with a displaced version of the same thing. if I recall properly, detail was reproduced better with displacement maps.

Does Daz Studio even support normal maps as well yet? I know the lest few iterations of poser has, but I've seen very few people use it.

I'm guessing the node setup will be straight foreward, and if applicable, the gamem on it should have the same setting BB recommended for the displacement map.

(Please forgive the zbrush displacement doodle.. its just practicing for this test.)

The shroom on the left used standard displacement maps, with the gamme set to 1

The shroom on the right uses a normal map, set to tangent space.

Its actually kind of odd in a way as well. In preview, the normal mapped one actually looks close to the final render texture wise, but is missing the top ribbed displacements seen on the displacement mapped one. There is no preview of the displacement at all.

When rendered, however, the displacement mapped one is clearly the best of the two.

The node setup for the normal map one is plugged into the gradient map, and set to tangent space. Is there something else that should be there?

lmk

Nice test! Displacement is the right choice here. I know you can split two displacement functions using a math node. Say, one for positive and one for negative displacement. Bump can carry a third surface effect..

But to help your question, I think normal maps are a done deal and not changeable. Bumpmaps can be dialed up or down.

I'm not really getting what the normal map is actually doing, other then what we used bump maps for for years.

I kind of expected what we see in video game normal mapping effects, and thats clearly not the case at all.

IIRC, normal mapping has a better impact when viewed straight on like a bump map as opposed to viewing at an angle.  The only diversity to a normal map is the how directional light interacts with the material shader.  But, I think, the sticking point here is when generating a normal map, you need to take account which direction the light is coming from (X,Y,or Z).  If, for example, you create a normal map with light coming from left to right, and you use the mapping with light coming from above in the scene, then the effects way not appear correct.  Normal maps can impart more realistic views on low poly structures, as in gaming, but they are reserved for distant background scenes.

Backgrounds, normal maps are applicable; closeups, bumps and displacement.  And, also they are set, not variable as Richardson mentioned. 

Attached Link: normal maps 3dcoat

Yes, most likely your normal map is wrong (looking at the tip of the mushroom, it looks like the one on the left is dark, while the one on the right is lit). If ZBrush gives you a choice for the format, try to use the Maya-compatible one, the 3dsmax will not work (or try other formats if there are other options). Also look into the attached link (which is for 3dcoat, but might be the same issue/solution).

Quote - I'm not really getting what the normal map is actually doing, other then what we used bump maps for for years.

If looked upon from high above, they do exactly the same as the greyscale bump maps you used for years; they both affect the normal of your surface, only in different ways.

Quote -   I kind of expected what we see in video game normal mapping effects, and thats clearly not the case at all.

What effects do you mean, do you have an example? Perhaps it is not normal mapping you are trying  to achieve !?

Ok, I checked and there is only really an option to use tangent space.

That DOES yield better results than I originally got, but still is no where near a good replacement for displacement maps.

That said, I do see more detail being being preserved in the normal map, but the unacceptable tradeoff is the loss of the displaced mesh "in/out" rendering.

I guess the real test would be to time each render. One for displaced and one for normal. One for bump... That should answer your question.

Using only that criteria, displacement maps are the best and only choice hands down.

Here's what it looks like in zbrush:

Quote - I'll check the export all maps zplugin and see what options are there.

Ok, I checked and there is only really an option to use tangent space.

Yes, tangent space is what you need mostly.  An alternative would be to use object-space (you can enable it in the posersurface node in the type for the bump-map).

Quote -   That DOES yield better results than I originally got, but still is no where near a good replacement for displacement maps.

That said, I do see more detail being being preserved in the normal map, but the unacceptable tradeoff is the loss of the displaced mesh "in/out" rendering.

The normal map stores the normals directly, which means the renderer needs only to access it for each value once. Displacement maps  on the other hand, store only height-values, and to calculate the normal from the heights it needs at least 2 height-values (same for greyscale bump-maps) with intermediate points interpolated, i.e. blurred, hence the appearingly higher detail. Therefore as a rule of thumb always make your displacement maps at least twice the size in each direction as the corresponding normal map. E.g. Use a 4K-displacement map when a 2K normal map looks about right. If you use large displacement values (could be the case for the ripples on your mushroom in extreme closup), you will also get quantization noise, requiring at least 16-bit sample values. So to be prepared for every situation you need at least double up in every dimension, no wonder all the video-game guys prefer normal-maps :-)

As usual this subject has resulted in posts containing a substantial amount of disinformation. For example, doubling the resolution does not compare poorly when you reconsider that you have no need for rgb data in a displacement map. The three channels are identical, and a monochrome map, which is one third the size you are typically using, would produce identical results. Before you compare, get the size down to what is actually needed. Then compare sizes.

I have a lot of work to do and cannot play. Hopefully I can come back to this.

There is value in normal mapping. There are advantages. But they are rarely cited correctly in these discussions.

Also, Firefly actually supports three dimensional displacement, not just in out along the normal. SM has not seen fit to give us a channel to reach that capability.

One more suggestion. If you cannot demonstrate a point you are making with a Poser scene, then perhaps the point isn't actually true.

Repeat stuff you have heard only if you can demonstrate what you are repeating at will. If you cannot do that, then you are not helping.

millighost said good stuff

But some is still half truth. For example, a bump or displacement map can be internally converted to a normal map. Thus, there is the possibility of direct normal lookup even then. Not everything has only one possible implementation.

Thanks for the input, BB. I think I got my answer though.. to best replicate zbrush's sculpting in poser, displacement maps are still the best current solution.

Since I hadn't really explored normal mapping at all, I figured looking into it could be beneficial, but that didn't pan out.

Quote - Also, Firefly actually supports three dimensional displacement, not just in out along the normal. SM has not seen fit to give us a channel to reach that capability.

Who do we need to beat on about this, BB? ;)

Quote - millighost said good stuff

Thanks, i hoped to do :-)

Quote - But some is still half truth. For example, a bump or displacement map can be internally converted to a normal map. Thus, there is the possibility of direct normal lookup even then. Not everything has only one possible implementation.

Yes, you can convert them (in which case the conversion process would still need to do multiple lookups, btw) but this is not the point. The point is: The materials and shaders operate usually with the direction of the surface normals, and a normal map directly stores exactly what the shader needs. A greyscale bump/displacement map does not store directions, it stores positions, or more exactly differences between mesh-geometry and the surface position, and from those positions the direction of the normal is calculated. But the renderer cannot calculate a direction from a single position (no one can) it needs at least two positions to do that. Therefore a higher resolution is needed. If the calculated normal is then stored for single lookup or not does not make any difference.

Imagine the most simple case: A normal map containing only one value (i.e. 1x1 pixel). Not particularly interesting, i admit, but it can still be used to make the surface reflect into one or the other direction. A 1x1 bump map on the other hand is even more limited; it does exactly nothing, because it does not contain enough information to create some varying normals from it. (A displacement map at least could move the surface up or down, but would not change the lighting either). So for lighting calculations a single pixel of a normal map carries more "value" than a pixel in a greyscale bumpmap.

You've obfuscated nicely!

The single pixel case only demonstrates that you need one extra pixel in each dimension, not twice as many.

If you have a 100 by 100 normal map, exactly the same information is found in a 101 by 101 bump or displacement map.

By analogy, I can describe a bank account as a series of balances, or as a series of transactions (deltas). Given one I can produce the other. The amount of data is the same.

Consider this bank account.

Initial balance 0

File 1: Subsequence balances - 10, 30, 50, 45, 70

File 2: Transactions - 10, 20, 20, -5, 25

Is there any difference in the information? How about the information density? No to both. But if you ask me to list the transactions, File 2 has them directly, while in File 1 I need a pair of balances to calculate a transaction - information that is directly stored in File 2, but readily reproduced from the data in File 1. There is a difference in efficiency, but not density.

The same is roughly true of normal versus bump map. The bump is in File 1 format - actual balances. The normal is (sort of) in File 2 format - deltas (or slopes).

Quote - As usual this subject has resulted in posts containing a substantial amount of disinformation. For example, doubling the resolution does not compare poorly when you reconsider that you have no need for rgb data in a displacement map. The three channels are identical, and a monochrome map, which is one third the size you are typically using, would produce identical results. Before you compare, get the size down to what is actually needed. Then compare sizes.

Yes, you are right. But a displacement map does not compare particularly great, too, when you reconsider that you have no need for the rgb data in a normal map either (in a tangent space normal map). Because it contains normalized directions, only two values per pixel suffice. In fact with Poser's firefly the blue channel seems to be completely ignored (at least i could not make out any difference when putting some random values into it). So the size factor is only 2 when comparing a greyscale bumpmap with a red/green-normal map, not 4 (rgb bumpmap vs. rgb normal map).

Quote - I have a lot of work to do and cannot play. Hopefully I can come back to this.

There is value in normal mapping. There are advantages. But they are rarely cited correctly in these discussions.

Also, Firefly actually supports three dimensional displacement, not just in out along the normal. SM has not seen fit to give us a channel to reach that capability.

Quote - You've obfuscated nicely!

The single pixel case only demonstrates that you need one extra pixel in each dimension, not twice as many.

Well, you got that one, i thought i could get away with it :-) Complicated explanation below.

Quote - If you have a 100 by 100 normal map, exactly the same information is found in a 101 by 101 bump or displacement map.

By analogy, I can describe a bank account as a series of balances, or as a series of transactions (deltas). Given one I can produce the other. The amount of data is the same.

Consider this bank account.

Initial balance 0

File 1: Subsequence balances - 10, 30, 50, 45, 70

File 2: Transactions - 10, 20, 20, -5, 25

 

Is there any difference in the information? How about the information density? No to both.

Actually yes for the information density. As soon as i know that your balance is 0, i know that your next transaction will be positive. You have only half the choices you normally have. If i would have no idea what your account was, the transaction sequence would carry more information. But this is not the main reason for much larger bump maps, but it is (among others) a reason for a larger sample size.

Quote - But if you ask me to list the transactions, File 2 has them directly, while in File 1 I need a pair of balances to calculate a transaction - information that is directly stored in File 2, but readily reproduced from the data in File 1. There is a difference in efficiency, but not density.

The same is roughly true of normal versus bump map. The bump is in File 1 format - actual balances. The normal is (sort of) in File 2 format - deltas (or slopes).

It would be true, if the maps were 1-dimensional. But they are 2-dimensional, so each value is not only bounded by its left and right, but also from its top and bottom. Imagine your bank account example, but with the additional restriction, that after the second transaction it must have the value 50. You would have no choice of what that transaction could be. If you picture a pixel line in a bumpmap as a sequence of account balances, you could choose freely what each transaction should be and assign the appropriate balance to the pixel. But now you want not only the lines to be account balances, but also the vertical columns to be account balances with the same pixels values. That would not be possible, because the values are already fixed because of the rows.

Another picture: Imagine a little ant running in circles on hilly landscape represented by a height map (bump/displacement map). The ant starts running, climbs hills and visits valleys, but whenever it returns to its starting point it will have moved the exact same amount up as it has moved down. With a normal map on the other hand, the ant could have climbed up all the time and still return to its starting point (almost like Escher's ants). This possibility is essentially what lets normal maps contain more information than bumpmaps.

From an information density standpoint, it would not be necessary to double the resolution in each direction, of course, it would suffice that the amount of pixels would be increased by a factor of 1.4 (sqrt (2)), because the normal map contains more or less twice the data, but that is rather an encoding problem, as you mentioned.

I have also found that a displacement at 4096 did render better quality than at 2048, not trying to pick a fight but my test did show better results, perhaps it was just my particular project scope, maps were created out of Zbrush at 4096 for all maps.

Normal and displacement maps on Chest Armor. Normal maps on Boot Armor.

Did you do a seperate normal map for minute detail? I'm justwondering how you managed to get displacement and normal maps working together without doubling up the entire overall displaced apperance.

I'm not sure that additional memory overhead would be good for the projects I'm working on, but it might come in handy in the future.

The normal map will simply enhance the displacement and not double the effect at all.   However, if you're concerned about it, you can do your form sculpting and export that out as displacement, delete lower levels of subdivision and then move up a division or two to create the minutia detail to be extracted with a normal map. For example - you sculpt musculature and export that as a displacement. Then you sculpt pores and export that out as a normal map.  Personally, I wouldn't delete the lower levels - but that's me and truth told, it depends on the project.

People should understand that a normal map won't replace a displacement map - it's not really  intended to do that, as it's reliant on the mesh's silhouette to help drive the look it's trying to achieve and won't hold up as well under close scrutiny. A displacement will actually alter the silhouette of the object, essentially changing the mesh into something else.

 Normal maps are best left for objects in the mid-ground/background of a scene in my opinion, where using a displacement would be overkill. Displacement is best left for when you need a close up or when something is being held in the frame for a long period of time or when you need the silhouette of a mesh to alter and a morph won't do the full job.

Yeah, I agree with what Teyon said. I don't know why but the displacement did not hold up well under close up shots and that's why I added the Normal to assist...but once I got the two maps to play nicely together I think the project came out rather well.

Yeah, I agree with what Teyon said. I don't know why but the displacement did not hold up well under close up shots and that's why I added the Normal to assist..

You saved them out at 8000x8000 ? I do this but still lose resolution. I think your technique might be my answer.

DarkEdge, I'm a big fan of using both maps on a model. 8K maps are the lower end of feature film res - if you're exporting maps that large and not getting what you want, I think you may need to look at how you're building up the displacement and at the topology you're applying the map to.

You need to build up your displacement. I see folks going to the highest subdivsion and starting to sculpt. that's great and all, if you're not exporting a map but if you are...you're missing the point. You build up form on the lower levels of subdivision, adding detail as you move up one level at a time. The highest level of subdivsion should be left to things like scratches and pores. This will give the app more to draw from (it looks at all levels of subdivision for building the map).  Once I got that in my head, I've never not been satisfied with a map out of ZBrush and I don't render maps higher than 4096x4096.  

Another huge factor is the detail level of the mesh in question. Does it contain enough polys flowing in the proper direction to support the detail you're trying to put on it? This is why folks retopo meshes - to support the shapes and detail they are trying to achieve. Sometimes you run into a flow that just does not want to do what you want it to do - you either have to accomodate your design to the flow of the mesh or you have to accomodate the mesh to the design in your head. Either way, something has to give or you're going to run into areas that look...sloppy. 

Last thing to look at is how the app handles displacement/normal mapping and what other effects you're using. Some handle it better than others, there's not if ands or buts about that. Poser does a decent job of it from what I've seen, so getting good results out of it should be entirely possible. If you're using SSS with displacement and normal maps keep in mind it has a softening affect to the overall look and consequently, some details may be lost, requiring you to crank up or turn down the values a little where possible.

That's my two bits. 

OH! one tip: Poser supports 16 bit TIFF files. So if exporting out displacement maps, you'll want to use that option. It will hold more info than its 8-bit counterparts, resulting in more detail/better looking displacement.

Hey Richardson, I saved out of ZB at 4096x4096.

I saved 2 maps one at 2048 and the other at 4096 and rendered them side by side in Poser and the 4096 came out cleaner. I wish I could cure the jaggies that happen along the z axis though with displacement.

Thanks Teyon, will keep those suggestions in mind.

I can't recall off the top of my head if I saved at 8 bit or 16 bit, so that might be one of the problems right there.

If I do any product with them, then I'll just include a material settings as a HD setting for people with more ram, or higher quality needs.

And I'll bug SM to see if we can maybe get that elusive channel added that BB mentioned for full 3d displacement.

Sorry for the confusion. I'm just starting to play in ZB again. I've been loading V4 with a single UVmap in and then saving out a 8192x8192 tiff which I cut up into 3 4096x4096 maps and swap original UVs back.

I don't know of a fix for you.

While I thought this was a done deal, it apparantly isn't quite as clear.

BB, when I did my warcow, you suggested using the colormath node with subtraction instead of the math subtraction node. I'm not positive, but it appears that the color math node renders faster than the math node. Have you done any comparisons with them as far as impact on render speed?

A standard setting of 1 does not work. If I set displacement to 1, the displacement is blown out to 100 times what it should be. Settings of anywhere from .01-.035 seem best so far here. (That was with displacement scale set to 1 in zbrush.)

Also, zbrush now can scale the displacement based on the object.. which means there might be one displacement amount setting that ends up correct on everything. When I had zbrush calculate the scale before generating a second displacement map, is came up with a scale of something like 13 or 14, obviously a lot more than the original displacement map output.

I'm still not getting as detailed a displacement as zbrush though, I don't think. (I have yet to include a normal map as well for the small detail.)

The problem is the discoloration. This is plugged into Grad Bump> Tangent Space (Normal). If Object space is used-there are pinholes showing in the mesh.

Note-he seems to have been able to render this same Nmap without discoloration.

Arrgh! Damn Firefox- it disallows cutting and pasting-on this forum!

Go to RDNA, forums, Poser9> Demos> Making Maps....

Arrgh! Damn Firefox- it disallows cutting and pasting-on this forum!

ctrl+c for copy, ctrl+x for cut, crtl+v for paste.

 "Copy/Cut/Paste not available in Mozilla/Firefox"

Quote - Arrgh! Damn Firefox- it disallows cutting and pasting-on this forum!

ctrl+c for copy, ctrl+x for cut, crtl+v for paste.

Quote - There can be problems with using a Normal map with SSS. Here is BB's Scatter+Blinn applied with Snarlygribbly's EZ Skin. The normal map is by Caisson at RDNA

The problem is the discoloration. This is plugged into Grad Bump> Tangent Space (Normal). If Object space is used-there are pinholes showing in the mesh.

And is it in fact a tangent space normal map?

What numeric value did you use in the parameter where it is plugged in?

I just checked it again. Caisson sets it at 2.0. Tis indeed Tangent Space. I ran EZ Skin 1.6.6 with or without fresnel-with and without ze olde BagginsBill Max Scatter Trick.

 In the render that is displacement only-I also took the N map into Pshop, desaturated, then used "Auto Contrast." It has more contrast than the Disp map I made-so I set it at 0.02. I have my own D map-but wanted to compare Caisson's N map with D map.

"Copy/Cut/Paste not available in Mozilla/Firefox"

I use Firefox and am able to cut and paste in this forum by using the keyboard shortcuts. If I try to do the same by right clicking, Firefox blocks it.

I

"Copy/Cut/Paste not available in Mozilla/Firefox"

"I use Firefox and am able to cut and paste in this forum by using the keyboard shortcuts. If I try to do the same by right clicking, Firefox blocks it."

THANKS!!!!!!!!!!!!!!!!!!!!!

 Thanks BB!

You are of course correct- defaults to "Use Gamma from render settings (2.2"

Quote - I posted at RDNA. I suspect you have gamma=2.2 on the normal map. Normals must be gamma=1. They are data, not colors.