Hardcore lighting stresstest (code)
I'm ashamed to admit that the only reason that this scene ran so slowly (around 0.2fps) before was because I was overlooking a really stupid pair of optimizations:
- Don't bother with lights which can't possibly affect the rendered image
- Don't bother casting shadows from objects which are further than a light reaches
There are basically three cases of light:
- Infinite - either F1 and F2 are zero (meaning the light never falls off) or it grows stronger as the radius increases (Solace doesn't impose any arbitrary physics-based restrictions on the light intensity, since it just allows anything the OpenGL lighting model allows)
- Linear - F1 > 0, F2 = 0; trivial
- Quadratic - F2 > 0; use the quadratic formula
Really quite basic.
So anyway, for light rejection case 1, it just tests the light's sphere (or cone) of influence against the camera frustum, and if it doesn't intersect, it just disables the light for the scene. This has the unfortunate side effect of messing up emissive light-pass shaders (such as what I typically use for cel shading), as such shaders will flicker in brightness as lights move on and off camera, and to a lesser extent the changing distance from an emissive object to a light will cause a similar effect, but that's basically unavoidable with the way that light-pass emission has to work. It also shows how much of a hack using emission on the light pass for cel shading is, and why I should look more into ways of improving cel shading using a specular exponent of 0 instead (which interacts with light falloff properly to begin with).
Or, alternatively, expanding the shader language to allow hardware shader functionality or register combiners or any of the other odd stuff which can be abused for cel shading. But I hate hardware shaders for lighting; you have to think about things totally backwards, and they basically force you to do multipass for multiple lights. (Every image I've put out from Solace is totally unextended OpenGL. Basically I just use OpenGL as a high-level language to a specialized SIMD processor as far as shaders are concerned. Which is why its performance sucks compared to specialized gaming engines, but why it's also far more general than any of them.)
I should look into shadow maps for spotlights, though. Unfortunately, shadow maps really don't get along with my visibility mechanism, unless I do separate visibility processing for each light, which gets into really obnoxious levels of overhead. Maybe when I finally get around to implementing a visibility algorithm I've come up with which doesn't rely so much on temporal coherence so much it'll work better.
But in the meantime, my parents and brother are going to be here in like half an hour. Eep!
Comments
Hi, I was talking to Paul today about this certain 12" Titanium G4 PowerBook in my possession that needs to sell extremely cheaply, and I thought you might be interested. If so, drop me an email and I'll get you more information.
Heh, I gave up more complex programming years ago(C++), but if I had kept on, 3D Programming probably would have been the likely next step, given my affinity for 3D animation. That said, having looked at some of the complexity in 3D programming, I'm glad I didn't go there. I liked programming. But prolonged exposure to it drove me nuts, lol. I needed to feel more artistic than technical(if that makes any sense).
Either way, IMO, you should probably stick with raytraced shadows. There is something about shadow mapping that doesn't feel right. They almost never turn out the way you want them to. They don't seem to adapt well to complex shapes(depending on the resolution of the map). And I find they don't take well to caustics(if you even implement that at all). But I guess it depends on your rendering engine.
All in all, what do you plan on doing with Solace when you're finished with it?
Those shadows are stencil-buffer shadow volumes, not raytraced. The next gen of graphics hardware should be capable of raytraced shadows at decent framerates, but this current generation definitely isn't.
Caustics are a total nonsequitur. That's something in lighting, not in shadowing.
Also, shadow maps can look just as good as stencil shadows when done right (read the paper "Perspective Shadow Maps" from Siggraph 2k2); the problem with most shadowmapping engines (like Half-Life 2 and Splinter Cell) is that they do post-process shadowmaps where the shadows reduce the already-lit surfaces, rather than blocking the light from getting to the surface to begin with. Stencil buffer shadow volumes can be implemented in the same braindead manner though; I just happen to do it The Right Way in my engine (and from what I've seen of Doom 3, it does too).
Solace will never be finished. :D But it's always been a general research platform with the intent of making an immersive MMORPG engine/virtual community/etc., which I started long before the term MMORPG came about.
Have you played Doom 3 yet? It's a real trip. =D
Scariest game I've ever played.
No, not yet. I'm not really looking forward to it, honestly. Half-Life 2, on the other hand...
Have you seen the demo video for Half Life 2? It looks like there is a lot of interaction between the player and his surroundings. Heh, you can even rip radiators off the wall.
I've only played the Alpha version of Doom 3(Yes, THAT Doom 3 Alpha ;p), and aside from the spooky shadows and dynamic lighting, it felt like an update to Quake. Interaction with the environment was minimal. Okay, okay, so it was in the alpha stage. Still, the levels in the game felt very much complete as they were. I didn't get the feeling they were going to add anymore to it. But we'll see. =)
Doom 3 has a lot of triggered events ala Half Life. That imo is what makes it scary as hell. I mean, really. A game has never scared the shit out of me before. Do not play this at night with the lights turned off. ^_^
Another plus of playing the alpha was that nothing was optimized. There were no compiled .pk3 files(or whichever extention they'll use this time around). Textures and config files were all laid out bare(Pinky's bump map looks interesting enough). So it was really interesting to poke around in various directories and sift through various textures and model files. But that's just the dork in me talking. =)
There was also one test level which was nothing more than a small square room with a few light sources. I could add lights of various types on the fly as well as add or remove monsters/make them rotate, etc.. You could also spawn active monsters and run like hell as they chase you around the little room(Pinky is FAST). It's just something neat to play around with, that's all.
btw, if you decide to buy the final(I know I probably will), check out the infamous bathroom scene.. When Pinky finishes chewing on the zombie and retreats into the shadows, turn and stare into the mirror for about five seconds. Heheh, I hope you don't have a weak heart. ;)
Yeah, that's exactly why I'm looking forward to Half-Life 2 but not Quake 4^W^WDoom 3, which just looks like id doing a graphical update on Half-Life 1.