Spine was developed alongside basic test applications as well as over-ambitious PC-game projects that used it's evolving capability. Spine has also gone through several generations of names and planned uses. Here are screenshots of various projects using the framework at several points in their lifetimes. Many of the applications and demos were different experiments for the creation of the ultimate user interface for a 3D terrain editor. Designing good interfaces to programs, at a user-level or developer-level, is a challenging and fun, yet never-ending task.
iCorelab's Alpine Engine
Spine used to be known as the Alpine engine, and spineFORGE was originally dubbed iCore Labs - that was until I saw the office block of a company called ioCore and figured that they probably added the 'O' because iCore already existed somewhere. It was close enough anyway - and with Apple Computer pushing it's iEverything branding, I suppose it was a good move in hindsight. At the time, the goal of Spine development was basic randomized fractal terrains. The Alpine Engine was first written as a simple wrapper around the OpenGL graphics library, with a terrain module bolted on.
The system provided tiled terrain textures and collision detection with trees.
From this platform a reasonably flexible particle system was built as an experiment.
No network support existed at the time, which was during my first (and only) university year. RiC Shields and I were working on two demo projects, Toasted Planet and
Death From Afar.
Fun and GamesToasted planet was an unfinished attempt at a 3D clone of old computer game, Scorched Earth, while with DFA we tried over-ambitiously and unsuccessfully to model ultra-realistic woodland sniper combat in the vein of the first-person shooter games Rogue-Spear and Ghost Recon. RiC made some cool otherworldy textures and built our prototype tank models. Unfortunately, realising that we were in over our heads and with university becoming too large an influence on our lives, we abandoned the projects. We'll get back to them one day.
Here is the one of the few remaining screenshots from the original OpenGL Alpine Engine:
The original Spine graphics system used a simple dynamic, CPU-based vertex buffer that fed OpenGL. The terrain engine was written early on, used (and still uses) quadtrees with distance-based level-of-detail reduction. Surround sound capability was available originally through DirectSound3D version 7, which was a very simple, yet powerful sound system. Spine now runs on DirectX9, and is capable of using hardware vertex buffers.
Alpine was capable of large (but not streaming) terrains and generated forested areas automatically. I also implemented a procedural lake generator, that found depressions in the terrain to fill lakes in.
It never seemed to find really large areas to fill unfortunately. A threshold value or overflow system is required somewhere...
Alpine was ported to DirectX with OpenGL development being shelved for the time being,
because too much variation in rendering results were being experienced between different
graphics drivers. I had strange Z-buffer issues that I just couldn't figure out.
I do want to return to OpenGL development once the plug-in rendering system is complete.
Difficulties in the port were redoing the frustum culling code, which in the OGL version, was based based on a well-known tutorial. Frustum culling is a part of 3D calculation where objects not in the view are flagged not to be drawn - thus speeding up the drawing of the scene.I had no reference for DirectX - which uses a swapped coordinate system. Some research and experimentation, rather than mathematical skill won the day in the end.
Here is the first screenshot from the DirectX port of Alpine.
Running DirectX, Alpine demos grew in functionality. More auxilliary features were added to increase immersion - simple things like realistic head movement while walking at different speeds, tweaked accelerations when starting and stopping, as well as smooth crouching.
Really fun stuff.
Here is an early version of the DirectX port which used tree sprites from the DirectX SDK. Multitexturing is in use on the terrain, with layer 1 a stretched base color map in which artist can paint fields, paths and river beds, while layer 2 is a tiled detail texture that can represent pebbles and grass.
At some indeterminate point, I became interested in the idea of using 3D immersive programs for more than just games and flight simulators, and renamed Alpine, the engine for making mountains, into Spine, the backbone of my immersive digital environment.
iCore became the spineFORGE.
Later versions of the system had a sprite-rendering facility for drawing distant objects. Since the plan for now is to extract the terrain renderer to a DrawModule, this function has been lost for the time being. Recent versions of Spine demos have full-resolution models for the entire view extent. On recent computers with modern graphics cards, this has proven to be no problem. Graphics hardware is spoiling us. The screenshot above was taken from a Voodoo3 16-bit card - my base-line benchmark for the time.
This screenshot is from the most functional Spine tech demo so far. I worked on it with Jean Pierre Allers, who did most of the 3D modelling, animation and most of the character-related texturing. This demo allows multiple players (I think 6 players as the most ever tested at college LAN events) to have a first person shootout in a bare-bones capture the flag-like scenario. Only very basic shooting-hitting-respawning functionality is in place. No scoring or anything like that was done. Game access is through command console only, so no nice menus or GUIs are available either.
A large heightmap based, river-crossed terrain with a large amount of fir-like trees along with grass and ferns provides the playing field. Sound support is quite advanced with each player able to hear his friends and allies crash through the underbrush in full surround sound. Simple test soldier models with basic animations and FAMAS and HK weapons provide the player avatars.
Finding a good terrain texturing system that artists like is difficult. Not to mention overcoming all the various hardware graphics card quirks while still allowing flexibility - so the best thing is to try just to let them do ANYTHING. Spine is nowhere near there, though I am working towards that goal.
Certain Spine tech demos also include underwater caustics implemented using animated multitexturing, using a similar method to that in the DX8 Dolphin demo.
Whats happening at the moment?
Web development. I have been spending the last year building this website, while going back to the drawing board after 3 years of non-stop coding to figure out how to integrate all I've learnt up to now. I hope to build Spine into a framework that I find extremely pleasing to use. I hope you do to once I release it.
Next on the TODO list is pulling out monolothic components into plug-in modules, and building a large library of tutorials and documentation for all the Spine components. The first major release will likely be a version of the Core networking services and application framework. One major decision is how many existing libraries to use. I have been building my own XML parser and DOM to act as a central access point to Spine configuration, but I've started to sway as I read more of the related spec's - because of course - I would want to implement them ALL. Moderation...[More screenshots]
Find out more about [spineFORGE]