Well, as the title of the file suggest, I'm right in the middle of exams. Heh. I haven't updated this in a while, and its pretty obvious my web page hasn't been done in a couple of months. Had physics yesterday, and another exam today. Got four more next week... Well, lets not talk of that right now...
Anyway, first things first. Well, a coupla weeks back some guy flamed me on the flipcode comment boards. Self proclaimed "Hitman" decided he would take a shot at me for mentioning that it was a "prominent person" in the industry who actually mentioned the so called article. Well, the reason I didn't mention the name of that person is they don't like "burning bridges". I did write a reply comment, but it got lost in the system. Phantom and Psy were both looking forward to seeing what I had to say. Which is basically this. "Hitman" (or whoever you were), you avoided my mention of all technical detail, and still managed to say "say something interesting or funny", when I already had. Still, I am not a sophist.
I would also like to say that I do know a few people around the net, as I've been a netizen for about five years now. I've worked hard to get all the knowledge I've got, and I've worked hard to get things together. This is my business, not yours.
Anyway, enough of the person who supposedly didn't care, but for some reason posted the message.
I haven't had much coding time, due to the double round of exams (only 3 and a bit weeks apart) of which I am now in. Soon I will be finished, and you will see a few of these things.
I did a fair bit of work however on lighting systems ideas for my new job. I went back to my quadtree idea and reviewed it, went through some discountiuty meshing stuff, and have now developed a little very physically correct light system, based on photon probability. I'm looking at the possibility of using the light system to create nice specular effects as well, using some various methods I'm looking into.
One interesting idea, which I don't think I will use is the concept of storing your lighting as a medium res discontinuity mesh (say, 64 points), and then rendering into a lightmap, which could be of a higher resolution than usual (Video card memory is now rarely the restriction to must lightmaps, but for big levels lightmap data in system memory is). Combine this with some nice edge antialiasing, and a slight dither, and you could get very accurate shadows and reasonable accurate lighting in lightmaps, without the need for wasting a good amount of your triangles on lighting instead of meshing.
Storing as a discontuity mesh has other advantages too, you have distinct shadow areas, you have only a few points to calculate accurate lighting for, and by seeing which points are effected by the dynamic lighting, you only have to update small regions of the map.
An advantage of using true discontuity meshing is that if you record shadows, you can do specular lighting with shadows. Otherwise, you either need to do a subtraction of the shadowed areas of the specular lighting on the fly, or revert to a three or four dimensional light representation, like a lumiagraph or holo-map.
I came up with a couple of systems for doing a 3d representation of all the intensity of the rays leaving surface. The premise is simple, for each lightmap, you have a extra ray direction dimension. This is based on a number of rays leaving surface of the object, and the light colour you would see. These rays leave uniformally in a hemisphere from the lumel. I came up with three options for making the decision on the actual colour of the light leaving at that point. The first is mapping to a hemicube. Good, but messy, with 5 sides, and possible trouble doing bilinear filtering. Using a hemisphere, and converting to spherical coordinates (basically a vertical and horizontal angle). You could do this, but it would require a sqrt per lumel. Slow but good. The last idea was to use a plane slightly behind the plane of the lightmap, and map the rays there. One problem with this is, you run into problems with the user at a sharp angle, and at an angle where the normal of the polygon being lightmapped it perpindicular to the view vector, this could be a problem, as you would never have a plane intersection. Chances are though, the plane should've been culled here, and you can just take the closest ray anyway when the polygon is at a sharp angle, as no one will notice.
This method allows diffuse lighting and specular lighting. In fact, you can even do a pure photon based model and base your diffuse on probability (a hundred percent diffuse means that a photon is likely to go in any direction when reflecting off a surface). And you get shadows as well. It isn't dynamic, but it would look very realistic. For a 16*16 lightmap, you could probably get away with 16 ray samples if you used bilinear interpolation. This would mean a cubic map of around 4k colours (using 24bit textures, 12k storage).
This method is doable in software mode, if your surfaces aren't to complex (in fact, you can pre-map the U and V into a cache, at 8*8 one byte is sufficient), and then do your ray look up on the fly. However, hardware rendering is a problem. If I had my way, hardware manufacturers would all support 3d textures, and texture offset overlays.
PS Its my year anniversary tomorrow. Thats right, Candace actually managed to put up with me for a WHOLE YEAR!