The Polycount Newsfeed

To add to what's already been said and hopefully clarify a few things: there's a number of different reasons why an artist would choose to use a triangle instead of a quad when creating an arch. The relevance of any specific answer really depends on the model's intended use and the desired outcome for the project. Looking at those two images, it's not entirely clear whether this model is just a block out or a final low poly.

If it's a block out then it's possible that the triangles provide some additional edges that are required for subsequent modeling operations. Quad corners work well for most linear edge transitions and some types of curved intersections but they can also disrupt the curvature of adjacent edge loops. N-gon corners produce a similar effect.

While it can be beneficial to model with quads and n-gons, triangles can also be useful for pulling support loops inwards along a curve. Below is an example of how quad and n-gon corners can create subtle smoothing artifacts near curved surfaces. Converting these corner faces to triangles produces edge tension that can help reduce the visibility of smoothing artifacts near surfaces that transition from flat to curved.

If it's a low poly model then the mesh may need to be triangulated in certain areas to make seam placement and UV unwrapping easier. While most applications can display quads and n-gons, there are a variety of different triangulation methods and there's no guarantee that the order of the underlying edges and faces will be the same in every application. Which is why it's generally considered best practice to triangulate the final low poly model before exporting for baking and texturing. This will ensure that the model's geometry and smoothing behavior is consistent as it moves through the production pipeline.

Here's an example of just how varied the triangulation methods can be when moving the same mesh between two different applications. This sort of geometry miss match isn't a deal breaker for most simple modeling operations or basic material authoring but it can cause significant issues when working with tangent space normal textures.

Severe gradation in the normal map is often caused by the differences between the shading behavior of the high poly and low poly surfaces. This additional color information is specific to the state of the meshes during the bake. Alterations to the order of the low poly mesh will tend to produce normal artifacts, unless the difference between the shading behavior and baked normal information is resolved.

Which is why normal bakes from meshes without any smoothing splits tend to be sensitive to triangulation changes. The example below shows how the direction and intensity of the normal values changes, based on the low poly's shading splits and edge order.

While it possible to find workarounds for actively controlling mesh triangulation and using smoothing groups, these types of "Never fail, quick and easy!" solutions tend to ignore the fundamentals of established, current generation workflows. Granted there are some situations where it may be beneficial or necessary to use single smoothing groups or add support loops to the low poly or rely heavily on normal data transfers but a lot of the application specific workarounds tend to fall apart when working with a team that uses a wide variety of tools and regularly moves models between applications.

Creating a low poly model with consistent shading behavior goes a long ways towards making tangent space normal bakes a one or two shot deal. Adding smoothing groups is large part of that but controlling mesh triangulation is another important element in the optimization process. A lot of current, industry standard applications use MikkTSpace. Which makes it relatively easy to create assets in a synced tangent workflow. Yes, there are edge cases but that really isn't a good excuse for actively avoiding contemporary tools and workflows for content destine for popular engines like UE or Unity.

While this following example is far from best practice, it does demonstrate that using smoothing splits, in conjunction with a synced normal workflow, is fairly robust when it comes to accidental or unintentional changes in the triangulation after baking. All of the meshes have the same hard edges and only use the texture baked from the quad / n-gon low poly. Much less impressive when considering that the application automatically triangulated the low poly during the baking process but still a reasonable demonstration of how important it is to control the shading behavior with smoothing splits.

As shown below, when using a single smoothing group, even quad geometry doesn't guarantee that the triangulation order won't affect the surface shading and normal data. Using hard edges [smoothing groups] with a synced normal workflow tends to produce clean bakes that can be more resilient but curved surfaces and single smoothing group workflows tend to be more sensitive towards changes to the edge and face order after baking.

Another thing to consider about triangulation order is that the placement of the edges can skew surface details. Which, though it's often quite subtle, can have a negative impact on the overall quality of the bakes. In the example below, the diagonal surface elements have a slight distortion wherever a low poly edge crossed over a change in the high poly's surface.

While it may be possible to resolve some of these issues with a skew map or custom low poly cage, it's worth noting that the low poly that has a triangulation order with similar diagonal edges does have less overall distortion. Simple stuff like this can help avoid unnecessary complexity and extra work that comes with trying to resolve visible baking errors that are caused by letting the software choose the triangulation method on critical areas.

In a workflow with synced tangent space and smoothing splits, edge triangulation in low value areas can be largely ignored, provided it remains consistent during the baking, texturing and importing. However, it is worth running some quick test bakes to evaluate how the current low poly triangulation is affecting areas that are right in-front of the player.

The mesh used to demonstrate these principles is fairly simple, so the issues are quite subtle but carelessness towards these sort of things tends to compound in a way that produces a lot of small errors that bring down the overall quality of a project. Often with no tradeoff for a tangible benefit. Below is a short animation that compares a few different triangulation methods and better highlights how these changes impact the details baked into the normal texture.

There's a lot of great resources on these topics here on polycount and on the help pages of the various texturing applications. Here's a few links that are a good jumping off point for additional self guided learning:

https://polycount.com/discussion/41232/lowpoly-or-the-optimisation-appreciation-organisation

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

https://polycount.com/discussion/163872/long-running-technical-talk-threads

https://www.youtube.com/watch?v=ciXTyOOnBZQ

https://marmoset.co/posts/toolbag-baking-tutorial/

https://substance3d.adobe.com/documentation/spdoc/baking-109608997.html

Sharing my latest finished #blender Project, "Scout Drone".

Its a reference from Roc H's concept art, You can find more renders at: luischerub.com

Enjoy!

• The first step is to design the lowpoly precisely according to the reference art/high poly, placing edges to support these details (like, for instance, having an edge that runs along the connection between boot and sole).
• These edges can also be used for UV splits, that way material separations will be razor sharp and will never depend on texture resolution.
• You can of course also control the baking rays with a custom cage to avoid wavy cylinders, but that's a bit of an obvious one.
• And lastly, you can also rely on manually editing the resulting textures. And this will be especially easy and relevant if the UVs have been split along material separations.

Overall you need to let go of the idea of baking begin a blind "retopo then UVs then hit bake" chain of events because it really isn't. The quality of the result almost fully depends on the way the lowpoly geo is built ... just like with old school "pixel based" texturing on ps1/ps2 era models really. You will not be "fixing" these distortions, you'll need to model your low with them in mind in the first place. But of course if this is your first time with all this this is a bit of a chicken and egg thing :D

Here's an extreme example of the principles above :

Also note that this model didn't even use a highpoly to bake from - the whole look comes from applying the principles above + adding a nmap bevel all around the panels. But of course it could receive baked highpoly details too.

One last remark : once your lowpoly and UVs are taking shape you can also take a few minutes/an hour painting in landmarks with a simple brush, just to get a feel of how the texture distortion will behave.

I can only recommend the study of models from Nintendo games, they are extremely tight in all these areas. That's the beauty of them always developing on low-end hardware, as it forces them to make pristine assets that look good even with lowres textures (while avoiding the pitfall of spending days on highpoly models).