Basics Q: Quads or tris when modeling?

[Jenni Darkwatch]

So I figured christmas is a good time to waste on mesh. Blender is too atrocious for me, and after mucking with a few programs I settled on Wings3D - still a crap proprietary UI, but at least halfway usable.

I figured the first thing to try was a simple marker buoy. Uploads fine, 3 LI at normal size (my fault, didn't optimize it). From what I read (and from ancient 3D experience) all surfaces must be quads or triangles. There's the first question... I only knew of triangles as render unit for realtime renders. Wiki says quads are fine too. Should I rather go for triangles when tesselating? Does it make any difference?

[Maeve Balfour]

Personally, both for SL and for prior experience in generic 3D dabbling, I have always preferred to model in quads. I guess I am biased towards box style modeling, having used programs that lean more towards this method of mesh making. (Also, for generic 3D rendering (non-realtime) such as Poser, it is preferable to have quad meshes otherwise glitches tend to appear in renders).

In regards to modeling for SL, I model in the same principle (quad-based) as it's easier for me. The only real adjustment I have made is using much lower polycounts for the realtime environment. When I have a mesh optimised as much as possible for each LOD, I simply convert the model to triangles. (I specifically import INTO Blender for this step, and then export the file as an .obj FROM Blender using its triangulate option, and then import the resultant model back into my preferred modeler. The reason is that Blender is far more efficient than my own modeler for this step (dividing each quad into TWO triangles; my own modeler tends to convert quads into FOUR triangles, which is bad for SL!).

After this basic conversion into tri's, I simple continue on as usual for UV-mapping / material mapping etc.

In regards to your question about the tesselating... I don't really know if it makes a difference. I'll let one of the experts answer that (you there Chosen or Drongle?) :smileyvery-happy:

So I guess overall... just model in the way you are most comfortable with. If you choose quads, it is a simple step to convert the finished model to Tri's prior to mapping etc.

:matte-motes-smile:

[Gaia Clary]

Using Quads has 2 more advantages:

 

1. Subdivision works more fuently (gives less artefacts when texturing).
2. Rigging and animation (for rigged meshes) gives typically much better results when you work with Quads.

However when it comes to optimizing meshes i found a nice method to lower the polycount but keep the shape mostly intact by using triangles at "strategic places". I show the idea in my Kettle Quest. (in parts III and IV i believe).

[Kwakkelde Kwak]

For convenience purposes, as has been said by the others, working in quads has some advantages.

As far as SL or any other renderer is concerned you can work in triangles, quads, pentagons, hexagons, etc... You mentioned the term already: tessellation. Before your model is rendered everything is tessellated into triangles. So a quad becomes two triangles, a pentagon becomes three triangles, a hexagon becomes four triangles etc.

The advantage of working in triangles (completely or partially), especially when working with complex objects with lots of curves and different sections, is you have better control over the uniformity of the polys. It's one of the big advantages of mesh over sculpts. A sculpt sphere for example (or the basic SL sphere) has very small polygons near the top and bottom, a lot smaller than you need for the detail you want. Using only quads there's no way around this so you use a lot more resources than is neccecary. With triangles you can keep every face the same size.

EDIT There's usually no need to turn your quads into triangles before uploading. The SL uploader will do the exact same thing. It will only matter if you have some curved planes where you need control over the way the two triangles make up the quad and in most builds this won't be the case.

The sphere on the left has 360 faces, the one on the right has 320 faces.The one on the right has more curve and more uniform curve.

[Chosen Few]

As far as the renderer is concerned, everything is tris. Anything more complex than that is a human construct, of which the renderer is not even aware.  As illustrated below, what we think of as a quad is just two tris that happen to be next to each other.  What we think of as a pentagon is either three tris or five.  What we think of as a hexagon is either four tris or six.  Etc.  At the rendering level, it's all triangles, no exceptions.

That's how any renderer sees it.  But there are always two other players involved, besides just whatever renderer is actually drawing the triangles.  One is the specific destination platform for which you're making the model.  The other is you, as a human artist.  Let's take them one at a time.

Some platforms can handle complex polygons just fine, while others will want everything broken down into tris beforehand. Most will at least accept quads.

However, even if you know you'll be working with a platform that doesn't care what the heck you feed it, it's still always best to triangulate your model by hand, before exporting it.  That's the only way to know for certain what your final poly count is going to be, and what the model's appearance will be. 

Even though you know a quad will break down into two triangles, you can't ensure which direction the dividing edge will run, unless you put it there yourself.  This can be incredibly important when a model is supposed to be symmetrical, for example, or when cleaning up any non-planar quads.  (Non-planar quads are BAD!) 

For more complex polygons than quads, all bets are off unless you control the triangulation yourself.  Is a pentagon three tris or five?  Is an octagon three quads, or is it six tris that all meet at one corner, or is it eight tris that all meet in the middle, or some other combination?  It's never a good idea to leave decisions like that up to the computer.

 

From a human work flow standpoint, it's generally easiest to work with quads.  As a species, we just tend to be pretty good at thinking in rectangles. 

Modeling by quads enable us to use edge loops, to control the geometric "flow" of a model.  For example, if you're modeling a human face, you want the geometry to flow in roughly the same way the real musculature would flow, so that when you animate the face, it can easily move in a realistic manner.   Take a good look at the avatar face, and you'll see what I mean.

It's not always possible to work entirely in quads, though.  Sometimes, the terminus of an edge loop just can't allow for the presence of an extra triangle to complete a quad.  In that case, best practice is generally to keep the quads flowing right up until that last polygon in the loop, and then use a triangle for the very last one.  You can see this on every longitudinal section of a default sphere, for example.  It's all quads except for the very top and very bottom, which each have to be tris, or else there would be no way to converge the geometry into poles.

 

If you think you can keep the structure of a model well organized by working entirely in tris, without regard for quadrangulation at all, there's no law that says you can't.  You'll find it to be quite a chore, though.  The results are likely to be pretty discordant.  Although you'll probably save some polygons, you'll find that a lot of otherwise basic things will become much harder to do, like UV'ing, rigging for animation, etc.  Without a clear flow of edge loops, it all gets very chaotic and tough to manage, very quickly. 

Also, working in quads enables you to easily step up the tesselation for better texture baking, normal mapping, etc., in programs like Zbrush or Mudbox, and then easily applying the results to the original low-poly model.  If it's all tris, with no quad structure to it, the divisions end up uneven, and anything baked from the high-poly version are less likely to be well applicable to the low-res version.

Lack of quadrangulation is generally considered sloppy modeling, for most purposes. 

 

The way I usually work is this.  Wherever possible, I'll work entirely in quads, adding the odd tri her and there, as necessary.  After everything else is done, as a near-final step, I'll triangulate the model, and correct any backwards splits.  (Maya makes this really easy to do.  There's a Quad Split attribute for the mesh itself, which will dictate split direction before the triangulation even happens, plus a  Flip Triangle Edges tool, to correct any mistakes after the fact.)  After triangulation, I'll go through, and look to see if the are any extraneous polygons that don't really need to be there.  If I find any that can be done away with, without screwing up the UV map, then I'll ax them.  After that, the model is ready for export.

That strategy is just a generalized best practice, though, nothing more.  Every model is different, obviously.  Some lend themselves better to different approaches than others.

[Jenni Darkwatch]

Thank you all very kindly, that cleared up one question. Not having to worry about quad/triangle is nice, though I think as the last step I'll go ahead and tesselate so I can see what the outcome is before uploading.

[Kwakkelde Kwak]

Although Chosen gave a very extensive and complete explanation, I'd like to add one more thing in favour of the quad over the triangle. Since light in SL usually hits objects from above, horizontal edges will give you smoother shadows than fractal ones that are the result of triangles.

[Angel Alphaville]

.

[Gaia Clary]

---

Angel Alphaville wrote:

May I finally ask,

what on earth

have subdivisions got to do with modelling for Second Life at its current state (lacking stuff like normal maps, for which workflows with subdivisions are meaningful) ?

---

I use subdivisions when i work with box modelling. I thought this is common practice and i apologize for any confusion. Here is a short summary of modelling with subdivisions as i found it was a very practical approach also for Second Life:

 

1. first i create a low polygon model.
2. then i add 1 or 2 subdivisions to it (using blender and a subdivision modifier) and work out more details.

When i am done with my model, i typically use following procedure to create the LODS:

 

1. The subdivision modifier allows me to "apply" the modifier with different Subdivision settings. So i can create copies of the original model and for each copy i apply the modifier with a different level of subdivisions to the mesh ( i usually use 2 subdivision levels such that i later can get 3 LOD levels out of my original model)
2. Then in a final step i optimize each copy for SL. At the end i have 3 levels of detail for the Importer.
3. For the lowest LOD i usually do some special treatment (like billboarding for example)

 

---

Angel Alphaville wrote:

Please , will you ever stop spreading confusion ? Since you keep ehm.. promoting (

spamming us with

) your web site, then you should at least be more responsible, you know.

---

I apologize if my contributions here are considered as spam.

[Kesiika Markova]

There is absolutely no need to snap on Gaia.. The lacking of normal map shader support in SL doesn't mean we don't bake normal maps from hires models and than rebake them back into the texture. So basically Gaia is correct. If you want to produce nice normal maps, your model should "play" with the lighting nicely. Not to mention, why on earth you assume those models will be used only in SL? So.. go hug someone/something please and chill.

I will not event start commenting on the "Spam" remark...

 

Best regards

[Jenni Darkwatch]

Most definitely not spam. Btw, that low-to-high is an interesting technique. I kinda go the other way around, but I'm also still stuck in the last century when it comes to practical knowledge about 3D renders. Software renders, no room to store different LODs etc.pp.

Lots of new things to learn, I'm afraid.

[Angel Alphaville]

.

[Gaia Clary]

---

Angel Alphaville wrote:

Be my guest to comment on my remark. It still stands, and it was precicely meant to be annoying, just like truth is annoying. Someone has to do the dirty job. There you go. Next time you see a mesh plank with 20 rows and 3 columns between its edges in-world, ask yourself whose "tutorial" site was followed.

---

Would you please tell me to which tutorial you refer ? I am eager to learn from you where i make errors and where i misslead people.

[Pamela Galli]

---

Angel Alphaville wrote:

"Subdivision works more fuently"

 

May I finally ask,

what on earth

have subdivisions got to do with modelling for Second Life at its current state (lacking stuff like normal maps, for which workflows with subdivisions are meaningful) ?

Please , will you ever stop spreading confusion ? Since you keep ehm.. promoting (

spamming us with

) your web site, then you should at least be more responsible, you know.

---

We all know who Gaia is, from her help here, her many videos, her help inworld -- all of which time and effort she donates -- but WHO tf are you and what have you ever done that qualifies you to criticize and insult her?

 

 

[Pamela Galli]

Why are we talking about how reindeer see quads?

 

Oh wait...nevermind.

[Chosen Few]

---

Angel Alphaville wrote:

May I finally ask,

what on earth

have subdivisions got to do with modelling for Second Life at its current state (lacking stuff like normal maps, for which workflows with subdivisions are meaningful) ?

---

I think there may be a mixup in terminology going on here. I'll therefore offer two responses to your question, Angel.  The first will assume you misunderstood Gaia's use of the word "subdivision".  The second will assume you did not.

 

Answer 1:

It's possible you might have misinterpreted Gaia's use of the word "subdivision" to mean she was talking about subdivison surfaces (commonly referred to as "subdivs" or "subD's").

In case anyone's unfamiliar with the term, subdivs are the newest of the three major types of surface models.  Polygons came first, then NURBS, then subdivs.  A very oversimplified way of describing it is subdivs employ polygon-like framework, along with NURBS-like display properties.  The math behind how sudivs work is mind boggling, way too complex for processing in any realtime engine.  Most modeling programs can't even handle subdivs.  Among the ones that can, each handles them a little differently.  Subdiv models aren't really directly transferrable from program to program, the way polygonal models are.

If that's indeed what you thought was being talking about, Angel, then from that point of view, you here correct to suggest there's no point in discussing subdivs with respect to SL.  However, since that's most certainly was not what Gaia was talking about, your rationale for even bringing it up was ill conceived.

 

 

Answer 2:

From how I read it, Gaia was using the term "subdivision" quite generically, as in "If you take one quad and subdivide it, you get four quads".  If you did understand that that's what she meant, but you still don't see how it's applicable to modeling for SL, then I'm afraid you've got me a bit dumfounded.  Subdividing is one of the most basic techniques in polygonal modeling.  It's applicable to EVERYTHING.

Anyone else suddenly reminded of Airplane II?  "Coming in low is part of every textbook approach.  It's just something you have to do when you land."

With respect to things like normal maps, you're obviously correct that SL can't utilize them (yet).  But that doesn't mean there's nothing to be gained by subdividing a model to a very high poly count, for texturing purposes.  It's often very advantageous to step up a model in a program like Zbrush or Mudbox, or even directly in your main modeling program, in order to bake better looking textures from it. Even without normal mapping to enhance it, a texture baked from the high-poly surface will almost always look better than one baked directly from its low-poly counterpart.

 

---

Angel Alphaville wrote:

 

Please , will you ever stop spreading confusion ?

---

Are you serious?  You think Gaia, of all people, spreads confusion?  Wow.

Gaia has done more to educate this community than just about anyone else I can think of.  She and her Machinimatrix team practically single handedly revolutionized the way Blender is taught, making it easily understandable to SL users in a way that was never before possible.

The amount of people on this forum about whom I can hontestly say, "This person really knows his/her sh!t," I can count on one hand.  Gaia is solidly among that number.

By claiming otherwise, it is you, not Gaia, who is "spreading confusion".

 

---

Angel Alphaville wrote:

Since you keep ehm.. promoting (

spamming us with

) your web site, then you should at least be more responsible, you know.

---

I fail to see how voluntarily producing tutorials, and then freely offering them to the community for no charge whatsoever could possibly be defined as "spam". 

Have you even looked at the site?  Its only purpose is to provide good information. 

I'm sorry if you maybe happent to be one of those strange people who simply can't believe that anyone would so freely volunteer to help a community, without any alterior motive.  Lord knows we've seen our share of those types come and go on this forum.  But that doesn't mean that's not in fact what Gaia has been doing all this time.  If you can't bring yourself to thank her for that, at least do us all the courtesy of not trying to make her out to be something she's not.

[Chosen Few]

---

Pamela Galli wrote:

Why are we talking about how reindeer see quads?

 

Oh wait...nevermind.

---

 

[Chosen Few]

---

Angel Alphaville wrote:

Be my guest to comment on my remark. It still stands, and it was precicely meant to be annoying, just like truth is annoying.

---

So you admit you're a troll whose intent was to stir up people's emotions, rather than contribute in any meaningful way to the discussion? I think we all already pretty much figured that was the case.  I'm glad you're honest with yourself about it, though.  Many trolls are not.

 

---

Angel Alphaville wrote:

Someone has to do the dirty job. There you go.

---

If your goal actually were to disseminate the truth, why would that be a "dirty job"?  Why not simply offer the correct information, and call it a day?

Contrary to your opening statement, there's nothing "annoying" about the truth.  The facts of 3D modeling are neither annoying or non-annoying.  They simply are.  There's no need to assign any emotional judgment to such mundane things.

 

---

Angel Alphaville wrote:

Next time you see a mesh plank with 20 rows and 3 columns between its edges in-world, ask yourself whose "tutorial" site was followed.

---

Care to post a link to the tutorial in question?  I've been up and down the site, and I have yet to find a tutorial on making mesh planks.

Once again, I feel compelled to ask, have you actually looked at the site yourself?

 

---

Angel Alphaville wrote:

If you feel like being prominent and seriously contributing then you should be responsible and know what you're doing.

---

How about showing us even the slightest evidence that YOU know what you're doing?  You're quick to try to tear down a frequent contributor, but you have yet to demonstrate that you have any knowledge of the subject at hand yourself.

If you think someone's advice isn't the best, then offer a better alternative.  That's the only true way to be "responsible", isn't it?

 

---

Angel Alphaville wrote:

Sub-division based "workflows" should be mentioned with caution, because they actually belong in the game modelling world outside the time bubble that Second Life currently is trapped into.

---

So no one should ever subdivide anything ever, when making models for SL?  I really have to ask, have you ever made a mesh model yourself?  It's pretty tough to do without ever subdividing a thing. 

I'm not sure what you mean by suggesting that use of subdivided models is OK for games.  As a professional in the field, I can promise you I've never put the high-poly version of any of my models into any game, ever.  I up the poly count in order to have a suitable surface from which to bake textures and any other applicable maps, and then I apply those to the low poly version.  That's standard practice in the industry.

 

---

Angel Alphaville wrote:

Anyway, my turn to apologize, not for being annoying (it was my precise and literal intention), but for the potential derailing of the thread which started to be about concerns more to the point, like rigging as she correctly mentioned, or how the quads or triangles go along with the renderers, or the in-world lighting system.

---

Had you not been annoying, the thead would never have been in any danger of derailment, and you know it.  We're now all talking about how annoying you are, instead of reamining on topic.  If that wasn't what you wanted, you could simply have said, "I disagree with that particular point, and here's why."  Had you done that, we would be discussing the point itself, instead of the manner in which you presented it. 

Clearly your goal was to be disruptive, rather than contributory in any way.  Trying to pretend otherwise at the very end doesn't change that.  Nobody's falling for it.

[Kavorka]

I dont think anyone mentioned this, but an other reason to use quads is to teach yourself how to make a clean mesh.  If you were to ever want to get a job in the industry and show an all tri model to a comapany they would just laugh and dismiss you.  A nice clean mesh shows that you know what you are doing.

 

I generally dont subdivide my entire model when making SL models, but I sure do add edge loops, which are just impossible when there are tris in the way.  Also, I often create a high res model that I then back an AO map onto because if you bake an AO map onto a low poly model, you get a lot of hard edges showing in your texture and ends up showing just how low poly it is.  Using the AO map from the high poly version gives an illusion of a higher poly model.

Whether you utilize it or not, trying to keep quads is a good practice as it will teach you to be a better modeler and may even help you out somewhere along the way.

[LindaB Helendale]

---

Chosen Few wrote:

However, even if you know you'll be working with a platform that doesn't care what the heck you feed it, it's still always best to triangulate your model by hand, before exporting it.  That's the only way to know for certain what your final poly count is going to be, and what the model's appearance will be. 

Even though you know a quad will break down into two triangles, you can't ensure which direction the dividing edge will run, unless you put it there yourself.  This can be incredibly important when a model is supposed to be symmetrical, for example, or when cleaning up any non-planar quads.  (Non-planar quads are BAD!) 

For more complex polygons than quads, all bets are off unless you control the triangulation yourself.  Is a pentagon three tris or five?  Is an octagon three quads, or is it six tris that all meet at one corner, or is it eight tris that all meet in the middle, or some other combination?  It's never a good idea to leave decisions like that up to the computer.

 

SL mesh uploader triangulates the polygons (specified by <polylist> block) by drawing edges from the first vertex in the list to all other vertices, which is not so good way to do it.

A hexagon is triangulated like this

 

 

 

 

 

 

 

Quads are done the same way, so for quads you could let the mesh uploader do it, but not for any polygon with more than four vertices.

 

[Chosen Few]

---

LindaB Helendale wrote:

SL mesh uploader triangulates the polygons (specified by <polylist> block) by drawing edges from the first vertex in the list to all other vertices, which is not so good way to do it.

A hexagon is triangulated like this

 

 

 

 

 

 

 

Quads are done the same way, so for quads you could let the mesh uploader do it, but not for any polygon with more than four vertices.

---

Thanks, Linda.  It's good to know what the methodolgy actually is.  I agree with you that it's not the greatest way to go about it, but I get why it's set up that way.

All the more reason to triangulate manually beforehand.

[Kwakkelde Kwak]

---

LindaB Helendale wrote:

SL mesh uploader triangulates the polygons (specified by <polylist> block) by drawing edges from the first vertex in the list to all other vertices, which is not so good way to do it.

A hexagon is triangulated like this

 

 

 

 

 

 

---

 

Ok, educate me here. The behaviour of lighting on this hexagon would be different from one where the lower triangles would be mirrored horizontally, but I really don't see why this is "not so good". When it's flat I see no disadvantage at all to be honest.

---

LindaB Helendale wrote:

Quads are done the same way, so for quads you could let the mesh uploader do it, but not for any polygon with more than four vertices.

---

This is just not true. As both Chosen and I said earlier, the way light hits a quad when bent, is affected by the orientation of the triangles within it.

Two quads with the same vertice pulled up, as you can see they are nothing alike.

[Kwakkelde Kwak]

---

Chosen Few wrote:

 

That's how any renderer sees it.

---

Are there really renderers that convert polygons the way they are drawn on the far right? I can see how a shape like that is useful in some cases, but it's no longer a polygon by definition. It's a flat pyramid.

[Gaia Clary]

Yes! Apologize in advance for adding more spam :matte-motes-sunglasses-3: : See quads in action:

have fun, or ignore.

[Jenni Darkwatch]

---

Kwakkelde Kwak wrote:

---

LindaB Helendale wrote:

SL mesh uploader triangulates the polygons (specified by <polylist> block) by drawing edges from the first vertex in the list to all other vertices, which is not so good way to do it.

A hexagon is triangulated like this

 

 

 

 

 

 

---

 

Ok, educate me here. The behaviour of lighting on this hexagon would be different from one where the lower triangles would be mirrored horizontally, but I really don't see why this is "not so good". When it's flat I see no disadvantage at all to be honest.

---

LindaB Helendale wrote:

Quads are done the same way, so for quads you could let the mesh uploader do it, but not for any polygon with more than four vertices.

---

This is just not true. As both Chosen and I said earlier, the way light hits a quad when bent, is affected by the orientation of the triangles within it.

Two quads with the same vertice pulled up, as you can see they are nothing alike.

---

Oke this is getting waaaay geekier than I had thought ~g~ Apologies if I use old, outdated, ancient terminology but... back in the day of software shaders, there was a (fast) way to shade polygons if shading was desired, i.e. to make any surface appear curved even at low triangle count. It was called Gouraud Shading, pretty simple math interpolation really. A better shader was Phong Shading, which I'd guess is what's in use in SL.

Based on how the uploader provides a way to allow for the automatic generation of normal maps I'd guess SL has a similar mechanism in place. Forgive me for not verifying the source code. I did however try it with a test object. For all intents and purposes the SL shader seems to ignore triangle orientation _if_ the surface is normal mapped. If not, your distinction is of course correct, though in that case I'd thing the edge is intentionally placed by the person modeling it.