UV issue with no reason in sight.

rememba_da_name

As you can see here I UV mapped it fairly well and there is no UV overlap of the highlighted UV islands. But when baked in substance painter and in Marmoset these issues appear.

The issues circled are mirrored geometry so the issue is in 2 places. The low poly is in FBX format and the highpoly is in OBJ format since the high poly has massive issues when exported as an FBX file. What could the issue be?

rememba_da_name

I also found the issue shows up without the normal map applied so what could that mean?

Kanni3d

Can be dozens of possible issues. You can include your low poly for us to take a look and better diagnose

rememba_da_name

Kanni3d said:

Can be dozens of possible issues. You can include your low poly for us to take a look and better diagnose

Yep. I added the highpoly incase that helps somehow. 

Alex_J

Bakes fine for me. There was funky smoothing on the mesh. I unlocked normals in Maya, solved the problem.

Baked with default settings in Toolbag. Didn't change anything on mesh except unlock normals.

rememba_da_name

Alex Javor said:

Bakes fine for me. There was funky smoothing on the mesh. I unlocked normals in Maya, solved the problem.

Baked with default settings in Toolbag. Didn't change anything on mesh except unlock normals.

What do you mean by unlocked normals? All other parts of the model has zero baking issues. This error is happening on the model before it is even baked apparently. I dont know how to fix that. Also i use 3ds max 

FrankPolygon

There's some stray geometry in the low poly model: mostly zero area faces that are connected to adjacent vertices. Moving the inner edges of the transverse rail slots revealed some of this stray geometry and it looks like it may be left over from previous modeling operations. It's also worth mentioning that having too many long, thin triangles in fan shapes can be less than ideal and have a negative impact on baking and rendering performance.

Dissolving the excess geometry along the inside walls of the longitudinal slot and re-triangulating the mesh resolved all of the major issues and improved the triangulation. Double check the UV layout after cleaning up the geometry in case anything shifted and the unwrap needs to be adjusted.

There's also a significant amount of micro triangles along the outside edge of the rail profile and although this is an accurate representation of the object's actual shape it may not be worth the resources to represent such a minor detail in the low poly model. Merging down this excess geometry and relying on the normal map to add the illusion of this minor shape and depth change may be a better strategy.

rememba_da_name

FrankPolygon said:

There's some stray geometry in the low poly model: mostly zero area faces that are connected to adjacent vertices. Moving the inner edges of the transverse rail slots revealed some of this stray geometry and it looks like it may be left over from previous modeling operations. It's also worth mentioning that having too many long, thin triangles in fan shapes can be less than ideal and have a negative impact on baking and rendering performance.

Dissolving the excess geometry along the inside walls of the longitudinal slot and re-triangulating the mesh resolved all of the major issues and improved the triangulation. Double check the UV layout after cleaning up the geometry in case anything shifted and the unwrap needs to be adjusted.

There's also a significant amount of micro triangles along the outside edge of the rail profile and although this is an accurate representation of the object's actual shape it may not be worth the resources to represent such a minor detail in the low poly model. Merging down this excess geometry and relying on the normal map to add the illusion of this minor shape and depth change may be a better strategy.

No issue shows up in my modeling software(3ds max). I ran multiple tools checking for ngons, concave and convex faces, floating verts and there are none so i dont see how you fixed the issue as i dont see one even in the normals there is no issue. So i dont understand how to fix based on what youve said.

poopipe

The issues are highlighted in the image. That long edge is a disaster waiting to happen.


You had the same sort of issues with bad geometry in another thread recently, you are not taking the time to ensure that you have a clean mesh before you move on to stages of your workflow that require it.

As far as checking goes,  Just cos a mesh passes an automated check doesn't mean it isn't dirty.
Put a turbosmooth on that and you'll soon see where the problems are.

This is one of the most important articles on game art ever written.  I'd suggest reading it
https://artisaverb.info/Hygiene.html

If you're in any doubt, Google him -its a pretty impressive cv

rememba_da_name

poopipe said:

The issues are highlighted in the image. That long edge is a disaster waiting to happen.


You had the same sort of issues with bad geometry in another thread recently, you are not taking the time to ensure that you have a clean mesh before you move on to stages of your workflow that require it.

As far as checking goes,  Just cos a mesh passes an automated check doesn't mean it isn't dirty.
Put a turbosmooth on that and you'll soon see where the problems are.

This is one of the most important articles on game art ever written.  I'd suggest reading it
https://artisaverb.info/Hygiene.html

If you're in any doubt, Google him -its a pretty impressive cv

I dont understand the issues he is proposing. Ive never had an issue like this. Ive only ever had baking issues. This isnt related to baking since its there before the normal map is ever made. This issue also wasnt there when i made the previous bake with the issue in the picture below so it came out of nowhere.

Previous bake issue where this issue didnt exist.

I did turbosmooth the low poly which is how i made the highpoly and it has no issues visible. The line he said i need to remove is required by the UV software i use so i can bake without the uvs being distorted and having to manually move vertices inside of the UV program which takes hours extra a work not needed like in the pic below. I had to add extra lines manually so the UV program wouldnt round my models.

FrankPolygon

In this case, there's a couple of significant issues with the low poly geometry and the corresponding UV unwrap that are contributing the overall issues with the shading behavior and the normal baking artifacts. Certain types of overlapping geometry issues can cause intermittent baking artifacts that can seem to appear and disappear at random.

The fan of long, thin triangles that doesn't connect to the bottom edges of the last five rail slots is a clear indicator that something is wrong with the geometry there. Triangulating the mesh a second time doesn't resolve the issue so that rules out an n-gon and indicates that it's likely an improper edge connection or a zero area face issue.

Faces with zero surface area are essentially a form of overlapping geometry and in this case the zero area faces were flattened along an existing edge and triangulated so it's unlikely they would trip any of the basic automated checks. The software would have to check specifically for faces with zero surface area to detect the issue. Based on the sample models provided, it appears that this is a likely source of the issues with the low poly mesh.

A very simplistic explanation of what's happening is: the geometry components of the zero area faces are so small they aren't reliably catching ray hits and since this type of geometry error often produces overlapping UVs the ray hits that are counted may end up being overwritten by whichever larger face ends up being the last layer during the baking calculations. The effect of these zero area faces is similar to Z fighting just it's more isolated and appears on a much smaller scale. Any padding or ray leaks from earlier calculations can be left behind and this may be the source of the artifacts.

Depending on the software and baking settings this kind of geometry issue may not cause any major baking issues but it's definitely something to avoid because it can cause unexpected issues further along in the process.

Here's a closer look at the low poly geometry after it's imported and what the geometry of the zero area faces looks like when it's revealed by moving the long edge downwards.

Here's a closer look at waht the UVs look like. Notice how extensive the zero are geometry is when a small section of the UV island is moved. All of those triangles are zero area faces and they all fall along the bottom of the rail cut outs where the baking artifacts occur. If there's any kind of padding bleed, ray miss or some other kind of calculation error it's going to spill out along those edges and create artifacts.

Here's a clearer example of the issue with the zero area faces. Running a limited dissolve operation highlights the presence of the zero area faces and moving the long edge downwards reveals all of the superfluous geometry that was previously hidden.

Here's what the geometry should look like once it's been cleaned up and re-triangulated. Notice that there's still a significant amount of long, thin triangles. Depending on the baking results it may be advisable to add two or three extra loops across the inside of the slot to reduce the extreme length and angle of the triangles along the walls of the slot.

Here's another look at some of the extremely long, thin triangles along the outer profile. Moving the bottom edge downward provides a clearer look at what's going on inside of such a small area. Since this is a very small part of the model and it's unlikely that players will ever view this rail closely enough to notice the difference it's probably worth simplifying this area of the model.

rememba_da_name

Okay i get why its a problem now but what would cause those zero area faces to appear? I made this middle section with a rectangle boolean and added those small lines you removed so my UV software (RizomUV) wouldnt smooth the UV islands like it does if the mesh isnt triangulated. I didnt want to triangulate due to having ADHD and the million extra lines drives me crazy while i try to unwrap. I use a bridge from 3ds max to RizomUV so it never triangulates the mesh but just imports it to make it easy. So i dont get how those zero area faces appeared since i never technically modeled i just booleaned

Kanni3d

Depending on how exactly you booleaned it, the subtracting meshes probably weren't perfectly aligned to that edge, creating an ultra thin strip of polygons. Doing a global weld of a low threshold after your boolean may solve little issues like that.

Alex_J

rememba_da_name said:I didnt want to triangulate due to having ADHD and the million extra lines drives me crazy while i try to unwrap. 

About this, the thing to do is duplicate your quad mesh after UV'ing it. Triangulate that duplicate mesh and export it to be used for baking. Save it as a separate file, don't overwrite your quad version. 

So this way you just use the triangulated version for baking. But you have the quad mesh to use for the rest of the pipeline.

This is what I do, anyway. Is that technically right, guys who know more than me?

Kanni3d

Alex Javor said:

But you have the quad mesh to use for the rest of the pipeline.

Well, it isn't right or wrong, it's just being a bit non-destructive is all. Thing is, what use would the quad mesh be for the 'rest of the pipeline' when the pipeline is nearly final when you're exporting the triangulated mesh out of your DCC?

Once you're at the point of triangulating your mesh automatically/manually and exporting it out, there's not much else use in that saved quad mesh, unless you're going back for revisions/tweaks. 

Alex_J

There's always revisions/tweaks. At least for me.

Main thing is rigging, I use a quad mesh for that. I guess for a hard surface model there is little reason you'd need to be changing the topology due to things you learn during rig/animate.

poopipe

Triangulating the original mesh won't fix this one - it's got problems before you get to that stage.
 The Boolean operations have resulted in a complex non-convex ngon which is a complete  bastard to triangulate algorithmically - the modelling app has taken a best guess at what to do with it but in cases like this you'll almost always end up with something dirty and need to explicitly create edges to prevent problems like this
 
Also....   Because this is Max  you can simply add a turn to poly modifier to triangulate the mesh  for export, no need for any of the bullshit you have to deal with in maya and it remains completely non-destructive.

To add to what frankpolygon has said..
Personally I'd add a few vertices along the bottom edge of the clean mesh  so that you don't need such long thin triangles - thin triangles are hugely inefficient at render time (and are also ugly)

garrettia

This is an incredibly useful topic, sorry for reopening it after years.FrankPolygon can you recommend a source for your writings?

sacboi

The 3rd link is the forum's long running sub-d modelling thread located top of this tech section page and aside from pearls wisdom shared by Frank, I'll also recommend browsing through other contributions offered by many knowlegable mesh gurus, over the years 👍️

https://www.artstation.com/frankpolygon

https://polycount.com/discussion/221392/sketchbook-frank-polygon

https://polycount.com/discussion/56014/how-the-f-do-i-model-this-reply-for-help-with-specific-shapes-post-attempt-before-asking