For example, the screenshot on the right there is using 3 shadow maps for the single directional light, the closest one being 1024×1024, and the other two being 512×512 – together they are 38% of the size of a single 2048×2048 shadow map and yet provide greater detail. The 3 shadow textures are displayed for debug purposes on the right – notice that all 3 are using LiSPSM projection to bias the texture precision toward the camera which also helps. If you look really closely on the full resolution shot, you can see the transition from the highest resolution shadow map to the second shadow map about halfway up the screen, it changes near the top of the closest tree shadow. It’s quite hard to see though, which is kinda the point

One of the challenges with supporting PSSM is that Ogre had previously assumed that there is a 1:1 mapping between lights and shadow maps, which clearly had to be overcome – this limitation also prevented easy use of dual parabaloid and full cubic shadow maps for point lights of course. It was one of those things that had been languishing on my TODO for a while, begging me to find some time for it, and that’s where it still was until Pang Lih-Hern (aka lf3thn4d) from Malaysia came along and did it for me What a star! His initial patch allowed multiple shadow textures per light in a very sensible way, and he then implemented a PSSM facility on top of that, via our pluggable ShadowCameraSetup system (which he also extended in the patch to be aware of shadow map iteration). I adapted the PSSM code from his demo to be a little more flexible (it now handles any number of splits, and a more flexible split configuration) , so that setting it up goes something like this (simple projected shadows here, depth shadowmaps are also possible of course but let’s not overcomplicate it):


float shadowFarDistance = 3000;
mSceneMgr->setShadowTechnique(SHADOWTYPE_TEXTURE_ADDITIVE_INTEGRATED);
mSceneMgr->setShadowTextureCountPerLightType(Light::LT_DIRECTIONAL, 3);
mSceneMgr->setShadowTextureCount(3);
mSceneMgr->setShadowTextureConfig(0, 1024, 1024, PF_X8R8G8B8);
mSceneMgr->setShadowTextureConfig(1, 512, 512, PF_X8R8G8B8);
mSceneMgr->setShadowTextureConfig(2, 512, 512, PF_X8R8G8B8);
PSSMShadowCameraSetup* pssm = new PSSMShadowCameraSetup();
pssm->calculateSplitPoints(3, mCamera->getNearClipDistance(), shadowFarDistance);
pssm->setSplitPadding(mCamera->getNearClipDistance());
pssm->setOptimalAdjustFactor(0, 2);
pssm->setOptimalAdjustFactor(1, 1);
pssm->setOptimalAdjustFactor(2, 0.5);
mSceneMgr->setShadowCameraSetup(ShadowCameraSetupPtr(pssm));
mSceneMgr->setShadowFarDistance(shadowFarDistance);


Notice that I used Integrated Shadows, this is a requirement of PSSM since only shaders with integrated shadow support can decide on the fly which shadowmap to sample from.

My sincere thanks to lf3thn4d for helping us get this feature in to Ogre 1.6 (and to all those who send us patches in fact). If you want to see it and OgreSpeedTree in motion, there is a video available; that’s the low-quality streamed version but you can also download the higher resolution version if you want.

I’m staying in Torrance since that’s close to my client’s offices, but we’ll be heading downtown to get registered for Siggraph today I’m sure. I have a fair few things in my diary for the next few days so hopefully I’ll be lucid enough.

If you’re at Siggraph too and want to say hi, drop me an email (sinbad at ogre3d dot org or steve at torusknot dot com), I’ll check my email as often as I can. Alternatively you may find me on the ‘Works Zebra’ stand on the AMD booth (#323) where I’ll probably be from 3:30pm Tuesday, 12:30pm Wednesday and 1pm Thursday. The company will also have a presence on the Vicon booth (#1101) at times although I don’t think I’ll be needed for that. Bear in mind I’m there for my clients while on booth duty though, so if you want to yak about Ogre & unrelated TorusKnot stuff we’ll have to arrange to meet again later on.

Why Custom Allocators?

Two words: performance and flexibility. The default C/C++ runtime allocation routines are very general purpose and not really designed for high performance applications, and can suffer from fragmentation particularly when dealing with lots of small allocations. In addition, for some applications people want to be able to allocate memory from particular pools based on the type of allocation being made – think embedded systems and consoles for example which can have non-homogenous memory architectures.

The Feature List

I had a list of bullet points I wanted to tick off as part of this work, and I’m glad to say I think I’ve covered them all:

• Completely replaceable memory allocators for all heap allocations, for all classes, structures, primitive types and containers
• Categorised memory usage for all allocations; category can influence the allocator used
• Allocators compiled statically for performance, without requiring a user to change anything other than a single header file, but without dumbing things down to a single global type of allocator
• Tracking of memory leaks, with file & line number information
• At least one example of using a custom allocator instead of the default malloc/free
• Support for aligned memory allocation; both platform-specific SIMD alignment and user defined alignments

The simple approach

If you search the net for information about C++ custom allocators, you’ll run into generally 3 examples:

1. Implementing custom new/delete operators in a class
2. Overriding the global new/delete functions, possibly with macros to add debug functionality
3. Implementing allocator classes to replace std::allocator in STL containers

Now, don’t get me wrong, there’s nothing wrong with these techniques; indeed I’ve used 1 and 3 in my implementation (2 is evil, for reasons I’ll discuss later). However, alone the base implementation doesn’t scale well or allow the level of flexibility I was looking for.

My approach

1. Allocation policy: this is a strategy for allocating memory; this is the basic fundamental building block of memory management. Implements (potentially aligned) allocation and deallocation. Any class at all can be an allocation policy so long as it implements the allocBytes and deallocBytes methods.
2. AllocatedObject<AllocPolicy>: a base class for all classes with a virtual function table which need to use custom allocators. Defines custom new/delete operators which route the allocation via the templated AllocPolicy
3. STLAllocator<T, AllocPolicy>: an STL-compatible allocator object which delegates requests for memory for STL containers of type T to the configured AllocPolicy class.
4. Alloc/dealloc macros: in order to add file & line number information in debug mode to allocations to assist tracking of leaks, macros are normally used (since functions and classes would hide this information). Some people redefine ‘new’ and ‘delete’, and indeed that’s what our old leak tracker did (adapted from Paul Nettle’s work), but in practice this is a bad idea – it works if you only ever have to deal with your own codebase, but in a heterogenous environment with many libraries, it becomes hopelessly entangled far too quickly – either other libraries will try to do the same and clash, or there will be a mixed use of macro’d or unmacro’d new/deletes because of header inclusion order, etc. Instead, we use macros such as OGRE_NEW, OGRE_DELETE, OGRE_MALLOC etc. The downside is that we have to update our code to use them instead of it being automatic, but it’s far outweighed by predictability and it also resolves some knotty problems with mixed types too.

No huge surprises there I hope. The nice thing about this is that you can quite easily implement a single class which implements allocBytes and deallocBytes and it can immediately serve most memory management contexts. However, we’re only just getting started.

Category Support

All allocations are done by specifying a memory category. At the base level, you’re expected to define classes that resolve the following policies, which are referred to in the OGRE code:

template <MemoryCategory C> class CategorisedAllocPolicy;
template <MemoryCategory C, size_t align = 0> class CategorisedAlignAllocPolicy;


MemoryCategory is just an enum listing various usages, such as general purpose, geometry, animation, etc. CategorisedAllocPolicy is used to allocate unaligned memory in a given category, and CategorisedAlignAllocPolicy is used to allocate aligned memory – the default parameter of ’0′ for alignment actually means ‘use the default SIMD alignment for this platform’. The simplest possible example that we provide is this:

template <MemoryCategory Cat> class CategorisedAllocPolicy : public StdAllocPolicy{};
template <MemoryCategory Cat, size_t align = 0> class CategorisedAlignAllocPolicy : public StdAlignedAllocPolicy<align>{};

This ignores the category and generates an implementation for all categories using the allocators StdAllocPolicy and StdAlignedAllocPolicy – both use the default system allocators. You can use full or partial template specialisation to provide different allocation policy implementations for different categories of memory, of course, something like this:

template <> class CategorisedAllocPolicy<MEMCATEGORY_SCENE_OBJECTS> : public YourSceneObjectAllocPolicy{};
template <size_t align> class CategorisedAlignAllocPolicy<MEMCATEGORY_SCENE_OBJECTS, align> : public YourSceneObjectAllocPolicy<align>{};

I’ll be providing one or two other custom allocation policies as alternative examples.

The challenge of dealing with primitive types and non-virtual or external classes

Ok, so the cases that most of the examples around the net tend to deal with are defining custom new/delete operators in your classes, and implementing a std::allocator compatible allocator for STL containers. We’ve done that, I won’t repeat the details here. But that’s only half the story.

A typical application has to allocate far more than that. It needs to allocate primitive types, such as ints and bools, potentially arrays of them. It also needs to deal with classes which have been made deliberately non-virtual, so are not appropriate to be conveniently derived from a class which provides standard allocator-aware new/delete operators (like our AllocatedObject). A good example of this in the Ogre source is Vector3 – it’s a class, but it’s deliberately non-virtual, because a virtual fuunction table adds a pointer overhead to every instance, and while small, when you’re dealing with classes that are essentially small value types, that one pointer could increase the size of each instance by a great deal – with Vector3 it would be a 33% increase for example. When you consider arrays of these types, this can soon add up and start adding extra cache misses you don’t need.

Sure, you could individually define custom new/delete operators for these small classes to avoid having to inherit the common implementation (and please, don’t suggest inheriting without a virtual destructor to get the implementations but with no virtual function table, that way leads to undefined behaviour according to the C++ standard), but not only is this code duplication, it won’t work for real primitive types, and also not for classes from external libraries. A more general purpose approach is needed.

At this point most people resort to global new/delete operators – sometimes wrapped in macros (hopefully not called new/delete of course). This works to a degree, again until you start using multiple libraries. As soon as more than one library / app has tried to globally override new/delete, all bets are off. Cue all sorts of linker clashes between the two, and that’s even if you managed to disentangle references to new/delete in header files to avoid cross-pollination of definitions, particularly if you used custom parameters to the new/delete operators as you generally need to do if you want leak tracking or variable allocators. Basically, it’s a nightmare and given that Ogre is supposed to be a good citizen in a multi-library setup, it just wasn’t a practical option.

So, I chose to do everything via safely-named macros. As well as the regular OGRE_NEW and OGRE_DELETE which provide debug functionality for full classes but otherwise just delegate back to new/delete, I also defined OGRE_NEW_T / OGRE_DELETE_T to handle allocator-aware memory management (and debugging) for primitives and classes we can’t or don’t want to add new/delete operators to. They require slightly more verbose code, but they’re unintrusive:


Vector3* v = OGRE_NEW_T(Vector3, MEMCATEGORY_GEOMETRY)(Vector3::UNIT_Y);
OGRE_DELETE_T(v, Vector3, MEMCATEGORY_GEOMETRY);


Notice how I can use constructor args as usual; this would not be the case if I was using a malloc analog. What’s happening inside the macro is that it’s calling placement new ie memory is allocated via a custom allocator and then the object constructed inside it. I have to tell it the category, as opposed to that automatically being known by AllocatedObject-derived classes allocated via OGRE_NEW. I also have to tell it the same information when I destroy it with OGRE_DELETE_T – the category so that the same allocator can be used to free the memory (if there were different allocators for different categories, this is important), and the type so that the destructor can be called – because objects allocated with placement new have to have their destructor called manually. Note there’s a small hack here – if you know for sure that there’s no destructor, you can use OGRE_FREE instead which doesn’t call the destructor and doesn’t require the type again – this might be a good optimisation particularly for arrays (OGRE_NEW_ARRAY_T/OGRE_DELETE_ARRAY_T).

For primitive types with no required constructor or destructor, there is OGRE_ALLOC_T and OGRE_FREE:

long* pLong = OGRE_ALLOC_T(long, 10, MEMCATEGORY_GENERAL);
OGRE_FREE(pLong, MEMCATEGORY_GENERAL);


As mentioned above if you have a single primitive type you need to use a constructor on, you can actually mix OGRE_NEW_T and OGRE_FREE because you want the constructor, but there is no destructor called ‘long’:

long* pLong = OGRE_NEW_T(long, MEMCATEGORY_GENERAL)(0);
OGRE_FREE(pLong, MEMCATEGORY_GENERAL);


It might seem complex to have these different ways of allocating memory, but it’s entirely necessary to provide the full breadth of flexibility to be able to handle all types of categorised allocation without clash-inducing global new/delete operators. It’s important to note every one of these types of allocations functions identically in terms of memory leak tracing, debug line number information, and use of the allocator policies. That’s just not something you can achieve with just class-level new/delete operators and STL allocators without globally redefining new/delete (with all the inherent problems that causes).

SharedPtr throws a spanner in the works

This is all very well, but now that there’s several ways to allocate memory, via regular new, placement new or just via a raw byte allocation, if we then give this memory to a SharedPtr, it needs to know how to free it afterwards. SharedPtr now has an optional enum param to tell it whether to use OGRE_DELETE (regular delete operator), OGRE_DELETE_T (manually call destructor and free), or OGRE_FREE (just free memory) – it defaults to the first one for backwards compatibility.

The one limitation here is that memory allocated any other way than OGRE_NEW has to have been allocated via the MEMCATEGORY_GENERAL category. The simple reason for this is that alloc policies are bound statically, for speed – if we had to look up an allocation policy dynamically every time an allocation / deallocation was done it would slow things down. Thus, for classes which don’t have their own alloc policy bound (because they have their own new/delete operators via AllocatedObject), a single general one has to be compiled in to SharedPtr’s single destruction routine. Code which manually deallocates can use whatever it likes of course, since that code will statically resolve the allocator independently.

Conclusion

Phew – this has been quite in-depth I know but that’s the nature of it. I’ve spent a long time on these allocation routines, way longer than I expected, because I’ve been trying out loads of different approaches and figuring out what I thought was the best tradeoff of flexibility, speed and elegance. I’m sure it’s still not perfect, but I think it’s a lot more practical than the glib versions that tend to pop up when you look into custom allocators – the sorts that work perfectly fine if you have simple needs, you use all virtual classes, and you only have to worry about a single application source, but fall apart as soon as you have to worry about dealing with a wider variety of types, playing nicely with many different libraries, and need a way to allow people to customise allocation for different categories of memory use easily.

I still have quite a lot of code to go through, changing the explicit new/deletes to the correct macros and assigning categories where they’re missing, but I’m getting there!

Drum Pads
I decided to go for drum pads from RocPadz, which are basically just circular cut mouse mats with a rigid back. I went with these for a number of reasons, such as that the neoprene rubber is hard wearing and long lasting (unlike foam pads which quickly lose their effect). These pads also scored highly in reviews for ‘bounce’ which can make playing easier, and they were also rated highly for the QM drum set which I have. The other main contender was DrumSoft, but while their pads are nice looking, they seemed a little too delicate for my liking – reviews were very keen to point out that you could rip the top surface if you weren’t careful during installation, which made me think they might not stand up to long-term abuse as well. The only downside to the RocPadz is that they’re a little expensive for 4 modified mouse mats – you could actually just buy yourself some regular office mouse mats, cut them to size and get some rubber glue to apply them with, but a combination of laziness and the fact that the dollar is weak meant I decided to just go with the prefabs.

Installation was very easy, they even supply you with a little alcohol swab to clean the pads with first which I thought was a nice touch. The result seems very good – the noise from the pads is definitely reduced, and the fact that the drum sticks bounce more really does feel better when playing. The only downside is that it seems to very slightly exacerbate the lack of sensitivity around the edge of the drum pads, which was already there anyway but seems slightly worse. However the middle area of the pads, where you had to play anyway to avoid missing notes, are not affected at all, they’ve still highly sensitive and a very light tap will trigger them. I hope to play more over the coming days.

Kick Pedal
The kick pedal mod should be a familiar one by now, an aluminium plate from Pedal Metal. I went with the billeted metal version because it looked nicer than the regular diamond-plate – yeah, I’m a sucker for aesthetics. I also paid a little more to get the hinge replacement bit too – I don’t need it yet, and haven’t installed it because it’s more fiddly – I figure I’ll keep it as an emergency reserve in case my hinge does break, so I don’t have to wait for a replacement.

Installation was easy, once you get over the fact that you’re invalidating your warranty by screwing stuff into your plastic pedal. But I figure the warranty on the pedal is pretty useless anyway, since it’s the one thing that is highly likely to keep breaking in it’s original form under any long period of stress (given the cost of the kit, it’s scandalous that it isn’t already reinforced with metal), so I might as well make it more robust myself. Once it’s on, while it doesn’t make any difference to the play experience itself, it’s nice not to have to worry so much about how hard you’re stomping it, particularly as I’m starting to play on Hard now which is bringing in some rapid-fire kick pedal action in places. The main thing is that it totally eliminates the rather disconcerting ‘flex’ in the pedal if you pressed it between the hinge and the spring – this pedal ain’t for bending now.

So, I’m very happy with these mods – it’s yet more money down the throat of the ravenous Rock Band monster, but it’s so much gosh darned fun I really can’t hate it for it

One was that we had been retrieving the internal format of a GL texture after construction using glGetTexLevelParameteriv with GL_INTERNAL_FORMAT, in accordance with recommendations. However we made a mistake in that for cubic textures we were passing the type enum GL_TEXTURE_CUBE_MAP instead of the target enum GL_TEXTURE_CUBE_MAP_POSITIVE_X et al. Subtle, and for whatever reason it must have worked fine on older drivers, but the 175.x drivers became more strict and were throwing an error. Unfortunately our other sin was that we weren’t checking the error code after that call (after all, what could go wrong with something that simple? ) so we completely missed it, and the internal format, which we then used later on to generate software mipmaps, was nonsense.

As it happens, I’ve been trying out Graphic Remedy’s gDEBugger again recently – I’d previously tried it a couple of years ago and couldn’t get it to work properly with Ogre for some reason, and my post in their forum about it had gone without a resolution, so I let it expire without buying it. However, I really have come to miss having some way to easily diagnose GL issues, like you do with the D3D debug runtime (and various GL intercept / dump tools are ok, but generate so much data it’s hard to sift through it), and it’s clear to me that the error above may well have been highlighted by a tool such as this before the driver started to bork on it. So, I emailed GR to see if they’d be willing to give me an extended trial license and some assistance with resolving the problems I was having. They got back to me really quickly, and via our correspondence identified an issue that they will resolve in the next version of gDEBugger, but which I could also work around in Ogre for now. I haven’t had a lot of time with it yet but I intend to give it a workout over the next couple of weeks, and buy a permanent license if it turns out to be as useful as I expect.

I really appreciate being able to get help like this when I need it, I’m in debt to the people at NVIDIA (especially Kevin) and Graphic Remedy for the assistance. Thanks chaps!

Your best conceptual design friend is a stack of paper (preferably recycled or, in my case, the backs of unwanted printouts), a HB pencil and a stout eraser. Oh, and a large paper bin, you’ll need that. There is nothing, absolutely nothing, faster for conceptual design than this, and I seriously doubt there ever will be, until of coruse they invent direct neural downloads. You’ll blast through ideas fast, you can link them up however you like, spatially arrange them, and easily discard them without feeling you’ve wasted too much time. Everything you do is exploration and requires no more effort than it merits.

So, don’t believe the hype from people trying to sell you design tools. Design is about what humans do best – deciding how best to tackle problems given a potentially abstract set of environmental conditions. The only tools you need are those that help you explore that, and the simpler the better. Get complex once you’ve decided on the approach by all means, but do that any earlier and it’s just slowing you down, and make doing the other things in this list harder.

2. Look at any problem from multiple directions
Don’t just think of a feature from the perspective of how you want to use it now; study trends and decide how it might be used in the future, or what else you might use it for given a moderate conceptual twist. You can’t predict everything, but anticipating change and alternate usages will give you a better chance of picking a holistic approach, where your current intended usage is just a facet of a greater, more generalised implementation.

3. Look for patterns
Almost every software engineering problem has been encountered before, in some guise or another. That means other people have already put a lot of thought into approaches (which may or may not be appropriate for your needs). Don’t come up with your own solution before exploring these, at the very least they may influence your eventual solution if you’re in the rare situation where none already exists.

This is one situation where being at the computer may help, if you don’t have a good grasp of a good number of design patterns already, and don’t have a good library on the subject. However, there is no tool that I’m aware of that can suggest a pattern for you, since drawing parallels with other data sets and pattern matching is something humans do very well, but machines very much less so. Also, blind internet searching can lead you astray, ince using patterns without appropriate context can be worse than not using them at all – every pattern comes with a set of parameters and suitability conditions that you really have to have a good grasp of. Your best bet is to read all the time – books like the Gang of Four, online articles etc, and re-read them regularly to keep them in your head so that you’re more likely to spot an appropriate pattern when you see it.

4. Always document your reasons for a design choice
There’s no such thing as a perfect design, every design is a series of compromises based on the goals and constraints in each problem domain. Being explicit about your reasons for choosing one approach over another allows you to evaluate alternative approaches long after your mind has exited ‘the zone’ on this particular issue.

5. Ruthlessly define scope
Knowing where your boundaries are is one of the most important things in design. If a designer can’t tell you where their system ‘ends’, or imply that it does ‘everything’, then they should be very worried. If you can’t define what’s inside, and just as importantly what’s outside your scope, how on earth are you ever going know when you’re finished, or whether a feature belongs in your system or whether it belongs somewhere else? You can’t.

You absolutely must be able to draw a clean, unambiguous box around any system you design. That’s because every system in the world has to interact with other systems, and that box represents the interface points – anything going in or out of that system boundary needs an interface, and that’s one of the most important aspects of the design; many systems will live or die by how well they can be integrated with other systems. If you can’t clearly define what’s ‘inside’ and what’s ‘outside’ that box, you can’t possibly define the line that describes it, which means you can’t define consistent interfaces. What you end up with is a bleeding, feature-creeping system with ad-hoc integration points without any holistic design behind it. If you’ve ever had to integrate with a system that feels like that, you have my sympathies.

6. Plan for change, but realise your limits
We all know that nothing stands still. That means we should try to design things flexibly so that they accept change readily. Using approaches like data-driven design, good abstraction of discrete concepts, dynamically customisable code (e.g. plugins) all help achieve that goal and are nearly always a good thing. But, you have to draw the line somewhere – there will be times when you have to make assumptions. That’s fine, so long as those assumptions are documented, and preferably they sit on your ‘scope boundary’ – ie in your original scope definition you said you would allow for ‘x’, and no more (see previous point). Sometimes, you just have to stop somewhere, stick a flag in, and move on to something else.

Why not try to plan for all change? Well, you can’t, and your efforts in this area will yield diminishing returns. Change within a strongly cenceived scope is a good idea, but beyond that scope you should deal with change through refactoring, should you need to. Hopefully your scope is defined clearly enough that you can draw that line in the sand unambiguously (again, see previous point).

7. Don’t be afraid to change your mind
Being wrong is fine, so long as you’re willing to realise and embrace it. Be aware that design is an optimisation process, and is often iterative – you’re trying to find the most appropriate design for the problem at hand, within the time constraints you have available. This means that even your best design may only be a local minimum; there may be other solutions which fit your needs better that are just over the next ‘bump’, you just might not be able to see them yet.

The previous points I’ve made are all in support of this point. Never assume you’ve got the best design yet, because you probably haven’t. Keeping agile in your design process (point 1), being as open-minded as possible (point 2), looking for accepted wisdom (point 3), putting a stake in the ground when you’ve made a particular choice (point 4), and knowing your scope for change (points 5 and 6) will all help you reflect when a potentially better option becomes available.

Maybe that’s given you a little insight into the way I go about design from a high level. Maybe not, or maybe you don’t care But there it is anyway.

Until my tooth starting yelling blue murder – loudly. You wouldn’t have thought that a tooth had a good pair of lungs on it, but this one did. I have sensitive teeth anyway, so I assumed it was a cold day / hot drink thing at first, but this little blighter just wouldn’t shut up. Not being able to concentrate, I left the computer and had a bash at Mario Kart for half an hour or so to take my mind off it. Still hurt. So, I made an attempt to dull it with pain killers and hit the sack.

This morning it had mercifully calmed down, but I went to the dentist to get it checked out. The news is that the oldest hunk of metal in my head (yes, this filling dates from the time when you had to go to a blacksmith to get yer teeth sorted, so yer did) has started to become defective, and hence has a habit of leaking ostensibly harmless tea into rather sensitive nerve ending cluttered cavities. Damn.

So, tomorrow I have to return to have the thing refitted with a new and improved ‘Filling 2.0′, which I can only imagine these days includes a toungue-activated, flash-based MP3 player built in. Well, for the price they charge, it has to have something good, right?

I have Express already obviously, but I’m still doing most of my work in 2002 since I can’t bear to be without my favorite plugins for too long. Let’s hope it arrives before Xmas, think of all those sad little faces on Christmas morning if Visual Studio 2005 doesn’t make it into their stockings. Santa just might end up on the business end of little Johnny’s next DDOS attack. Bless.

Dagon is still waiting in the wings, targetted at the end of the year now although, as always, it’ll be done when it’s done – something that’s especially applicable when doing things in your spare time. My main goals are to implement shape exporting in XSI, for morph animation and facial animation, but it requires that I learn more about modelling those things in XSI first. I’ve already started making my way through the training DVD and it’s really quite fun. I wish I had more time to play around with XSI, it’s a really nice tool.

Given _mental_’s absence lately I’m may also going to need to pick up the point sprite work he was going to do, unless :wumpus: gets there first. People’s time is very unpredictable so we’ll see how it goes. I’d also like to do a HDR demo of some sort sometime since I messed about with HDR in OGRE for a client a little while back and would like to show it in action.

Of course along with all this I have Kadath in the background, which I really must get on with. I lost a fair amount of time due to some personal issues over the last couple of months, and pretty soon it’s going to be early 2006 which was my target for the first version. So, time to crack the whip some more.