Home

Awesome

libc3 - No frill 'scene' graph library in C

(C) 2012 Michel Pollet buserror@gmail.com

WARNING This API is not your nanny. It is made to be lean, mean, efficient with no frill, no asserts, no bounds checking, no sugar coating.

On the other hand it's fast, reasonably clean and is a micro-fraction of the other giganormous 'scene graphs' or 'game engine' libraries around.

It's vaguely inspired by THREE.js funnily enough, because it allows you to hack around and quickly get stuff on screen with the minimal amount of effort.

Introduction

The general idea is that the library keeps track of geometry and stuff, but doesn't do any opengl or related calls. Instead, it uses callbacks into code that will take care of the rendering related tasks.

So for example a c3pixels represents a texture, but a callback into the rendering layer will be responsible to push the pixels to OpenGL, and store the object back into the c3pixels for reference.

Status

The API is generally functional, but it's brand new. I try not to add bits that I aren't needed, and I also don't add stuff that isn't tested.

There is an ASCII STL file loader that works, and a few other bit of geometry related helpers.

It's currently used in one 'serious' project and also in my 3D printer simulator. libc3 also builds a companion library called libc3-gl that implements a default OpenGL renderer 'driver' as a set of callbacks. libc3-gl does the 'dirty' work for loading shaders, creating and maintaining frame buffer objects, vertex buffer objects etc.

General Roadmap

There is a PDF Flowchart of how things are mostly organized as far as data structure goes, but the following is a breakdown of the major components.

The API has various bits:

The basic data structure is as follow:

Also there are:

Draw Drivers "Inheritance"

Various object uses static tables of callbacks to implement their behaviours it's kinda cheap c++ inheritance, without the usual bloat.

There just a couple macros to call the driver chain for a particular function call. The relevant bits are in c3driver*.h.

Mostly the code looks for a matching callback in a static table, and call it if found. If that callback wants, it can also call the inherited object callback too.

Dirtyness

There is a notion of 'dirtyness' in the tree, when you touch a c3transform, and/remove objects and geometry, a dirty bit is propagated up the tree of object. This tells the rendering it needs to reproject the dirty bits and repopulate the projected vertice cache.

The 'dirty' bit moves both ways, when setting a dirty bit to true, it propagates upward, when you set it to false, it propagates downward in the tree.