If it looks fine, you shouldn't worry about it then.
Mine weren't looking alright. Everything set to 1 smoothing group lead to huge gradients over flat surfaces, which looked crappy using viewport shaders.
If your models are organic or higher poly, without flatter areas, that become less visible. But in my case, I had to split the low poly in many different smoothing groups, as if it was supposed to be vertex lit in an older engine. Worked fine in the end.
But yeah, if you can get away with 1 smoothing group, just do it and be glad that it works!
Using uniform ray distances will never get you a very accurate bake and in most cases you are much better off using a cage because they offer much more control
The only reason you would want to use smoothing groups is if the tangent basis of the baker doesn't match the engine that you are rendering the final model with.
The colours and gradients in the normal map are there to represent the differences between the low and high poly models and if the tangent basis doesn't match then these colours and gradients cant be translated accurately into correct lighting, which is why you can get the smoothing errors (which are simply the visual difference between the tangent basis of the baked map and the renderer)
Adding smoothing groups reduces the gradients and in doing so, also reduces the errors because there is less chance of an incorrect translation happening as the areas with smoothing groups tend to be flatter and resulting values tend to be much closer to 128,128,255 (in addition to other factors)
In xNormal, you always want to bake using the final low poly model with it's normals intact (as exported) as averaging the normals in xNormal is different to the averaged cage that EQ is talking about. If you are averaging the normals in xNormal and then using that bake on a mesh with different normals, then the bake wont match the LP mesh, which will cause errors.
Exported normals Vs Av. Normals in Marmoset (on the exported normals LP)
Averaged normals
Exported normals
Difference map
xNormal requires that the topology of the cage matches the LP mesh 100% and doesn't have an averaged cage, so using it's inbuilt cage feature doesn't work because when the cage is expanded, gaps are also expanded.
The only work around i have found is to make a duplicate of the LP mesh for use as an external cage and then apply the smoothing groups after the cage has been expanded in your 3d application, which seems to reduce any gaps in the bake so that they are pretty much non existent.
The thing is that I've been keeping it all at one smoothing group in Max, so the normals are the same for baking in xNormal. The thing I'm not doing is breaking my models into smoothing groups, at all. I've been putting them all to 1, importing into xNormal and baking with the distance rays.
I get exactly how a cage is important (at least I do now), but for all my work so far there haven't been issues. My question is that if my smoothing groups are always set to averaged across applications, why should it matter or why should I bother with smoothing groups.
I've read a bit about using hard edges and an averaged cage, but what difference does it make from smooth edges and an averaged cage?
Maybe you've answered this but if so it's gone over my head, so sorry for my ignorance and thanks for all the help!
If you are using a single smoothing group and the tangent basis of the baker matches the engine that you are rendering the final model with, then there is no need to use smoothing groups, other than for texturing reasons (it makes for a cleaner normal map that is easier to texture in some cases)
The cages Max and xNormal work differently because xNormal doesn't use averaged cages, but if you are only using 1 smoothing group then it doesn't matter because there are no breaks in the meshes normals and therefore, no gaps to worry about.
As EQ said, with an averaged cage in Max, there is no difference in using a model with smoothing groups or no smoothing groups because the cage ignores the normals anyway
Per: he's referring to using the cage as apposed to the "offset" method in max, which break edges when using SG's. He is correct in what he's say. You're mistaken in thinking that he's suggesting using a Custom cage tweaked vrs a simple cage setup. But he's talking about a proper averaged cage, vrs the broken edge projection of the offset thing, or basic ray distance setting in xnormal etc. Unless you're trying to say something else and I misread.
[edit] NM I see his "control" comment below and yeah, agree with per here, if you've gotta do any custom cage work, you should really be looking to fix your mesh, not your cage. Tweaking cages needs to be redone any time you change your mesh, so its really just a bad idea.
Now as far as SG's, yeah there really is no reason NOT to use smoothing groups. Use a quick script to set all your uv borders as hard edges/SG in Max or Maya, there is absolutely no drawback to performance to do this, no matter if you're using a synced display or not. The only drawback is that you have to actually use the proper cage, but really, being able to visibly see the cage as apposed to guessing a ray distance value is a much easier way to work anyway.
Using uniform ray distances will never get you a very accurate bake and in most cases you are much better off using a cage because they offer much more control
By this I meant that you can run into issues like projection problems when using the minimum/maximum uniform ray distances on things that are close together and cant be exploded, such as fingers for example. Perhaps accurate wasn't the best terminology
You can use things like blockers, but i always find it easier to use a cage. I still use uniform projection for things like textures though.
I 100% agree on the smoothing groups comment though. There is no reason not to use them on SG splits (i actually released a Blender 2.5 script for this a few days ago ^^) but as i don't use Max or Maya, i cant really comment on the use qualified normals for them
Also, I 100% agree on the pros. of using smoothing groups for texturing reasons too.
With Blender, xNormal and Marmoset there are a couple of very small errors with the mesh above (top corner) but nothing really major.
xNormal baked Normal in Marmoset (single SG)
xNormal baked Normal (single SG)
I made the test mesh above to see how well Blender could handle single smoothing groups with its internal renderer and baker, since they have recently implemented a new tangent basis it seems they did a really good job in getting everything synced up (GLSL viewport shader, Baker and the Rendering engine)
Top row is HP, bottom is LP (single SG)
Blender baked Normal (single SG)
@EQ,
Just noticed your post!
Yea, you pretty much hit the nail on the head with what i was trying to say
Thanks for the translation!
I'm trying to understand this stuff as thoroughly as possible, but I think I'm still missing some things. Sorry if it's already been explained and I missed it.
Does it matter if you use one smoothing as opposed to multiple smoothing groups with UV splits? Is it a matter or personal preference, or are there specific instances when each method would be better suited?
I've been talking to oniram about his recent SMG, where he baked with one smoothing group and ended up with great results. I then tried it with a recent model I worked on and ended up with worse results than I got from using smoothing groups with UV splits.
I'm trying to understand this stuff as thoroughly as possible, but I think I'm still missing some things. Sorry if it's already been explained and I missed it.
Does it matter if you use one smoothing as opposed to multiple smoothing groups with UV splits? Is it a matter or personal preference, or are there specific instances when each method would be better suited?
I've been talking to oniram about his recent SMG, where he baked with one smoothing group and ended up with great results. I then tried it with a recent model I worked on and ended up with worse results than I got from using smoothing groups with UV splits.
Well the real question you need to ask is why would you ever need to avoid using smoothing groups/hard edges? If you can come up with the answer for this question, it should be apparent.
If we're using a proper averaged cage(as has been covered here extensively) there will be visual no gain to using 1 smoothing group. On the technical side, your vertex's are already being double along your UV borders, so using hard edges there adds zero performance loss. So why this obsessive need to worry about having only 1 SG?
This whole thing comes from some programmer telling someone 1 SG is better, back in like 2001 or whatever, and everyone repeating that advice. But really, the conclusion is that using hard edges/smoothing groups along your uv boarders will never be a bad thing.
Now, a few good reasons TO use hard edges on your uv borders:
1. If your engine isn't synced, it can significantly reduce smoothing errors.
2. Even if your engine is synced, it can avoid artifacts related to texture resolution. EI: your triangle is too small and the require gradiant needed to counter the smoothing is impossible to record in your normal map.
3. Extracting "detail maps" from crazybump or xnormal is a more straight forward process, you worry less about artifacts from extreme gradiation.
4. Texture compression generally is going to produce better results with less gradiation.
So yeah, the question shouldn't be which is better when, it should be why would I ever want to use 1SG?
Now a lot of people, upon hearing this ask me: "Why do I care about synced normals then?" Well, the answer is relatively simple.
Even if you're using hard edges, your end result can be significantly better with synced normals(3ps Quality mode, Maya, etc), so much so that you can even take old models, baked with hard edges etc and simply turn the feature on and see a notable improvement.
When you have synced normals, you can also simply worry much less about uvs and hard edges. Without sync'd normals, you may need to use a lot more hard edges and split UV islands to get a bake without any smoothing errors. Generally with a sync'd workflow, you can simply model naturally, not worry about excessive bevels, or excessive hard edges/uv splits, just model in a sensible manner and use a script to add hard edges where your natural UVs seams are to ensure an even higher level of quality, and you're good to go.
Hoever, this boils down to a matter of Sync'd or no, not 1 SG or no.
On a complex mesh, you could see 2-3x the vertex count(either with excessive beveling, or excessive hard edges) to get the same results with a sync'd bake.
[edit] NM I see his "control" comment below and yeah, agree with per here, if you've gotta do any custom cage work, you should really be looking to fix your mesh, not your cage. Tweaking cages needs to be redone any time you change your mesh, so its really just a bad idea.
I don't mean custom cage work
By control, I meant that using using uniform ray distance/offset is much more of a guessing game than using a standard non tweaked cage and the results can often leave something to be desired.
When making a cage I just use use Blenders equivalent of the push modifier with no other edits.:)
Generally for these kind of things, like fingers, the trick is to sample based on surface direction (xNormal has had this for quite a while). When you do that, you'll only sample the next finger if the ray travels all the way through it, which is quite a distance. If you don't do it, you'll sample the side of the second finger that's closest to the first finger and you'll get the artifacts you mention. I'm sure you're aware of that, just dropping it in there for anyone following the chatter.
I didn't know this actually.
How is it enabled in xNormal?
Yeah, when you say "control", to my understanding that means you are using a custom cage, because the only way to control it is to tweak it, and if you tweak it, then it's custom. 3ds Max causes some confusion with terms here, because even if you just set a constant distance, it's still called a "cage", which is a term I'd only use for when you're customizing it. Fixed distance can be/is done 100% programmatically, except 3ds chooses to visualize it as a "cage". Don't know how this is in, say, blender.
Ahh right, I see what you mean. I have always viewed these a totally separate ray casting methods, so I can see what you are getting at now.
Blender uses Distance and Bias settings with numerical input in which you set the maximum distance from the active object to the target with the bias allowing you to set a preference to objects that are further away. Most of the time it seems to get nice results, but its not super intuitive (initially, at least :P).
I do all my baking xNormal though, as it generally provides more detailed results.
Yeah, definitely an issue of terminology here. Technically a non-tweaked cage is not a cage per se, since it does not need to be stored. The "cage" doesn't have to exist; it's actually just a single "uniform ray distance/offset" as you say. You can visualize it as a cage, but it doesn't need to be stored as a separate mesh (that 3ds does this is just non-ideal programming on the part of 3ds)
The best way of defining the distinction should probably be:
-if your ray target position parameter is a single value, you're not using a cage
-if your ray target position parameters are per-vertex, you're using a cage, with the extra work required to maintain those parameters.
Of course, if you're in a situation where you have no choice but to use a cage, then you just have no choice, but it's definitely inefficient and should be avoided wherever possible
Ok awesome
My only issue is that when I use the max/min ray distance in xNormal, it often bakes incorrectly and breaks the edges, but this doesn't happen when I use a cage (non tweaked) in xNormal. Any ideas why this is happening? Maybe the sample based on surface direction setting you talked about will fix it?
Thanks for the detailed post Perna. Always appreciated
I didn't know this actually.
How is it enabled in xNormal?
Ok awesome
My only issue is that when I use the max/min ray distance in xNormal, it often bakes incorrectly and breaks the edges, but this doesn't happen when I use a cage (non tweaked) in xNormal. Any ideas why this is happening? Maybe the sample based on surface direction setting you talked about will fix it?
Thanks for the detailed post Perna. Always appreciated
In Xnormal, when you're just using the ray distance, it uses the vertex normals of your lowpoly mesh, so you get gaps along your hard edges.
In max, if you use the "offset" method, it does the same thing.
So to me, when I say cage, I mean a proper averaged cage, not a simple ray distance. I don't mean a manually tweaked cage, just a proper averaged cage. But thats getting a bit semantical, I don't think we need two different terms for if you've manually tweaked your cage or not. You've got an averaged cage, or you've got a distance based raycast from your lowpoly mesh normals, these are the important things to identify. To me, using a cage certainly doesn't mean you're going in there and tweaking it to avoid errors and things like that, its differntiating between the two obvious methods that the software gives you.
It is all a "cage" in a sense, but I think Per's explanation of terminology is a bit confusing there.
In max, you have:
A. Offset Method
B. Cage
In Xnormal:
A. Ray distance
B. Cage
In Maya:
A. Surface normals
B. Geometry normals(averaged)
Anyway, these are the important things to understand, "offset" in max will cause gaps, ray distance in xnormal will cause gaps, surface normals in Maya will cause gaps.
Weather or not you're manually tweaking your cage has no bearing on the technique used to project, and that is the important factor here, that you're using a proper averaged cage.
In most apps, what is presented to the user is; you're either using the cage or you're not, and that, to the user, is what causes or solves the hard edge gap problem, its the most basic and simple way to refer to it. You should be using the cage, not the basic ray distance. We can talk about the technical side behind it etc, but the user isn't seeing that, so its not particularly relevant.
So to say "Are you using a cage or a ray distance?" is a good question to ask, as almost everyone will have some basic understanding here.
In a sense, Maya operates on the User level the closest to what Per is explaining, its all just a ray distance, and you have a choice between averaged normals on the projection "envelope"(what maya calls it lol) or using the lowpoly vertex normals.
In max its more complex and much less ambiguous, as the two methods not only have completely different UIs, but have different behavior as well. In max tweaking the cage will affect normal direction as well as distance, in maya it will only effect distance. XN is the same as max in this regard as well, a completely different interface and behavior for using a "cage" or not.
In Xnormal, when you're just using the ray distance, it uses the vertex normals of your lowpoly mesh, so you get gaps along your hard edges.
In max, if you use the "offset" method, it does the same thing.
So to me, when I say cage, I mean a proper averaged cage, not a simple ray distance. I don't mean a manually tweaked cage, just a proper averaged cage. But thats getting a bit semantical, I don't think we need two different terms for if you've manually tweaked your cage or not. You've got an averaged cage, or you've got a distance based raycast from your lowpoly mesh normals, these are the important things to identify. To me, using a cage certainly doesn't mean you're going in there and tweaking it to avoid errors and things like that, its differntiating between the two obvious methods that the software gives you.
It is all a "cage" in a sense, but I think Per's explanation of terminology is a bit confusing there.
In max, you have:
A. Offset Method
B. Cage
In Xnormal:
A. Ray distance
B. Cage
In Maya:
A. Surface normals
B. Geometry normals(averaged)
Ahh right. That makes sense. It's basically what I thought when I made my initial reply, but was confused a little by what Perna was saying. Thanks for the clarification
From your explanation, it also looks like Blender uses the same Geometry normals(averaged) method as Maya as there are never seams or broken edges when everything is set up correctly.
Anyway, these are the important things to understand, "offset" in max will cause gaps, ray distance in xnormal will cause gaps, surface normals in Maya will cause gaps.
Weather or not you're manually tweaking your cage has no bearing on the technique used to project, and that is the important factor here, that you're using a proper averaged cage.
In most apps, what is presented to the user is; you're either using the cage or you're not, and that, to the user, is what causes or solves the hard edge gap problem, its the most basic and simple way to refer to it. You should be using the cage, not the basic ray distance. We can talk about the technical side behind it etc, but the user isn't seeing that, so its not particularly relevant.
So to say "Are you using a cage or a ray distance?" is a good question to ask, as almost everyone will have some basic understanding here.
In a sense, Maya operates on the User level the closest to what Per is explaining, its all just a ray distance, and you have a choice between averaged normals on the projection "envelope"(what maya calls it lol) or using the lowpoly vertex normals.
In max its more complex and much less ambiguous, as the two methods not only have completely different UIs, but have different behavior as well. In max tweaking the cage will affect normal direction as well as distance, in maya it will only effect distance. XN is the same as max in this regard as well, a completely different interface and behavior for using a "cage" or not.
Awesome. Thanks for the very detailed clarification. I think what is basically come down to, is a clash in terminology between Perna and myself. I have always used the Cage vs Ray distance to mean a non tweaked cage vs offset in Max.
It's great to get a good flowing discussion when things like this happen as it's always nice to be able to learn something about how everything works on a much finer level. I love this type of stuff
Thanks again EQ and Perna for the great info in the thread
Right, it is of course implementation specific, and I'm still not sure why XN does it in this way, as I've actually brought up the issue with Santiago on a few occasions. Like in maya, you just select from a dropdown list which implementation you want to use.
I just try to stick with how people commonly refer to this stuff, so the noobs can understand it.
If max/XN finally get around to fixing the gap problem, there wont really be any need to make the differentiation between cage and not, but until that actually happens, there is a need to talk about the differences.
In addition to that, I'm simply using max terminology, for instance whenever you are doing a bake in max, and you're using the projection modifier you're tweaking the cage. Literally the "cage" parameters in the projection modifier. Weather you're tweaking it by hand or with numeric values, you're changing variables that relate to the cage. So to tell someone you're "not" using the cage, when he's tweaking the cage parameters gets very confusing.
For clarity it would be good to have some sort of standardized terms for everyone to understand though. "Cage" is sort of a taboo word, as it relates to very specific functions in max.
Regardless of all the terminology, the important things to note are:
A. Your projection mesh should be averaged and thus gap-less.
B. You shouldn't need to spend time tweaking your projection mesh by hand.
There, I didn't say cage. Do I get a prize?
Its a "Who's on first" problem though, in max.
Q: Should I use the cage?
A: No you shouldn't use the cage
Q: Oh so I should use the offset method?
A: No you need to use an averaged projection mesh.
Q Oh, so I should use the cage?
infinite loop
Instead of re-defining what "cage" means to many max users. We should just use a generic term like "Averaged projection mesh", then we can simply explain, per app, how to get an "Averaged projection mesh".
This is just as future proof, but doesn't rely on a term that already means specific things to some people, and apparently different things to others.
Very specifically, when you go in to bake a normal map in max, you use the projection modifier, and tweak the cage either with a numeric value or by hand, both are quite distinctly the "cage" just using different methods to adjust the parameters of the cage. So to say one is a "cage" and the other isn't, this to me is very confusing. However both will result in an averaged projection mesh. The difference here is actually a workflow difference, not a technique/implementation difference.
To visualize:
So, to say one is the cage, and one isn't is just confusing, from a max perspective.
If we are to base terms on the basis of 3ds crappiness, then it's literally impossible to bake a mesh without a cage.
This is not true, from what I understand. If you're just using the offset method with a numeric value locked in, you don't have to do anything, this is just like the ray distance in XN, you can edit your mesh or whatever without resetting anything. Quite possible to bake like that, its just a bad idea for various reasons like gaps etc. However, people DO bake this way.
Again, to illustrate:
Baking without using the cage. Not at all impossible.
AFAIK, Santiago is removing the numerical ray distance in xN4, so that will be one less thing to explain
It will be a shame though, as its great for baking tileable textures.
Doom Baker? Are you referring to the baking tools with Doom 3 or is this a separate program?
Also which features are you referring to that have not been copied? If there is something amazing that we have been missing out on, I would love to know
I guess he means Open Render Bump which is a separate program and integrated into the doom3 editor
Some features i miss in either xNormal or 3dsmax are for example the ability to chose a bump map to bake into the low(i know that you can apply it in the material editor, but thats just a hassle if you just need it for baking) or choosing the normal closer to the low poly if the high and low poly are equidistant.
Some features i miss in either xNormal or 3dsmax are for example the ability to chose a bump map to bake into the low(i know that you can apply it in the material editor, but thats just a hassle if you just need it for baking) or choosing the normal closer to the low poly if the high and low poly are equidistant.
Do you mean baking a bump/height map into the generation of the normal map? This can be done by using the Fine Detail option, which is under the bake options.
It's impossible in that that method has a major bug which makes it unsuitable for any kind of real production. Could also say baking in max without a cage is possible because you can maxcscript it yourself
Well yeah, me and you understand that, but this thread isn't for us. Its for all the people who use these totally backwards/broken workflows still. =D
I just took a look at ORB and its pretty interesting. The executable still works, so i will have a play around later
Do you mean baking a bump/height map into the generation of the normal map? This can be done by using the Fine Detail option, which is under the bake options.
I'm not sure about Max because I don't use it, but its definitely in xNormal. You just have to make sure the aspect ratio of the detail image matches that of the final bake and you are good to go
Hi, I'm quite new to baking stuff, especially from High to Low, keeping the detail quality.
Thanks to everyone contributing to this thread with either questions or answers. I haven't been able to read it all with strict attention.
I just finished making some normal maps that required alot of thinking and researching from me(hence founding the thread) so I would like to drop here some interrogations and statement, in hope of feedback. "It's a hit me if I'm wrong kind of post"
Questions:
What does a cage do exactly?
-It seems to me that it allows one to set different ray distance along the model.
-It seems to me that it will in a way override direction given by vertex normals, since now at each vertex the baking direction will be pointing to the cage.
So if i use a cage and set in xNormal Hardened or Average, these will simply do the in betweens of what the cage.
Why do you show this image? What is the influence of the cage normals, in the baking process? What is the issue with unwelded cages? It seems to me that cages can be faceted and unwelded as long as the direction that each point makes with it's corresponding point in the base mesh it's a good direction.
Oh, and another thing. Even if your lowpoly's normals look like A, your Cage/Projection mesh normals look like B. That is unless of course your bake is set up poorly(either using "offset" in max, match using "surface normals" in maya, or using the ray distance in XN instead of a proper, welded cage). If your cage is not averaged, you will get seams on all of your hard edges, as the normals will be facing perpendictular along those edges, and cause gaps in the projection.
Statements Taking risks here..
Because I was baking everything with Averaged Normals, the 2 main issues I've found were Waviness on Cylinders and Roundness on Flat Areas. They got me to the Hard or Smooth Edges crossroad:
-Hard- give me good bakes for the contours and good flat areas. But it has gaps and the low poly geometry becomes more apparent
-Smooth- give me smooth transitions and a better illusion of detail, but flat areas wont be flat and but the will get roundish flat areas and waviness roughly like this:
-I get the waviness on the side (High contains Low)
-I get the Waviness on the cap (Low contains High)
The best results I found for my work so far were:
- Use Hard edges on convex transitions because I will see the contour angle , so it's best that my texture fills up to model contours. And also, whats flat, will be flat.
- Use Smooth edges on on concave transitions because I will not see the contours, but the interior, so smooth transitions won't look faceted. Waviness won't be a much of problem here.
This is how I got away with my model.
But ok I got Gaping going on on those hard edges.
There were 4 ways I saw one could solve baking hard sharp edges:
- Vertex Normal Map, Smoothing Group
- Unweld Mesh
- Edges Inset, Control Loops.
- Bevel
The First 2 are quite alike, they basily have the same Normals, geomtery remains the same. Unweld has the benefit of matching the cage better.
Edge Inset will add geometty on each side of the edges, isolating the flat areas from the smoothing transition in the rim. This way has it's problems because from many angles the rims will seem to shine or smoothing badly (thing triangulation)
Bevel will make nice smooth trasitions, it will add a few geometry, will require a new UV map and, the flat areas are not perfectly flat.
So i began to think I could overcome the Gap.
Untested, but this seems to be one solution. Requires a lot of work, i guess. Making Edge Insets is not fun, especially if one is past the UV step.
probiner: Your post is a little hard to follow, I'm not entire sure I understand all of it, but it seems that your confusion stems from the fact that you're not getting the difference between the mesh normals of your model, and the normals of your projection mesh(cage)
You can have hard edges on your lowpoly
BUT your projection mesh needs to be averaged, to avoid gaps. Its been outlined a few times how to do this in various apps so I wont write it up again, but this is the important bit.
Here is a clear example:
The lowpoly mesh normals are the same on both A and B.
BUT, the cage is averaged on A, and using the lowpoly mesh normals on B.
When you understand this, the rest of your issues on the matter aren't really relevant, there isn't a need to do anything extra like add additional geometry etc.
EarthQuake, ty for trying to understand me :poly142:
I understand what you mean with your post. Altough I get a bit confused about your use of the term "Averaged", since you are talking about the Cage and it's normals have no account in the baking process. I guess you mean Welded, which will average the projection on the LP.
My problem with an Averaged projection is that I get Waviness on cylinders.
The attachment (feet of the model I'm working now) shows the model with Averaged cage and Unwelded cage on that cylindrical area:
- While waviness does help to get the 'round look' on a lowpoly cylinder, when your point of view is different than the cage projection, it will suck!!
Having Faceted look also sucks, but less than waviness.
Since that part of the model is the feet. It will be seen mostly from above, so the top upper part of the side of the Cylinder will actually benefit from the waviness and I will keep the Average projection, but the bottom I will Unweld the cage there and make the projection strictly horizontal, so I'll get faceting but no waviness.
Of course you can say my low-poly sucks and it should have more geometry, I would probably agree with you, but right now I'm not gonna redo it =P
Still having some issued with the "wireframe" showing up not only on hard edges but sometimes on smooth edges. Probably something wrong with the difference of how I bake and how I render.
EarthQuake, ty for trying to understand me :poly142:
I understand what you mean with your post. Altough I get a bit confused about your use of the term "Averaged", since you are talking about the Cage and it's normals have no account in the baking process. I guess you mean Welded, which will average the projection on the LP.
Of course you can say my low-poly sucks and it should have more geometry, I would probably agree with you, but right now I'm not gonna redo it =P
Yeah if you're not willing to adjust your model there isn't any advice I can give you, I wrote up a big thread here on how to avoid waviness in the first place, there are a variety of hacks you can do to try to fix it after the fact, but they all suck.
EarthQuake, ty for trying to understand me :poly142:
I understand what you mean with your post. Altough I get a bit confused about your use of the term "Averaged", since you are talking about the Cage and it's normals have no account in the baking process. I guess you mean Welded, which will average the projection on the LP.
Your lowpoly mesh normals will be ignored if the your projection mesh normals are averaged, there isn't a situation where your projection mesh normals would be ignored, the projection mesh normals are what dictate the normal direction used for ray-tracing the normal map.
Of course you can say my low-poly sucks and it should have more geometry, I would probably agree with you, but right now I'm not gonna redo it =P
Yeah if you're not willing to adjust your model there isn't any advice I can give you, I wrote up a big thread here on how to avoid waviness in the first place, there are a variety of hacks you can do to try to fix it after the fact, but they all suck.
@ metalliandy and anyone else who would care to take a look
I downloaded the files you posted a few weeks ago, I have been having problems with seams a long my hard edges for a few weeks now I have not been able to figure out why.
Now I downloaded your test HP, LP and Cage and baked it in XNormal yet for some reason the normal map is different to yours with the seams being a lot more visible, this is the problem I have on pretty much every hard edge I try and bake.
I baked the the maps at 1024x1024 with 16 edge padding, yet no matter what I change the edge padding value to nothing seems to make a difference.
I have have no idea what so ever what is causing such a difference in end result, I used the exact files you supplied not editing them at all, high poly in the high slot, low in the low slot, with the cage in the cage slot on the low.
So could somebody please give some insight into what is going on :poly142:
Which version of xNormal are you using? Jogshy added a new tangent-basis calculator in xNormal 3.17.5, which is a better match for most engines (Marmoset matches it 98-99%)
The size of the baked map needs to be 2048wx1024h (or 1024x512 etc.), though the 1024x1024 size you had written above, was prob. a typo
In xNormals LP options, "Use exported normals" should be selected (not "Average normals") and "Use cage" should be checked.
Try using a newer version of Marmoset (I used 1.03 or 1.04, iirc) as the guys at 8ML may have done some tweaks somewhere and the normal rendering in newer versions may have changed slightly.
I Just baked the files I uploaded again, and came up with the same results as posted a few pages back, so it should work
Hey metalliandy thanks for the reply, you seem to nailed the problem right away. Me being the idiot I am sometimes having downloaded the latest version of xnormal a few months back thinking it would overwrite the previous version, I continued to use my icon pinned to the task bar thinking I was using 3.17.5 when I was in fact using 3.17.4 still.
Just re-baked it and it came out identical to yours, cheers for that, I can now get back to working on stuff without having to worry why my hard edges always looked so terrible.
Okay like most people here, I thought I somehow new how to make a correct normal map till now.
It appears you can get away with everything in one smoothing group, as long as your UV islands align with where you would have hard edges on your model.
Couple questions regarding this:
1. EQ - you say you have a script that sets all your uv borders as hard edged in maya. Doesn't that put hard edges on areas sometimes where you would want smooth edges? (ie the bevel at the end of a cylinder? or a cylinder itself where an unwrap would cause a seam running along it?)
2. I have simply always gone with putting hard edges where angles are less than 90 degrees, and split your UVs there, is this bad technique? (I believe racer445 discussed this technique but apparently its out of date).
3. What I've learnt (correct me if I'm wrong). It a safe option to just use 1 smoothing group (so long as your cage is correct). Cut your UVs where you would have hard edges on your model. Add some smoothing groups if you have SEVERE triangle shading.
I've noticed some people ask the same question numerous times, and I'm pretty sure I'm one of those, but hopefully you won't mind answering :P.
Okay like most people here, I thought I somehow new how to make a correct normal map till now.
It appears you can get away with everything in one smoothing group, as long as your UV islands align with where you would have hard edges on your model.
I'm not sure where you're getting that from this thread;
A. Smoothing groups or not, will have no effect on your bake(as far as projection goes, seams etc) if you've got a properly set up averaged projection mesh.
B. Whether or not you can get away with 1SG is very specific to how your renderer and baker are sync'd up, if your baker and render are NOT sync'd you can almost certainly NOT get away with 1SG.
C The relevance of UV is when you're using hard edges/smoothing groups. If your entire mesh is smoothed, your uvs have no relevance.
1. EQ - you say you have a script that sets all your uv borders as hard edged in maya. Doesn't that put hard edges on areas sometimes where you would want smooth edges? (ie the bevel at the end of a cylinder? or a cylinder itself where an unwrap would cause a seam running along it?)
Yes, you will end up with hard edges in "illogical" areas, however with a properly averaged projection mesh, and a sync'd up baking workflow, this has absolutely zero effect on the end result of your bake. Even a hard edge on the seam of a cylinder like you said, that if you were doing it by hand you would always make sure it was soft, its of no concern. Virtually all of my guns for Brink have areas like this, but you'd never know without looking at the untextured mesh.
If you want to go back and soften up a few edges after you run the script, by all means go for it, but its sort of an obsessive compulsive thing to do that provides no gain or negative impact either way.
2. I have simply always gone with putting hard edges where angles are less than 90 degrees, and split your UVs there, is this bad technique? (I believe racer445 discussed this technique but apparently its out of date).
The whole "90 degree" or trying to come up with rules thing is just counter productive. Its more important to think critically, take into account your pipeline(sync'd or not?), do test bakes, and set up your geometry, uvs, and mesh normals(hard edges/sgs) accordingly. I would never tell someone "Set all your 90 degree edges to hard" as that is useless as far as teaching someone what the problem is. Once you understand the root of the problems, you'll know exactly what to do and wont need someone else to give you a set of rules to "get a good bake".
3. What I've learnt (correct me if I'm wrong). It a safe option to just use 1 smoothing group (so long as your cage is correct). Cut your UVs where you would have hard edges on your model. Add some smoothing groups if you have SEVERE triangle shading.
Now we're getting subjective, see this is something I dont have any desire to discuss. I'm not going to argue if minor smoothing errors are bad or not, or what is minor and what is extreme. If I'm spending 3-4 days on a highres mesh, only to have the end result look like crap because of smoothing errors(minor or extreme) i'm not going to be happy. When it comes to hard surface mechanical objects, even very minor smoothing errors can totally mess up specular/reflection.
So.... If it looks ok to you don't bother? I mean thats something you decide for yourself isn't it?
I've noticed some people ask the same question numerous times, and I'm pretty sure I'm one of those, but hopefully you won't mind answering :P.
Don't worry, you're not the first or last person to annoy me by asking the same questions. =P
Thanks EQ that was a good read and almost completely sums everything up.
What's weird is I always looked back at my old school bakes in Maya (I now use Max) and have thought, damn I was better at baking back then haha.
So it's all about what is synched. Because back then I would just throw everything into 1 SG, nowadays in max I think I'm pro by using multiple and that I was noob before >_>.
So when you did work for Brink, or for any other game, do you test how their engine handles normals prior to production? Or do you just go with what looks good with say the 3ps?
How do I know if I'm "Synced" with my game engine, Ie Max/CE3 or Maya/CE3, is there no tricks but to just play with if you need SG or not and do a load of test bakes?
Thanks EQ that was a good read and almost completely sums everything up.
What's weird is I always looked back at my old school bakes in Maya (I now use Max) and have thought, damn I was better at baking back then haha.
So it's all about what is synched. Because back then I would just throw everything into 1 SG, nowadays in max I think I'm pro by using multiple and that I was noob before >_>.
Well Maya's viewport(HQ mode) dispaly is perfectly synced with maya's baker. So by default, if you're just viewing in maya, you will get perfact(as perfect as is possible) bakes without doing much work.
So when you did work for Brink, or for any other game, do you test how their engine handles normals prior to production? Or do you just go with what looks good with say the 3ps?
How do I know if I'm "Synced" with my game engine, Ie Max/CE3 or Maya/CE3, is there no tricks but to just play with if you need SG or not and do a load of test bakes?
For Brink specifically, we were told that the engine was Synced to maya, so we used maya for all of our baking, and what looked good in maya looked good in the game. Splash Damage has some pretty smart guys, so they had a very polished workflow in place.
Generally, most game engines aren't synced up to anything, so you'll have to hack it up to get good results. Hopefully in the future more developers are going to start noticing this, and sync up with Max or Maya.
So yeah, you just need to do a lot of test bakes. I do a lot of test bakes when i'm doing a complex asset, to check for things like:
A. To make sure I have enough geometry so the model doesn't look jagged/lowpoly, and to avoid excessive waviness(generally goes hand in hand).
B. To make sure I have supporting geometry to avoid skewed floaters and detail
C. To check for resolution issues, IE: make sure I have enough resolution for details to show up, and then tweak the low or high accordingly if I dont.
D. For smoothing errors etc.
Can you make two different low polys, one that you bake off (with fixed edges and so forth) and then one that you apply the normal map to that is lower polygons with hard edges. Would that work? :P
Can you make two different low polys, one that you bake off (with fixed edges and so forth) and then one that you apply the normal map to that is lower polygons with hard edges. Would that work? :P
Can you make two different low polys, one that you bake off (with fixed edges and so forth) and then one that you apply the normal map to that is lower polygons with hard edges. Would that work? :P
This.
If you bake a map from one mesh and then apply that map to a mesh with different vertex normals, it would be compensating for vertices that no longer exist and wouldn't light correctly. It would only work in very specific circumstances.
This.
If you bake a map from one mesh and then apply that map to a mesh with different vertex normals, it would be compensating for vertices that no longer exist and wouldn't light correctly. It would only work in very specific circumstances.
Thanks for the answer! I was just wondering what would happen.
Replies
Mine weren't looking alright. Everything set to 1 smoothing group lead to huge gradients over flat surfaces, which looked crappy using viewport shaders.
If your models are organic or higher poly, without flatter areas, that become less visible. But in my case, I had to split the low poly in many different smoothing groups, as if it was supposed to be vertex lit in an older engine. Worked fine in the end.
But yeah, if you can get away with 1 smoothing group, just do it and be glad that it works!
The only reason you would want to use smoothing groups is if the tangent basis of the baker doesn't match the engine that you are rendering the final model with.
The colours and gradients in the normal map are there to represent the differences between the low and high poly models and if the tangent basis doesn't match then these colours and gradients cant be translated accurately into correct lighting, which is why you can get the smoothing errors (which are simply the visual difference between the tangent basis of the baked map and the renderer)
Adding smoothing groups reduces the gradients and in doing so, also reduces the errors because there is less chance of an incorrect translation happening as the areas with smoothing groups tend to be flatter and resulting values tend to be much closer to 128,128,255 (in addition to other factors)
In xNormal, you always want to bake using the final low poly model with it's normals intact (as exported) as averaging the normals in xNormal is different to the averaged cage that EQ is talking about. If you are averaging the normals in xNormal and then using that bake on a mesh with different normals, then the bake wont match the LP mesh, which will cause errors.
Exported normals Vs Av. Normals in Marmoset (on the exported normals LP)
Averaged normals
Exported normals
Difference map
xNormal requires that the topology of the cage matches the LP mesh 100% and doesn't have an averaged cage, so using it's inbuilt cage feature doesn't work because when the cage is expanded, gaps are also expanded.
The only work around i have found is to make a duplicate of the LP mesh for use as an external cage and then apply the smoothing groups after the cage has been expanded in your 3d application, which seems to reduce any gaps in the bake so that they are pretty much non existent.
Hope that helps and sorry for all the pics!
http://dl.dropbox.com/u/2057427/Polycount/PC_SG_Test.zip
The thing is that I've been keeping it all at one smoothing group in Max, so the normals are the same for baking in xNormal. The thing I'm not doing is breaking my models into smoothing groups, at all. I've been putting them all to 1, importing into xNormal and baking with the distance rays.
I get exactly how a cage is important (at least I do now), but for all my work so far there haven't been issues. My question is that if my smoothing groups are always set to averaged across applications, why should it matter or why should I bother with smoothing groups.
I've read a bit about using hard edges and an averaged cage, but what difference does it make from smooth edges and an averaged cage?
Maybe you've answered this but if so it's gone over my head, so sorry for my ignorance and thanks for all the help!
The cages Max and xNormal work differently because xNormal doesn't use averaged cages, but if you are only using 1 smoothing group then it doesn't matter because there are no breaks in the meshes normals and therefore, no gaps to worry about.
As EQ said, with an averaged cage in Max, there is no difference in using a model with smoothing groups or no smoothing groups because the cage ignores the normals anyway
[edit] NM I see his "control" comment below and yeah, agree with per here, if you've gotta do any custom cage work, you should really be looking to fix your mesh, not your cage. Tweaking cages needs to be redone any time you change your mesh, so its really just a bad idea.
Now as far as SG's, yeah there really is no reason NOT to use smoothing groups. Use a quick script to set all your uv borders as hard edges/SG in Max or Maya, there is absolutely no drawback to performance to do this, no matter if you're using a synced display or not. The only drawback is that you have to actually use the proper cage, but really, being able to visibly see the cage as apposed to guessing a ray distance value is a much easier way to work anyway.
I would like to explain myself a little better as perhaps my wording wasn't super awesome.
By this I meant that you can run into issues like projection problems when using the minimum/maximum uniform ray distances on things that are close together and cant be exploded, such as fingers for example. Perhaps accurate wasn't the best terminology
You can use things like blockers, but i always find it easier to use a cage. I still use uniform projection for things like textures though.
I 100% agree on the smoothing groups comment though. There is no reason not to use them on SG splits (i actually released a Blender 2.5 script for this a few days ago ^^) but as i don't use Max or Maya, i cant really comment on the use qualified normals for them
Also, I 100% agree on the pros. of using smoothing groups for texturing reasons too.
With Blender, xNormal and Marmoset there are a couple of very small errors with the mesh above (top corner) but nothing really major.
xNormal baked Normal in Marmoset (single SG)
xNormal baked Normal (single SG)
I made the test mesh above to see how well Blender could handle single smoothing groups with its internal renderer and baker, since they have recently implemented a new tangent basis it seems they did a really good job in getting everything synced up (GLSL viewport shader, Baker and the Rendering engine)
Top row is HP, bottom is LP (single SG)
Blender baked Normal (single SG)
@EQ,
Just noticed your post!
Yea, you pretty much hit the nail on the head with what i was trying to say
Thanks for the translation!
I'm trying to understand this stuff as thoroughly as possible, but I think I'm still missing some things. Sorry if it's already been explained and I missed it.
Does it matter if you use one smoothing as opposed to multiple smoothing groups with UV splits? Is it a matter or personal preference, or are there specific instances when each method would be better suited?
I've been talking to oniram about his recent SMG, where he baked with one smoothing group and ended up with great results. I then tried it with a recent model I worked on and ended up with worse results than I got from using smoothing groups with UV splits.
Well the real question you need to ask is why would you ever need to avoid using smoothing groups/hard edges? If you can come up with the answer for this question, it should be apparent.
If we're using a proper averaged cage(as has been covered here extensively) there will be visual no gain to using 1 smoothing group. On the technical side, your vertex's are already being double along your UV borders, so using hard edges there adds zero performance loss. So why this obsessive need to worry about having only 1 SG?
This whole thing comes from some programmer telling someone 1 SG is better, back in like 2001 or whatever, and everyone repeating that advice. But really, the conclusion is that using hard edges/smoothing groups along your uv boarders will never be a bad thing.
Now, a few good reasons TO use hard edges on your uv borders:
1. If your engine isn't synced, it can significantly reduce smoothing errors.
2. Even if your engine is synced, it can avoid artifacts related to texture resolution. EI: your triangle is too small and the require gradiant needed to counter the smoothing is impossible to record in your normal map.
3. Extracting "detail maps" from crazybump or xnormal is a more straight forward process, you worry less about artifacts from extreme gradiation.
4. Texture compression generally is going to produce better results with less gradiation.
So yeah, the question shouldn't be which is better when, it should be why would I ever want to use 1SG?
Now a lot of people, upon hearing this ask me: "Why do I care about synced normals then?" Well, the answer is relatively simple.
Even if you're using hard edges, your end result can be significantly better with synced normals(3ps Quality mode, Maya, etc), so much so that you can even take old models, baked with hard edges etc and simply turn the feature on and see a notable improvement.
When you have synced normals, you can also simply worry much less about uvs and hard edges. Without sync'd normals, you may need to use a lot more hard edges and split UV islands to get a bake without any smoothing errors. Generally with a sync'd workflow, you can simply model naturally, not worry about excessive bevels, or excessive hard edges/uv splits, just model in a sensible manner and use a script to add hard edges where your natural UVs seams are to ensure an even higher level of quality, and you're good to go.
Hoever, this boils down to a matter of Sync'd or no, not 1 SG or no.
On a complex mesh, you could see 2-3x the vertex count(either with excessive beveling, or excessive hard edges) to get the same results with a sync'd bake.
I don't mean custom cage work
By control, I meant that using using uniform ray distance/offset is much more of a guessing game than using a standard non tweaked cage and the results can often leave something to be desired.
When making a cage I just use use Blenders equivalent of the push modifier with no other edits.:)
How is it enabled in xNormal?
Ahh right, I see what you mean. I have always viewed these a totally separate ray casting methods, so I can see what you are getting at now.
Blender uses Distance and Bias settings with numerical input in which you set the maximum distance from the active object to the target with the bias allowing you to set a preference to objects that are further away. Most of the time it seems to get nice results, but its not super intuitive (initially, at least :P).
I do all my baking xNormal though, as it generally provides more detailed results.
Ok awesome
My only issue is that when I use the max/min ray distance in xNormal, it often bakes incorrectly and breaks the edges, but this doesn't happen when I use a cage (non tweaked) in xNormal. Any ideas why this is happening? Maybe the sample based on surface direction setting you talked about will fix it?
Thanks for the detailed post Perna. Always appreciated
Sounds like "Discard back-faces hits" to me.
Maybe. I always have this checked and I still get bad results though
Can someone post a script for 3ds Max (2012) which allows me to apply hard edges on UV seams?
In Xnormal, when you're just using the ray distance, it uses the vertex normals of your lowpoly mesh, so you get gaps along your hard edges.
In max, if you use the "offset" method, it does the same thing.
So to me, when I say cage, I mean a proper averaged cage, not a simple ray distance. I don't mean a manually tweaked cage, just a proper averaged cage. But thats getting a bit semantical, I don't think we need two different terms for if you've manually tweaked your cage or not. You've got an averaged cage, or you've got a distance based raycast from your lowpoly mesh normals, these are the important things to identify. To me, using a cage certainly doesn't mean you're going in there and tweaking it to avoid errors and things like that, its differntiating between the two obvious methods that the software gives you.
It is all a "cage" in a sense, but I think Per's explanation of terminology is a bit confusing there.
In max, you have:
A. Offset Method
B. Cage
In Xnormal:
A. Ray distance
B. Cage
In Maya:
A. Surface normals
B. Geometry normals(averaged)
Anyway, these are the important things to understand, "offset" in max will cause gaps, ray distance in xnormal will cause gaps, surface normals in Maya will cause gaps.
Weather or not you're manually tweaking your cage has no bearing on the technique used to project, and that is the important factor here, that you're using a proper averaged cage.
In most apps, what is presented to the user is; you're either using the cage or you're not, and that, to the user, is what causes or solves the hard edge gap problem, its the most basic and simple way to refer to it. You should be using the cage, not the basic ray distance. We can talk about the technical side behind it etc, but the user isn't seeing that, so its not particularly relevant.
So to say "Are you using a cage or a ray distance?" is a good question to ask, as almost everyone will have some basic understanding here.
In a sense, Maya operates on the User level the closest to what Per is explaining, its all just a ray distance, and you have a choice between averaged normals on the projection "envelope"(what maya calls it lol) or using the lowpoly vertex normals.
In max its more complex and much less ambiguous, as the two methods not only have completely different UIs, but have different behavior as well. In max tweaking the cage will affect normal direction as well as distance, in maya it will only effect distance. XN is the same as max in this regard as well, a completely different interface and behavior for using a "cage" or not.
Muchas gracias
Ahh right. That makes sense. It's basically what I thought when I made my initial reply, but was confused a little by what Perna was saying. Thanks for the clarification
From your explanation, it also looks like Blender uses the same Geometry normals(averaged) method as Maya as there are never seams or broken edges when everything is set up correctly.
Awesome. Thanks for the very detailed clarification. I think what is basically come down to, is a clash in terminology between Perna and myself. I have always used the Cage vs Ray distance to mean a non tweaked cage vs offset in Max.
It's great to get a good flowing discussion when things like this happen as it's always nice to be able to learn something about how everything works on a much finer level. I love this type of stuff
Thanks again EQ and Perna for the great info in the thread
I just try to stick with how people commonly refer to this stuff, so the noobs can understand it.
If max/XN finally get around to fixing the gap problem, there wont really be any need to make the differentiation between cage and not, but until that actually happens, there is a need to talk about the differences.
In addition to that, I'm simply using max terminology, for instance whenever you are doing a bake in max, and you're using the projection modifier you're tweaking the cage. Literally the "cage" parameters in the projection modifier. Weather you're tweaking it by hand or with numeric values, you're changing variables that relate to the cage. So to tell someone you're "not" using the cage, when he's tweaking the cage parameters gets very confusing.
For clarity it would be good to have some sort of standardized terms for everyone to understand though. "Cage" is sort of a taboo word, as it relates to very specific functions in max.
Regardless of all the terminology, the important things to note are:
A. Your projection mesh should be averaged and thus gap-less.
B. You shouldn't need to spend time tweaking your projection mesh by hand.
There, I didn't say cage. Do I get a prize?
Its a "Who's on first" problem though, in max.
Q: Should I use the cage?
A: No you shouldn't use the cage
Q: Oh so I should use the offset method?
A: No you need to use an averaged projection mesh.
Q Oh, so I should use the cage?
infinite loop
This is just as future proof, but doesn't rely on a term that already means specific things to some people, and apparently different things to others.
Very specifically, when you go in to bake a normal map in max, you use the projection modifier, and tweak the cage either with a numeric value or by hand, both are quite distinctly the "cage" just using different methods to adjust the parameters of the cage. So to say one is a "cage" and the other isn't, this to me is very confusing. However both will result in an averaged projection mesh. The difference here is actually a workflow difference, not a technique/implementation difference.
To visualize:
So, to say one is the cage, and one isn't is just confusing, from a max perspective.
This is not true, from what I understand. If you're just using the offset method with a numeric value locked in, you don't have to do anything, this is just like the ray distance in XN, you can edit your mesh or whatever without resetting anything. Quite possible to bake like that, its just a bad idea for various reasons like gaps etc. However, people DO bake this way.
Again, to illustrate:
Baking without using the cage. Not at all impossible.
It will be a shame though, as its great for baking tileable textures.
Doom Baker? Are you referring to the baking tools with Doom 3 or is this a separate program?
Also which features are you referring to that have not been copied? If there is something amazing that we have been missing out on, I would love to know
Some features i miss in either xNormal or 3dsmax are for example the ability to chose a bump map to bake into the low(i know that you can apply it in the material editor, but thats just a hassle if you just need it for baking) or choosing the normal closer to the low poly if the high and low poly are equidistant.
Well yeah, me and you understand that, but this thread isn't for us. Its for all the people who use these totally backwards/broken workflows still. =D
But only in xNormal or am i really that blind?
I'm not sure about Max because I don't use it, but its definitely in xNormal. You just have to make sure the aspect ratio of the detail image matches that of the final bake and you are good to go
Thanks to everyone contributing to this thread with either questions or answers. I haven't been able to read it all with strict attention.
I just finished making some normal maps that required alot of thinking and researching from me(hence founding the thread) so I would like to drop here some interrogations and statement, in hope of feedback. "It's a hit me if I'm wrong kind of post"
Questions:
What does a cage do exactly?
-It seems to me that it allows one to set different ray distance along the model.
-It seems to me that it will in a way override direction given by vertex normals, since now at each vertex the baking direction will be pointing to the cage.
So if i use a cage and set in xNormal Hardened or Average, these will simply do the in betweens of what the cage.
Why do you show this image? What is the influence of the cage normals, in the baking process? What is the issue with unwelded cages? It seems to me that cages can be faceted and unwelded as long as the direction that each point makes with it's corresponding point in the base mesh it's a good direction.
Statements Taking risks here..
Because I was baking everything with Averaged Normals, the 2 main issues I've found were Waviness on Cylinders and Roundness on Flat Areas. They got me to the Hard or Smooth Edges crossroad:
-Hard- give me good bakes for the contours and good flat areas. But it has gaps and the low poly geometry becomes more apparent
-Smooth- give me smooth transitions and a better illusion of detail, but flat areas wont be flat and but the will get roundish flat areas and waviness roughly like this:
-I get the waviness on the side (High contains Low)
-I get the Waviness on the cap (Low contains High)
The best results I found for my work so far were:
- Use Hard edges on convex transitions because I will see the contour angle , so it's best that my texture fills up to model contours. And also, whats flat, will be flat.
- Use Smooth edges on on concave transitions because I will not see the contours, but the interior, so smooth transitions won't look faceted. Waviness won't be a much of problem here.
This is how I got away with my model.
But ok I got Gaping going on on those hard edges.
There were 4 ways I saw one could solve baking hard sharp edges:
- Vertex Normal Map, Smoothing Group
- Unweld Mesh
- Edges Inset, Control Loops.
- Bevel
The First 2 are quite alike, they basily have the same Normals, geomtery remains the same. Unweld has the benefit of matching the cage better.
Edge Inset will add geometty on each side of the edges, isolating the flat areas from the smoothing transition in the rim. This way has it's problems because from many angles the rims will seem to shine or smoothing badly (thing triangulation)
Bevel will make nice smooth trasitions, it will add a few geometry, will require a new UV map and, the flat areas are not perfectly flat.
So i began to think I could overcome the Gap.
Untested, but this seems to be one solution. Requires a lot of work, i guess. Making Edge Insets is not fun, especially if one is past the UV step.
Uff big post, sorry.
Cheers
You can have hard edges on your lowpoly
BUT your projection mesh needs to be averaged, to avoid gaps. Its been outlined a few times how to do this in various apps so I wont write it up again, but this is the important bit.
Here is a clear example:
The lowpoly mesh normals are the same on both A and B.
BUT, the cage is averaged on A, and using the lowpoly mesh normals on B.
When you understand this, the rest of your issues on the matter aren't really relevant, there isn't a need to do anything extra like add additional geometry etc.
I understand what you mean with your post. Altough I get a bit confused about your use of the term "Averaged", since you are talking about the Cage and it's normals have no account in the baking process. I guess you mean Welded, which will average the projection on the LP.
My problem with an Averaged projection is that I get Waviness on cylinders.
The attachment (feet of the model I'm working now) shows the model with Averaged cage and Unwelded cage on that cylindrical area:
- While waviness does help to get the 'round look' on a lowpoly cylinder, when your point of view is different than the cage projection, it will suck!!
Having Faceted look also sucks, but less than waviness.
Since that part of the model is the feet. It will be seen mostly from above, so the top upper part of the side of the Cylinder will actually benefit from the waviness and I will keep the Average projection, but the bottom I will Unweld the cage there and make the projection strictly horizontal, so I'll get faceting but no waviness.
Of course you can say my low-poly sucks and it should have more geometry, I would probably agree with you, but right now I'm not gonna redo it =P
Still having some issued with the "wireframe" showing up not only on hard edges but sometimes on smooth edges. Probably something wrong with the difference of how I bake and how I render.
Cheers
Yeah if you're not willing to adjust your model there isn't any advice I can give you, I wrote up a big thread here on how to avoid waviness in the first place, there are a variety of hacks you can do to try to fix it after the fact, but they all suck.
Your lowpoly mesh normals will be ignored if the your projection mesh normals are averaged, there isn't a situation where your projection mesh normals would be ignored, the projection mesh normals are what dictate the normal direction used for ray-tracing the normal map.
Yeah if you're not willing to adjust your model there isn't any advice I can give you, I wrote up a big thread here on how to avoid waviness in the first place, there are a variety of hacks you can do to try to fix it after the fact, but they all suck.
I downloaded the files you posted a few weeks ago, I have been having problems with seams a long my hard edges for a few weeks now I have not been able to figure out why.
Now I downloaded your test HP, LP and Cage and baked it in XNormal yet for some reason the normal map is different to yours with the seams being a lot more visible, this is the problem I have on pretty much every hard edge I try and bake.
I baked the the maps at 1024x1024 with 16 edge padding, yet no matter what I change the edge padding value to nothing seems to make a difference.
Here are some example screenshots below:
http://dl.dropbox.com/u/26084016/MyBake.jpg - My baked normal map applied
http://dl.dropbox.com/u/26084016/YourBake.jpg - Your normal map that was supplied with the .obj's
Second view of the model
http://dl.dropbox.com/u/26084016/MyBake2.jpg - Mine
http://dl.dropbox.com/u/26084016/YourBake2.jpg - Yours
I have have no idea what so ever what is causing such a difference in end result, I used the exact files you supplied not editing them at all, high poly in the high slot, low in the low slot, with the cage in the cage slot on the low.
So could somebody please give some insight into what is going on :poly142:
It could be a number of things really.
I Just baked the files I uploaded again, and came up with the same results as posted a few pages back, so it should work
Just re-baked it and it came out identical to yours, cheers for that, I can now get back to working on stuff without having to worry why my hard edges always looked so terrible.
It appears you can get away with everything in one smoothing group, as long as your UV islands align with where you would have hard edges on your model.
Couple questions regarding this:
1. EQ - you say you have a script that sets all your uv borders as hard edged in maya. Doesn't that put hard edges on areas sometimes where you would want smooth edges? (ie the bevel at the end of a cylinder? or a cylinder itself where an unwrap would cause a seam running along it?)
2. I have simply always gone with putting hard edges where angles are less than 90 degrees, and split your UVs there, is this bad technique? (I believe racer445 discussed this technique but apparently its out of date).
3. What I've learnt (correct me if I'm wrong). It a safe option to just use 1 smoothing group (so long as your cage is correct). Cut your UVs where you would have hard edges on your model. Add some smoothing groups if you have SEVERE triangle shading.
I've noticed some people ask the same question numerous times, and I'm pretty sure I'm one of those, but hopefully you won't mind answering :P.
I'm not sure where you're getting that from this thread;
A. Smoothing groups or not, will have no effect on your bake(as far as projection goes, seams etc) if you've got a properly set up averaged projection mesh.
B. Whether or not you can get away with 1SG is very specific to how your renderer and baker are sync'd up, if your baker and render are NOT sync'd you can almost certainly NOT get away with 1SG.
C The relevance of UV is when you're using hard edges/smoothing groups. If your entire mesh is smoothed, your uvs have no relevance.
Yes, you will end up with hard edges in "illogical" areas, however with a properly averaged projection mesh, and a sync'd up baking workflow, this has absolutely zero effect on the end result of your bake. Even a hard edge on the seam of a cylinder like you said, that if you were doing it by hand you would always make sure it was soft, its of no concern. Virtually all of my guns for Brink have areas like this, but you'd never know without looking at the untextured mesh.
If you want to go back and soften up a few edges after you run the script, by all means go for it, but its sort of an obsessive compulsive thing to do that provides no gain or negative impact either way.
The whole "90 degree" or trying to come up with rules thing is just counter productive. Its more important to think critically, take into account your pipeline(sync'd or not?), do test bakes, and set up your geometry, uvs, and mesh normals(hard edges/sgs) accordingly. I would never tell someone "Set all your 90 degree edges to hard" as that is useless as far as teaching someone what the problem is. Once you understand the root of the problems, you'll know exactly what to do and wont need someone else to give you a set of rules to "get a good bake".
Now we're getting subjective, see this is something I dont have any desire to discuss. I'm not going to argue if minor smoothing errors are bad or not, or what is minor and what is extreme. If I'm spending 3-4 days on a highres mesh, only to have the end result look like crap because of smoothing errors(minor or extreme) i'm not going to be happy. When it comes to hard surface mechanical objects, even very minor smoothing errors can totally mess up specular/reflection.
So.... If it looks ok to you don't bother? I mean thats something you decide for yourself isn't it?
Don't worry, you're not the first or last person to annoy me by asking the same questions. =P
What's weird is I always looked back at my old school bakes in Maya (I now use Max) and have thought, damn I was better at baking back then haha.
So it's all about what is synched. Because back then I would just throw everything into 1 SG, nowadays in max I think I'm pro by using multiple and that I was noob before >_>.
So when you did work for Brink, or for any other game, do you test how their engine handles normals prior to production? Or do you just go with what looks good with say the 3ps?
How do I know if I'm "Synced" with my game engine, Ie Max/CE3 or Maya/CE3, is there no tricks but to just play with if you need SG or not and do a load of test bakes?
Thanks you, you're a geeeeenius
Well Maya's viewport(HQ mode) dispaly is perfectly synced with maya's baker. So by default, if you're just viewing in maya, you will get perfact(as perfect as is possible) bakes without doing much work.
For Brink specifically, we were told that the engine was Synced to maya, so we used maya for all of our baking, and what looked good in maya looked good in the game. Splash Damage has some pretty smart guys, so they had a very polished workflow in place.
Generally, most game engines aren't synced up to anything, so you'll have to hack it up to get good results. Hopefully in the future more developers are going to start noticing this, and sync up with Max or Maya.
So yeah, you just need to do a lot of test bakes. I do a lot of test bakes when i'm doing a complex asset, to check for things like:
A. To make sure I have enough geometry so the model doesn't look jagged/lowpoly, and to avoid excessive waviness(generally goes hand in hand).
B. To make sure I have supporting geometry to avoid skewed floaters and detail
C. To check for resolution issues, IE: make sure I have enough resolution for details to show up, and then tweak the low or high accordingly if I dont.
D. For smoothing errors etc.
Don´t do that...ever
If you bake a map from one mesh and then apply that map to a mesh with different vertex normals, it would be compensating for vertices that no longer exist and wouldn't light correctly. It would only work in very specific circumstances.
I did some tests:
The file:
3ds max 2011:
http://db.tt/r4g8ELe2
My bad and thanks!
Offtopic:
Does anyone know what to do when "shaded" in projection mapping - cage does not work - how to fix?