Shopping Cart
heightmap and matchUV
January 7, 2011 - 4:02am
- 6325 reads
Hello,
for some reason creating heightmaps while using the matchUV feature gives strange results.
(it does work to generate a normal map though!)
Switching the setting off does work but I'd love to use matchUV because it gives the best quality.
I've attached some images, I hope it gives some clues.
seb
ps: I'm using the latest beta but I think I had the same issue with previous versions
Are you sure your lowpoly and highpoly meshes share the UVs? To use it effectively the highpoly mesh must be created subdividing the lowpoly mesh. So HP's UV must be contained inside the LP's UV ( and too the geometry ).
Btw, I think Blender 2.5 has a bug in the subdivision routine in case you're using it.
Can you post your LP and HP's UV layouts pls?
Btw, currently there is a problem in the Interactive Heights Normalization tonemapper tool in the 3.17.4 B1.
Hello,
yes I did double check everything.. also it works fine when rendering a Normalmap, which is the strange thing. I sent you a private message with a link to some test data.
Thanks,
seb
I'm seeing the same blotchy results when using MatchUVs. My high res mesh is a subdivision of my base mesh so the UVs match perfectly, all the other channels bake as you'd expect, and the height map is correct if I don't use MatchUVs.
Have you setup your cage in a way that covers complely the highpoly mesh? Screenshot pls!
Are you using the 3.17.4 B2 with the interactive normalization tool ?
ps: I've not received the private message with the link to the files.
Do we need to set up a cage when using matchUV? It isn't necessary for baking any of the other map types. It never occurred to me to check my cage because I never use a cage for baking anything - just ray distance and blockers if the UVs don't match and matchUV if they do. Anyhoo, just checked and turning on and adjusting the cage makes no difference.
I'm using 3.17.4 beta 2, but I've also tried it in 3.17.3 and 3.17.2 release and I get the same results. The problem persists whether using Auto-normalize, Manual, Interactive or raw.
Tell you what, I'll email you the source files rather than post screenies. Stay tuned.
I sent you my results by email.
Basically, you need to use MatchUV and render a VDM map with heights unsigned in the alpha channel, because each point in a subdivided model should be contained in the control cage.
If you use a heightmap then you must bias the heights in the pixel shader. That's why appear those dark pixels in the heightmap ( they represent negative distances, while the white pixels represent possitive ones ). But for a VDM(or matchUV), heights are always possitive, so the height will look more "color-continuous" or smooth. Pls, also notice a height map is not really a displacement map, unless you subdivide your lowpoly model manually.
Please, use the 3.17.4 B2 because the interactive tool was a bit buggy in previous versions.
Do we need to set up a cage when using matchUV?
Not unless you plan to use the cage to limit AO rays or something similar.
However, sometimes you can disable the MatchUV feature, enable the cage and render a wireframe and ray fails map to discover/debug problems with the rays. The Direction map ( aka VDM ) can be used also not only to render a vector displacement map but also to see distortions of the cage ( which will affect the ray directions too ).
Hi Jogshy,
thanks for your replies!
I'm still confused though 
http://eat3d.com/files/imagecache/forum/forum_images/mushroom_heights.jpg
http://eat3d.com/files/imagecache/forum/forum_images/mushroom_ray_height...
are both generated with the same settings - both are a heightmap, the only difference is that the second one is not using "matchUV". Only the heights in the first image seem to discontinuous though? The second one looks perfectly "normal" to me.
Thanks,
seb
PS: I sent you a private message with the models I used for the above image.
Cannot find you meshes. I've not received the PM.
Weird. Well, here is a link: www.sebscorner.org/mushroom.rar
Hope it helps!
Downloaded the files, thx.
I hope tomorrow I could test it.
Ok....
I think there's a "conceptual" problem in my code: if you enable MatchUV for a height map, I'm not computing correctly the height "extrussion" direction.
The displacement must be computed in a way that pos' = pos + vertexNormal*height.
However, I'm using vertexNormal/extrussionVector as == (Hp.pos-Lp.pos).normalize() which is problematic unless you pass a heavily-tessellated lowpoly mesh.
To be honest, I don't know how to deal with that. The displacement map's result should be always computed using the vertex normal so you should try always to use uniform ray distances or a "not wielded/averaged" cage. VDM solves this problem for sure ( because it outputs the extrussion vector explicitly ) but, in the case you want to use only a scalar displacement map, not...
Let me illustrate the problem with a simple drawing:
( You expect a distance d but, if you use MatchUV and LP is not very subdivided, you'll get instead a distance d' ).
A possible workaround is to subdivide a few the LP but that can be problematic due to the polycount. Other solution is to use Vector Displacement Mapping(VDM) or to disable MatchUV+render with a cage/uniform distances.
I don't know... I must think about all this in depth. It's not easy to solve.
( the last image is created without matchUV, the other two with)