<p>I think it is commonly accepted that real time is everything that is above interactive. And interactive is defined as "responds to input but is not smooth in the fact that the animation seems jaggy".<br>
So real time will depend on the speed of the movements one needs to represent. Cinema projects at 24 FPS and is sufficiently real time for many cases.</p>

<p>Then how many polygons a machine can deal with is easily verifiable by checking for yourself. Just create a little VBO patch as a simple test and a FPS counter, many DirectX or OpenGL samples will give you the perfect test bed for this benchmark.</p>

<p>You'll find if you have a high end graphics card that you can display about 1 million polygons in real time. However, as you said, engines will not claim support so easily because real world scene data will cause a number of performance hogs that are unrelated to polygon count.</p>

<p>You have:</p>

<ul>
<li>fill rate

<ul>
<li>texture sampling</li>
<li>ROP output</li>
</ul></li>
<li>draw calls</li>
<li>render target switches</li>
<li>buffer updates (uniform or other)</li>
<li>overdraw</li>
<li>shader complexity</li>
<li>pipeline complexity (any feedback used? iterative geometry shading? occlusion?)</li>
<li>synch points with CPU (pixel readback?)</li>
<li>polygon richness</li>
</ul>

<p>Depending on the weak and strong points of a particular graphic card, one or another of these points is going to be the bottleneck. It's not like you can say for sure "there, that's the one".</p>

<p>EDIT:</p>

<p>I wanted to add that, one cannot use the GFlops spec figure of one specific card and map it linearly to polygon pushing capacity. Because of the fact that polygon treatment has to go through a sequential bottleneck in the graphics pipeline as explained in great detail here:  <a href="https://fgiesen.wordpress.com/2011/07/03/a-trip-through-the-graphics-pipeline-2011-part-3/" rel="nofollow">https://fgiesen.wordpress.com/2011/07/03/a-trip-through-the-graphics-pipeline-2011-part-3/</a><br>
TLDR: the vertices have to fit into a small cache before primitive assembly which is natively a sequential thing (the vertex buffer order matters).  </p>

<p>If you compare the GeForce 7800 (9yr old?) to this year's 980, it seems the number of operations per second it is capable of has increased one thousand fold. But you can bet that it's not going to push polygons a thousand times faster (which would be around 200 billion a second by this simple metric).</p>

<p>EDIT2:</p>

<p>To answer the question "what can one do to optimize an engine", as in "not to lose too much efficiency in state switches and other overheads".<br>
That is a question as old as engines themselves. And is becoming more complex as history progress.  </p>

<p>Indeed in real world situation, typical scene data will contain many materials, many textures, many different shaders, many render targets and passes, and many vertex buffers and so on. One engine I worked with worked with the notion of packets:</p>

<p>One packet is what can be rendered with one draw call.<br>
It contains identifiers to:</p>

<ul>
<li>vertex buffer</li>
<li>index buffer</li>
<li>camera (gives the pass and render target)</li>
<li>material id (gives shader, textures and UBO)</li>
<li>distance to eye</li>
<li>is visible</li>
</ul>

<p>So the first step of each frame is to run a quick sort on the packet list using a sort function with an operator that gives priority to visibility, then pass, then material, then geometry and finally distance.</p>

<p>Drawing close objects gets prirority to maximize early Z culling.<br>
Passes are fixed steps, so we have no choice but to respect them.<br>
Material is the most expensive thing to state-switch after render targets.  </p>

<p>Even in-between different materials IDs, a sub-ordering can been made using a heuristical criterion to diminish the number of shader changes (most expensive within material state-switch operations), and secondly texture binding changes.  </p>

<p>After all this ordering, one can apply mega texturing, virtual texturing, and attribute-less rendering (<a href="http://renderingpipeline.com/2012/03/are-vertex-shaders-obsolete/" rel="nofollow">link</a>) if deemed necessary.  </p>

<p>About engine API also one common thing is to defer the issuing of the state-setting commands required by the client. If a client requests "set camera 0", it is best to just store this request and if later the client calls "set camera 1" but with no other commands in between, the engine can detect the uselessness of the first command and drop it. This is redundancy elimination, which is possible by using a "fully retained" paradigm. By opposition to "immediate" paradigm, which would be just a wrapper above the native API and issue the commands right as ordered by client code. (<a href="http://virtrev.git.sourceforge.net/git/gitweb.cgi?p=virtrev/virtrev;a=tree;f=coding/opencl_opengl_sharing/src;hb=HEAD" rel="nofollow">example: virtrev</a>)</p>

<p>And finally, with modern hardware, a very expensive (to develop), but potentially highly rewarding step to take is to switch API to metal/mantle/vulkan/DX12-style and preparing the rendering commands by hand.  </p>

<p>An engine that prepares rendering commands creates a buffer that holds a "command list" that is overwritten at each frame.</p>

<p>Usually there is a notion of frame "budget", a game can afford. You need to do everything in 16 milliseconds, so you clearly partition GPU time "2 ms for lightpre pass", "4 ms for materials pass", "6 ms for indirect lighting", "4 ms for postprocesses"...</p>

CC BY-SA 3.0
2015-12-14T09:00:57.703Z
A million seems a bit low to me.
joojaa
CC BY-SA 3.0
2015-12-14T09:30:38.697Z
just take how many MPoly/s the card is capable of, and that's the FPS at which it will render 1 million. I just recalled an experiment for a terrain renderer on an ATI4800HD. If you take this list https://en.wikipedia.org/wiki/List_of_Nvidia_graphics_processing_units they don't give Vertices/s info starting from the era of unified architecture. but 10 year old hardware seems to advertise about 40 FPS for 1 million triangles. + c.f. edit in my answer
v.oddou
CC BY-SA 3.0
2015-12-14T13:49:23.330Z
@v.oddou Yeah, but to get near that number you need to do batching of geometry, or instancing, in case of dynamic scenes, and **that** is what I'm asking about. How to not bottleneck yourself 2% of the way towards what hardware can do.
Llamageddon
CC BY-SA 3.0
2015-12-15T01:47:59.120Z
@Llamageddon aaah, I see, THAT is a question indeed. Let me see what I can say about it. (EDIT2)
v.oddou
CC BY-SA 3.0
2015-12-17T12:50:50.273Z
Great in depth answer! I've made a few minor edits, as a user rather than a moderator. Feel free to roll back any/all if they don't match your intention.
trichoplax is on Codidact now
CC BY-SA 3.0
2015-12-14T02:15:36.533Z
2016-10-18T13:38:34.603Z
2016-10-18T13:38:34.603Z
v.oddou
<p>In my experience using VBO allows to render model consisting of 500 million triangles in realtime (more then 20 fps) on NVidia RTX 2080 videocard.</p>
<p>Model size is 8GB, there is 11GB available video memory</p>

CC BY-SA 4.0
2021-09-17T12:52:23.857Z
2021-09-17T12:52:23.857Z
George Vinokhodov
<p>A fairly basic, in some ways, question, but one that many people, myself included, don't really know the answer to. GPU manufacturers often cite extremely high numbers, and the spread between polygon counts that various game engines claim to support often spans multiple orders of magnitude, and then still depends heavily on a lot of variables.</p>

<p>I'm aware that this is a broad, pretty much open-ended question, and I apologize for that, I just thought that it would be a valuable question to have on here nonetheless.</p>

CC BY-SA 3.0
2015-12-10T09:51:04.117Z
I don't think the question's necessarily too open-ended, but any numeric answer is going to be wrong within 12 months.
Dan Hulme
CC BY-SA 3.0
2015-12-10T18:47:56.763Z
@DanHulme Yeah, but the approaches used to reach that kind of efficiency stay the same. And when not, I've seen questions that require updating answers periodically on other stackexchange sites, so I think that's fine.
Llamageddon
CC BY-SA 3.0
2015-12-11T06:39:54.973Z
This is really impossible to answer. First of all, what is "realtime"—60fps? 30? Less? Second, the answer will vary hugely based on what GPU you have and what resolution you're rendering at. Third, the answer will vary hugely depending on the details of how the rendering works. Limits on scene complexity are more complicated than just the number of polygons per se, but involve such things as the number of draw calls, state changes, render passes and so on—which are affected by how the engine works, how the artists constructed the scene, and so on...
Nathan Reed
CC BY-SA 3.0
2015-12-11T12:31:49.687Z
@NathanReed And those are precisely what I'm asking about, the number itself isn't important, and likewise, realtime is loosely defined here as well, although personally I'd go with being able to maintain a framerate above 30. The question itself is about techniques and approaches used to minimize costs per frame, I just couldn't think of a better way to title and phrase it.
Llamageddon
CC BY-SA 3.0
2015-12-12T00:39:01.593Z
@Llamageddon Considering your comments, I'm not quite sure what you actually ask for. On one hand, your question title is quite clear (max out geometry and how to do so), but as Nathan pointed out, this is kind of impossible to answer. On the other hand, in your comments you say you want to know how to minimize cost per frame. This is an extremely broad question, because you could improve/optimize your shaders, scene graph, models, textures, API usage, simply everything that does some part of your rendering. You could probably write entire books about this (if not done by someone already).
Nero
CC BY-SA 3.0
2015-12-12T23:32:10.617Z
@Nero As I said, it's a broad question, I'm interested in all kinds of techniques utilized to push hardware to the limits - occlusion culling, scene graph management, batching, instantiation, virtual texturing, deferred rendering, etc. Setting aside implementing more than just the baseline of geometry, shadows, basic shading, but inclusive of everything leading up to that. I'm sorry if it's a bad question.
Llamageddon
CC BY-SA 3.0
2015-12-14T02:19:57.877Z
The more you stuff every technique in one program (what usually an engine does) you are not pushing the hardware to the limits, on the contrary you give it many opportunities to breathe. The way to use the hardware at max capacity is what OCCT does. only a benchmark can do this.
v.oddou
CC BY-SA 3.0
2015-12-14T02:56:24.510Z
@v.oddou I'd say it's still pushing it to its limits, just in a smarter way. I'm not necessarily interested in super-advanced techniques, just how to... ugh, honestly, I thought this question would be self-explanatory, I even gave examples of what I mean. I just give up, honestly. It's like you guys are literally trying to interpret the question word-by-word instead of actually considering it. Should I just write a wiki answer and let others correct me where I'm wrong or miss something? :/
Llamageddon
CC BY-SA 3.0
2017-04-09T15:42:59.287Z
this is a bit late, but [here](https://i.sstatic.net/nKqSd.jpg) you can see a STATIC mesh with 24.000.000 Vertices in Blender.
And i can rotate it SMOOTH with 40 FPS. I think it is just amazing what modern graphic cards can do.
user6420
<gpu><optimisation>
How many polygons in a scene can modern hardware reach while maintaining realtime, and how to get there?
Llamageddon
# How many polygons in a scene can modern hardware reach while maintaining realtime, and how to get there?

(Asked by: username_0 on 2015-12-09)

A fairly basic, in some ways, question, but one that many people, myself included, don't really know the answer to. GPU manufacturers often cite extremely high numbers, and the spread between polygon counts that various game engines claim to support often spans multiple orders of magnitude, and then still depends heavily on a lot of variables.

I'm aware that this is a broad, pretty much open-ended question, and I apologize for that, I just thought that it would be a valuable question to have on here nonetheless.

**Tags:** gpu, optimisation

> **Comments:**
> **username_1**: I don't think the question's necessarily too open-ended, but any numeric answer is going to be wrong within 12 months.  
> **username_0**: @username_1 Yeah, but the approaches used to reach that kind of efficiency stay the same. And when not, I've seen questions that require updating answers periodically on other stackexchange sites, so I think that's fine.  
> **username_2**: This is really impossible to answer. First of all, what is "realtime"—60fps? 30? Less? Second, the answer will vary hugely based on what GPU you have and what resolution you're rendering at. Third, the answer will vary hugely depending on the details of how the rendering works. Limits on scene complexity are more complicated than just the number of polygons per se, but involve such things as the number of draw calls, state changes, render passes and so on—which are affected by how the engine works, how the artists constructed the scene, and so on...  
> **username_0**: @username_2 And those are precisely what I'm asking about, the number itself isn't important, and likewise, realtime is loosely defined here as well, although personally I'd go with being able to maintain a framerate above 30. The question itself is about techniques and approaches used to minimize costs per frame, I just couldn't think of a better way to title and phrase it.  
> **username_3**: @username_0 Considering your comments, I'm not quite sure what you actually ask for. On one hand, your question title is quite clear (max out geometry and how to do so), but as username_2 pointed out, this is kind of impossible to answer. On the other hand, in your comments you say you want to know how to minimize cost per frame. This is an extremely broad question, because you could improve/optimize your shaders, scene graph, models, textures, API usage, simply everything that does some part of your rendering. You could probably write entire books about this (if not done by someone already).  
> **username_0**: @username_3 As I said, it's a broad question, I'm interested in all kinds of techniques utilized to push hardware to the limits - occlusion culling, scene graph management, batching, instantiation, virtual texturing, deferred rendering, etc. Setting aside implementing more than just the baseline of geometry, shadows, basic shading, but inclusive of everything leading up to that. I'm sorry if it's a bad question.  
> **username_4**: The more you stuff every technique in one program (what usually an engine does) you are not pushing the hardware to the limits, on the contrary you give it many opportunities to breathe. The way to use the hardware at max capacity is what OCCT does. only a benchmark can do this.  
> **username_0**: @username_4 I'd say it's still pushing it to its limits, just in a smarter way. I'm not necessarily interested in super-advanced techniques, just how to... ugh, honestly, I thought this question would be self-explanatory, I even gave examples of what I mean. I just give up, honestly. It's like you guys are literally trying to interpret the question word-by-word instead of actually considering it. Should I just write a wiki answer and let others correct me where I'm wrong or miss something? :/  
> **username_5**: this is a bit late, but [here](https://i.sstatic.net/nKqSd.jpg) you can see a STATIC mesh with 24.000.000 Vertices in Blender. And i can rotate it SMOOTH with 40 FPS. I think it is just amazing what modern graphic cards can do.  

---

## 2 answers

### Answer by username_4 on 2015-12-14. Score: 7

I think it is commonly accepted that real time is everything that is above interactive. And interactive is defined as "responds to input but is not smooth in the fact that the animation seems jaggy".  
So real time will depend on the speed of the movements one needs to represent. Cinema projects at 24 FPS and is sufficiently real time for many cases.

Then how many polygons a machine can deal with is easily verifiable by checking for yourself. Just create a little VBO patch as a simple test and a FPS counter, many DirectX or OpenGL samples will give you the perfect test bed for this benchmark.

You'll find if you have a high end graphics card that you can display about 1 million polygons in real time. However, as you said, engines will not claim support so easily because real world scene data will cause a number of performance hogs that are unrelated to polygon count.

You have:

* fill rate
  + texture sampling
  + ROP output
* draw calls
* render target switches
* buffer updates (uniform or other)
* overdraw
* shader complexity
* pipeline complexity (any feedback used? iterative geometry shading? occlusion?)
* synch points with CPU (pixel readback?)
* polygon richness

Depending on the weak and strong points of a particular graphic card, one or another of these points is going to be the bottleneck. It's not like you can say for sure "there, that's the one".

EDIT:

I wanted to add that, one cannot use the GFlops spec figure of one specific card and map it linearly to polygon pushing capacity. Because of the fact that polygon treatment has to go through a sequential bottleneck in the graphics pipeline as explained in great detail here: <https://fgiesen.wordpress.com/2011/07/03/a-trip-through-the-graphics-pipeline-2011-part-3/>  
TLDR: the vertices have to fit into a small cache before primitive assembly which is natively a sequential thing (the vertex buffer order matters).

If you compare the GeForce 7800 (9yr old?) to this year's 980, it seems the number of operations per second it is capable of has increased one thousand fold. But you can bet that it's not going to push polygons a thousand times faster (which would be around 200 billion a second by this simple metric).

EDIT2:

To answer the question "what can one do to optimize an engine", as in "not to lose too much efficiency in state switches and other overheads".  
That is a question as old as engines themselves. And is becoming more complex as history progress.

Indeed in real world situation, typical scene data will contain many materials, many textures, many different shaders, many render targets and passes, and many vertex buffers and so on. One engine I worked with worked with the notion of packets:

One packet is what can be rendered with one draw call.  
It contains identifiers to:

* vertex buffer
* index buffer
* camera (gives the pass and render target)
* material id (gives shader, textures and UBO)
* distance to eye
* is visible

So the first step of each frame is to run a quick sort on the packet list using a sort function with an operator that gives priority to visibility, then pass, then material, then geometry and finally distance.

Drawing close objects gets prirority to maximize early Z culling.  
Passes are fixed steps, so we have no choice but to respect them.  
Material is the most expensive thing to state-switch after render targets.

Even in-between different materials IDs, a sub-ordering can been made using a heuristical criterion to diminish the number of shader changes (most expensive within material state-switch operations), and secondly texture binding changes.

After all this ordering, one can apply mega texturing, virtual texturing, and attribute-less rendering ([link](http://renderingpipeline.com/2012/03/are-vertex-shaders-obsolete/)) if deemed necessary.

About engine API also one common thing is to defer the issuing of the state-setting commands required by the client. If a client requests "set camera 0", it is best to just store this request and if later the client calls "set camera 1" but with no other commands in between, the engine can detect the uselessness of the first command and drop it. This is redundancy elimination, which is possible by using a "fully retained" paradigm. By opposition to "immediate" paradigm, which would be just a wrapper above the native API and issue the commands right as ordered by client code. ([example: virtrev](http://virtrev.git.sourceforge.net/git/gitweb.cgi?p=virtrev/virtrev;a=tree;f=coding/opencl_opengl_sharing/src;hb=HEAD))

And finally, with modern hardware, a very expensive (to develop), but potentially highly rewarding step to take is to switch API to metal/mantle/vulkan/DX12-style and preparing the rendering commands by hand.

An engine that prepares rendering commands creates a buffer that holds a "command list" that is overwritten at each frame.

Usually there is a notion of frame "budget", a game can afford. You need to do everything in 16 milliseconds, so you clearly partition GPU time "2 ms for lightpre pass", "4 ms for materials pass", "6 ms for indirect lighting", "4 ms for postprocesses"...

> **Comments:**
> **username_6**: A million seems a bit low to me.  
> **username_4**: just take how many MPoly/s the card is capable of, and that's the FPS at which it will render 1 million. I just recalled an experiment for a terrain renderer on an ATI4800HD. If you take this list https://en.wikipedia.org/wiki/List_of_Nvidia_graphics_processing_units they don't give Vertices/s info starting from the era of unified architecture. but 10 year old hardware seems to advertise about 40 FPS for 1 million triangles. + c.f. edit in my answer  
> **username_0**: @username_4 Yeah, but to get near that number you need to do batching of geometry, or instancing, in case of dynamic scenes, and **that** is what I'm asking about. How to not bottleneck yourself 2% of the way towards what hardware can do.  
> **username_4**: @username_0 aaah, I see, THAT is a question indeed. Let me see what I can say about it. (EDIT2)  
> **username_7**: Great in depth answer! I've made a few minor edits, as a user rather than a moderator. Feel free to roll back any/all if they don't match your intention.  

---

### Answer by username_8 on 2021-09-17. Score: -1

In my experience using VBO allows to render model consisting of 500 million triangles in realtime (more then 20 fps) on NVidia RTX 2080 videocard.

Model size is 8GB, there is 11GB available video memory


---

