Archive for May, 2003

Anti-aliasing in 3D

Since converting George to OpenGL some time back (years?) I have been without anti-aliasing on mesh objects. Now finally I have re-introduced it, only to realize that the technique is probably superfluous these days, what with most 3D cards offering anti-aliasing themselves (using a brute force method). Anyway, here is what my special edge rendering technique looks like, now that I have finally patched it into my 3D renderer.


This object is rendered at 320 x 200 resolution, using standard techniques. Note all the jaggy edges which stand out against the white background.


The same object rendered at the same resolution, with the addition of anti-aliased edges. The technique requires no special hardware, simply rendering edges as polygons with alpha blending to soften them.

Apart from the extra rendering and the setup required, a problem with the technique is its tendency to fatten shapes, because the anti-aliased edges must be drawn outside the existing edges of the regular shape.

Another reason why this method doesn’t seem as relevant to me anymore is that it does nothing to smooth the edges formed by the intersection of polygons in the ZBuffer. The image on the right is an enlarged view [with double sized pixels] of 2 cubes intersecting, and while the silhouette edges and regular cube edges are smoothed, the edges where faces intersect are as jaggy as ever. A lot of models do contain such intersections, partly because it simplifies the design process to allow them.

Non 3D Stuff

Oh yeah, of course I’m still kind of working on my serious software too at the moment, although things are going just a little… slow. I did get rid of a few niggly problems in JujuEdit, and also repaired Fragt so that I can actually use it (to download great big video files over several days).

More screwing around

Trying out some new fun with style sheets, as well as a tweak for HTML Editor to allow self links to be styled differently, to provide visual feedback of which page in a list of contents you are currently viewing. This current look (which could change, invalidating this sentence) is kind of a textbook thing, attempting to use only 2 colors for text and layout (albeit in varying shades). It may look yukkier to you than to me, because I am red-green color-blind ;)

Specularization

Specular lighting is an important part of 3d graphics, but it is also a mega pain in the ass, because far more than regular ol’ diffuse lighting it can give away the polygonal nature of an object. This is because a specular hilight causes such rapid change in brightness of a surface. One way to deal with it is to use higher polygon models, but this is computationally expensive, and generally requires at least a four-fold increase in geometry detail. I have also tried dynamic tesselation, where the surface is further subdivided in areas where light levels vary rapidly, but found this difficult and fiddly to implement.

So now I am experimenting with a dynamically generated reflection map. The 2 spheres shown here are actually identical, except that the one on the right is using an environment map for its specular hilights instead of generating them at triangle vertices as the left one does. Now it’s only the silhouette which gives away the low detail level of the model. Neat eh?

shiny teapot

A reflection map, as its name implies, can contain actual reflections of other objects, so if you have a relatively static sky in a scene, you can render that to the reflection map and your shiny objects will then appear to reflect the sky!

There are [unfortunately] some limitations to this method, the biggest one being that the reflection map is only ever correct for a single position, and the further an object deviates from this location the less accurate the placement of the hilights will be. The real strength in this method lies in the fact that the creation of the reflection map and the rendering of the object are done separately, and the rendering pass is comparitively ‘cheap’. Although it is computationally expensive to create the reflection map, the same map can be used on several objects, and you can even cheat by only updating the map every few frames. Many driving games do this; if you carefully watch the reflections on the cars, you will see they are more jerky in their motion.

Mmmmm…. pointless rearranging

Have just updated the page template for this log, providing a more log-centric sidebar and changing some colors. Will probably make it look totally different from the main site as soon as I’ve got some other important work to do.

Bump mapping is more ‘real’ than texture mapping

Texture mapping works by painting a simple surface [usually a polygon] to look more detailed than it actually is. A real world analogy would be to paint a plastic bucket to look like a wicker basket. The problem with this technique is that whatever light and shadow is painted onto the surface is henceforth ‘frozen’ and can not change when the viewing conditions change, so even though a casual glance may fool you into thinking the bucket is a basket, waving a torch around it will quckly reveal the true flatness of the image.

Bump-mapping, on the other hand, uses a map of surface height values rather than color values. This means that a bump in the surface can be reproduced appropriately in any given lighting situation. Even though the 2 spheres pictured here are both using the same bump map, the appearance of the small "crater" in each is different because of the slightly different orientations to the light source. In the real world, many materials are very samey in color, and it is actually the bumpiness of a surface which our eye is observing. Using bump mapping instead of texture mapping [although they can also be used together] allows a result which is "truer" to reality.

Unfortunately there are a lot of setup calculations involved for each of the vertices (of which there are several hundred used for this shot), so perhaps that’s why it’s not necessarily used all over the place. The bump mapping used here only reflects diffuse light [matte], not specular [shiny], but it does support multiple colored light sources, so that’s a plus. Also the algorthm I use doesn’t need hardware bumpmapping support, so it also works on cards that are a bit old fashioned (like the one I have).

The bump map being used here is a tilable fractal, generated on demand. Tweaking a few of the starting parameters can result in vastly different surface types, such as mountain ranges, stucco, etc.

Metal Fatigue

Although I am hardly a gamer, I used to keep my eyes peeled for new things in the world of realtime 3d graphics. For the past few years I have considered myself well out of the loop, concentrating instead on the world of 2D and windows applications. Having just got an ADSL connection, it occurred to me that it might be fun to download a few of the latest demos to blow my socks off with the incredible improvements in technology and design…

[please put on your spittle resistant goggles now]

The sort of games I’m really interested in are the space flight ones [since space flight is something I can only ever experience in simulation] and in this day and age I expect to see realism to make my jaw drop. But what do I see? Or, to get to the point, what do I see that really pisses me off?

  1. Space is represented as a "viscous ether", with a uniform distribution of pebbles, and in order to stay in motion we need to have thrusters firing continuously. Star Trek and Star Wars are largely to blame for this, with the notion of an absolute reference frame and the tendency to come to a halt when your engines go offline. Particularly inappropriate when in low planetary orbit, since arresting lateral motion should leave us at the mercy of that planet’s gravity.
  2. Planets are allowed to be surprisingly close together (closer than the earth is to the moon) and also may be surprisingly small (as small as a few kilometres across, judging by nearby reference points)
  3. While the notion of ubiquitous space travel seems to be easily grasped, the notion that an energy weapon might have the ability to actually aim itself is clearly considered too futuristic. Instead you have to make yourself nauseous lurching about trying to keep your cross hairs over the target leader.
  4. All surfaces of space ships appear to be of a matte texture, and all are plastered with similar bitmaps of overlapping grey squares, apparently forseeing that engineers of the future wont even bother cutting metal to shape, they’ll just keep slapping squares on until they’ve covered every bit of the hull.
  5. All surfaces on all sides of objects are lit so as to make it possible to discern the startlingly boring detail that the texture artists have created, eg overlapping grey squares. The brightness of a surface facing the sun is only about twice as bright as a surface facing away, rather than a thousand times plus.

Ok, so I can understand why so much [visualized] space fiction go with the idea of a viscous ether. The motion is so much more familiar to us (think ships/airplanes).

My biggest beef is probably with the boring texture mapping [and boring lighting] problem. What the hell is wrong with geometry? Aren’t 3D cards supposed to be able to render a gazillion triangles per second these days? Wouldn’t it be nicer to use higher detail models which don’t need to be slathered with hokey textures? The "space station" on the right seems to have been fabricated out of sheet metal, and then painted grey. Note that the curvy bits don’t even look curved. And can you see any shiny bits (eg windows, solar collectors)? Texture mapping an object kills its surface properties, because the shadows and hilights you draw on a texture map can’t move when the light source changes.

Compare and contrast with this model I downloaded… It isn’t so detailed that it can’t be rendered in real time, but it is detailed enough that it requires NO texture mapping! And once you’ve freed yourself from texture dependency, you can experiment with lighting and material parameters to simulate surface qualities. Here a variety of material parameters are used to simulate different surface properties, including what might be called "chalky" or "metallic".

Another great thing about using geometry instead of texture mapping is that when you get close to the object, the realism is not compromised by blurry textures. When you approach a window on a space ship, it doesn’t turn out to be a black smudge of blurry pixels… it maintains its definition, and even catches the light like a shiny thing should. The whole thing feels more real.

Will all this get me fired up to work on George again? It’s very tempting, I have to say…

Lacking discipline

An ephemeral drawingAlways looking for something to do which isn’t the thing I’m supposed to be doing, I drew a picture this morning, which I thought I might post here, since the original data is probably going to become unusable with the next change I make to JujuSketch. The picture is loosely based on the idea of a character called Jenny Everywhere, an "open source" character mentioned on Ben’s weblog. [my picture does not look anything like it should, but is at least wearing goggles for some reason - also I drew it before I saw the official imagery]. The closest I can come to preserving this image is to export it to SVG format, a one way and slightly lossy process. Click on the image to view the SVG file (about 150K).

Ugly man inexplicably holding a poleThis is a real pain about writing software… you are always tempted to try out the damn stuff, and when you do, you are probably using some flakey intermediate version with a barely defined file format. Actually this is probably a broad generalization, since I think I am the only person I know who both writes and uses his own software… so I’m talking about me, not you, and personally I do this kind of thing all the time. Poor old George, my 3d space simulator… I can’t count the number of promising universes that have disappeared without a trace as I ruthlessly modify file formats without bothering to add backwards compatibility (after all, since the thing isn’t yet public it’s only my own universes that die).

Furthermore, it’s not just data that suffers from [this] programmer['s] neglect; code can vanish as well, although the exact process whereby this happens is hard to pin down. Alls I knows is: good features in software can actually disappear if you don’t pay attention to them. An example is a light sourcing technique I once created to simulate brushed metal. It worked pretty well, but that was years ago, and in the time intervening, it seems that the code just got squeezed out! I think I probably "temporarily" disabled it because of some new feature I was adding, which turned out to be incompatible with the way I was doing it, and then I just never got around to re-implementing it.

Unexpected vacancies

Further to Wednesday’s post, I was recently indulging in a bit of idle domain name checking that one does when one is supposed to be working, and discovered that the following domains are not even registered!

I believe there is some law, at least in the UK, that prevents squatting on people’s names, so I don’t believe they are in danger of having their names stolen from under them. Also the .co.uk versions of all these names are listed as not available, although none of them even maps to an IP, let alone a site. I just can’t believe that the respective bodies of work of such people wouldn’t justify a decent web site! What the hell are their agents thinking? What, is the internet just not worth bothering with now?

Purrrrrrrdy

Gradient fills are very good for making an application look more sophisticated (or gaudy, depending on your angle).