Baker: Convert Object to Tangent from Mirrored/Repeating Geometry Seam.
polycounter lvl 18
I tried a variety of bakers as shown and only Marmoset is incorrectly making a seam at the border. The shot should show my setup in case I did something wrong?? The original object space was baked from a high poly to medium poly.
Replies
Once you sort that out what you're trying to do here should work.
Where was the object space map baked? Different bakers bake this differently, and unfortunately it's not just a matter of inverting the green but some bakers pack the different axes in different channels, ie: Maya vs Max.
Does the object space input map have padding applied to it? If no padding that could explain the artifact along the seam edge.
If you want to send over the scene and the maps I can have a look. Easiest way to do this is to do File -> Export -> Scene Bundle and zip up the .tbscene and /assets/ folder.
As an aside, is there some reason that you can't bake from the high poly?
One thing you could try here is baking from a tangent rather than object space normal map. I have a suspicion that using an object space normal map but UVing it in the way you have here may be causing some issues (odd sampling at the seam as the object space normals are only correct for 1/3rd of the mesh).
"I use medium meshes to get detail that won't be as warped (even with skew) versus if I had gone straight to the in game version. That and have you handed in a mesh to be told it's too high in polycount? Using the object space is a shortcut to this."
It seems like you're causing more problems for yourself here than this is worth. If this is to correct skewing:
A. You haven't really done that, your bake still has wavy details and any skewing can be easily corrected with the skew tools
B. Your mesh is generally inefficient, with many micro bevels but not enough sides to represent the round forms and inconsistent poly usage (few sides next to many). If you sorted this out you would get better bakes at roughly the same triangle count. In most productions I've worked on these meshes would get rejected for poor topology rather than polycount concerns. If you want to send the high poly mesh I can show you how to create a more efficient low poly that bakes with less artifacts. This was mentioned in your other thread but I can give you more real-world examples if you don't understand what I mean.
"Using a tangent space would get rid of the whole point of using a object space as the input. The object space is using coordinates from the world versus the objects surface. (Which is why I find it strange Marmo went with Object Space vs World for naming)"
A couple things here:
A. You can bake tangent on a medium poly mesh and rebake that to low poly. There is nothing about this that would negate the point of using an object space bake. Baking medium to low in Toolbag with tangent maps will take the low poly mesh normals + normal map (which to the renderer, is essentially the same thing as OS normals, assuming you have synced tangents) into account and everything should be translated correctly, giving you the same benefits of using OS. The only thing I would suggest here is using a 16 bit map and at a higher resolution than you need.
B. Object space is the correct usage. World space refers to an object transformed in the world, it's an extra level of transformation. In the context of what we're talking about here, the difference would be the object space normals, ie: as baked from the object in its default pose, and the world space normals, ie: the normals of a translated mesh in a game engine. A practical example would be a rock or something rotated in the game engine. As a practical example you might use the world space normals for a shader that places snow on the rock's up axis, and the world space normals will vary dynamically in relation to how an object is transformed in the world.
No bakers bake world space normals, if they claim to it's a poor use of terms. OS and WS are commonly and erroneously used interchangeably. With that said, if you have not applied any additional transforms to the object, OS and WS normals will be identical. Generally speaking unless you're a technical artist who is writing shaders, you're not doing anything which involves world space normals.
"Since the surface (but not the uv islands) have changed on the lowest version, the object space map would account for this and transfer that difference to the lowest version. "
Object vs tangent space normals makes no difference here (for reasons explained above). Both will work for your purposes. I can make some examples later if this is confusing.
"The point is no other converter's have this issue with the same input. Personally I'm wondering that unlike the other converters, it's using a bake cage system when all that is needed is a straight conversion on the same mesh."
Yeah when you're doing this sort of baking in Toolbag you're using the cage. Toolbag wasn't really designed for this purpose but it generally works. We have a number of people who do this sort of baking from LOD0 to lower LODs and Toolbag can translate normals (from TS or OS) and UVs. I don't expect the cage system is a factor here but it could be. You might consider Handplane if you need a dedicated tool for normal space conversion.
There may be a bug in the way Toolbag handles this object to tangent space conversion with UV instancing in the way you've set, and I'll make sure it's logged in our bug system. But even if we fix it it seems like you've got some problems with your workflow, and you'll be better off addressing those in the long term.
Now, as far as adding more geometry, I want to make it clear that I'm not suggesting adding more triangles or verts, what I am suggesting is using your geometry budget more effectively. Right now you have wildly inconsistent geometry use.
In the above image, you can see what I mean. With ideal topology, these red lines will have roughly a consistent length. This means that as your cylinders get wider and wider, they get more sides. Your topology seems to follow the opposite logic, where the bigger cylinders have the fewest amount of sides. This is the root of all of your problems. Your low poly isn't constructed well, so you're getting bad bakes, and this is causing you to invent these convoluted workflows where you bake to a mid poly and then to a low poly. You're causing yourself all sorts of problems trying to put band-aids on the symptoms of the problem rather than focusing on the cause.
The logical reduction in sides for concentric circles should look something like this. Not only will this help you better use your polygon budget, it should drastically improve the overall look of the asset. When you have small, nicely rounded areas, next to large faceted curves, it brings down the quality of the entire asset.
Additionally, you've got these tiny bevels all over the mesh that are eating a large portion of your polygon budget. If you redirect the inefficent polygon usage in this mesh to the areas that need it, you'll make your life a lot easier.
Let's put these ideas into practice. This mesh is 784 triangles. That's lower than the mesh bundled with the FBX file you sent (1080 triangles for the same area), though that mesh doesn't appear to be the same as the one in the .tbscene you sent (that one seems to have a few less bevels/edge loops). In any case, you can see that by killing those micro-bevels, and using a logical amount of sides for the width of each cylinder, we can represent these shapes more effectively and efficiently.
To drop the poly count even lower, you can reduce the innermost edge to something like 32 sides (48 currently). I was too lazy to do this.
This bakes great without any cage tweaks, mid-low baking, skew map painting, or anything else. Just load it and bake.
You could paint skew around indented area on the top with the 6 circles to straighten those out further, but due to the larger bevels on either side it isn't really necessary.
I've attached my low poly if you want to have a look.
TL;DR: It's not about adding more polygons, it's about using the polygons more efficiently and logically.
If vert count is the main concern you can get away with bevels if you otherwise would have used a hard edge and UV split. But it will increase the poly count, and most project specs will be defined in triangle count so it may be an uphill battle convince your art director or whoever comes up with the specs that true vertex count is what really matters.
The cock and ball UV layout is bad for a couple reasons:
1. It's hard to pack
2. You can use hard edges along the logical UV seams