Jump to content
  • Advertisement
Sign in to follow this  
Toni Petrina

Scenegraph and entity management

This topic is 5465 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Since I'm out of computer, I dived into some designing. My first target is scenegraph implementation and entity management. Sorry for this long post but I encourage you to read it. Consider example scene :

          ( )

Sorry for the art. This is a ball above a plane above which is a light. Not too many elements, huh? In my opinion, scenegraph for this scene should (could) be somthing aling lines of this
Scene root							// root node
 |-Materials						// all scene materials
    |-Dirt							// plane material (diffuse+color)
       |-TextureRef(Dirt01.jpg)		// reference to texture
       |-ShaderRef(BasicShader)		// shader for rendering
    |-Plastic						// ball material (color+n.l lignting)
       |-ShaderRef(SpecularShader)	// shader for rendering
 |-Textures							// scene textures
    |-Dirt01.jpg					// texture that Dirt material is referencing to
 |-Shaders							// scene shaders
    |-BasicShader					// plane shader
    |-SpecularShader				// ball shader
 |-Models							// scene models
    |-Plane.x						// plane model data
       |-MaterialRef(Dirt)			// link to our material
    |-Ball.x						// ball model
       |-MaterialRef(Plastic)  		// link to our material
 |-Entities							// all scene entities, you could have them flat in scene root
    |-Static01						// entity that represents our plane
									// has following properties : renderable, collideable, receives shadow
	|-Pawn01						// entity that represents our ball
									// has following properties : renderable, collideable, casts/receives shadow
    |-Light01						// entity that represents our light
									// has following properties : casts shadow
    |-Force01						// entity that represents scene gravity
									// has properties that describe force's vector, strength, area or volume of influence...

Note: There could be more (like renderer's, collision geometry, global vars such as ambient color, music, etc...) but I think this is enough for this example.

Scenegraph follows Composite design pattern while some nodes follow flywight pattern. What we can see here is that most of this nodes cannot posibly inherit some base class (except ISceneNode which is base class for all scene nodes, contains child nodes and parent pointer) because there is hardly any relationship between some of these classes. I grouped these classes in following group GroupNode : This node has one property - name that describes that group (such as Material, etc...). ReferenceNode : This node references other nodes in scenegraph EntityNode : Key node for game. What you can see here in scenegraph is that there is plenty of information. Fortunately, not every sub system needs all nodes. Texture subsystem is only interested in texture nodes, rendering in renderable entites, physics in force and collideable nodes, etc... Scene browsing can be implemented using Visitor design pattern (I am currently analyzing Loki's Visitor) where each system only visits certain type of nodes. However, key question is obviously the design of EntityNode. Such a diversity of functionality like renderability, physics calculations, providing support for other systems (like light, it is only a proxy if you consider it) is not acomplishable in one class unless wh go for monostate pattern and include everxthing (even kitchen sink). What should go in IEntityNode interface. My first shot is some sort of custom RTTI (if necessary) and serialization interface (for savinf/loading). Every other task is acquired via subsystems. Since it is not required for those subsystems to exist, this decreases coupling. Once this scene starts, physics system will kick in providing collision detection and autonomyous movement, rendering system will render data, sound system will play sounds and music, etc... What do you think of such design? Is it scalable for small and large systems? Would you change anything, and how? Comments, suggestions appreciated.

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!