"You don't need drugs to change reality, all you need is to redefine the inner product."
More pages: 1 ... 11 ... 15 16 17 18 19 20 21 22 23 24 25 ... 31 ... 41 ... 47
Wednesday, January 14, 2009 | Permalink

When you look at a highly tessellated model it's generally understood that it will be vertex processing heavy. Not quite as widely understood is the fact that increasing polygon count also adds to the fragment shading cost, even if the number of pixels covered on the screen remains the same. This is because fragments are processed in quads. So whenever a polygon edge cuts through a 2x2 pixel area, that quad will be processed twice, once for both of the polygons covering it. If several polygons cut through it, it may be processed multiple times. If the fragment shader is complex, it could easily become the bottleneck instead of the vertex shader. The rasterizer may also not be able to rasterize very thin triangles very efficiently. Since only pixels that have their pixel centers covered (or any of the sample locations in case of multisampling) are shaded the quads that need processing may not be adjacent. This will in general cause the rasterizer to require additional cycles. Some rasterizers may also rasterize at fixed patterns, for instance an 4x4 square for a 16 pipe card, which further reduces the performance of thin triangles. In addition you also get overhead because of less optimal memory accesses than if everything would be fully covered and written to at once. Adding multisampling into the mix further adds to the cost of polygon edges.

The other day I was looking at a particularly problematic scene. I noticed that a rounded object in the scene was triangulated pretty much as a fan, which created many long and thin triangles, which was hardly optimal for rasterization. While this wasn't the main problem of the scene it made me think of how bad such a topology could be. So I created a small test case to measure the performance of three different layouts of a circle. I used a non-trivial (but not extreme) fragment shader.

The most intuitive way to triangulate a circle would be to create a fan from the center. It's also a very bad way to do it. Another less intuitive but also very bad way to do it is to create a triangle strip. A good way to triangulate it is to start off with an equilateral triangle in the center and then recursively add new triangles along the edge. I don't know if this scheme has a particular name, but I call it "max area" here as it's a greedy algorithm that in every step adds the triangle that would grab the largest possible area out of the remaining parts on the circle. Intuitively I'd consider this close to optimal in general, but I'm sure there are examples where you could beat such a strategy with another division scheme. In any case, the three contenders look like this:

And their performance look like this. The number along the x-axis is the vertex count around the circle and the y-axis is frames per second.

Adding multisampling into the mix further adds to the burden with the first two methods, while the max area division is still mostly unaffected by the added polygons all the way across the chart.

[ 20 comments | Last comment by Hobgoblin (2009-08-08 04:53:00) ]

Sunday, January 11, 2009 | Permalink

So I left a comment over at Wolfgang Engel's place. And this is what the site's anti-bot system system asks me to type:

If you're not programmer you may not see what's so cool about it, but out of the set of random characters I found it a bit amazing that I got a C++ keyword.

Speaking of const, it's one of my favorite keywords. However, I often see code where it's not used at all, or not nearly as much as it should be. I tend to use it as often as possible and I'd encourage everyone to do the same. It's good for you.

[ 1 comments | Last comment by yosh64 (2009-01-14 08:55:29) ]

Wednesday, January 7, 2009 | Permalink

Over the holidays I began some work on a new framework. I'm building it around DX11; however, I'm still making it reasonably platform independent and I plan to put OpenGL 3.0 and Linux support in there at some point too. So far I haven't done much, but at least I have a window and DX11 device up and running. Yay!

There are a few changes I'm making to the overall structure of the code. One is of course to separate the rendering context from the device in order to be able to take advantage of DX11 deferred contexts, AFA command buffers. Another change I'm making is to try to resolve more stuff on link time rather than at runtime. In previous frameworks I've had base classes with virtual functions that subclasses implemented. For instance D3D10Renderer and OpenGLRenderer inheriting from Renderer. However, since I'm always using one or the other and never both in the same app it adds unnecessary overhead. Not that this overhead was ever a problem, but it just feels better to do it right. So instead I'll create a common interface, and just add the right implementation to each project.

Another change is that I'll use a better coding style. As a self-learned coder I've been using many odd coding practices throughout the years. Slowly I've adapted to common industry conventions, but Framework3 was still based on a lot of old coding style preferences which I never bothered to change, because I'd rather be consistent than mix conventions. With the clean break with Framework4 I'll now be using "m_" on member variables and "{" will be on its own line etc.

[ 11 comments | Last comment by acid (2012-12-18 15:36:19) ]

More site updates
Monday, January 5, 2009 | Permalink

Another thing I recently noticed is that I've been sort of anonymous for I don't know how long. I know I stated my name and occupation on this site in the past and I never really intended to hide who I am. I suppose when I rewrote the whole website a couple of years ago those bits got lost. In any case I've fixed that now and changed the "Contact" page into an "About Humus" page, which also holds the contact info in addition to a few words about who I am.


RSS feed
Monday, January 5, 2009 | Permalink

By popular request I've finally added an RSS feed to this website. For some reason Firefox refused to load my permalinks, but using start=X like on the front page worked fine. Not sure what up with that, but I suppose start=X links are OK since the feed should always be up to date with the front page anyway. I've tested it in Firefox only though, so I don't know how it'll work with any other RSS readers. Let me know if there are any issues with it.

[ 4 comments | Last comment by Humus (2009-01-15 21:00:56) ]

Back again
Saturday, January 3, 2009 | Permalink

Just back again after being pretty much disconnected from the world for the last two weeks. As usual I spent the holidays with my family in the north of Sweden. The winter may be cold up there usually (although I dodged the worst this time with mostly around -5░C to -10░C and only this last morning did it dip down to -24░C); however, it's also very beautiful. Occasionally you may be able to see some polar stratospheric clouds (AKA nacreous clouds), which I was able to snap a series of pictures of.

Today I returned to a slightly snowy Stockholm. Although it's not as pretty as up north this winter is still turning out much better than the last one so far. Last winter was more or less just a long autumn with mostly cold rain and essentially no snow until late March. So I'm happy we're having snow at all.

[ 3 comments | Last comment by Stoepsel (2009-01-07 02:35:00) ]

Custom bokeh
Thursday, December 18, 2008 | Permalink

Speaking of aperture and bokeh, one cool photography trick is to create a shaped aperture instead of the regular sphere or polygonal shape that you'll find in lenses. You can do this by putting a piece of cardboard onto the front of the lens with a hole cut out of it. If you make the hole small enough, say a couple of millimeters or so, it'll turn into your new aperture. You can shape the hole into anything you like and the bokeh will be shaped in the same way. The results are best if you use a lens with a large aperture, but you can get pretty good results even with regular lenses. This is what I got when I took a picture through the window in the dark Swedish winter night with a heart shaped aperture on a standard kit lens.

[ 2 comments | Last comment by yosh64 (2008-12-31 23:20:20) ]

On depth of field
Tuesday, December 16, 2008 | Permalink

For my first entry in my new blogging effort I'm going to talk about depth of field, which is a particularly interesting subject given both my graphics programming and photography interests. My former boss Andreas ThorsÚn sent me this interesting blog post on the subject.

First thing first, I agree with Vincent that "current depth of field effects in games fall short of delivering the same cinematic emotion as movies and TV", or as I would put it: they generally suck. My pet peeve with depth of field as typically implemented is that there's no smooth transition between sharp and out of focus areas. Many games implement depth of field by taking the framebuffer and blurring it. Then the sharpness is controlled by linearly interpolating between the sharp and blurry image. This is generally cheap, especially since you probably already have a blurred version of the framebuffer around anyway for other posteffects such as bloom. However, except in the fully sharp and fully blurry areas the quality leaves a lot of be desired. Object edges aren't going to be smoothly blurred, but instead you'll see a sharp edge with some sort of halo blended on top of it. Not exactly what you want. What you really want is a blur kernel with an adjustable radius. Unfortunately, that's also a lot more expensive.

Now that wasn't what Vincent complained about in his post on the subject. He is complaining that the bokeh (that's "out of focus blur" for you non-photographers) in games isn't anywhere close to what you see in movies or on TV. Instead of the gaussian blur that's commonly applied by games he's suggesting a filter similar to "lens blur" in Photoshop with disc shaped blobs of out of focus light sources. Personally I'm not convinced this is better though. Even though this is the result you'll see in most photos it's not exactly "the gold standard" either. Many photographers (including myself) considers this an artifact, just like for instance lens-flares. Not that that has ever stopped game developers from adding it to their games. The shape of the blobs depends on the aperture of the lens. Lenses with adjustable aperture generally are created by a bunch blades. The higher the number of blades the closer to a circle the aperture will be. On a cheap lens you might see something like an octagon shape whereas with more expensive lenses it will look almost circular. The reason you're seeing a blob rather that something softer like a gaussian falloff is because the aperture has hard eges. The question is if that's desirable. Producers of highend lenses tend to not agree. Hence there are some highend lenses that contain special elements in order to produce softer bokeh and remove the blob effect, like for instance this one. If you compare the 80-200@F4.5 and 135 STF@F4.5 example images on that site I'm sure most will agree with me that the latter is the better looking image.

With that said, what's best is of course highly subjective. I'm sure there are people that prefer blobbier bokeh, and other lens artifacts such as flares, vignetting, scratches etc. has been used for artistic reasons before. Since people are used to seeing blobby bokeh I'm sure that effect has its place too.

[ 2 comments | Last comment by sqrt[-1] (2009-01-04 11:28:28) ]

More pages: 1 ... 11 ... 15 16 17 18 19 20 21 22 23 24 25 ... 31 ... 41 ... 47