Jump to content
  • Advertisement
Sign in to follow this  
Pilpel

Propagate properties using a scene graph

This topic is 1095 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

I read the book Real-Time Rendering and the author explains in section 14.1 - "Spatial Data Structures" that scene graphs can be used to propagate more than just matrix transformations down the hierarchy, like "materials" and light sources, and that's cool but the explanation ends right there. There's no info on techniques of doing these stuff.

 

Right now I'm using scene nodes as containers for geometry objects and the farthest I've gone is doing skeletal animation with them.

 

How such a system of using scene nodes as cameras, lights, shadows etc. can be be implemented and used in rendering? (A reading source will be gratefully accepted as well).

Is this "multipurpose" scene node approach just another form of ECS?

Edited by Pilpel

Share this post


Link to post
Share on other sites
Advertisement

So you're saying I shouldn't go with that approach and use scene nodes just for propagating transformations?

If yes, what's the alternative of doing what I mentioned?

Share this post


Link to post
Share on other sites

This link gives a pretty detailed introduction into the history and evolution of scenegraphs:

http://www.realityprime.com/blog/2007/06/scenegraphs-past-present-and-future/

 

As people itterated on the concept they ended up trying to leverage it for too many things that it wasn't optimal for, so implementations became bloated and inefficent messes many times.  All that gave using the word 'scenegraph' somewhat a less than positive connotation.

 

Even if they don't call it a scenegraph most engines have something that still fits the basic description of the concept.  Yet good implementations keep them directed to a task, being smart about reserving it for what it's does well and avoiding the temptation of a one-size fits all needs approach. 

 

Today most wouldn't store the data in the graph, as a graph's best use is to optimize traversal of a hiearchy vs. efficency of data storage for varied types of objects.  Instead you can use specialized graphs that are organized in a way that's ideal for the task that graph needs to solve, they reference objects/entities that are constructed in a way provides things like composition and that references data that's stored in the way that is most effecient for the processing, transfer and storage of data vs. forcing everything to couple to a representation that's good for graph searches and/or object composition.

Share this post


Link to post
Share on other sites
Another thing to keep in mind is that far fewer things are in the transform hierarchy than one might think. Physics and constraints keep many objects attached in many of today's games rather than the (graphics-only) transform hierarchy.

Also note that the transform hierarchy is often separate from the spatial structure used for object culling during rendering. The hierarchy is made for fast updates of transform data while the spatial structure is used for fast frustrum intersection tests, and are generally best served by very different data structures and algorithms. There may even be different data in both structures since there are items you probably want in the transform hierarchy that aren't even rendered (attachment points controlled by skeletal animations, camera locations, etc.).

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!