 <\/td><\/tr><\/table><\/p>\nWell, I guess we should say there are 512 triangles, since that’s what really matters. In any case, the screensaver dawdles a bit. We’re only drawing 512 triangles. Why is it so slow?<\/p>\n Back in 2004, Doom3<\/sup> gave us characters that weighed in at about 1,500<\/a> or so. For example, the imp…<\/p>\n <\/td><\/tr><\/table><\/p>\n…was the simplest foe in the game at just 1,100 triangles. So that imp has more than twice as many triangles as my screensaver. And the imp is being drawn using monumentally complex (by comparison, anyway) shaders that do lighting, shadowing, specular gloss, texturing, and bump-mapping. Meanwhile, my screensaver is drawing simple unlit no-shader polygons. And Doom3 shows us not only an imp, but several. Plus all the level geometry. Plus the moving machinery in the room. Plus all the other crap like the HUD and the player’s arms and weapon. And it did all of this on 2004 level hardware at a decent framerate. <\/p>\n Meanwhile, my screensaver chugs on my not too shabby machine<\/a>. Why can a 2004 game draw many more (perhaps an order of magnitude more) triangles with far more demanding processing faster than my 2013 machine can draw this tiny handful of colored circles? <\/p>\nIt’s all about fill rate.<\/p>\n How much of the screen are we filling with polygons? Or more accurately, how many total pixels are we drawing? Let’s assume we’re going to run Doom 3 and Plasma at the same resolution. And let’s just assume, for the sake of having a nice 16:9 ratio, that we’re running at a desktop resolution of 1600×900. (That’s probably small by today’s standards, and large by 2004, standards, and I’m not sure if that was ever a native resolution of a monitor, but whatever. I’m making a point here.) That means you’ve got a total of 1,440,000 pixels. In Doom 3, you will draw every pixel at least once. Some portion of the screen will get drawn more than once. Back to our two imps:<\/p>\n  <\/td><\/tr><\/table><\/p>\nIn the circled area, we might end up drawing some of the pixels in the red circle as many as three times. Say we draw the floor first. Fine. We’ve drawn an empty room. Then we draw the imp in the back, which ends up overwriting a little bit of the drawing we did earlier. Then we draw the imp in the front, and all of the pixels he occupies are drawn. So everywhere we have imps, pixels were drawn twice, except for where the arm of the front imp covers that leg of the rear one. Those pixels were drawn three times. <\/p>\n  <\/td><\/tr><\/table><\/p>\nThere are, in a broad sense, two stages to rendering. The first is vertex processing: Considering where this imp is in the scene, will it appear on screen, and if so, where?<\/em> The second is pixel processing: Now that we know what regions of the scene are occupied by the imp, let’s painstakingly go over it a pixel at a time and draw it.<\/em> For the curious: These two steps are what make up “vertex shaders” and “pixel shaders” that us programmers are always on about. The second step is way, way more expensive. A triangle only has three vertices, but can contain hundreds or even thousands of pixels, and in a game like Doom 3 a pixel is probably more computationally expensive than a vertex. (To draw a pixel you have to do multiple texture lookups to get the texture, specular, and bump map, and then do a page or so of math to turn that into your final color value.)<\/p>\n <\/td><\/tr><\/table><\/p>\nSo the polygon count of our scene basically doesn’t matter. Both of the programs we’re discussing are drawing a trivial number of polygons as far as my graphics card is concerned. <\/p>\n You’ll notice that in my program, polygons don’t occlude each other. It’s not like I’ve got solid imps blocking our view of the scenery. It draws one polygon, and then another on top of that, and another on that. Each time it draws a polygon it must draw all the pixels, adding to what’s already been drawn. It has to. That’s how this effect is achieved. <\/p>\n Let me do a quick test…<\/p>\n  <\/td><\/tr><\/table><\/p>\nThat’s a single test polygon exactly halfway through its lifespan, rendered without the fuzzy texture so we can see its shape. I took a few screenshots like this, and this is a very typical sample. Running at our test resolution, it takes up about 176,319 pixels, or ~12% of the area of the screen. So each of our 256 polygons draws, on average, 12% of the screen pixels. <\/p>\n In the Doom example, we rendered every pixel once and a few unlucky ones got drawn a couple of times. Even in our worst-case scenario, I doubt our overdraw was anywhere near double the total pixel count. On average, every pixel is drawn slightly more than once. <\/p>\n In the case of my screensaver, every screen pixel pixel is drawn an average of…<\/p>\n 0.12 x 256 = 30.72<\/code><\/p>\n…thirty times. <\/p>\n And that’s what makes it slow.<\/p>\n  <\/td><\/tr><\/table><\/p>\nHaving said all that, I accomplished what I set out to do, which was smear some pretty colors all over the place. There are a lot of things you could do to speed this up, but this effect is fundamentally mean to our existing graphics technology. It actually runs fine on one screen, but in my dual-monitor setup Windows asks the screensaver to handle a gargantuan 3600×1334 window that covers both monitors, which (according to our back-of-the-napkin work above) gives my graphics card 147,529,728 pixels to draw, which is apparently unreasonable? The framerate dips to 20 or so, and the effect loses some of the magic at that speed. <\/p>\n So there it is. Another disposable afternoon project. As before, it’s released under a “do as you please” deal. <\/p>\n Plasma screensaver<\/a>.
\nPlasma screensaver source<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"So we’re doing another one of these things. I know this isn’t as fun as a Good Robot update, but hopefully this can keep us amused until the project gets moving again. While working on this, I found an interesting wrinkle that gives us a reason to talk about poly count vs. fill rate and […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[66],"tags":[],"class_list":["post-22004","post","type-post","status-publish","format-standard","hentry","category-programming"],"_links":{"self":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/posts\/22004","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=22004"}],"version-history":[{"count":0,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/posts\/22004\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=22004"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=22004"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=22004"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}} |
|
|
|
|
|
|
<\/td><\/tr><\/table><\/p>\n
<\/td><\/tr><\/table><\/p>\n
<\/td><\/tr>
<\/td><\/tr><\/table><\/p>\n