Baker: Convert Object to Tangent from Mirrored/Repeating Geometry Seam.

polycounter lvl 14
Offline / Send Message
oXYnary polycounter lvl 14
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

  • EarthQuake
    The shading with the object space normal map looks incorrect, so there is likely a problem with how that was set up. From the image it looks like you have a tangent space map, rather than an object space map, loaded in the input.

    Once you sort that out what you're trying to do here should work.
  • oXYnary
    Offline / Send Message
    oXYnary polycounter lvl 14
    Thats an Object/World space map; maybe my labeling makes it confusing.  Basically the input map was not a tangent space normal map if that helps since all these programs have different names for World/Object maps.  Ill put a static image below.  Also all other converters had no issue using the World/Object I baked out from Marmo.

    This isn't to scale/cropped, but so you can see that indeed this isn't a tangent space map I used as the input.


    Edit: Don't know if this will help any, but its not a mirror versus a repeating section (cylinder side is repeating in thirds versus straight mirror).
  • EarthQuake
    Okay, I was just looking at the tiny thumb and it looked like maybe it was a tangent space map. I see the different colors in there now hat you've posted the full size image.

    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.
  • oXYnary
    Offline / Send Message
    oXYnary polycounter lvl 14
    Here you go, I padded to hell obviously, but it was the easiest way to get it to you quick.  No difference.  I also attempted using the medium bake as the high with the object map and still had that seam.
  • EarthQuake
    oXYnary said:
    Here you go, I padded to hell obviously, but it was the easiest way to get it to you quick.  No difference.  I also attempted using the medium bake as the high with the object map and still had that seam.
    Okay I had a quick look at this, try offsetting the mirrored UVs outside of 0-1.
  • oXYnary
    Offline / Send Message
    oXYnary polycounter lvl 14
    Hmm, thought I did.  I wonder if that exporter shifted everything back.
    I'll  check the orginal file's and let you know, but in theory they should be.


    EDIT:

    Checked original file and the one from the export.  They are all outside the area.  Maybe your importer (Modo?), combined them?



  • EarthQuake
    oXYnary said:
    Hmm, thought I did.  I wonder if that exporter shifted everything back.
    I'll  check the orginal file's and let you know, but in theory they should be.


    EDIT:

    Checked original file and the one from the export.  They are all outside the area.  Maybe your importer (Modo?), combined them?



    I'll have another look. The mesh in the .fbx included had some overlapping UVs but it didn't seem to match the mesh in the scene so I wasn't sure.

    As an aside, is there some reason that you can't bake from the high poly?
  • oXYnary
    Offline / Send Message
    oXYnary polycounter lvl 14
    I did.  I'm doing the high poly bake to medium poly to lowest poly (that shares the same uv Island placement)

    Per scene and unused objects, I was only using one of the models in it for the test. I guess instead of exporting just the model in the scene, it exported the entire imported model list.  I believe the one in particular shown above is the base_irisA_low
  • EarthQuake
    oXYnary said:
    I did.  I'm doing the high poly bake to medium poly to lowest poly (that shares the same uv Island placement)

    Per scene and unused objects, I was only using one of the models in it for the test. I guess instead of exporting just the model in the scene, it exported the entire imported model list.  I believe the one in particular shown above is the base_irisA_low
    Sorry I mean, is there a reason you can't bake from the high poly directly to this mesh? Is it an LOD or something like that?

    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).
  • oXYnary
    Offline / Send Message
    oXYnary polycounter lvl 14
    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.

    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)

    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.

    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.


  • EarthQuake
    @oXYnary

    "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.
  • oXYnary
    Offline / Send Message
    oXYnary polycounter lvl 14
    @oXYnary

    "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.


    Thanks for logging it.  Thats all I needed. ;) 

    I cant justify the added polycount for as round as it needs to minimize the distortion.  I still work with engines that every vertices counts (and I have to make the LODs as well vs auto).  Hence again why I hope you guys can add a checkbox to follow traditional cage distance/direction with a imported cage and disable skew.  In most cases your system is working fine, but not on these lower poly cylinders where I need to keep the polycount low.  I am trying a cheat with a medium with higher amounts of sides but I then need to manually mix the caps into these to keep the roundness.  So photoshop is still in the workflow.

    FWIW, I did use the skew tool - it really didn't help, and it means I would have to do that for each and every side.

    EDIT: Here is the High poly of that area.

    P.S. I know your trying to help, and I appreciate it.  It's my own internal frustration of how long this asset group is giving me a headache. (100s of smaller objects and I have like 7 different marmofiles at 2-5gb each that I have to combine in substance in the end).
  • oXYnary
    Offline / Send Message
    oXYnary polycounter lvl 14
    Since I already have edits above I made a new reply, I did a test to show why OS/WS to Tangent is better for my purposes.  Note the curvature/lip on the top area thats very dull with the tangent2tangent.


  • EarthQuake
    I'll look more into the Tangent to Tangent case here. I did some tests and I'm seeing some weirdness so the tangents may not be converting correctly. I'm also seeing additional waviness introduced here by going from a mid-low poly mesh, so I think overall for this sort of purpose (converting OS to TS), you're better off using a tool like Handplane that uses UV matching rather than a cage-based system like Toolbag.

    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.


  • oXYnary
    Offline / Send Message
    oXYnary polycounter lvl 14
    Okay, I see, so you add polyies to the outer rim.  Using the border of the uv island for the sides to make a hard edge (since you get it for free) is a smart idea.  Something I wouldnt have thought of.

    I kind of did it with the redux medium bake I created to get the waviness down.


    You know that probably the biggest take away I should keep in mind.  That as you have stated elsewhere, UV island edges are split in engine, so you can make them hard edges/smoothing groups without vertex increase.  So instead of beveling, at edges where you have a UV island anyways, keep beveling to area that are in the same island.?

    An aside, the err "cock and balls," method of unwrapping a cylinder I assume is a bad idea as well?  Versus 3 islands (side/top/bottom).

  • EarthQuake
    Yeah so, since you had a UV seam there in your asset, I was able to add a UV seam and hard edge without increasing the vertex count. Since you had a bevel there, you could have unwrapped that without the seam, and generally that's why one would add a bevel, so you can keep a continuous UV layout in that sort of situation.

    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
Sign In or Register to comment.