About this blog
Projects, coding, stuff
Entries in this blog
The finished article looks a lot like this.
Now if only I knew a decent artist... [smile]
(click to enlarge)
The project got a bit delayed by the fact that I felt the need to write a new scripting language to handle per-mesh calculations. A kind of per-object shader language I suppose. Since there are a lot of matrix calculations that are only performed once per mesh, it seemed wasteful to do them in a vertex program, and I wanted to keep the C++ code separate from the shaders as much as possible.
In the end I wrote a C-like language which compiles to bytecode, which can then be read through a virtual machine. After that I spent ages getting the VM to run at a sensible speed. It was worth it in the end though. The language (BunnyScript) is pretty general purpose, so I can see it being useful to other things such as AI.
I guess I could have just used a language that was already available - why bother to reinvent the wheel etc - but I've always wanted to write my own. Plus, I'm fairly confident that mine is faster than most other interpreted languages, which is a good thing because the programs are being run thousands of times per frame.
ATM I'm just using OpenGL's vertex lighting, but I'll probably put in a bump-mapping pixel shader if I can get the frame rate to improve.
I'm not recalculating a shadow volume unless the light or the mesh moves, which is a lot more efficient, particularly for this type of scene. Fill rate is still proving to be a major pain in the ass in antialiased modes though; with 6xAA, I get about 16fps for the above scene (@1024x768). Without AA, I get ~65fps.
I've been working on a demo CD to send to recruiters. At least, that's the theory. In practice I've been playing around with shadow volumes a lot; adding a robust shadow volume lighting system into my engine's mesh classes.
I'm using a depth-fail algorithm to render the shadows. The silhouette calculation turned out to be pretty slow, so I'm caching it and calculating it every 4 frames or so. The volume itself is stored in a single VBO, basically using the mesh's geometry with the silhouette edges extruded. Obviously there's one volume per light/mesh combination. The contributions of each light are blended additively in multiple passes.
I'm getting about 43 fps for the above scene (Radeon 9700 Pro, Athlon 2100+). The slowest part is currently calculating the silhouette for the shadow volumes. Fill rate is also pretty poor, but there's not much I can do about that, short of buying a new video card. There are a lot of optimisations I can make. Dumping the shadow volume calculations into a vertex shader (article) should help a lot, as should adding distance-based culling for distance attenuated lights. Occlusion culling could also be used to cull out shadow volumes that aren't visible from a light source, which would be very useful in large, detailed scenes where there's a lot of occlusion.
I'm still not decided on whether shadow volumes or shadow mapping are best for general purpose scenes. Both currently have significant limitations. Shadow volumes do seem more robust in general though, if slower. OTOH, Shadow mapping does have the advantage of working very well with the image-space occlusion culling system I've implemented.