A behavioral scene graph

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.

Node tree

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.

Example 1:

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.

Example 2:

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.

Example 3:

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.

Example 4:

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.

This Post Has 5 Comments

  1. Johannes Bühler

    Hi Per-Erik,
    besides the interesting article i really do like the diagramms. What software did you use for creating these images?

  2. max

    Thanks for the post.What is the maximum amount of nodes that can be stuffed and displayed on a typical android application??

  3. Per-Erik Bergman

    max: That is almost impossible to say since it is depending on what the nodes will do. It is also depending on if you using some kind of octree or quadtree to help you.

  4. Evandro

    Hello! My name is Evandro and I live in Brazil. I am doing Bachelor of Computer Science faculty of the Catholic University of Salvador. I was reading the tutorial on OpenGL + Android. Very good! But I had a problem in the first part. It’s a bit complicated for me be reading and writing in English. With the help of google translator did this message. I would like to contact you so that I can “unlock” my current state and start developing using OpenGL. I await your response by e-mail . And I hope it is gratifying to know that his teachings are to traverse the world. A hug. Evandro.

Leave a Reply