Frequently Asked Questions

Here are some common questions and answers about spineFORGE, the Spine system and Immersive Digital Environments:

What is an "Immersive Digital Environment"?

An Immersive Digital Environment is an artificial interactive environment presented by computers which enable human users to immerse themselves in any imagined scenario. I use this term to describe it because I feel the commonly-used term, "virtual reality" does not fully describe the possibilites of virtual worlds.

The Digital Environment can be applied in many ways. The role or application of this environment is up to the environment designer. A well designed immersive application can get the user "closer" to the task at hand - be it work, learning, shopping or playing games.

Please see [this page] for more information.

What is spineFORGE?

spineFORGE is (for the moment) a one-man project started by Chris Rose-Mathew, the author and maintainer of this website, to build software libraries and tools that enable the creation of diverse immersive digital environment applications.

I collaborate with a small band of talented creators who contribute to various aspects of spineFORGE developments such as collecting and building digital resources, brainstorming and providing constructive criticism.

Please see [this page] for more information.

What is Spine?

SPINE is a software platform that developers can use to build immersive applications or tools. It provides the basic constructs needed to develop useful programs, as well as access to 3D graphics, surround sound, networking and storage capabilities of today's multimedia-enabled computer systems.

Spine is targeted at computer programmers familiar with C++, although the library has been designed with a focus on being easily discoverable and understandable by a much larger audience. It is hoped that bindings will eventually be made available for a wide variety of programming languages.

See [this page] for more information.

Is Spine ready yet?

Not yet. The core Spine modules are in late implementation phase. They are also undergoing extensive documentation. And as they say, the last 10% always takes 90% of the time...
Due to the fact that spineFORGE is a part-time enterprise, exact release-dates cannot be established.

It must also be said that the initial release of Spine will not be a "finished product" by any means. It will contain a core set of modules that should provide the beginnings of a solid base for expansion towards the goal of providing a flexible platform for immersive digital environments.

The roadmap for Spine will see it expand to provide comprehensive interfaces for the "essential utilities" required by multimedia application developers of the moment.

Why are you building a new real-time system?

Because 3D immersive digital worlds are great fun and full of possibilities...

Spine started off as a personal academic challenge to "see if I could".
Originally I wanted to build my own custom VR worlds and video games - so I needed a basic platform upon which to build up my ideas, a layer to shield me from the messy parts of computer programming.
Spine is becoming that layer, and in recent times, 3D visualization is garnering enough mainstream publicity and application to prompt me to focus on enabling outside usage as it would be cool if other people could get as much of a kick out of my work as I do.

How much will it cost?

The gritty details of Spine licencing are still under consideration, but I have resolved to release it under some sort of Free Software license, probably in some kind of dual-licensing situation, which could enable Free Software and commercial developers alike to benefit in the ways that each respective party appreciates - it enables commercial developers to build closed-source proprietary applications for a fee, while opening up the source code to Free Software adherents.

One should not have to "subscribe" to a development platform, or depend on the existance and good graces of the original developer, to be able to use and apply a technology.

When it is finally made available, please visit the licencing section of the Spine Software Development Kit for more information.

Will Spine suit me?

You can read the Spine Introduction to find out more about the purpose and design of Spine.
Coming shortly, you will be able to browse the API Overview to see what components and types Spine makes available to programmers.

How do I do XYZ with Spine?

Please see [this page] for more information.

What sort of graphics can it draw?

Spine will eventually be capable of drawing 3D and 2D real-time graphics involving animated characters within detailed immersive worlds. The technicalities and complexities of 3D drawing and rendering will be largely taken care of by Spine's Visual module, but the quality and uniqueness of your world, will be up to your artistry of course.

In it's current state, Spine can draw static 3D models loaded from OBJ files as well as from ESRI shapefiles, which store geographic vector data. It can also be manually fed geometry to render in batches.

Spine can load and make use of image texture files in various formats, including JPEG, PNG, TIFF, BMP and others.

The programmer can compose a scene by using terminology and concepts familiar to film-makers, placing lights and textures onto a stage and capturing the visuals through a camera as they change over time.

How will Spine provide access to graphics hardware?

Spine is a simple "direct-mode" image renderer. It does not provide a persistant scene-graph. The Spine graphics system (modules found in the Spine::Visual package) is built around an abstract Scene interface, which enables the building of plug-in graphics systems layered thinly over various industry standard graphics API's such as DirectX and OpenGL, or custom systems using alternative methods.

Currently a DirectX8 renderer is in place and there are plans for an OpenGL implementation of equivalent capability.

In terms of programming Spine graphics, your code will send Visual::Shape objects to the renderer with a position and orientation and these are drawn with an active Material. A Scene usually has many different materials. Each Material has modifiable properties such as shininess and transparency that affect how each Shape is drawn. The final scene is captured with a Camera.

I am in the process of providing support for blending (or morphing) multiple shapes together, which can achieve subtle animations like breathing and facial expressions. Skeletal animation based on joints will follow a little later.

Currently, only fixed-function graphics capabilities are exposed by the Spine Scene interface. I have refrained from jumping onto the "latest-shader-model bandwagon" due to the rapid evolution of the various graphics interfaces and shading languages in recent times. It has been more worthwhile investing effort in more basic, but essential aspects of the system, but the time for shader-based graphics will come.

How does Spine handle user input like keyboards, mice and joysticks?

Spine has been designed with a minimal and generic, but flexible idea of how to handle physical user input actions and responses:

Spine has a module called "Haptic" that provides human input capture. This module provides a way to recieve buffered input through application-defined KeyBoardReader and PointerReader objects.
These objects allow the accurate capture of motions and trigger commands from real computer input device such as a mice, tablets, joysticks and the usual keyboard. Your application can handle these input events how it pleases.
It is also possible to directly query Haptic::DeviceManager objects for the current state of attached input devices in real-time.

Does Spine support accurate timers?

Spine currently provides comprehensive support for timers on the Windows platform. Spine has a Time module that includes classes that manage dates, timestamps and timers. The Spine Timer can use high-performance operating system timers and can also fall back to use standard multimedia timers if no performance timers are available.
I am in the process of building equivalent support on POSIX-compliant platforms as well.

What about scripting?

Spine does not support scripting directly (yet), but it's API has been written in such a way as to be appealing to web developers familiar with Java, Javascript and .NET, and that will fit in well with the existing API's used in these places.

On another level, it is hoped (maybe a little optimistically) that Spine might provide a C++ interface friendly enough that the need for scripting is minimized, and that people who might have passed over C++ as a viable development option might take another look. I consider it highly important for our society at large that a sizable and vibrant community of developers using "low level" languages continues to exist.

What about OpenKODE?

OpenKODE seems to offer a new solution to a lot of the problems Spine is trying to solve.

On one hand, if it proliferates, OpenKODE would certainly make my life easier when implementing Spine support for many different platforms, but on the other hand, it sits as some kind of competitor because many developers would likely bypass a little-known C++ library for a industry-supported API.

In Spine's defense, OpenKODE does not offer multimedia support, leaving that to sibling API's like OpenGL, and it is not yet very widespread across platforms. It is still very POSIX-like and procedural than many application developers might prefer, leaving a market gap for software frameworks that provide higher level programming interfaces, especially those that can provide low-level speed.

Either way, if enough platform vendors offer an OpenKode API it would be an amazing boon for the computer industry and an advancement in the adoption of open interfaces and specifications, protecting users from vendor lock-in.



Back to Top