> The guy is drawing like 100 quads

I'm curious about this. I always had the impression, mostly from reading Shamus Young, that there's no such thing as drawing something other than a triangle.

Blender guides tell you to divide your model into quadrilaterals. Though I did find one reddit post saying "I imported this model from a console game and it's all triangles. I thought models were supposed to use quads." The answer was "that model is finished, so it's in triangles because that's what you actually draw".

What's going on? Is there such a thing as drawing polygons with more than three sides? Why is the current advice "use quads" to the point that people don't even realize they're drawing triangles?

What is going on here is that modeling a mesh and rendering it are very different things. There are algorithms to edit a model that work best on quad based topology (e.g. selecting edge loops and others). That's why quads are preferable for editable "source" versions of 3d models. The conversion from quads to triangles is also a very fast algorithm.

GPUs rasterize triangles because they are a primitive type with very convenient properties: rasterization requires only a few basic math operations per pixel and triangles can never overlap themselves in projections, which quads can.

It's generally tempting to assume the mesh data that is edited in a DCC tool (Maya etc.) as the same as what is rendered. This couldn't be further from the truth because they need to be in completely different representations. For example, vertices on UV map seams need to be duplicated for rendering, but that would make editing the mesh extremely unwieldy. So the datastructures are totally different.

Well said.

It's built of triangles so a quad is 2 triangles etc.

The advice about using quads I'm not sure is really a tautology. I tend to work with quads until one of the quads is non-planar then I cut it so that when I bring it into a game engine the import/bake step doesn't triangulate the mesh in a way I didn't want it to.

Building out of quads is more about overall topology and the aesthetic result.

this is what i thought too. its sort of easier to see if ur topology is good / efficient. atleast for me.

opengl can do dots, lines, triangles, quads, ngons. just an option in the drawcall. pretty sure dx and vulkan will be the same but i didnt try em... what is more optimal.. idk.

maybe under the hood past the drawcall it will triangulate it. never bothered to look into that.

pretty sure the HW doesnt care one bit as it operates on vertices... not primitive shapes. (ofc like u note if ur quad is non planar it wont look like u expect but thats no concern for the driver or hw..)

I though about mentioning that but I didn't want to muddy the waters. There other option in opengl like you said but I can count on one had the times I've used them in a professional context and I think possibly zero for anything that I've shipped. Also I have never looked into what it does under the hood in those cases. You might be right.

The base primitive a GPU draws is triangles; they are the fastest primitive for math-y reasons, but the basic premise is that you can subdivide any triangle into two right-angle triangles, which have favorable properties for scanline-based rasterization.

Now, software modelling packages can represent geometry in any way they want, as long as that software package can somehow eventually transform that representation into triangles for the GPU to rasterize to pixels (barring custom software rasterizers).

My comment referred to quads, but at the end of the day, a quad is 2 triangles. Same goes for arbitrary polygons. The GPU speaks triangles.

this guy is unlikely to have read the games source or reversed it far enough to make these claims..what you see on the screen, how a game represents it on memory and how the translation between them works , can vary greatly.

that all being said. it is very easy to write bad code for games or use old features etc., we're all guessing unless some of you put a profiler and debugger to it... if so , show the money.

Jesus, dude. I was just pointing out that graphics driver defects very much can result in any number of difficult to diagnose issues. Yes, even decreasing performance over time, if the driver isn't releasing memory correctly and the system is starting to hit swap. There really is no telling for certain what is going on with graphics without having a deeper analysis across multiple, varied system configurations. Which is nigh inaccessible to hobbyist developers.

I guess I just wasn't willing to assume OP was basically incompetent and hadn't already done a basic algorithm review if their post about not being able to debug this issue made it this far.

I have to agree with the other person, comments like yours are annoyingly pedantic and just derails the conversation to a useless place. Like cmon, look at the game for a second, the chances of fps problems being due to him running on the Mx macbook pro (whether hardware or driver defects) is like 0.00001%.

A game like this should be running for like 1000+fps and this point should be emphasized in case the maker of this game is clueless when it comes to this kind of stuff, as his blog suggests (sharing an executable with users and asking for a recording is not how you would debug this perf issue) And it's totally fine if they are clueless, we all start somewhere. What sucks is derailing comments like yours that do the opposite and pretend that there is a conversation to be had here other than the implementation is probably terrible, which is, again, completely fine if it is, and we can talk about it and help them with it or point them in the direction of good resources about this stuff.

sorry for the rant, I just see these "akshually theoretically it could be due to blablabla" type comments on HN so much lately and I hate them