Message edited on: 06/30/2005 04:02

Attached Link: http://www.renderosity.com/messages.ez?Form.ShowMessage=1740708

You can find a workaround at the link. It is not pretty, but it works.

Stefan

Hi there DigiCalimero, How are those face morphs coming along for Eszter. We need some new faces around here. She has so much potential,a new face but wearing the same clothes as V3. I hope you do pursue her. If you can't get the V3 UV mapping through, I would make some face maps for her. She has great expressions. cheerio lululee

quinlor, thank you very much for that link, it doesn't look like too much work :) lululee, yes I'm almost done with it, I had to put it on hold because I had other urgent things that needed finishing. It will be ready in about 1 week. It would be great if you make face maps for her, the UV's I made for her are very good. I don't plan on making a V3 compatible version for different reasons...

Cool, I will do some face maps for her. In lieu of recent developments I can see that you are on the right track. I like the concept of the unique face you have created with lots of great expressions, but the same clothes the same as V3 with no copyright problems. cheerio lululee

Just would like to add that sometimes I have no clue as to how the Poser developers are reasoning... First, they implement subpixel displacement in Poser, but then only let you work with 8 bit files....making the displacemet feature pretty useless unless you use it for very fine stuff like pores or little scratches, which you would do with a bumpmap anyway....

Hmmm ... I might be wrong on this, but being that there are only 256 possible levels of gray (0,0,0 through 255,255,255 with all three numbers always being equal), a 16-bit grayscale image would appear identical to an 8-bit image.

Message edited on: 06/30/2005 10:32

To add ... The main differences between an 8-bit, 16-bit, 24-bit, and 32-bit image are: 8-bit (handles only 256 colors, or 2 to the 8th power) 16-bit handles 65,536 colors, or 2 to the 16th power. There are still only 256 shades of gray, however. 24-bit handles 16 million (or thereabouts) colors. , or 2 to the 24th power. This is actually more colors than the eye can see naturally, so that's the best we are gonna get. 8-) 32-bit is the same as 24-bit, but with the addition of an alpha channel.

No, the 16bit RGB file stores 65 536 shades of grey. You must think of R G B channels as a separate grey channel. An 8 bit file stores only 256 levels of grey. 256 levels in most cases is ok, like in your pic example, but when you have very smooth gradations (zoom in close on a portion of a pic too see), you will get banding with an 8 bit image. You are confusing "bit depth". You can either talk about it as bits/channel or total bits. In your 24bit example, you are actually talking about an 8bit/channel image, which would make 16 and some millions of colors.

Message edited on: 06/30/2005 11:21

To be truly gray, that is totally desaturated, all values in the RGB "formula" are equal. R0, G0, B0 is black. R255, G255, B255 is white. R128, G128, B128 is 50% gray. However, R 27, G 12, B 27 is not pure gray. It has slightly less green in it, so it will be a tinted gray. In order for it to be a true gray it has to have equal levels of all three color guns. And because the color gun values only go from 0 (full off) to 255 (full on), the most shades of gray you can get are 256. As a result, there are only 256 possible shades of gray in any image, regardless of its resolution.

Ah, OK I see what you are saying now ... you are talking 16 bits PER CHANNEL. Gocha. (Emily Latella voice ....) Never mind! ;-)

No...that's wrong :) the electron gun doesn't just display 256 distinct levels of a nuance....it can display many more...it's an "analog" device, works by changing tiny amounts of current. If you talk about pixels we must only think of how they are STORED on the computer. An 8 bit greyscale (so single channel) image, can hold 256 distinct levels of information (2 to the 8th power) A 16 bit greyscale image can hold 65 536 distinct levels of information (2 to the 16th power) If you don't believe it, make a new 16 bit greyscale image in PS. First make a smooth gradient (black to white) lets say horizontally, then take a big very smooth brush, set it to a nuance of grey and paint a little. Now zoom in and convert the image to 8 bit and see what happens.

Sorry, didn't have time to finish typing before you replied :)

Digi - out of interest, are you creating the displacement maps with ZBrush or manually in Photoshop?

Both :) I always have to smooth some areas from the displacement map generated in Zbrush.

I'm finding the same thing. I've tried both adaptive and dpix at 2 in ZB2, but still get underlying noise.

Message edited on: 06/30/2005 17:53

It is a known bug in ZBrush. Due to the way they calculate the displacement there is always noise around the seams. To minimize tis - I always cut an extra edge-loop close to the seams (both UV & geometric). This extra loop is only in the mesh I use to create the displacement maps. You still get "noise" but it is minimized due to the seams proximity to the edge.

Very interesting EK. Have you done the extra edge-loop trick on a V3 type figure? (Damned if I know how you'd do it!).

Haven't installed V3 (and won't until such time as DAZ releases their Developer's Addendum), but I have used it on other figures. You still need to smooth out the noise in a Photoshop-like app (I use GIMP's smudge tool), there is just less area with the noise in question. You DO need to use a character with welded verts though. Using a cut up OBJ file like that required by Poser's rigging is just ASKING for hassles (not to mention it severely hampers one's use of ZBrush's "Smooth" tool). EK

Yep - I'm using a welding mesh. Seems to be uv boundries that cause the most problem (some total white or total black spots on the displ map at the seams). And a general "noisiness" - even in the 16bit map. How do you cut the extra loop at the edge?

I use Wings. Select edges on both sides of a UV/geometric seam, connect them (creating an extra edgeloop), slide the new edges close to the uv/gemoetric seam (both in UV & in 3D space). Once I have done this to all the seams - I export the new object out and use it in ZBrush. I have not examined the fact of whether it is just UV seams or geometric ones... I will have to experiment on that today. I knew "seams" were involved - so I just played it careful. EK

the general noisiness is a problem for me too, even with a 16-bit map. It's not because of zbrush though, i tried just making a map in PS. I guess that conversion trick works but doesn't work as well as true 16 bit support, OR Poser's displacement mapping needs to be improved.

EK - interesting workflow. Connecting V3 uv seams could be tricky, since that would create overlapping uv's which would crash ZB2 when creating the displacement map. But that definitely gives me some things to play with. I wonder if ZB2.5 fixes this problem. DC - have you compared the displacement map results in another 3d app to compare the noisiness (to see if it's a map problem, or a rendering probs)? I tried rendering the displacement maps I've created in DAZStudio and I still got some noise (although different to the P6 noise), so I think the actual map is the culprit in my situation.

I think that in 24 bit pictures, there are still only 256 shades of grey, so if you make an 8 bit picture that is greyscale, it will show all these 256 shades. Maybe that is why the displacement maps are changed to 8 bit in poser?

Xantor, if you look at a ZB2 displacement map in Photoshop, it loads as greyscale, 16 bit - so a very fine level of detail - 65536 levels to be precise. Moving back to 8bit gives you only 256th of the details (ie only 256 levels). Poser only uses 8 of the 16 bits of an image. Search for "quinlor" in these forums to see the tricks to being able to use all 16 bits.