|We do what we must, because we can
||[Mar. 22nd, 2008|02:44 am]
Spectre Gruedorf Challenge Blog
A token update because, for once, I had a busy week. Sadly, not much has gotten done this week, and hence my Lame Score will go up. |
At least, nothing with pictures of it anyway. Some days, most of what you do just consists of fucking about writing systems code that doesn't do anything useful. Other days, you do research that goes nowhere. And this, too, is part of life. So, let us discuss and analyze what's been up - in terms of Spectre code, at least.
This week, specifically, I spent a great deal of time working on the code to kill T-Junctions. It completely fails to do this. I honestly don't know why this is giving me such trouble, but I think it's because I'm too lazy to write code to generate a proper data structure for doing edge collapses and splits "nicely". I think I'm thinking of what you would call a double-winged edge list if you were a comp. sci nerd, but Matthew will probably tell me that this isn't what it's called at all. Oh well. I will probably write the damn nice data structure this weekend and then maybe CSG will not fail.
Interestingly enough, you mainly get T junctions where the 'split triangles' from object A meet the split triangles from object B. Remember that the Thibault + Naylor CSG algorithm operates by feeding polygons (Naylor calls this 'a B-Rep', which I'm guessing is short for boundary representation?) from object A into a BSP tree representation of object B, and then only keeping the bits that are on the outside of the other object. The actual output before you put the two halves together seems to be T-junction free, or at least nothing that a vertex welding pass won't sort out. The natural question: is there an ordering on the triangles of A and B and the BSP trees of A and B such that the Thibault + Naylor CSG operation produces no t-junctions, or at least the same set of splits? My gut instinct is "no", or at least not without splitting the triangles of B along the planes of B's own BSP tree. Maybe if you kept both A and B as BSP trees and then did the intersection/operation that way, you would get a result that was better. I think you'll need to do a T-junction pass regardless.
The second main thing that got done this week, that actually DID get done, was actually moving the new brush data out of SLED and into the main game engine. Currently it assumes that brushes are contained in a sector (which they are - however, there really is only one sector at this point) - and then each sector contains, cunningly divided into material batches, big chunks of stinking brush geometry. (And brick data, which is what we call prefabricated meshes. And objects. And lights. And particle systems. And portals. And occluders. And Balls!(TM). And...)
I'm still having trouble sorting out the just-in-time editing system, and exactly how that's going to work. I think that it internally maintains a set of compiled output (read: a copy of the world and game universe defined entirely in terms of SLED objects) and then a collection of linking data relating SLED objects to their real world counterparts. Instead of loading a world from compiled data, a 'trick' is played on the game engine: the data it receives is really pseudo-compiled data from SLED.
Also, I'm breaking in a new character modeller. The hope is that I'll have something interesting to show at my various sordid interviews next week. I'm sure that aen, at least, will want to see the engine running if he gets half a chance.
I was thinking about what it is that I actually do on a daily basis, and this is what I came up with: as a programmer doing graphics work/game work/whatever work, I tend to think of myself as an algorithmic designer. Day-to-day programming work, say 99.9% of what actually happens doing web development, is uninteresting. It revolves around writing interfaces that make libraries talk to other libraries. You can do this in a nice fashion, and you can make it all pretty and unit tested, but really it's not about creative problem solving beyond thinking in terms of pretty structures.
Most of what I do, on the other hand, involves finding solutions to problems that are a) algorithmic as opposed to implementation-centered, b) hard, c) math-oriented. Most of computer graphics is math; furthermore, a lot of that math is Hard Math. To just get a cube up and running requires linear algebra - a lot of it. Implementing dot product bump mapping is actually an exercise in differential geometry - the idea of a tangent space stems from the work of nineteenth century differential topologists. Spherical Harmonics, the new in-technology, are the solutions in spherical coordinates to a system of partial differential equations. Even something as simple as making a good looking particle system work is a mild form of numerical integration.
So that's why graphics programming is some of the most interesting programming you can do. And also, I think, some of the hardest.