Yeah, bit depth is something I would like to do a short write up on. Baking out at 16bit if you can is generally a good though. 32 bit is almost always overkill, especially when the end goal is 8bit, but yeah, worth talking more about.
One thing I'm having big troubles with atm is getting my head around where to place UV splits, specifically for a good bake and optimised mesh.
I've read all the literature including EQ's posts, the Polycount Wiki and 'Beautiful, Yet Friendly' - so I understand on a basic level that they should be placed where your model has a hard edge and/a different material.
However, does that mean that I can go into every model thinking 'There's a hard edge (> 70°) right here, so I'll put a seam and a smoothing group there?'. I know there's more to it than that so how else can a seam's location be determined?
I'm not sure if it is skewing or not but I'm having this problem:
I would assume you have too much stretch on UV layout, but it could also because of you did not triangulate the mesh for it to properly bake. Did you? I've experienced once the same thing. They usually appear at where a quad triangulates. Can't really remember why, but I've never found same issue again.
Non-triangle mesh used for baking will somehow create artifact because it can only bake if the model is fully defined in triangles, where all normal directions are solid. If the points of the quad/polygon are not on a same plane (having different normal direction), the software will want to automatically figure it out where to make the triangle. Than if your low poly model in the view port isn't triangulated in the exactly the same way, when you apply the normal map texture, it will contain some artifacts.
Fantastic write-up, Joe, thank you for explaining these concepts in a detailed and clear manner. Have you thought about teaching a class? Also interesting and insightful discussion following, thanks everyone!
My two cents regarding the last two comments....
If the points of the quad/polygon are not on a same plane (having different normal direction), the software will want to automatically figure it out where to make the triangle. Than if your low poly model in the view port isn't triangulated in the exactly the same way, when you apply the normal map texture, it will contain some artifacts.
If you are modeling and baking in the same software, then the low poly mesh not being triangulated is probably not the issue. I'm assuming you're not editing the low poly model after baking. So the same software should always triangulate the same non-planar quad the same way. So within the confines of the geometry, the bake settings, and the smoothing groups/soft/hard edges, etc., the tangent space normal map will be generated to make the normals of the low poly mesh read as the high poly mesh as closely possible. Exporting a mesh with non-planar quads from one modeling package to another, or to a game engine, is where problems with the normal map come up, because different software calculates normals and tangents differently. (There are some good posts on this but I can't seem to find them, will edit and post if I do).
Regarding the image posted, I would say the skewing in the normal mapped model is probably due to skewed UVs of the low-poly model, and due to projection angle of the bake.
I've got a question about it. I've had some pretty good results by splitting my low poly mesh up as a lot of loose elements. In 3DS Max it's pretty easy to select smoothing groups and detach them an element. This creates split vertex normals and the correct cage on seems I need it.
Like this:
It gives me this:
The edges are not very nice in this example, but this bakes out nicely in xNormal.
Yeah you get gaps by splitting the edges, or by using hard edges and not using a cage, which is what xnormal does by default if you don't set up a cage or import one. Max does this if you enable "use offset" in the RTT settings too, you don't need to split the mesh up.
But its not really a good idea, the gaps at the edge look terrible. You would need to do two bakes, one with gaps, one without, and then photoshop them together to get a usable result. I've done this long ago, but it's an annoying workflow, and it doesn't fully solve the problem anyway (only helps where you have a hard edge near skewed detail).
Right, you could do that in this very specific case where all 6 faces of the box have hard edges, and thus completely flat normals, but you won't be able to do it on a mesh with any sort of complexity as it will change the mesh normals and introduce smoothing errors.
If you want to use that workflow, you need to bake an object space map, and the removed the geometry, and convert the OS map to tangent space with handplane or xnormal.
Right, you could do that in this very specific case where all 6 faces of the box have hard edges, and thus completely flat normals, but you won't be able to do it on a mesh with any sort of complexity as it will change the mesh normals and introduce smoothing errors.
If you want to use that workflow, you need to bake an object space map, and the removed the geometry, and convert the OS map to tangent space with handplane or xnormal.
Plus the time it takes to go and remove a bunch of geometry for your final low poly, and the issues that introduces with iteration.
What about this idea, using the bolts/box example in the first post. What if you scaled the bolts down do they were super flat but still retained some of the their slope information, say about 5 or 6 times just to the point that they would fit under a cage that worked well with the edges. Then, in a program that allowed you to bump up the intensity of the normal map, you did so with the resulting map with the squished high poly floating detail, intensifying it until it looked right and using that map as your normal map? Or would have ruin the edges?
One thing you could do to make this work better maybe it to remove any geo that did not give any slope information to the renderer, such as undersides of bolts or perpendicular oriented polygons, or simply push that into the highpoly (if that works).
In a realistic case, you would just model a low profile floater that bakes the same info into the normal map. You wouldn't use the whole nut and bolt model shown here ... it's way overkill.
What about this idea, using the bolts/box example in the first post. What if you scaled the bolts down do they were super flat but still retained some of the their slope information, say about 5 or 6 times just to the point that they would fit under a cage that worked well with the edges. Then, in a program that allowed you to bump up the intensity of the normal map, you did so with the resulting map with the squished high poly floating detail, intensifying it until it looked right and using that map as your normal map? Or would have ruin the edges?
The skew in the projection would still be there but lessened. But what happens with other maps, like it will lessen AO contribution, height map will be off so that could screw up displacement.
In a realistic case, you would just model a low profile floater that bakes the same info into the normal map. You wouldn't use the whole nut and bolt model shown here ... it's way overkill.
Yeah absolutely, but it's a mistake I see sooo often. That's why I included the bit about angle vs depth info in the first post.
Haven't read all the thread but I cope with this that way: on beveled shapes I just edit vertex normals so they always perpendicular to a surface . Before baking.
Imo works pretty fine since the problem is caused by vertex normals being skewed.
So why don't fix the skew first. As an extra plus you would get rid of normal map gradients and forget about synched or not workflow for some extent
It works to fix the skewing, but removing the loops after baking causes smoothing errors as the mesh normals change. If you want to work with that method, simply bake an object space map instead, remove the loops, and then convert the map from OS to TS. It takes like 30 seconds to do the OS -> TS conversion in XN or Handplane.
http://www.handplane3d.com/ - Handplane can also convert to a variety of different apps/engines tangent spaces.
If you remove the edge loop after you bake the normals will no longer match and more than likely you'll get seams or weird shading.
I wonder if a handplane sort of app could take the two different normal maps and combine them together with the knowledge of what was intended to be the final low poly geometry.
For some weird reason our engine likes 3d max baker more than anything else. I didn't try Xnormal for pretty while. Need to try again. Thank you for the hint, Eatrh Quake.
I was just going to ask a simple question in a new thread, but i will just ask it here along with another question to perna.
1. How do you automate cage editing? Are you talking about using the control loops to make the projection be correct "automatically" or is there something more we can do?
2. When pushing the cage out in 3DS max, is it okay for edges of the cage to intersect each other? I avoided it in the past, but now im assuming it has little relevance at all?
3. From a 2007 thread, someone with a lot of knowledge about the tech side (my presumption)... lol actually it was you i see , ...stated that not using a cage, in Max at least, gave much better results, is this still true?
Hey guys. Modern graphics cards can render TENS of THOUSANDS of polygons in realtime turbo graphics. The tiny handful of verts you add to control lowpoly bake projection and shading make no difference to rendertime (and don't require you to redo a ton of work every time you change your mesh).
Editing normals and cages is perfectly fine when it's automated. Doing that stuff by hand is/are shottings in the foot.
So much this. I've been trying to tell people this for awhile now. You don't have to sweat a few hundred extra verts. Really. It's OK. The graphics card does NOT care. Bevel that edge, add a vert to that face, go on ... it'll be OK.
I was just going to ask a simple question in a new thread, but i will just ask it here along with another question to perna.
1. How do you automate cage editing? Are you talking about using the control loops to make the projection be correct "automatically" or is there something more we can do?
2. When pushing the cage out in 3DS max, is it okay for edges of the cage to intersect each other? I avoided it in the past, but now im assuming it has little relevance at all?
3. From a 2007 thread, someone with a lot of knowledge about the tech side (my presumption)... lol actually it was you i see , ...stated that not using a cage, in Max at least, gave much better results, is this still true?
I know you asked Per, but I can probably fill in as a not so convincing look-a-like.
1. Here, automation refers to basic tools to push/enlarge the cage to cover the highpoly. Manual hand editing would refer to painstakingly editing verts to attempt to fix projection errors, which is time consuming, not particularly effective, and needs to be redone when revisions are needed. Automation for editing vertex normals would be scripts that allow you to select a face or group of faces and alter the normals, rather than manually entering in the values.
2. You should do some tests. Typically a little overlap is ok, but when your cage starts folding over itself you can have issues due to the projection normals going crazy.
3. Link to thread? Per was probably referring to a standard cage made in the normal way vs a hand edited cage, basically #1.
So, if i have set custom projection directions manually via cage tweaking or via script, i have to use that same cage to do the AO bake as well to get the AO to match the normals for geometry with lots of detail? Or do people just bake the AO for the LP with just the LP, no HP?
I understand this thread is about avoiding this very thing (i think), but i am right in the middle of trying to bake a really detailed model with lots of big floaters.
Thats awesome, i should have checked the wiki first.
Edit: I didn't see anything about matching projection distortion between the normal bake and the AO bake, but in thinking about it more, i am assuming that if you tweak the cage projection direction, like you can in Max and Xnormal (and other programs i probably don't know about) you must match that distortion within the AO bake too, but just for the HP projection bake and perhaps just for the fine details, like the example im working on right now. Please correct me if i am wrong.
btw, this is the thread perna stated the thing about getting different results with baked edges.
Noren: There are two types of normal map processing cages. One that limits only length, one that controls direction and length (like in max).
Controlling direction like that means the generator is not able to tweak the results ideally.
Here's a test you can try: Push a ray cage in max X units and render out the normal maps... then disable the cage and use an offset/raylength of the same X units instead. You should get the exact same result, right? But you don't, the non-cage output is going to be significantly better in most cases. Someone may have time to provide some screenshot examples.
Is that still true?
You can see i've added in some control loops since reading this thread and the bake has gotten much better
Its important to keep in mind that Per was talking specifically about projection direction here. If you don't use a cage you won't be able to use hard edges without getting gaps in the projection, so using a simple ray distance (default in xn, offset in max) rather than a cage is not a recommended practice unless you don't have any smoothing group splits/hard edges.
As a side note, if im understanding this correctly, in a way Maya's cage does control ray direction, when you have hard edges (Maya) (aka a smoothing group for Max users like myself)? Or do you just mean select "averaged normals" in Xnormal and that you don't have to use the cage?
From my understanding of Maya, you have two options.
1. Match using surface normals, this is like the offset method in max and the default XN method in that it uses your low poly normals explictly for projection direction, so hard edges cause gaps.
2. Match using geometry normals, this is like the standard method in max, and using a custom cage in XN (either making it in XN or importing it).
(I may have match using backwards, don't have maya on my laptop)
However, I believe Maya does not work like max in that no matter how much you hand edit the cage (called envelope) it will only adjust distance, not projection angle. From what I understand, it will always use the base lowpoly's averaged normals for direction, while max will recalculate the normals, which allows you to do certain tricks.
Noticed something weird with the cage in Max (or maybe its a feature?). I had made an inset in the faces in the model in the image i posted two posts before this one to capture all the floating geo you see. It worked great the first time i tried to render and i thought i'd never have to revisit that situation again however i noticed that in redoing the cage and rebaking i got some distortion, which once again shook my quite vague understanding of how all this works and in trying to figure it out i noticed that when pushing the cage out in Max:
1. The first push of the vertices of the newly inset faces follows the normal direction of straight away from the surface following its normal.
2. The second time you use push, those vertices suddenly start to expand in an outward direction, not following the normal and obviously creating distortion in the final projection....
EDIT2: I've replicated the behavior on a simple box with insets.
Really? Is that a feature i don't know about. I didn't see anything about it in the 3DS max doc in the projection mod section.
EDIT: btw, i initially thought it might be because i didn't set the new faces from the inset operation with a smoothing group, something related to that, but giving that whole back plane its own group didn't help. I also thought it might stem from the fact that i forgot to triangulate those new faces from the inset, but nope.
Really, this isn't a big deal? You basically get one try to get your cage or section of your cage covering everything before the verts start going haywire. God forbid we would like to pan around the mesh and make sure everything is covered, then have to push out a little bit again here and there.
I just can't believe they don't have a separate button for this if it on purpose. If it not on purpose i'd like to know what the heck is going on at autodesk corp because Max feels like beta software for the work im doing thus far.
It would at least be nice if they could implement a dune buggy driving game into the bake process, that you could drive on the surface of the object wielding a microscope to look for HP protrusions through the cage(you'll only understand that if you're a max user). Yep, i think i speak for everyone in that regard. :poly142:
Thane, if you use external bakers you can make your cage with a Push modifier on the stack of the object. This is generally more efficient, and you won't run into the issue you described.
Also keep in mind that you can export/import the cage mesh from the projection modifier in 3dsmax.
This is a smart thing to do even if you're aren't using an external baker. That way if you end up having to change the geometry of the low poly for some reason, you can create a new cage and "conform brush" or snap it, to the old cage, and import it into the projection modifier. Saving you from having to redo a lot of those manual cage tweaks.
Scripts like WrapIt or MaxRetopo can also help you snap the surface of the new cage to the old.
I just wanted to drop this here too, because maybe it will be useful to someone... I did a test with some support methods and the cage, and however fwvn doesn't help, supportloops should solve skewing issues.
Okay I did an another, complete test, but it gave the result I expected after seeing the cage in the first test. We need a cage that gets pushed based on vertex normal direction, and not based on average direction .
-At least this happens in Max.
As a side note - even a simple chamfer can work if you have patience to manually edit the cage.
I have been given a task of making this bowl (on the picture) and make a normal map for it. I have been strugling all day long with the seams in the corners. I read a lot of posts and tips how to make the seams go away but nothing i tried really helped me and I am starting to be desperate.
The model of the bowl has shared UVs (the front and left side). The shared UVs have been moved to the right by 1 unit so its not influencing the bake. I tried to bake the model in xNormal with my own cage, which is overlapping the high poly very tightly. I also tried to bake the normals in 3ds Max but the results are very similar. The hight poly doesn't fit the low poly that well on the edges but that is because I dont wanna lose the roundness of it. The polycount of the lowpoly can't be changed.
I am sorry if this was already discussed in some other post, but I haven't find any. Could anyone give me some advise about this please?
Those parts appear black because the projected normal in that place points behind the model (it makes sense: just think of the shape of the hipoly).
Since the viwport's light is from the camera, a normal facing away from the camera is displayed as black.
This might not look as bad with an HDR map, or environment, or multiple lights setup.
The part with the normals facing backwards will still recieve light
About seams, make sure
-your normals are smoothed on the base lowpoly wherever an UV split isn't occurring
-tangents are synced between the baker and the viewer
We need a cage that gets pushed based on vertex normal direction, and not based on average direction .
-At least this happens in Max.
As you may remember, in my tests i was able to get Max's cage to follow the normal direction perfectly on the first use of the push function, but after that it seemed to go another direction.
I have no idea but in the Max help file, the only example problem they have for normal maps is solving skewing on the top of a cylinder by reorienting the cage so the cage verts are more perpendicular to the top face, like you already know, and i thought maybe the Max devs made it that way to reorient the cage automatically in such a way, but it just a theory and Max's help file doesn't mention it either way (thanks Max).
Those parts appear black because the projected normal in that place points behind the model (it makes sense: just think of the shape of the hipoly).
Since the viwport's light is from the camera, a normal facing away from the camera is displayed as black.
This might not look as bad with an HDR map, or environment, or multiple lights setup.
The part with the normals facing backwards will still recieve light
Thank you very much for the reply. Those black part doesn't bother me since, as you said, it won't be that noticeble.
About seams, make sure
-your normals are smoothed on the base lowpoly wherever an UV split isn't occurring
-tangents are synced between the baker and the viewer
Lowpoly is in 1 smoothing group. What do you mean by synced tangents between baker and the viewer? You mean synced tangents between the LP and the cage? If that is the case, I made the cage from LP and only moved the vertices along the normals.
Okay I did an another, complete test, but it gave the result I expected after seeing the cage in the first test. We need a cage that gets pushed based on vertex normal direction, and not based on average direction .
-At least this happens in Max.
As a side note - even a simple chamfer can work if you have patience to manually edit the cage.
You don't have to manually edit the cage if you just edit the vertex normals and add support loops.
Yes. But now you have a triple bevel. But... Maybe you can remove the support loops after the baking, as you have edited normals and the bake went based on that? I think it should look the same after removing them.
Yeah I removed the support loops, the one with the support loops I used to bake. The top image is comparing the two low poly models with the same normal map.
Okay thanks for the answer. I was thinking the same. Normalmap fight with vertex normals won't happen because you have the edited normals, so the supporting can be removed. :thumbup:
Replies
I've read all the literature including EQ's posts, the Polycount Wiki and 'Beautiful, Yet Friendly' - so I understand on a basic level that they should be placed where your model has a hard edge and/a different material.
However, does that mean that I can go into every model thinking 'There's a hard edge (> 70°) right here, so I'll put a seam and a smoothing group there?'. I know there's more to it than that so how else can a seam's location be determined?
low poly:
high poly:
What can cause this?
I would assume you have too much stretch on UV layout, but it could also because of you did not triangulate the mesh for it to properly bake. Did you? I've experienced once the same thing. They usually appear at where a quad triangulates. Can't really remember why, but I've never found same issue again.
Non-triangle mesh used for baking will somehow create artifact because it can only bake if the model is fully defined in triangles, where all normal directions are solid. If the points of the quad/polygon are not on a same plane (having different normal direction), the software will want to automatically figure it out where to make the triangle. Than if your low poly model in the view port isn't triangulated in the exactly the same way, when you apply the normal map texture, it will contain some artifacts.
My two cents regarding the last two comments.... If you are modeling and baking in the same software, then the low poly mesh not being triangulated is probably not the issue. I'm assuming you're not editing the low poly model after baking. So the same software should always triangulate the same non-planar quad the same way. So within the confines of the geometry, the bake settings, and the smoothing groups/soft/hard edges, etc., the tangent space normal map will be generated to make the normals of the low poly mesh read as the high poly mesh as closely possible. Exporting a mesh with non-planar quads from one modeling package to another, or to a game engine, is where problems with the normal map come up, because different software calculates normals and tangents differently. (There are some good posts on this but I can't seem to find them, will edit and post if I do).
Regarding the image posted, I would say the skewing in the normal mapped model is probably due to skewed UVs of the low-poly model, and due to projection angle of the bake.
Like this:
It gives me this:
The edges are not very nice in this example, but this bakes out nicely in xNormal.
But its not really a good idea, the gaps at the edge look terrible. You would need to do two bakes, one with gaps, one without, and then photoshop them together to get a usable result. I've done this long ago, but it's an annoying workflow, and it doesn't fully solve the problem anyway (only helps where you have a hard edge near skewed detail).
More on hard edges here: http://www.polycount.com/forum/showthread.php?t=107196
Couldn't you just bake #2 box , then reduce tri-count by removing edge loops?
And essentially, more geometry = less skew
If you want to use that workflow, you need to bake an object space map, and the removed the geometry, and convert the OS map to tangent space with handplane or xnormal.
Plus the time it takes to go and remove a bunch of geometry for your final low poly, and the issues that introduces with iteration.
One thing you could do to make this work better maybe it to remove any geo that did not give any slope information to the renderer, such as undersides of bolts or perpendicular oriented polygons, or simply push that into the highpoly (if that works).
The skew in the projection would still be there but lessened. But what happens with other maps, like it will lessen AO contribution, height map will be off so that could screw up displacement.
Yeah absolutely, but it's a mistake I see sooo often. That's why I included the bit about angle vs depth info in the first post.
https://www.dropbox.com/s/8hniajain8adpaf/normals.jpg?dl=0
If there is no chamfer I do hard edge + cage and extra loops next to the hard edge as a modifier. Then switch loops off after baking
So why don't fix the skew first. As an extra plus you would get rid of normal map gradients and forget about synched or not workflow for some extent
http://www.handplane3d.com/ - Handplane can also convert to a variety of different apps/engines tangent spaces.
I wonder if a handplane sort of app could take the two different normal maps and combine them together with the knowledge of what was intended to be the final low poly geometry.
1. How do you automate cage editing? Are you talking about using the control loops to make the projection be correct "automatically" or is there something more we can do?
2. When pushing the cage out in 3DS max, is it okay for edges of the cage to intersect each other? I avoided it in the past, but now im assuming it has little relevance at all?
3. From a 2007 thread, someone with a lot of knowledge about the tech side (my presumption)... lol actually it was you i see
So much this. I've been trying to tell people this for awhile now. You don't have to sweat a few hundred extra verts. Really. It's OK. The graphics card does NOT care. Bevel that edge, add a vert to that face, go on ... it'll be OK.
I know you asked Per, but I can probably fill in as a not so convincing look-a-like.
1. Here, automation refers to basic tools to push/enlarge the cage to cover the highpoly. Manual hand editing would refer to painstakingly editing verts to attempt to fix projection errors, which is time consuming, not particularly effective, and needs to be redone when revisions are needed. Automation for editing vertex normals would be scripts that allow you to select a face or group of faces and alter the normals, rather than manually entering in the values.
2. You should do some tests. Typically a little overlap is ok, but when your cage starts folding over itself you can have issues due to the projection normals going crazy.
3. Link to thread? Per was probably referring to a standard cage made in the normal way vs a hand edited cage, basically #1.
I understand this thread is about avoiding this very thing (i think), but i am right in the middle of trying to bake a really detailed model with lots of big floaters.
http://wiki.polycount.com/wiki/Ambient_occlusion_map#EarthQuake.27s_Baking_Method
Edit: I didn't see anything about matching projection distortion between the normal bake and the AO bake, but in thinking about it more, i am assuming that if you tweak the cage projection direction, like you can in Max and Xnormal (and other programs i probably don't know about) you must match that distortion within the AO bake too, but just for the HP projection bake and perhaps just for the fine details, like the example im working on right now. Please correct me if i am wrong.
btw, this is the thread perna stated the thing about getting different results with baked edges.
http://www.polycount.com/forum/showthread.php?t=50588&page=2
Is that still true?
You can see i've added in some control loops since reading this thread and the bake has gotten much better
1. Match using surface normals, this is like the offset method in max and the default XN method in that it uses your low poly normals explictly for projection direction, so hard edges cause gaps.
2. Match using geometry normals, this is like the standard method in max, and using a custom cage in XN (either making it in XN or importing it).
(I may have match using backwards, don't have maya on my laptop)
However, I believe Maya does not work like max in that no matter how much you hand edit the cage (called envelope) it will only adjust distance, not projection angle. From what I understand, it will always use the base lowpoly's averaged normals for direction, while max will recalculate the normals, which allows you to do certain tricks.
1. The first push of the vertices of the newly inset faces follows the normal direction of straight away from the surface following its normal.
2. The second time you use push, those vertices suddenly start to expand in an outward direction, not following the normal and obviously creating distortion in the final projection....
EDIT2: I've replicated the behavior on a simple box with insets.
Really? Is that a feature i don't know about. I didn't see anything about it in the 3DS max doc in the projection mod section.
EDIT: btw, i initially thought it might be because i didn't set the new faces from the inset operation with a smoothing group, something related to that, but giving that whole back plane its own group didn't help. I also thought it might stem from the fact that i forgot to triangulate those new faces from the inset, but nope.
Here is a photo to help visualize:
It would at least be nice if they could implement a dune buggy driving game into the bake process, that you could drive on the surface of the object wielding a microscope to look for HP protrusions through the cage(you'll only understand that if you're a max user). Yep, i think i speak for everyone in that regard. :poly142:
This is a smart thing to do even if you're aren't using an external baker. That way if you end up having to change the geometry of the low poly for some reason, you can create a new cage and "conform brush" or snap it, to the old cage, and import it into the projection modifier. Saving you from having to redo a lot of those manual cage tweaks.
Scripts like WrapIt or MaxRetopo can also help you snap the surface of the new cage to the old.
http://www.polycount.com/forum/showpost.php?p=2331130&postcount=94
-At least this happens in Max.
As a side note - even a simple chamfer can work if you have patience to manually edit the cage.
I have been given a task of making this bowl (on the picture) and make a normal map for it. I have been strugling all day long with the seams in the corners. I read a lot of posts and tips how to make the seams go away but nothing i tried really helped me and I am starting to be desperate.
The model of the bowl has shared UVs (the front and left side). The shared UVs have been moved to the right by 1 unit so its not influencing the bake. I tried to bake the model in xNormal with my own cage, which is overlapping the high poly very tightly. I also tried to bake the normals in 3ds Max but the results are very similar. The hight poly doesn't fit the low poly that well on the edges but that is because I dont wanna lose the roundness of it. The polycount of the lowpoly can't be changed.
I am sorry if this was already discussed in some other post, but I haven't find any. Could anyone give me some advise about this please?
Since the viwport's light is from the camera, a normal facing away from the camera is displayed as black.
This might not look as bad with an HDR map, or environment, or multiple lights setup.
The part with the normals facing backwards will still recieve light
About seams, make sure
-your normals are smoothed on the base lowpoly wherever an UV split isn't occurring
-tangents are synced between the baker and the viewer
As you may remember, in my tests i was able to get Max's cage to follow the normal direction perfectly on the first use of the push function, but after that it seemed to go another direction.
I have no idea but in the Max help file, the only example problem they have for normal maps is solving skewing on the top of a cylinder by reorienting the cage so the cage verts are more perpendicular to the top face, like you already know, and i thought maybe the Max devs made it that way to reorient the cage automatically in such a way, but it just a theory and Max's help file doesn't mention it either way (thanks Max).
Thank you very much for the reply. Those black part doesn't bother me since, as you said, it won't be that noticeble.
Lowpoly is in 1 smoothing group. What do you mean by synced tangents between baker and the viewer? You mean synced tangents between the LP and the cage? If that is the case, I made the cage from LP and only moved the vertices along the normals.
You don't have to manually edit the cage if you just edit the vertex normals and add support loops.