Normal map baking | eat3d Fountain Workflow |
polycounter lvl 18
Hi there,
i know...its yet an other normal map issue but i want to ask if i am doing st worng here.
in the eat3d fountain dvd they use a workflow like this:
- Creat highpoly
- create Low poly
- create UVs
- insert edgeloops around corners ( no chamfering )
- Bake maps
- delete edgeloops
( to get less confusion : all cubes are baked "non-eat3d-way" except the last 2 on the right)
Its interesting that the cube with no smooth/uvsplit has the same amount of verteces than the one with smooth/no uvsplit and looks also better. Does that mean i have use different smoothing on my different UV Islands?
Imo the best way is to handle more complex models is to chamfer keyedges, use fiew big UVIslands and smooth those seperately. Or am I missing st here?
But again...what about the eat3d WF ? Am I doing st wrong?
Thanks for any help,
greets
i know...its yet an other normal map issue but i want to ask if i am doing st worng here.
in the eat3d fountain dvd they use a workflow like this:
- Creat highpoly
- create Low poly
- create UVs
- insert edgeloops around corners ( no chamfering )
- Bake maps
- delete edgeloops
( to get less confusion : all cubes are baked "non-eat3d-way" except the last 2 on the right)
Its interesting that the cube with no smooth/uvsplit has the same amount of verteces than the one with smooth/no uvsplit and looks also better. Does that mean i have use different smoothing on my different UV Islands?
Imo the best way is to handle more complex models is to chamfer keyedges, use fiew big UVIslands and smooth those seperately. Or am I missing st here?
But again...what about the eat3d WF ? Am I doing st wrong?
Thanks for any help,
greets
Replies
it makes much more sense in the following example. sometimes you need more geometrie to read the hp properly. after the baking process you can get rid of many edges without any lack of much detail. Of course here you can see it but this is extreme.
its kind of creating LODs.
but i dont see the real point on simple geometry...
Wouldn't this create a normal map specifically meant for the middle option, and not the actual low poly mesh? If the Eat3d tutorial is an older one, you might want to just stick with what guys like EQ have documented here. Between them and Max being updated, you shouldn't have too much trouble fighting hard edges like that.
I think... although since then I've never done that and just split my UVs.
but on the sofa i think its a really good ways to get more detail on the normal map.
of curse you can loose some shading information by reducing...
also i know how to get the hardedges away. but it costs verts from splitting uv or tris.
but i was interested in this wf...
ah ok...but the result is not really promising (look at the nm of the eat3d wf)
To simplify, you should pretty much never do this, if you understand how normal maps work it should be obvious why.
Read up a few of Earthquakes posts that are spread all over Technical Talk, that should help, also check the wiki.
And there's nothing wrong with having hard edges when needed really, as long as you split the UVs, chamfering everything like crazy can be nice, but it's not always necessary.
Well I never remember my normals looking like that to be honest. At the time I didn't really understand it all that well; but knew I was getting pretty nice results. After reading the wiki here I've avoided using the method in that Eat3D tutorial and stuck with splitting UVs.
Although there is a use: if you wanna keep your vert count down then you don't wanna be splitting your UVs.
thats exactly why i wanted to take a look at this. when i followed the fountain dvd some time ago i didnt had to bad results too...but here and there the edges were not nice.
i thought i might get better normalmap shading 1 smoothing group and without splitting UVs.
@ bal: thx i looked through many threads and the wiki...
learned a lot from these pages! thanks for putting all that down btw !
but i dont see why this should be a problem...again i think even the lowpoly sofa looks ok
maybe it just wont work on this low and simple mesh like this cube...
You'll want to place the UV seams with the hard edges on the mesh, so I think the extra verts are already going to be there. Simple cubes were never really the best example.
- create Low poly
- create UVs
- insert edgeloops around corners ( no chamfering )
- Bake maps
- delete edgeloops"
Are those images of cubes with vert counts from the Eat3d video? There are so many problems with this workflow.
The biggest one is deleting edge loops from the mesh after baking. If you do that you effectively have a normal map for a different model and it will shade terribly.
Second of all, putting supporting edges everywhere is totally vertex inefficient and there is no reason to do it in max. Your UVs will inevitably have splits. Unless you can somehow manage to unwrap your entire asset onto one island you will be worse off than just using UV/smoothing splits to control smoothing errors.
From the images you posted (not sure if those are from the DVD) there seems to be a bunch of other fundamental problems. I would try and ignore/forget pretty much everything in that video about normal maps.
Your sofa looks cool.
ok i understand the fact that the map isnt for the right model after deleting the edges.
also everybody can clearly see that those two cubes look awful.
as for the sofa, i only have 3 UV islands..so deleting edges dont get me much trouble or splits.
you dont bake the normal again for a LOD do you?
Generally you don't bake a normal map again for a lod as there's not usually enough texture memory and it's far enough away to not see the errors but if you wanted correct shading you would need to.
btw does i have to flip green with every engine or just unity?
"Implementation Dependent
A common misunderstanding about tangent space normal maps is that this representation is somehow asset independent. However, normals sampled/captured from a high resolution surface and then transformed into tangent space is more like an encoding. Thus to reverse the original captured field of normals the transformation used to decode would have to be the exact inverse of that which was used to encode.
This presents a problem since there is no implementation standard for tangent space generation. Every normal map baker uses a different implementation and, additionally, there is no standard for how the interpolated frame is to be used to transform the normal into tangent space.
The math error which occurs from this mismatch between the normal map baker and the pixel shader used for rendering results in shading seams. These are unwanted hard edges which become visible when the model is lit/shaded. They are a source of wasted time and frustration to an artist/designer."
actually the last paragraph should include apparently curved areas that should be hard.
examples here of it breaking
http://forum.unity3d.com/threads/38781-Calculating-Unity-s-tangent-basis-for-xNormal
if you have to invert green it's a good sign that its not synced up, but you should beable to flip it in the baker settings if its the closest you can get.
i am still playing with this technic of putting some edgeloops in my model and deleting them after baking again. everybody know the issue of curves in the normal map, right?
i am testing out this tablemesh and i put many edgees before baking and removed them after. the curves were not as strong in this workflow. what do you think?
Really, try to avoid that. When normal maps are baked, they're designed to work with the specific low poly mesh they were baked with. Changing the silhouette and vertex normals around afterwards are just going to leave you with a mesh and normal map that are no longer synced.
When it comes to the waviness, check out the giant sticky http://www.polycount.com/forum/showthread.php?t=81154
If the surface of the table wasn't void of detail you would realize that the silhouette of the the top and bottom of the table wouldn't line up when you remove those edges.
Also the distortion on the left image doesn't look so bad if it at an angle ie: from the direction of the projection.
I know some people go and smudge these edges to fix stuff, but like many of the above posters said alot of these quick fixes become a paint later on in the pipeline and are hard to iterate on.
but youre probably right. if you are not happy with the result later , its a real pain to go back and rectreate the workflow again...