This is the best news I’ve had in ages. The Legal Affairs Committee of the EP has demanded that the Computer Implemented Inventions Directive be completely rewritten. Not only that, they voted 19-2 in favour of this. The EC, which increasingly seems to listen only to lobbyists highly funded by the likes of patent arms-dealers (global multinational IT companies - you know who you are) and those who seek to make a killing out of a horrifically abusable patent law (read lawyers and the patent office) simply cannot ignore this.
I found out today that an article I wrote about OGRE on request from Software 2.0 Magazine has made it onto the shelves, at least it has in French and Polish. You can see the magazine cover in the French language section of their site, it’s the ‘Programmation de jeux’ issue. No, I didn’t write the article in French (or Polish), they translated it for me. The English version comes out later in the year.
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.