I spent today making the OGRE_DOUBLE_PRECISION option, which has been there since the start but has never really been tested, work properly so that when enabled, all the internal math classes operate in double precision mode. The GPU can still only handle single-precision so there is downsampling when it comes to the actual rendering, but at least those people writing scientific apps which need this precision can use the Ogre math classes without losing that precision in the intermediate stages (and it was the comments of one real user on IRC which reminded me about this).
This is a quickie update because it’s late: I started working on a grass demo using the StaticGeometry class, and here’s an early shot: And no, I don’t know why I used that skybox, I just liked the ‘field at night’ idea with dynamic lighting and didn’t have a night time skybox to hand. 😀 Tweaking it so that the fillrate doesn’t become too much of an issue is challenging, I hope to get the grass waving with a vertex program in time for the release.
Ah, I fixed the use of animated meshes in StaticGeometry; the inclusion of blend weights / blend indices in the vertex declaration that was being copied in caused the renderer to try to blend using bone matrices that weren’t there. These meshes can now be added (although of course they are not animated once in the StaticGeometry). Here’s proof: Now to see if I can find time to write a dedicated demo for this.
Well, it’s working - today I’ve been ironing out the issues and getting stencil shadows to work with it (which was slightly awkward, but then stencil shadows always are). I still have one bug to iron out with adding skeletally animated entities to the static geom, which is a little odd since they won’t be animated once they’re in there, but nevertheless they should work. After that, I want to try to squeeze in a nice demo using it before I have to start work on getting the release prepped for takeoff.
Well, I got a couple of decent day’s production, and the StaticGeometry class is very nearly code complete. LOD support (mesh and material) is in, as is a little mesh optimisation and support for multiple index sizes, ‘bucket overflow’ (running off the edge of addressable vertex space given the type if index in use) and all the glue required in the middle which required quite a lot of work. I just have to finish the fairly trivial part of doing the actual pretransformation.
Gah, what a day. To start with, Sourceforge CVS is currently performing at the speed of an apathetic slug towing a family saloon full of other slugs, said family having also forgotten to fully disengage the handbrake. 45 minutes for a ‘cvs up’ is not my idea of enjoyment. Secondly, I’d been trying to test what I thought was a useful update to SharedPtr whicih simplified a few things and added weak pointer support, all through templates, but whilst it compiles fine I get the weirdest runtime problems, such as hangs deep in STLport.
Well, I finally decided to shelve the lost device handling since it’s mostly working except for the couple of crazy little things left over which are utterly baffling. D3D’s return codes say everything is peachy, it’s debug runtime on full diagnostic mode continues to make reassuring cooing noises, yet deep in it’s innards it’s choosing to completely ignore some render state changes (namely those that implement transparency) after the device restore, no doubt whilst cackling wildly to itself (and perhaps rocking backwards and forwards and drooling a little).
Well, I have lost devices restoring in many situations now - I still have to sort out a remote debug session because fullscreen restores still error sometimes and they’re kind of hard to track when your machine is locked solid (now I wish I had dualhead!). But now I have the most bizarre problem - after restoring the device, on this machine the ‘scene blend’ factors, ie transparency, no longer work.
I managed to polish off a loading screen example at the weekend, Demo_BSP now reports progress as it loads (which is good, because if you hook it up to Quake3Arena’s pak0.pk3, parsing all those shader scripts can take a little while!). It’s wrapped up in a little ExampleLoadingBar class that people can re-use relatively easily in their own apps, or of course simply rip off - like the rest of the example code it’s written under a a very lenient license.
The last week has been something of a mixed bag; I’ve been going through lots of patches for Hastur because they were mounting up, and the result (plus all the other fixes for the past 6 weeks) is today’s release of 0.15.2. This _should_ be the last Hastur release before the mighty Azathoth, which I can finally get back to working on. My overlay issues while trying to get a loading screen working are first on the ‘to stamp on repeatedly until it gives in’ list.