Actor Render Component VS scene graph

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Actor Render Component VS scene graph

      So I finally made it to this part in my engine. I already made simple renderer, Resource Cache, AssetManager.

      Yeah I made my custom level/map format and I was able to laod it successfully.. However I was wondering, why would I separate the scene graph from my actors? I've got global access to almost all systems( I don't feel like I need event manager, at least not for now ) so I really don't see any reasons.
      Why shoudn't I iterate trough all actors and tell render components to render themself with the following renderer? Each actor got transform component, relative to its parent.

      Direct Question:
      In other words, what will I get+/rewarded with if I use separate hierarchy for the drawing part? At least I want to see your reasons so I can "free" my mind.


      OffTopic: This is my second registration, for some reason I cound't log in with my old. Even with the resetted password..
    • RE: Actor Render Component VS scene graph

      For a simple world like Teapot Wars, there's not advantage. As your world gets more complex, looping through all actors will be become very inefficient. The advantage of a tree structure is that you can cull out whole sub-branches very easily.

      A great example of this is a game I worked on called Rat Race. Rat Race took place in an office building and was very densely populated with objects. There were 10,000+ objects in a single level. Looping through 10,000+ objects every frame and doing math on each one to determine whether or not they were visible would have been WAY too slow.

      Our solution was to use a BSP tree and have each room be a separate node with the objects in that room attached to the node as sub-nodes. Larger rooms were often divided into multiple nodes as well. Then, whenever we rendered the scene, we'd perform the visibility test on each room. Most of them weren't visible, which culled out the vast majority of our objects. No tests had to be run on them at all.

      So the real reason for using some sort of rendering tree is performance. Again, if you have a small world with less than 100 objects, it probably won't matter. If you have a huge world with tens of thousands of objects, you will have to do something like this.

      Regarding the event system and having global access to everything, this will work as long as nothing has to change. The real benefit of a strong architecture is that it is resistant to the effects of change. If you have global access to everything and allow all systems to talk directly with each other, then changing or refactoring any one system will require you to touch every other system in your game. A simple refactor will turn into an epic nightmare and eventually you'll be rewriting your whole game engine just to change a simple thing.

      Events, interfaces, and design patterns are all intended to abstract the implementation of a system from the interface used to communicate with it. For example, in my own engine, I was able to rewrite the entire graphics system without touching any code outside of the graphics system because the interface stayed the same. While working on The Sims, I completely rewrote the internal AI with very few changes outside of the system because it was nice and decoupled.

      Learning about coupling and code cohesion becomes very important as the complexity of your code increases. It's probably fine for a game that may only be 10,000 lines of code, but when you have a game like The Sims Medieval (which was around 2.5 million), it becomes critical.

      -Rez
    • Thanks.
      I know about BSP and Octree algorighms themself but just as a name(I still haven't made it to this part), however I don't know how they work, that's why I exclude them as possible reason for separation of the hierarchies. (and also it doesn't seem to be a huge memory waste ;/, they are just 16 floats. I was really shocked when I realized I need to dublicate the vertices, however I actually gain performance, and the dublication actaully didn't take so much memory :P)
      Something I regret is that I made my whole project in just one library, and sometimes I need to recompile the whole world, if I touch something global.
    • Yep, it's a classic memory vs CPU trade-off. In this case, you're trading a small amount memory for a big pay-off in CPU speed. It also makes the code a lot more complex.

      If you're just making really simple games with a few dozen actors and maybe 50 - 100 world objects, I wouldn't bother with anything too complex. If you want a bigger or more populated world, you will need something like this.

      Recompiling all of The Sims Medieval took about 10 minutes. Recompiling the entire game I'm working on now takes a good 15+ minutes now. This even takes into account that it's split into multiple solutions so you can compile in parallel and the fact that I'm compiling on an SSD, not a traditional harddrive (MUCH faster). Recompiling everything is a huge productivity killer. ;)

      -Rez
    • I love the first stages of a project where it literally takes 10 seconds to compile (on my laptop at least), now it takes about 1 minute for a rebuild.

      I wish you didn't have to sign a non-disclosure agreement, I am really curious about what you are making currently, my wife really likes the Sims. Oh well lol
      PC - Custom Built
      CPU: 3rd Gen. Intel i7 3770 3.4Ghz
      GPU: ATI Radeon HD 7959 3GB
      RAM: 16GB

      Laptop - Alienware M17x
      CPU: 3rd Gen. Intel i7 - Ivy Bridge
      GPU: NVIDIA GeForce GTX 660M - 2GB GDDR5
      RAM: 8GB Dual Channel DDR3 @ 1600mhz
    • Originally posted by mholley519
      I wish you didn't have to sign a non-disclosure agreement, I am really curious about what you are making currently, my wife really likes the Sims. Oh well lol

      I'll post about it when we announce. :)

      -Rez