iDeveloper's Advocate

A small introduction to scene graphs and the Composite design pattern

Every non trivial graphical application houses within it some form of data structure that organizes the placement and grouping of the objects that need to be rendered to the screen. The data structure used is most often represented as a collection of discreet data blocks linked to each other in a parent child relationship. The data blocks can house many different types of information useful to applications rendering passes.

Spatial and positional data represent the size, rotation and location of objects.

Graphic engine state data represent the current rendering instructions to be applied to a group of visualized objects.

Command/control and rigging data representing property and state changes for a group of objects.

A scene graph is a high level spatial data structure that organizes visual data in a tree made up of a collection of nodes. A node may have many children but will often only have a single parent. The transformation and render state data of the parent node provides context for the child nodes. An operation applied to a parent node automatically propagates its effect to all of its children unless purposely blocked. As a spatial implementation of the Composite design pattern scene graphs allows groups of graphical data or nodes to be treated as a singular node.

The Composite pattern specifies Components, leaves and Composites as it structural components. It describes a means of composing objects into tree structures to represent object hierarchies. The whole of the composite is made up of it's parts and each part can be viewed as identical in the composite. In a scene graph the node class is used for all 3 of the above structures. The base node class implementation has at least member variables referencing it's parent nodes and a collection of children nodes. The references between the nodes are used to form the structure of the scene graph.

CocosNode

In the Cocos2d-IPhone framework's scene graph implementation CocosNode is the basic node class. The CocosNode class houses a single pointer to it's parent node and an NSMutableArray of pointers to any children nodes it may have. CocosNode objects also maintain an NSMutableDictionary of Selectors (callback function pointers kinda, well talk about these in a future post) and data members for size, position and rotation data.

Since the CocosNode class is the base of the node inheritance hierarchy it doesn't do much on its own. It is an object with no size and no sprite or texture information that cannot except touches or accelerometer data. The CocosNode derived classes provide the majority of the special functionality required to create a usable Cocos2d-IPhone based touch application. The majority of these classes add enough functionality that each should really get its own post. I will introduce some of the more necessary CocosNode derived classes here and describe some of the functionality they add to the base node class. Remember, when all else fails and you cannot find a CocosNode derived class that does what you need you can always derive your own and add your special functionality.

Class derivation and Cocos2d

On a side note, your general workflow for using Cocos2d in you applications will most likely be to subclass one of the CocosNode derived classes, add custom code in it to manipulate its properties and or its children nodes properties, instance the derived class and push the instance into the scene graph. There are a few exceptions Sprite, the canned particle effects, and Menu for example where you can instance without subclassing, but you should get comfortable with subclassing.

Scene

Any node can be the root of a scene graph data structure. Some scene graph implementations provide a base node subclass who's only purpose is to act as the root of a scene. The Cocos2d-IPhone Scene class when instanced creates such a node and it or a derivative of it should act as the root node for all of your in application's scenes. Scene class instances are anchored at there center and are no different than the base CocosNode in any other respect.

If you review my previous post on the Director class you probably recognize that I created a blank generic scene in the example code and ran with it. In a real simple example application it would be useful to create a credits/splash scene, a menu scene, and maybe a gameplay scene. Each a scene represents a logical unit of functionality and can be used to organize interface mode transition and flow. For example the splash scene go be set to display for a short period of time and then the menu scene could run and wait for the user to select a menu item transitioning the application to the gameplay scene. I generally like for my scenes to be instanced in the Director as it is a singleton that can be found easily but there are many ways to skin a cat.

Layer

The Layer Class is probably the first do something CocosNode derivative that you will encounter. Before we go into what it does lets discuss what layers represent. (Warning: The aspect of layers I am about to discuss is not represented by any special functions or member variables. This is just an opinion/understanding I came across.)

Layers could be seen as analogous to transparent sheets stacked along an axis exactly on top of each other. In the areas of a layer that don't contain content, you can see through to the layers below. Layers in Cocos2d allow cartoon cell style imagery in a scene. For example you can have one layer as a the background of the scene, One representing the score or some other textual data and another with actions moving visual objects around the scene. Objects in one layer may partially or fully occlude objects in the layer beneath it during the running of the application.

Cocos2d layer class instances are command and control nodes. Instances of the layer class can take in the touch and accelerometer data that represents the users interaction on the IPhone platform. Layer is a canned conduit for you the developer to allow the user to interact with your application in a special way. I will go into the Layer and Touch delegation in more detail in a future post. The Layer class has a couple of derived classes that allow for coloration and multiplexing. Coloration is simply allowing the tinting of a Layer. Multiplexing in this context is about having a set of layers being mutually exclusive and not visible together. Maybe useful for separate selection screens or multiple menu hierarchies.

TextureNode, Sprite, AtlasSprite

I am going to finish this post with a small discussion of the TextureNode, Sprite and AtlasSprite CocosNode derivatives. Each of the classes is primarily concerned with the getting image data to the screen. I consider instances of these classes to be primarily leaf nodes in the scene graph.

TextureNode simply allows a specified image to be rendered to the screen. It handles the work involved to import and render an image in OpenGL (you should try to do this using opengl calls so you appreciate the class).

Sprite is concerned with sprite rendering and simple sprite animation (think gif) and allows you to use individual images to do sprite based animation. Using Sprite and its individual image based animation implementation can be memory consumptive and slow. I could see using the Sprite class initially in a project to get things set up and looking good an then moving on to the AtlasSprite Class and a texture atlas once you are actually producing something for App Store consumption.

The AtlasSprite class allows for a collection of visual data to be specified in a single image generally called a texture atlas. The AtlasSprite and its manager class controls the navigation of the texture atlas moving around to the indexed part of the texture and render a set of pixels from the location. Texture atlas-ing is a topic unto itself so i'll stop at that until later.

This concludes this post. Next time I will talk about Actions, Transistions and callback selectors. Thanks for reading!

PS: I am trying to get code printing pretty but its not working out well. Once I figure it out I will be adding code examples to this post.

iDeveloper's Advocate

Tuesday, June 11, 2013

Moving to DoublePlusTouch.com

Sunday, March 7, 2010

Still going

Still going

Still going

Monday, December 21, 2009

MotionInk Free for 24 hours

Wednesday, September 2, 2009

The end of project crunch!! Feverous

Saturday, August 8, 2009

Ramblings about Scene graphs and CocosNode

About Me

Blog Archive

The list of 10 (There's never ever actually 10 Links)