This will be an overview of that I think is the coolest scene graph philosophy ever. It will reduce the code and make your graphical framework more dynamic and easier to maintain. It is preferred that you know a bit about regular scene graphs to better grasp the idea since this is not a post about scene graph in general.
The basic structure of a scene graph is a basic node tree. The biggest difference is that the node in a scene graph will have more properties. How ever I will not go into details about this since it is a basic abstract data type. Although I will give you a really quick overview so that you will see the difference between a regular scene graph and a behavioral scene graph.
The regular node has a data object attached to it. I think this data is the perfect place to store the data to be rendered. I usually uses the name entity instead of data so we change that. So now we got this:
The graph is still intact with just one single node type, what we change is the entity. Different entities can be light, camera, animations or any other type that you usually find in a scene graph.
I also like to add another property to the node called behavior.
This is where it gets cool. A behaviour is attached to the node just as a data object but the behavior also have access to the node and it’s properties.
Before the rendering we usually have a call to update the logic this update call should be rerouted to the behavior. Meaning that we do not add any specific logic to the node we add it to a behaviour attached to the node. This make it easy to change during runtime.
Say we have a behaviour that is an animation it can animate the node by accessing it’s properties. This way we get an easy way of animating a node. It is also really easy to reuse and attache to other nodes.
Let us make a button. We create an implementation of the behaviour that have functions like: onClick, onLongClick, onRelease and so on. This functions could trigger different animations depending on the desired behaviour on our button.
If we have a behaviour that strives to put the children of the node in a certain way by animating them in a nice ease-in-ease-out tween from their current position towards their preferred position.
And we implement a behaviour to have the preferred positions mapping against a grid like layout. This will make the nodes in a nice way be animated into a grid layout.
If we then make an implementation that have the preferred positions arranged as in a circle and at any given time set this behaviour to be the acting behaviour on our node. This will make all the child nodes change their preferred positions and start moving towards the new preferred positions.
Let us step it up one more time. Say we create an adapter node similar to the adapter view in android and give the node a default set of 5 children. We then make an implementation that arrange the children of our node into a list and makes it scrollable and to exchange the children as they fall in and out of the visible range of the list.
Make an other behaviour that also uses an adapter node and make this one display the child nodes as a roller index and swap the behaviours. Now when we change the behaviour we get a cool animation between two different list layouts.