If you are not crossing poly budget then add more polys. It is fine to have some more polys than to have artifacts, it should serve some purpose and should be justified.
Or what you can do is create a mid poly bake textures on that and then apply those baked textures to low poly.
Thanks for that Much appreciated. Will try the 2nd method first to see if it fixes the issue. It's only for a port folio piece so no hard poly limit.
Help me out here on using bevels vs. subdivision surface to create high poly. The TL;DR of my problem is that I generally find the bevel method to work best, but you can't really add sculpted detail if you go that way.
So here is my low poly model, which has straight and curved segments.
Method 1 of creating high poly: subdivision surface. You get a much smoother curve, but this can result in waviness when baking normal maps.
Method 2 of creating high poly: bevels. This way you preserve the silhouette of the low poly model, which makes baking normals a breeze.
The problem I'm having with the latter method of creating high poly, is that it basically becomes impossible to sculpt on additional detail. If you add geometry to the mesh, you lose the smooth curve of the normals.
So do I just need to suck it up and deal with subdiv and potential wavy normal maps? Is there another way to go about this?
Maybe I'm missing something you are saying here, but generally wavy normal maps come from the low poly not having enough sides to accurately represent the curvature of the high poly surface rather than being an issue with the high poly itself. If you add more sides to the large curved part of the low poly, so it better matches the high poly, then the waviness will be reduced.
You also probably want to add bevels to the low poly too so it bakes down better rather than having a bunch of 90 degree angles.
I think maybe you are trying to match the silhouette of the high poly to the silhouette of the low poly, where really it should be the other way around. The high poly is de facto source of detail for the bakes so you should aim for the the low poly to better match the high poly rather than vise-versa.
I mean the only way to get the silhouette to match perfectly is for it to have as many radial segments, which isn't practically.
Maybe I could really up the poly though. Is there one of those spreadsheets for polygon limits for 2018 or 2017? For all I know I'm being way to conservative with my geometry in general here.
Sure, you are never going to get a perfect wave free bake without matching the side counts, but it's worth remembering that while waviness can sometimes be a little unsightly on bakes, it is not an error per se, but rather a
natural result of the bake that is view dependent (the
waviness only appears at certain angles when the model is viewed in 3d).
The question needed to be asked is how much does reducing the waviness matter in the
context of what you are doing?
How close will the asset be to the
camera?
Is it for a FPS or third person game?
How reflective will the
final textured asset be?
It's always very hard to answer the "How many tris for this mesh?" question as in production such answers are dictated by more factors than a simple mesh in isolation. The most important thing is that you add enough geometry to
support the shape of the mesh you are building without being wasteful. That being said, for a pure portfolio piece your tricount is less
restrained by external factors so you can afford to make it heavier than
you would in a game, without making it so heavy as to be unrealistic.
Probably the best thing you can do to get an idea of a rough production tricount is to take a look around Polycount or Artstation for art dumps that show similar assets and find a decent average for something close to what you are currently doing. For an FPS something like a barrel might have 24 sides but a rifle scope
might have a similar amount (or more) even though it is much smaller in
size because it is closer to the camera.
All you can really do is make an informed decision to increase the side count until you feel that the waviness is reduced to an acceptable level for the asset in question while taking into consideration your specific set of circumstances.
Probably not the answer you were looking for, but I hope it helps somewhat
Nah that helps, actually. This is purely portfolio stuff I'm working on (or if I'm being more honest practice for later portfolio stuff). I'll have to experiment with different numbers of sides to the curved bits.
When the model doesn't have curves I find that right angled boxes don't look bad at all with their baked normals. Hopefully I can get something similar enough.
The reason I suggested bevels is because when you zoom out sharp 90 angles tend to alias badly & bevels are free in terms of vertex cost (assuming that you are replacing two adjacent smoothing groups or a single hard edge between two faces) as in such cases the vertices are already already created in both 2D & 3D space.
Comparing 2 cube meshes is probably the easiest way for you to see this. Bevel all the border edges on one and and add smoothing groups/hard edges to all border edges on the other and you will notice that both cubes will have the same vertex count, even though the triangle count is higher on the cube with the bevels.
@metalliandy yes, they will have the same amount of vertices as long as your beveled cube don't unwrapped. If you start to add UV seams it doubles vertices that being cut. And in this case regular cube with hard edges and UV will have less vertices, coz if you make UV seams on hard edge it won't double it again, coz hard edge already did
@Ask Oops, yes. You are of course correct. Assuming the unwrap is sensible the increased vertex perf cost should be pretty negligible really as vertex counts are no longer the bottle neck they once were (unless the target platform is mobile or something) especially when the increased fidelity is taken into account. Of the top of my head, in the case of a cube it's probably something like 6 extra verts generated in UV space (from 24 to 30). It also depends on the geometry being bevelled too. It might be an interesting exercise to see what the average increase is for some basic shapes is and then find an average. Will do that later if I remember.
As I understand it, if you've got a UV seam it costs nothing to also make that a hard edge. I've never really understood the bevel workflow, so hopefully you can help me out with this. When you put in a single segment bevel, you end up with the normals still smooth over the whole surface, which the normal map then has to correct.
I imagine I would cut the left shape up and the bevel would end up with one or the other primary faces in each case. But isn't this making the normal map do a lot of corrective work that could potentially lead to artifacts?
The other reason that I like the 90° angles with hard edges is that as long as the surface is completely planar, I can put as much or as little geometry on it and it renders the same. It lets me work with the geometry on the right when making the model. That lets me cage-bake without any surface details being distorted in any way, because except for at the edges, the rays from low poly to cage are orthogonal to the surface of the plane. I can get rid of all that geometry at the very end and have a super low poly model.
@Rekov Look into face weighted normals. I've seen it available for Blender but I don't know the specifics. For reference, here's the same topology in Maya, but with weighted normals. Here my large faces have perpendicular normals, which puts more "strain" onto the smaller faces, but generally we're less concerned about the smaller areas. If my high poly had much more rounded edges, the bake would come out much cleaner.
Yeah face-weighted normals would seem to solve that problem. Do those get retained when exporting to obj or fbx or whatever? Do game engines (Unreal, Unity) need anything special to account for them, or is all of that information retained in the model itself, and the game just processes it normally?
Yeah face-weighted normals would seem to solve that problem. Do those get retained when exporting to obj or fbx or whatever? Do game engines (Unreal, Unity) need anything special to account for them, or is all of that information retained in the model itself, and the game just processes it normally?
Yep, normals get exported and read pretty much universally, just check your export options- sometimes it's a special option.
As I understand it, if you've got a UV seam it costs nothing to also make that a hard edge.
Yes, that's correct. This is because the extra vertices needed to generate the hard edge have already been created in UV space. If you create a hard edge in 3d space however, you have to split the UVs in order to get a correct bake at the same location which costs extra.
I've never really understood the bevel workflow, so hopefully you can help me out with this. When you put in a single segment bevel, you end up with the normals still smooth over the whole surface, which the normal map then has to correct.
I imagine I would cut the left shape up and the bevel would end up with one or the other primary faces in each case. But isn't this making the normal map do a lot of corrective work that could potentially lead to artifacts?
Yes, the normal map would have to do more work, but in reality this is rarely a problem by itself any more as most engines and bakers are synced via the use of MikkTSpace and such errors are usually down to a sync mismatch. With a fully synced workflow you can bake everything with one smoothing group (no hard edges at all) and it would show up perfectly in your engine. That said, this isn't always desirable it can sometimes accentuate other issues not related to normal map sync such as banding if you are working with hard surface objects that are very reflective.
I find that usually the best workflow is to not worry about hard edges until the last minute (pre-bake) and just set them to whatever your UV borders are once everything is unwrapped. This generally strikes a good middle ground as it reduces the heavy lifting on the normal maps side, which in turn, causes fewer issues with compression and banding, but also allows you to get a sensible and efficient unwrap without worrying about packing a bunch of faces because you set them to be hard.
The other reason that I like the 90° angles with hard edges is that as long as the surface is completely planar, I can put as much or as little geometry on it and it renders the same. It lets me work with the geometry on the right when making the model. That lets me cage-bake without any surface details being distorted in any way, because except for at the edges, the rays from low poly to cage are orthogonal to the surface of the plane. I can get rid of all that geometry at the very end and have a super low poly model.
This is generally something that you want to avoid when baking directly to tangent space. Any time you alter the underlying geometry of an already baked mesh, it breaks the associated tangent space normal map. I totally understand the workflow and get why you want to do it, but in order for it to work correctly you need to bake to object space with the extra geometry> remove the loops> convert the previously baked object space normal map to tangent space using the mesh with the removed loops.
This is generally something that you want to avoid when baking directly to tangent space. Any time you alter the underlying geometry of an already baked mesh, it breaks the associated tangent space normal map. I totally understand the workflow and get why you want to do it, but in order for it to work correctly you need to bake to object space with the extra geometry> remove the loops> convert the previously baked object space normal map to tangent space using the mesh with the removed loops.
I'm not sure this is true in the situation where you're only dealing with extra geometry on totally planar faces separated as their own smoothing groups. The extra geometry in that specific case doesn't affect the normals that you're baking to, so the tangent space normal map produces the same result.
I get what you're saying though and it's clearly a limiting constraint best avoided. I'll play around with weighted normals, because that seems like a huge game changer in general, and if it allows for cheap and effective bevels that reduces waviness on curved segments all the better.
It's true in all cases as long as the cage isn't split. Any time you are using a proper averaged cage the vertices of said cage set to all smooth (no double verts) so there are no gaps in the projection & you add loops to control that projection in order to stop skewing. If adding geometry didn't change the result of the bake then you wouldn't bother adding it right? Adding loops must change the vertex normals of the low poly or it wouldn't control the skew and removing them also change those same vertex normals.
Added to that is the problem with triangulation. When you remove the loops, the mesh will probably triangulate differently which increases the error present, so you are fighting that in addition to different vertex normals.
My point is that baked tangent space normal maps are geometry specific by their nature. They are mathematical values encoded in the form of a texture and you cant edit the TS normal map in something like Photoshop or remove faces from the low poly bake mesh without changing the values needed to be decoded correctly. The error is still present even if you cant see it easily, and unfortunately that includes the simple box case you posted earlier.
It sucks, I know, but thems the breaks.
The only correct way is to convert an OS normal map to TS using the new geometry or use something like ndo to paint image space normals directly
It could be that I'm just not conveying what I mean very well here since this is new to me, so this is an example of what I'm talking about. The extra geometryisn't changing the vertex normals of the low poly model in terms of the shading because they are on a plane that is cut off by split edges. I'm essentially just using the extra geometry to to affect the cage, and the resulting rays for the bake, not the shading on the low poly model itself.
Here are the high poly boxes I'm going to bake down:
These are the inflated cages used in the bake. The faces within the supporting geometry on the B cage have just moved directly outward along their normals without changing size, so all of the rays are just straight up along the normals and there's no distortion to details.
Here are the normal maps. The distortion is obvious for the A side.
What I've then done is dissolved all of the additional supporting geometry for the low poly B model, so that it looks exactly like the A model, and render the result. Because the supporting geometry wasn't actually affecting shading at all on the low poly model, it doesn't change anything once the normal map is on.
In terms of the normal map results for the box itself, not the details, the only difference is that the rounded edges are baked slightly larger on the A box, but it's basically not noticeable, and it has to do with the different cages, not the geometry on the low poly model itself post-bake.
Yea, I know the technique you are using. I guess I'm trying to say that it's a slippery slope and when people see & copy such a technique without really knowing the technical details they can start to have problems. While the example you posted works, it is limited to incredibly basic geometry and I'm doing my best not to encourage such techniques as for the vast majority of the time it is not transferable.
Please understand that this isn't a dig at you or anything. It's just that for the past 7+ years or more there have been a few of us on Polycount that have been trying to teach people the correct way to do things in regards to baking and such work is quickly undone. Before you know it people are back to painting out wavy lines in Photoshop. Dark days indeed
Anyway, You sound like you have a good technical grasp on what is going on behind the scene in regards to normals so I'm happy that it's working for you.
Well you're absolutely right that it only works with very limited geometry, which is part of the reason that I ended up in here asking for alternatives.
It doesn't work once you have any curved surfaces at all. I've already started playing around with face-weighted normals, and they're clearly far more versatile, especially given the more generous poly budget games can handle these days.
Well, I love custom vertex normals now. Testing them out on an old mesh of mine made me wonder though, to what degree do you guys continue to propagate these bevels through the mesh vs. having them pinch out into triangles or whatever? Does this mostly depend on whether or not I need good geometry for future work, or is there a good reason to keep this geometry for the sake of the normals themselves?
Does it matter how the occasional n-gon that results from the beveling is broken up into tris, or does whatever work?
Brilliant. Clear and concise explanation. Sticky it, wiki it, put it on the News page. Your next installment needs to be MOAR GEO, then 90% of the newb questions will be answered.
To reiterate what fletch said in another thread, they really need to pay you for this shit.
Thanks, maybe I'll condense everything I know and write a book someday.
Replies
So here is my low poly model, which has straight and curved segments.
Method 1 of creating high poly: subdivision surface. You get a much smoother curve, but this can result in waviness when baking normal maps.
Method 2 of creating high poly: bevels. This way you preserve the silhouette of the low poly model, which makes baking normals a breeze.
The problem I'm having with the latter method of creating high poly, is that it basically becomes impossible to sculpt on additional detail. If you add geometry to the mesh, you lose the smooth curve of the normals.
So do I just need to suck it up and deal with subdiv and potential wavy normal maps? Is there another way to go about this?
You also probably want to add bevels to the low poly too so it bakes down better rather than having a bunch of 90 degree angles.
I think maybe you are trying to match the silhouette of the high poly to the silhouette of the low poly, where really it should be the other way around. The high poly is de facto source of detail for the bakes so you should aim for the the low poly to better match the high poly rather than vise-versa.
Maybe I could really up the poly though. Is there one of those spreadsheets for polygon limits for 2018 or 2017? For all I know I'm being way to conservative with my geometry in general here.
The question needed to be asked is how much does reducing the waviness matter in the context of what you are doing?
It's always very hard to answer the "How many tris for this mesh?" question as in production such answers are dictated by more factors than a simple mesh in isolation. The most important thing is that you add enough geometry to support the shape of the mesh you are building without being wasteful. That being said, for a pure portfolio piece your tricount is less restrained by external factors so you can afford to make it heavier than you would in a game, without making it so heavy as to be unrealistic.
Probably the best thing you can do to get an idea of a rough production tricount is to take a look around Polycount or Artstation for art dumps that show similar assets and find a decent average for something close to what you are currently doing. For an FPS something like a barrel might have 24 sides but a rifle scope might have a similar amount (or more) even though it is much smaller in size because it is closer to the camera.
All you can really do is make an informed decision to increase the side count until you feel that the waviness is reduced to an acceptable level for the asset in question while taking into consideration your specific set of circumstances.
Probably not the answer you were looking for, but I hope it helps somewhat
When the model doesn't have curves I find that right angled boxes don't look bad at all with their baked normals. Hopefully I can get something similar enough.
The reason I suggested bevels is because when you zoom out sharp 90 angles tend to alias badly & bevels are free in terms of vertex cost (assuming that you are replacing two adjacent smoothing groups or a single hard edge between two faces) as in such cases the vertices are already already created in both 2D & 3D space.
Comparing 2 cube meshes is probably the easiest way for you to see this. Bevel all the border edges on one and and add smoothing groups/hard edges to all border edges on the other and you will notice that both cubes will have the same vertex count, even though the triangle count is higher on the cube with the bevels.
Hope that makes sense.
It also depends on the geometry being bevelled too. It might be an interesting exercise to see what the average increase is for some basic shapes is and then find an average. Will do that later if I remember.
Thanks for the correction btw!
I imagine I would cut the left shape up and the bevel would end up with one or the other primary faces in each case. But isn't this making the normal map do a lot of corrective work that could potentially lead to artifacts?
The other reason that I like the 90° angles with hard edges is that as long as the surface is completely planar, I can put as much or as little geometry on it and it renders the same. It lets me work with the geometry on the right when making the model. That lets me cage-bake without any surface details being distorted in any way, because except for at the edges, the rays from low poly to cage are orthogonal to the surface of the plane. I can get rid of all that geometry at the very end and have a super low poly model.
Yes, the normal map would have to do more work, but in reality this is rarely a problem by itself any more as most engines and bakers are synced via the use of MikkTSpace and such errors are usually down to a sync mismatch. With a fully synced workflow you can bake everything with one smoothing group (no hard edges at all) and it would show up perfectly in your engine. That said, this isn't always desirable it can sometimes accentuate other issues not related to normal map sync such as banding if you are working with hard surface objects that are very reflective.
I find that usually the best workflow is to not worry about hard edges until the last minute (pre-bake) and just set them to whatever your UV borders are once everything is unwrapped. This generally strikes a good middle ground as it reduces the heavy lifting on the normal maps side, which in turn, causes fewer issues with compression and banding, but also allows you to get a sensible and efficient unwrap without worrying about packing a bunch of faces because you set them to be hard.
I get what you're saying though and it's clearly a limiting constraint best avoided. I'll play around with weighted normals, because that seems like a huge game changer in general, and if it allows for cheap and effective bevels that reduces waviness on curved segments all the better.
It's true in all cases as long as the cage isn't split. Any time you are using a proper averaged cage the vertices of said cage set to all smooth (no double verts) so there are no gaps in the projection & you add loops to control that projection in order to stop skewing. If adding geometry didn't change the result of the bake then you wouldn't bother adding it right? Adding loops must change the vertex normals of the low poly or it wouldn't control the skew and removing them also change those same vertex normals.
Added to that is the problem with triangulation. When you remove the loops, the mesh will probably triangulate differently which increases the error present, so you are fighting that in addition to different vertex normals.
My point is that baked tangent space normal maps are geometry specific by their nature. They are mathematical values encoded in the form of a texture and you cant edit the TS normal map in something like Photoshop or remove faces from the low poly bake mesh without changing the values needed to be decoded correctly. The error is still present even if you cant see it easily, and unfortunately that includes the simple box case you posted earlier.
It sucks, I know, but thems the breaks.
The only correct way is to convert an OS normal map to TS using the new geometry or use something like ndo to paint image space normals directly
Here are the high poly boxes I'm going to bake down:
These are the inflated cages used in the bake. The faces within the supporting geometry on the B cage have just moved directly outward along their normals without changing size, so all of the rays are just straight up along the normals and there's no distortion to details.
Here are the normal maps. The distortion is obvious for the A side.
What I've then done is dissolved all of the additional supporting geometry for the low poly B model, so that it looks exactly like the A model, and render the result. Because the supporting geometry wasn't actually affecting shading at all on the low poly model, it doesn't change anything once the normal map is on.
In terms of the normal map results for the box itself, not the details, the only difference is that the rounded edges are baked slightly larger on the A box, but it's basically not noticeable, and it has to do with the different cages, not the geometry on the low poly model itself post-bake.
While the example you posted works, it is limited to incredibly basic geometry and I'm doing my best not to encourage such techniques as for the vast majority of the time it is not transferable.
Please understand that this isn't a dig at you or anything. It's just that for the past 7+ years or more there have been a few of us on Polycount that have been trying to teach people the correct way to do things in regards to baking and such work is quickly undone. Before you know it people are back to painting out wavy lines in Photoshop. Dark days indeed
Anyway, You sound like you have a good technical grasp on what is going on behind the scene in regards to normals so I'm happy that it's working for you.
It doesn't work once you have any curved surfaces at all. I've already started playing around with face-weighted normals, and they're clearly far more versatile, especially given the more generous poly budget games can handle these days.
Does it matter how the occasional n-gon that results from the beveling is broken up into tris, or does whatever work?