Oh, not sure if anyone will ever comes across this, but you can't use GIMP to fix bit depth issues. It can't handle 16 bit files and it fractures the mesh even worse. Just do the conversion in Photoshop.
I spent far too long looking for a way to do this without PS until I finally found out that pre-release builds of GIMP 2.9 support higher bit depths. I'm currently using one by Partha (search Partha GIMP build). It allows you to set every part of the image precision: bit depth (8, 16, 32, 64), linear or gamma, integer or floating point. There are also a range of dithering options when decreasing bit depth.
I spent far too long looking for a way to do this without PS until I finally found out that pre-release builds of GIMP 2.9 support higher bit depths. I'm currently using one by Partha (search Partha GIMP build). It allows you to set every part of the image precision: bit depth (8, 16, 32, 64), linear or gamma, integer or floating point. There are also a range of dithering options when decreasing bit depth.
WOW thank you for this life-saver!! Gonna search for this and try it out soon.
Been spending a long time figuring out how to avoid all any waviness on this fire hydrant model, but there was one part that was proving to be an issue. I wanted to have a perfect circle in the normal map around the top of the bottom chunk, and not have any waviness or weirdness, I tried modeling in the /¯¯\, but that used a lot of polygons, and I couldn't get the perfect circle shape I wanted. So instead my solution was to split up the base and the body so I could have the cages project exactly how I wanted, but splitting, re-merging, and playing around with capturing the exact shapes I wanted ended up being a lot of extra work. Is there a better way to do this? I posted only the relevant part of the normal map. I know I probably need to exaggerate the shape a bit more, it wont hold up over a distance.
I know there's some issues with the part that sticks out, but that's not what I'm focusing on right now.
Hey man, don't apologize. I ran into the same issues and I read a bunch of different threads and looked at a lot of different things before I got good results. Take a look at this video:
I thought this was the simplest explanation I've come across and it really made everything come together in all of the various threads I read. If you still have issues, post again and I'll try and help you out.
Having some troubles with my normals. Is this a bit depth issue ?
Baking my normals as .EXR solved some issues as seen in the image above, but there are still some artifacts occurring.
Already tried baking the normals as .TIFF, .TGA, downsizing from 32bit to 16, 16 to 8, using psd etc, but no luck so far.
The artifacts are only visible at extreme angles, from far away it is really difficult to see them.
Any thoughts?
It's most likely a bit depth issue, you can minimize it by adding more edges or adding uv spits. 90 degree angles with no splits really pushes your normal map to the point of artifacting.
Having some troubles with my normals. Is this a bit depth issue ?
Baking my normals as .EXR solved some issues as seen in the image above, but there are still some artifacts occurring.
Already tried baking the normals as .TIFF, .TGA, downsizing from 32bit to 16, 16 to 8, using psd etc, but no luck so far.
The artifacts are only visible at extreme angles, from far away it is really difficult to see them.
Any thoughts?
Yea, ZacD is correct. This is most certainly a bit depth issue due to the low curvature of the underlying surface. UV splits on smoothing groups/hard edges, 16bit normals and making sure that the HP/LP meshes are flat where they are supposed to be flat are the only things you can do really.
The problems will be much worse if you are using 8bit normals, even if they are created from a 16/32bit source. Best to stick with a native 16bit format such as Tiff or PSD than convert to 8bit.
Quick question to double check my thinking. I have these shading issues here. The main piece in the screenshot has 1 smoothing group. I noticed that the cage was not flat like the faces of the LP in this area so i tried to make those faces planar and rebake but it didn't make any difference. I am surprised that didn't help and am wondering if i did something wrong. Is that normal that planarizing the cage to match the LP wouldn't help this issue?
Also, is this topology horrible? Would you have connected the arching vertices in the middle horizontally?
Quick question to double check my thinking. I have these shading issues here. The main piece in the screenshot has 1 smoothing group. I noticed that the cage was not flat like the faces of the LP in this area so i tried to make those faces planar and rebake but it didn't make any difference. I am surprised that didn't help and am wondering if i did something wrong. Is that normal that planarizing the cage to match the LP wouldn't help this issue?
Also, is this topology horrible? Would you have connected the arching vertices in the middle horizontally?
You want to avoid long thin triangles wherever you can really. Even when everything is synced they can cause other issues and for the most part such topology is unnecessary.
I cant really tell what is going on with your topology exactly due to the angle of the screenshot, but you probably want something more like this.
Just wondering - would aligning the lowpoly vertex normals to the plane help in this case?
I.E. you select the border vertices of the planar surface with the triangulated topology, and align the vertex normal so that they are perpendicular (as seen in that recent thread here in technical talk) would this get rid of the shading artifacts?
I think aligned vertex normals would force the bake to be actually perpendicular, because baking is based on vertex normals direction.
This could also help with wavyness, as an alternate method to the skewmesh one (I can see some skewing on those screws, btw).
Am I wrong?
@metalliandy: I ended up doing about what you suggested. To give an insight into the mind of a learning 3D modeller, i avoided doing it that way in the first place because i thought it might smooth better on the round ridge, i think because of my experience with using turbosmooth... :shifty:
@ a3d: Yeah, those screw heads are definitely skewed from the averaged projection mesh render. The whole thing has no hard edges and is all one smoothing group because i expect people might see it in VR since i plan on donating it to Technolust if they want it and so i was really concerned about seems. In the end i just selected all the verts from the front faces and pulled them straight outward so the projection would look straight on and eliminate skewing , just like giving it a hard edge and baking without a cage and i did the same for the many of the other large faces, such as the front body of the receiver since there is so much normal mapped stuff on it.
I tried planarizing the cage verts on the face to match the LP plane of the face, which i noticed were not planar after being pushed out, but it didn't help the shadowing. I assume the projection calculations come up with the same normal angles for each pixel it filling (ie, it looked exactly the same as before). I also ended up pulling up the lowest verts on the face so the screws looked like you were looking down on them, correct if viewed from the higher up, which i think they will be in the end.
Edit: holy molly i can't believe how many spelling errors i make these days.
Edit2: I found it interesting that 3DS Max's bake were better in many areas than Xnormals, but had some issues that gave Xnormal the lead by a hair. Of course Xnromal killed it in speed since i used Hammersely.
Planarizing the cage verts does nothing in most baking applications. I was suggesting (well, not really. I'm not sure if it works) a different route, based on reorienting the vertex normals of the lowpoly mesh before generating the cage
Basically - aligning the vertex normals (marked in yellow in the left part of the pic) didn't fix the skewing at all.
But it DID fix the bit depth issue.
I understand why it fixed the bit depth issue, but I don't understand why it didn't fix skewing.
I thought baking engines took vertex normals in account when calculating the projection direction.
PIC:
I even later aligned manually the cage with the unerlying vertices, just to be extra sure (altough I know Maya doesn't chech that really. Just for the sake of experimenting) but it made zero difference
Does anybody have any insight on this?
(you can try it yourself as well)
From what I understand, Maya ignores your lowpoly mesh normals and makes an averaged cage, so manually editing the normals won't do anything. At least when match using is set to geometry normals.
If you set it to surface normals, it should work, but then you can't use hard edges without getting gaps. So, custom edited normals and no hard edges may work.
I tried using Surface Normals match, and it worked for the plane. However, it gave me all kind of troble and artifacts on basically every other part. Not sure if I'm doing something wrong, or if it's not feasible after all.
Right, with match surface normals, you'll get artifacts anywhere you use hard edges. At hard edges, the projection mesh is split, and you get gaps in what the projection "sees", which results in nasty seam artifacts.
I didn't use hard edges, but I moved the cage manually to encompass the floating geometry. I'm not sure of what might have caused it since I never used this kind of projection.
Of course I read your threads. Specifically the last one you linked had me wondering if one could avoid skewing by re-orienting vertex normals, without additional geometry. So I tried and shared results hoping to contribute something to the community.
The interesting thing is, for now, it appears aligning normals fixes banding on perfectly flat surfaces (no dithering, no need for higher bit depths) even when using geometry normals match.
I haven't lost hope for the skewing problem tho. If we find out what caused the artifacts with the Surface Normal match (I assure you, it wasn't hard edges) this could become a viable, optimized workflow.
It would help if you posted images of the problem in that case.
The dithering improvement makes sense, when you make the normals completely flat, you're essentially matching the normals of the highpoly as closely as possible, this means the base normal map can be a flat neutral 127/127/255. Bit-depth issues are most frequently seen when the difference in normals between the highpoly and lowpoly is very very subtle as there are not enough values to represent it without dithering/adding noise. Having no difference, or a larger in normals for high vs low should mean less artifacts, assuming your workflow is synced (if not, but changes in normals may cause smoothing errors).
Been spending a long time figuring out how to avoid all any waviness on this fire hydrant model, but there was one part that was proving to be an issue. I wanted to have a perfect circle in the normal map around the top of the bottom chunk, and not have any waviness or weirdness, I tried modeling in the /¯¯\, but that used a lot of polygons, and I couldn't get the perfect circle shape I wanted. So instead my solution was to split up the base and the body so I could have the cages project exactly how I wanted, but splitting, re-merging, and playing around with capturing the exact shapes I wanted ended up being a lot of extra work. Is there a better way to do this? I posted only the relevant part of the normal map. I know I probably need to exaggerate the shape a bit more, it wont hold up over a distance.
I know there's some issues with the part that sticks out, but that's not what I'm focusing on right now.
Depending on your budget, I would either...
For rendering efficiency: I would split the bottom part off completely, cap it off, and model in the hole you need in the highpoly. This should also save you some tris, at the expense of UV space compared to having the top and bottom parts connected.
For good looks:
Weld top and bottom together, and chamfer the edge a bit at where they meet. Keep it all in one smoothing group and don't split the UVs unless you're getting errors.
This adds a whole lot of tris to your model, makes your UVs and bake cleaner, but is more expensive to render. Good for a show-piece, not good for a prop.
For the top bit, most of your waviness can be fixed by manually going over your triangulation. You have a very clean model that has very unclean triangulation. You've got that zig-zag thing going on, which is not helpful for a clean bake.
Triangulation has very little to do with getting a "clean" bake, the only thing that really matters is that the triangulation in your baked mesh matches that in the final engine.
Triangulation has very little to do with getting a "clean" bake, the only thing that really matters is that the triangulation in your baked mesh matches that in the final engine.
well inner triangulation definitely plays a role when it comes to extreme angles and silhouette changes thanks to the inner edge building either a concave or convex shape. While the normalmap might look correct and clean from some angles, there will be others where the mesh might look broken and just.
But yeah this tri stripping workflow is kinda not in use anymore, thankfully
Yeah but that's a silhouette/general modeling issue, non-planar quads should generally be triangulated to match the surface, I won't argue with you there. However, it isn't really related to baking or what was being discussed.
Good point, you'll get X shaped smoothing errors if you triangulation varies on either side of a mirrored axis. This is basically the same problem as triangulation not matching from 3D app to game engine though. Triangulation must be the same when baked, in final engine, and for all geometry that shares uv space.
I've had Maya randomly triangulate one half in the wrong direction and needed to fix it manually, pain in the ass.
TLDR: I can do an example when I get home from work, where I'll break this dare I say perfect bake by simply going over the LP, flipping some of the triangulation, and rebaking the normals.
While the bad-triangulation effect is negligible with a busy texture, on chromed or smooth surfaces it becomes apparent that the triangulation on the LP wasn't nit-picked on, especially at grazing angles where fresnel comes into play, and even more so if your normals are ported to an engine that has mismatched tangent normals.
Normally I wouldn't even bring it up or point it out, but the guy was asking for any and all solutions to wavyness.
I've had this "issue" loads of times, where I've noticed that at curvy or cylindrical areas where I have perfectly planar quads, like a barrel or a bendy bit, I was getting a faint wavy effect on some but not all polygons. This was apparent both in max viewport and in game with synced normals. Triangulation was of course forced, and it wasn't until I cleaned up the triangulation on my lowpoly and rebaked, that the effect vanished.
I see zero meaningful difference here, the projection is exactly the same, all the pixels are in the same spot, what waviness is here is present in all 3 versions. Baked in Maya, rendered in TB2 with Maya tangent space. I wouldn't judge what you see with Max's viewport shaders, as they are notoriously broken (do not match max's baker or offline render).
Edit: 1&2 had different AA settings than 3, fixed in the content but too lazy to update the image.
I see zero difference at all, actually, so now I'm thinking this "good triangulation" merely helps conceal the issues you get when your renderer and baker are out of sync as we all know max suffers from, because I was able to replicate my claims exactly.
This effect was also visible in Source, so I had to recompile my crowbie.
I took a handful of quads on the right one, flipped them, and baked normals for both so I'd know they both should look the same. I also put viewport in orto mode so the lighting difference between them should be negligible:
@EarthQuake
Maybe the triangulation problem occurs only where there are nonplanar quads, which does not happen in your test mesh, but does happen in the crowbar.
Could it be useful to make a test with a twisted tube? (or any other shape involving nonplanar quads)
Yeah but that's a silhouette/general modeling issue, non-planar quads should generally be triangulated to match the surface, I won't argue with you there. However, it isn't really related to baking or what was being discussed.
Yes, I read the whole discussion. I know it looks like he addressed it. But it's slightly different here, please pay more attention.
The supposedly "good" triangulation is not about matching the shape at its best, it's about a regular edgeflow, and this is what is being tested.
Does a regular edgeflow produce better results than an irregular one?
Apparently, it does not make any difference with planar quads.
But maybe it makes a difference with nonplanar quads.
The matter here is the reason: if it makes a difference, why does this make a difference? Is it because the shape was poorly represented by triangulation (EQ's stance), or because the triangulated edgeflow was irregular (good triangulation theory) ?
According to what EQ said, the best way to bake nonplanar quads is to match the shape, which is logical and plausible and probably true.
However, if this "good triangulation" thing is real, it would work by simply aligning the edges in a certain direction, and it should work better than manually flipping edges, which would result in an irregular edgeflow, albeit with a possibly more similar silhouette.
//// by the way, here's what I believe
The regular triangulated edgeflow ("good" triangulation) was a relevant technique before synced workflow became the standard.
It was relevant because bare gouraud shading works best with some patterns of triangulation rather than others, and since your bakes weren't synced, you wanted your lowpoly to look as clean as possible before recieving any projection.
Nowadays synced workflow takes care of these small differences.
Triangulation might become relevant again if the difference is extreme, to the point of a visible change of shape, in which case it's a modeling issue rather than a gouraud issue, like EQ said.
I see zero difference at all, actually, so now I'm thinking this "good triangulation" merely helps conceal the issues you get when your renderer and baker are out of sync as we all know max suffers from, because I was able to replicate my claims exactly.
This effect was also visible in Source, so I had to recompile my crowbie.
I took a handful of quads on the right one, flipped them, and baked normals for both so I'd know they both should look the same. I also put viewport in orto mode so the lighting difference between them should be negligible:
Yeah, what you're seeing here are smoothing errors related to an unsynced workflow. This isn't waviness at all as discussed in this thread (projection errors causing wavy edges, skewed detail, etc).
I get the concepts here relating to skew and curvature, but I'm confused about the purpose of using slopes as recommended. Sketching out the ray directions on paper it seems that there would be two consequences to using a shallower incline compared to a sharp 90 degrees- it will make the rays cast out more perpendicular to the surfaces of both the highpoly and lowpoly, and it will make the changes in ray direction near the corners less sudden. Is the latter the point of using them?
Hey guys, I'm currently going back to basics and doing a metal barrel model because I've had problems with waviness on my normals in the past and thought I would do this to fully understand and tackle the problem. Here is my High poly model
And now my Low Poly model...
I'm encountering waviness at the top like this...
I'm suspecting its mostly because there is not enough circumference in the main body of the barrel? I really want to understand this issue properly so I can hopefully avoid it in the future.
I added some geometry to help support the shape better and the waviness is almost gone.
Is there always going to be SOME waviness? I can't see it being feasible adding even more supporting edges to match the circumference even more is all.
Try using a skewmesh.
You basically add temporary support geo on your lowpoly, that you will use to bake an object space map.
Then, you will import the actual lowpoly without supporting geometry and your object space map in xnormals, where you will convert the OSNM into a tangent space normal map.
Try using a skewmesh.
You basically add temporary support geo on your lowpoly, that you will use to bake an object space map.
Then, you will import the actual lowpoly without supporting geometry and your object space map in xnormals, where you will convert the OSNM into a tangent space normal map.
I'll give this a go. I'm a Maya user and can only find tutorials on this for 3DS Max due to the tessellation modifier 3DS Max has. Is there any kind of plugin for Maya for this? Would just be cumbersome for me using 3DS Max just for that modifier hah.
Add red edgeloops. Your extrusions in the middle of the barrel and the rim are probably throwing the normals off a bit.
You can also possibly get rid of the purple loops!
Or, you can crease every edge and smooth, but this will smooth all your normals as well
Adding divisions doesn't seem to affect the edge flow of the mesh. It just adds more faces. Is there anyway to add these divisions with edge flow so it will affect the circumference?
This is what its doing...
Before ]
After
Nvm, just figured a solution, just went to Mesh > Smooth.
You mustn't change the shape, this will make the conversion from OSNM to TSNM incorrect.
Mesh>smooth will produce bad results at the end of the process. Use add divisions instead.
The skewmesh lowpoly and the actual lowpoly must have the exact same shape in order for the conversion to work. The support geometry is only there to prevent skewing, it is not supposed to change the silhouette
You've got a fundamental problem here, and that is the # of sides of your base cylidner is low, while you've got a seemingly excessive amount of sides cut in for things like the beveled edges at the tops and bottoms. If you optimized those areas, you could use more sides to make the barrel more round, which would significantly reduce waviness without needing to do any special baking tricks.
But let's not forget that wavyness can be caused by both low poly geo not matching the high close enough, and the averaged normals. Adding some support loops help the latter, like this:
By just adding a couple of edgeloops I've gotten rid of the wavyness on the sides of the barrel. Wavyness on the top and bottom edges happen because of the lack of geo on the base cylinder as EQ said.
All in all is just a matter of distributing your geo more properly all around.
how far can the projection Cage be? frankly i push mine out till it removes ray misses compeletly?
The ray distance should be as far as the biggest difference between your low and high poly model- so, probably not much. If you make it too much, your rays could accidentally project into something unintended.
Are you using 3ds max? I haven't used it in a while, but I think max's baking is/was limited to projecting inward- whereas xnormal projects the lowpoly/cage both in and outward, limited the need for blowing up your model and using large ray projection distances.
After reading all normal map threads a few times, I think I understand a lot of it now. But a few things are still unclear to me. Does a normal map overwrite the normals of a low poly or does it only alter it? And which normals will be affected? The face normals or the vertex normals? Or both?
From my understanding, assigning a normal map to a low poly will replace the low polys face normals. But I am not sure if this is correct. I would be grateful if someone could help me figuring this stuff out.
And... sorry for my poor english. It is not my native language.
After reading all normal map threads a few times, I think I understand a lot of it now. But a few things are still unclear to me. Does a normal map overwrite the normals of a low poly or does it only alter it? And which normals will be affected? The face normals or the vertex normals? Or both?
From my understanding, assigning a normal map to a low poly will replace the low polys face normals. But I am not sure if this is correct. I would be grateful if someone could help me figuring this stuff out.
And... sorry for my poor english. It is not my native language.
Tangent space normal maps only alter the vertex normals, a world or object space normal map overwrites all vertex normal information, but is more limited and not commonly used much.
Also there's different ways to generate normal maps because of how the vertex normals are taken to account, and can cause your normal map and game engine (or render) to be out of sync, and can cause minor shading artifacts.
Replies
*Asking as poor dirty Gimp user*
WOW thank you for this life-saver!! Gonna search for this and try it out soon.
I know there's some issues with the part that sticks out, but that's not what I'm focusing on right now.
Thank you for this video, it help me a lot.
Having some troubles with my normals. Is this a bit depth issue ?
Baking my normals as .EXR solved some issues as seen in the image above, but there are still some artifacts occurring.
Already tried baking the normals as .TIFF, .TGA, downsizing from 32bit to 16, 16 to 8, using psd etc, but no luck so far.
The artifacts are only visible at extreme angles, from far away it is really difficult to see them.
Any thoughts?
Yea, ZacD is correct. This is most certainly a bit depth issue due to the low curvature of the underlying surface. UV splits on smoothing groups/hard edges, 16bit normals and making sure that the HP/LP meshes are flat where they are supposed to be flat are the only things you can do really.
The problems will be much worse if you are using 8bit normals, even if they are created from a 16/32bit source. Best to stick with a native 16bit format such as Tiff or PSD than convert to 8bit.
Also, is this topology horrible? Would you have connected the arching vertices in the middle horizontally?
You want to avoid long thin triangles wherever you can really. Even when everything is synced they can cause other issues and for the most part such topology is unnecessary.
I cant really tell what is going on with your topology exactly due to the angle of the screenshot, but you probably want something more like this.
I.E. you select the border vertices of the planar surface with the triangulated topology, and align the vertex normal so that they are perpendicular (as seen in that recent thread here in technical talk) would this get rid of the shading artifacts?
I think aligned vertex normals would force the bake to be actually perpendicular, because baking is based on vertex normals direction.
This could also help with wavyness, as an alternate method to the skewmesh one (I can see some skewing on those screws, btw).
Am I wrong?
@ a3d: Yeah, those screw heads are definitely skewed from the averaged projection mesh render. The whole thing has no hard edges and is all one smoothing group because i expect people might see it in VR since i plan on donating it to Technolust if they want it and so i was really concerned about seems. In the end i just selected all the verts from the front faces and pulled them straight outward so the projection would look straight on and eliminate skewing , just like giving it a hard edge and baking without a cage and i did the same for the many of the other large faces, such as the front body of the receiver since there is so much normal mapped stuff on it.
I tried planarizing the cage verts on the face to match the LP plane of the face, which i noticed were not planar after being pushed out, but it didn't help the shadowing. I assume the projection calculations come up with the same normal angles for each pixel it filling (ie, it looked exactly the same as before). I also ended up pulling up the lowest verts on the face so the screws looked like you were looking down on them, correct if viewed from the higher up, which i think they will be in the end.
Edit: holy molly i can't believe how many spelling errors i make these days.
Edit2: I found it interesting that 3DS Max's bake were better in many areas than Xnormals, but had some issues that gave Xnormal the lead by a hair. Of course Xnromal killed it in speed since i used Hammersely.
The results:
Basically - aligning the vertex normals (marked in yellow in the left part of the pic) didn't fix the skewing at all.
But it DID fix the bit depth issue.
I understand why it fixed the bit depth issue, but I don't understand why it didn't fix skewing.
I thought baking engines took vertex normals in account when calculating the projection direction.
PIC:
I even later aligned manually the cage with the unerlying vertices, just to be extra sure (altough I know Maya doesn't chech that really. Just for the sake of experimenting) but it made zero difference
Does anybody have any insight on this?
(you can try it yourself as well)
If you set it to surface normals, it should work, but then you can't use hard edges without getting gaps. So, custom edited normals and no hard edges may work.
Read this thread on skewing if you haven't yet: http://www.polycount.com/forum/showthread.php?t=147227
Of course I read your threads. Specifically the last one you linked had me wondering if one could avoid skewing by re-orienting vertex normals, without additional geometry. So I tried and shared results hoping to contribute something to the community.
The interesting thing is, for now, it appears aligning normals fixes banding on perfectly flat surfaces (no dithering, no need for higher bit depths) even when using geometry normals match.
I haven't lost hope for the skewing problem tho. If we find out what caused the artifacts with the Surface Normal match (I assure you, it wasn't hard edges) this could become a viable, optimized workflow.
The dithering improvement makes sense, when you make the normals completely flat, you're essentially matching the normals of the highpoly as closely as possible, this means the base normal map can be a flat neutral 127/127/255. Bit-depth issues are most frequently seen when the difference in normals between the highpoly and lowpoly is very very subtle as there are not enough values to represent it without dithering/adding noise. Having no difference, or a larger in normals for high vs low should mean less artifacts, assuming your workflow is synced (if not, but changes in normals may cause smoothing errors).
Depending on your budget, I would either...
For rendering efficiency: I would split the bottom part off completely, cap it off, and model in the hole you need in the highpoly. This should also save you some tris, at the expense of UV space compared to having the top and bottom parts connected.
For good looks:
Weld top and bottom together, and chamfer the edge a bit at where they meet. Keep it all in one smoothing group and don't split the UVs unless you're getting errors.
This adds a whole lot of tris to your model, makes your UVs and bake cleaner, but is more expensive to render. Good for a show-piece, not good for a prop.
For the top bit, most of your waviness can be fixed by manually going over your triangulation. You have a very clean model that has very unclean triangulation. You've got that zig-zag thing going on, which is not helpful for a clean bake.
well inner triangulation definitely plays a role when it comes to extreme angles and silhouette changes thanks to the inner edge building either a concave or convex shape. While the normalmap might look correct and clean from some angles, there will be others where the mesh might look broken and just.
But yeah this tri stripping workflow is kinda not in use anymore, thankfully
An example (not mine)
I've had Maya randomly triangulate one half in the wrong direction and needed to fix it manually, pain in the ass.
TLDR: I can do an example when I get home from work, where I'll break this dare I say perfect bake by simply going over the LP, flipping some of the triangulation, and rebaking the normals.
While the bad-triangulation effect is negligible with a busy texture, on chromed or smooth surfaces it becomes apparent that the triangulation on the LP wasn't nit-picked on, especially at grazing angles where fresnel comes into play, and even more so if your normals are ported to an engine that has mismatched tangent normals.
Normally I wouldn't even bring it up or point it out, but the guy was asking for any and all solutions to wavyness.
I've had this "issue" loads of times, where I've noticed that at curvy or cylindrical areas where I have perfectly planar quads, like a barrel or a bendy bit, I was getting a faint wavy effect on some but not all polygons. This was apparent both in max viewport and in game with synced normals. Triangulation was of course forced, and it wasn't until I cleaned up the triangulation on my lowpoly and rebaked, that the effect vanished.
1. alternating triangulation
2. "good" triangulation
3. "bad" triangulation, random direction
content: https://dl.dropboxusercontent.com/u/499159/tridirectioncontent.zip
I see zero meaningful difference here, the projection is exactly the same, all the pixels are in the same spot, what waviness is here is present in all 3 versions. Baked in Maya, rendered in TB2 with Maya tangent space. I wouldn't judge what you see with Max's viewport shaders, as they are notoriously broken (do not match max's baker or offline render).
Edit: 1&2 had different AA settings than 3, fixed in the content but too lazy to update the image.
This effect was also visible in Source, so I had to recompile my crowbie.
I took a handful of quads on the right one, flipped them, and baked normals for both so I'd know they both should look the same. I also put viewport in orto mode so the lighting difference between them should be negligible:
Maybe the triangulation problem occurs only where there are nonplanar quads, which does not happen in your test mesh, but does happen in the crowbar.
Could it be useful to make a test with a twisted tube? (or any other shape involving nonplanar quads)
The supposedly "good" triangulation is not about matching the shape at its best, it's about a regular edgeflow, and this is what is being tested.
Does a regular edgeflow produce better results than an irregular one?
Apparently, it does not make any difference with planar quads.
But maybe it makes a difference with nonplanar quads.
The matter here is the reason: if it makes a difference, why does this make a difference? Is it because the shape was poorly represented by triangulation (EQ's stance), or because the triangulated edgeflow was irregular (good triangulation theory) ?
According to what EQ said, the best way to bake nonplanar quads is to match the shape, which is logical and plausible and probably true.
However, if this "good triangulation" thing is real, it would work by simply aligning the edges in a certain direction, and it should work better than manually flipping edges, which would result in an irregular edgeflow, albeit with a possibly more similar silhouette.
//// by the way, here's what I believe
The regular triangulated edgeflow ("good" triangulation) was a relevant technique before synced workflow became the standard.
It was relevant because bare gouraud shading works best with some patterns of triangulation rather than others, and since your bakes weren't synced, you wanted your lowpoly to look as clean as possible before recieving any projection.
Nowadays synced workflow takes care of these small differences.
Triangulation might become relevant again if the difference is extreme, to the point of a visible change of shape, in which case it's a modeling issue rather than a gouraud issue, like EQ said.
Still a final test could clear this up for good.
Yeah, what you're seeing here are smoothing errors related to an unsynced workflow. This isn't waviness at all as discussed in this thread (projection errors causing wavy edges, skewed detail, etc).
And now my Low Poly model...
I'm encountering waviness at the top like this...
I'm suspecting its mostly because there is not enough circumference in the main body of the barrel? I really want to understand this issue properly so I can hopefully avoid it in the future.
Is there always going to be SOME waviness? I can't see it being feasible adding even more supporting edges to match the circumference even more is all.
You basically add temporary support geo on your lowpoly, that you will use to bake an object space map.
Then, you will import the actual lowpoly without supporting geometry and your object space map in xnormals, where you will convert the OSNM into a tangent space normal map.
I'll give this a go. I'm a Maya user and can only find tutorials on this for 3DS Max due to the tessellation modifier 3DS Max has. Is there any kind of plugin for Maya for this? Would just be cumbersome for me using 3DS Max just for that modifier hah.
Or, you can crease every edge and smooth, but this will smooth all your normals as well
Add red edgeloops. Your extrusions in the middle of the barrel and the rim are probably throwing the normals off a bit.
You can also possibly get rid of the purple loops!
Adding divisions doesn't seem to affect the edge flow of the mesh. It just adds more faces. Is there anyway to add these divisions with edge flow so it will affect the circumference?
This is what its doing...
Before
After
Nvm, just figured a solution, just went to Mesh > Smooth.
Mesh>smooth will produce bad results at the end of the process. Use add divisions instead.
The skewmesh lowpoly and the actual lowpoly must have the exact same shape in order for the conversion to work. The support geometry is only there to prevent skewing, it is not supposed to change the silhouette
1) Took my low poly duped it, Edit Mesh > Add Divisions. Which is now my skew mesh
2) Created a cage for the Skew Mesh
3) Baked as normal but created an Object Space map with my Skew Mesh and High Poly.
4) Used the Object/Tangent Space Converter in Xnormals to convert the OS Map to a TS Map with my original Low poly mesh.
There was just as much wavyness when I applied the new TS Normal map onto my LP.
I'm not sure if I'm doing anything wrong but yeah.
@Bruno I'll give that method a go soon, thanks!
Edit: Pic
Shown here: http://www.polycount.com/forum/showpost.php?p=1289327&postcount=36
By just adding a couple of edgeloops I've gotten rid of the wavyness on the sides of the barrel. Wavyness on the top and bottom edges happen because of the lack of geo on the base cylinder as EQ said.
All in all is just a matter of distributing your geo more properly all around.
The ray distance should be as far as the biggest difference between your low and high poly model- so, probably not much. If you make it too much, your rays could accidentally project into something unintended.
Are you using 3ds max? I haven't used it in a while, but I think max's baking is/was limited to projecting inward- whereas xnormal projects the lowpoly/cage both in and outward, limited the need for blowing up your model and using large ray projection distances.
From my understanding, assigning a normal map to a low poly will replace the low polys face normals. But I am not sure if this is correct. I would be grateful if someone could help me figuring this stuff out.
And... sorry for my poor english. It is not my native language.
Also there's different ways to generate normal maps because of how the vertex normals are taken to account, and can cause your normal map and game engine (or render) to be out of sync, and can cause minor shading artifacts.