You don’t need to use the edge split modifier. You just need to set your UV Boundary Edges to sharp. You shouldn’t even need to triangulate if you’re just previewing the normal map in Blender, as you’ll have baked on the same internal triangulation you’re currently looking at. You will need to triangulate if you want to export.
That said, I can’t bake this without artifacts either. The video linked above doesn’t touch on the types of artifacts shown by OP.
I imagine this stems from a hardlocked 16 sample max in the bevel node. You can read through this thread for more information (similar issue).
Basically, someone took the bevel code and created a new script node in the shader editor with an unlocked sample count and it resolved artifacting issues. Not having any luck with his file/script on my version of Blender though (2.82). No idea why you can’t go above 16 samples on the Bevel node, but I imagine it wasn’t made with baking in mind and was probably deemed good enough for Cycles image renders.
Would really love to know what the solution for this is (without Photoshopping)
I’m glad someone confirmed this. I don’t know how people bake with artifacts and happily accept it. The workflow can’t handle a simple booleaned box, let alone a whole gun.
Just as Realeyez said, the 16 sampling cap is one of the factors of the artifacts in the baking. However, there are a lot of optimizations to the mesh that can totally remove the artifacts, even with a lower sample.
I did some tests with the file you posted and I managed to greatly reduce the artifacts. The main problem is caused by very long or very thin triangles, which you have a lot.
As you can see, the messy triangles caused the artifacts, however, by inseting that face I managed to get rid of it. Also note that I inserted some loops around the vertical edges to make them shorten too.
Another observation: You can remove the additional edges after you’re done baking. Since none of them affected the shading of the mesh, the normal map will work correctly
One more observation just in case. When baking with the bevel shader, you only need to use the same amount of samples in the render settings.
Eg. If you set the bevel shader to 12 samples, you only need to bake the texture using a maximum of 12 samples in the render properties tab. This can save a lot of time.
I just posted a link above with an entire gun baked like this. Go to the Artstation page. It’s full of closeups.
The reality is that baked assets should be taken through the proper workflow procedure, using all the basic rules for a successful and clean bake. Decent topology that shades well and with good UVs will always bake down well. The normal map can only carry the illusion so far. A solid workflow will get you the rest of the way. Your example is unrealistic and would never be the basis of a production mesh.
Yes, Skewmeshing is an old-school technique and especially on flat surfaces with no gradient.
P.S -sorry, didn’t have a chance to do test bakes. I’m flying to Australia soon…
The topology is indeed disgusting, but that shouldn’t affect the bake outcome to this degree (or really at all in this instance). For what it’s worth, I retopo’d and re UV’d it as well as a test to see if it was a result of that, and it still couldn’t bake correctly. The artifacts are purely a limitation of Blenders implementation of the bevel shader (or maybe just the locked sample count).
I threw a regular bevel modifier on the high and took that and the low as it was (but triangulated) into Painter and baked it real quick (with no AA for fairness), and these are the results:
Blenders bevel shader seems very hit and miss. For planar/box-y objects the artifacts it produces might be literally unnoticeable (but still there), but to me, this doesn’t seem like an unusual type of shape to need to be able to reliably make (topology aside) and makes me uncomfortable using the shader in any sort of production.
It is interesting though. Maybe I just got lucky. There are close to 100 baked parts on that gun and I didn’t experience any of this strange artifacting, but from your tests it must be certainly an issue with the bevel shader.
You’re confusing adding a bevel modifier shader with baking REAL geometry HI to LO. Very different procedures and I would expect the REAL geometry to be better. There are several bevel shader routines out there and I’ve yet to see one that works perfectly in all instances. The trick is to understand it’s limitations. FWIW, it’s not always possible to add a bevel modifier on complex geometry and in many of these instances, a bevel shader bake will work.
The fact is when you’re using bevel shaders, your UV mapping matters-- a lot. So crappy UVs create for crapping bevel baking with the bevel shader. I don’t know of any program that doesn’t have similar problems when using a bevel shader baking process.
I’m not confusing either of them. What I did was bake the actual high poly geo to the low geo (in Painter with no AA) to show that there wasn’t an issue with the low geo’s ability to receive normal map information (whether it be for UV, topology, triangulation issues, etc.), but rather with Blenders ability to bake the rounded edge shader information to the low. Real geometry would technically be better (and is, as you can see from the result of the bake), but I still expect the shader to bake fine unless it’s a weird edge case situation, which I don’t consider this mesh to be.
I agree, but this shape isn’t asking a lot from the shader here.
I know, that’s the point of this thread (lately) The issue is sometimes it doesn’t, and it’s awkwardly often or unpredictable enough to hold it back from use in production.
The UVs here were good. I actually didn’t the ones OP posted above from the blend file and redid them myself. It’s a limitation of either the node or Cycles ability to bake. I doubt Houdini would fail to bake this shape with its round edge shader, and I know Modo would not fail to bake this shape either. I’ve baked a fair amount of rounded edge stuff in Modo and this mesh is not one I would have ever thought twice about. I’d open it up and bake it right now if I still had it installed, but I haven’t had it for a while now since moving to Blender.
You’re missing the ACTUAL point. These are two very different workflows with very different technologies behind them. You cannot use one to evaluate how the other should work.
I’m aware. The process is different but the result we’re after is the same, which is exactly why I can reference the quality of result from one to the other. One works perfectly in all scenarios, the other doesn’t. This is a result of a limitation of the shader/Cycles baking ability on specific topology where there doesn’t seem for there to be a reason to be.
A regular car and an electric vehicle are both vehicles, with the point of them being to get me from point A to point B reliably. I don’t care about the differences under the hood if one of them randomly intermittently turns itself on and off while driving, and I can definitely point to the other fully functional one as an example of stability, reliability, predictable result, and how it should work.
That may matter if I’m building cars, but I’m just driving.
While shooting for the same result is of course the right idea, the WAY you get there is different. Take my electric car for instance. I cannot take it to a gas station but instead must recharge it at home. Different technical approaches gives me the same result-- I can transport myself using either my electric car or my gas truck.
(Interesting-- we’re both in Austin, TX
(Even more interesting-- we both have designed a Mars Habitat
I don’t mean to sound arrogant but I know how to bake a mesh properly and know all the basic rules. I’m not a beginner in preparing an asset for baking. The topology of that cube is highly optimized and is perfect for a game asset. It doesn’t matter how thin or far those triangles are, the bake comes out wrong. Long thin triangles don’t affect flat surfaces as much as uneven surfaces. The cube is a simple example of what could be on a gun. A cylinder booleaned into a cube. From what I’ve seen on test examples, there’s nothing solid about this workflow. A bake should be clean, even if it’s not “the basis of a production mesh”.
Bake looks clean in the video. I did exactly everything in the video except using cpu and choosing 32bit. Though I suspect you got results because you didn’t triangulate the mesh. The mesh would be triangulate before baking and using in a game engine. I’ll try this at work at let you know the results. Thanks for the video.
1 - One side booleaned
2 - One side booleaned and mirrored (and re-uved)
3 - One side has 34 faces on the loop going around the cylinder, other side has 25 faces
4 - One side has 68 faces on the loop going around the cylinder, other side has 25 faces
1 - Bakes with no artifacts on top face
2 - Bakes with no artifacts on top face
3 - Bakes with artifacts on top face
4 - Bakes with artifacts on top face
(This is the face loop I’m counting faces on, btw -)
They were all triangulated before the bake (modifier off on screenshot for clarity). Also baked without triangulation and just the ngons and got varying results, but still artifacts in 3 and 4.
The number of faces doesn’t really seem to matter, but it looks like they need to be the same in order for it to create the smooth baked result.
mrgesy’s mesh from the .blend attached to their OP has 99 faces on one side, and 126 on the other, so this is consistent there too. If you boolean 2 different cylinders with different edge counts out of the top of a cube like there and get a result that doesn’t have any artifacts, I definitely want to know the sorcery
At any rate, in the interest of not “spamming” this thread, I won’t post more about it after this, but it looks like we may have found the limitation with it here.
There are close to 100 baked parts on that gun and I didn’t experience any of this strange artifacting, but from your tests it must be certainly an issue with the bevel shader.
