Code regrets… :)

There’s always regrets while coding, specially when we’re talking about a 10+ year codebase (with lots of refactoring, etc)… One of my main mistakes for ages was not to use matrix calculation. Of course, I used matrixes when it was time to deliver things to the graphics card, etc, but other than that, I ran away from them like a madman, because:

• they’re hard to debug,
• my linear algebra is terrible
• they’re terrible to interpolate and manipulate (except in very specific cases, more on that ahead)
• the dreaded gimbal lock problem

Thing is, matrixes are brilliant for hierarchic representation of data… and SurgeEd has plenty of that!

So, I’ve been converting (slowly) my engine to leverage matrixes, using them to describe composite transformations, but keeping my old system of vectors/quaternions to store the local transforms. So, each time I find something I can’t do using my normal system, I refactor another piece of Spellbook/SurgeEd to accommodate it.

A problem when doing this sort of thing is that algebraic spaces get confused easily… A matrix describes a local space, but the composition of matrixes eventually describes world space, and going from one to the other is an issue, specially because Spellbook was always used in a world-space only philosophy.

For example, the routines that compute the bounding box of an object return that bounding box in world space, but in most calculations nowadays, it’s better to use local space in most of it and just convert it in the end, if needed.

I should just bite the bullet and refactor the whole transformation system in the engine, but when you have about 200k lines of engine code+100k lines of editor and player code, it’s a though decision to make…

Anyway, been working in the innards of the editor and engine lately, trying to get some systems to run smoothly and add options to the artist. For example, now I’m implementing custom bounding boxes, so that the artist can just define a bounding box for the object, which is exceptionally useful for skinned meshes that have objects locked to mountpoints. Visibility culling is easier to implement this way, and faster; the only problem is that it is very “conservative”, leading some objects to be drawn even if they are off-screen, but considering the GPU/CPU tradeoff nowadays, it’s a small price to pay.

My bug list is currently huge (quick glance at it has more than 40 active bugs), but hopefully I’ll really tear into it the next few days, since I know where most of the problems are.