SceneGraph in GCC4

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

    • SceneGraph in GCC4

      Hi,

      First, your book is amazing and it's the best book i have ever read about 3D engine architecture.

      Second, sry for my bad english.

      I have a question about scenegraph, i'am a little bit confused about it works in gcc4 engine.

      I thought every actors inherits SceneNode and the onUpdate function of the BaseGameLogic iterate through SG. But it's not like this. I don't understand your choice, probably i missed something.
      Could you help me?

      Thx again for this incredible book.
    • The scene graph is used only for rendering, the actor system is decoupled from the rendering this way. When a render component is created on an actor, it inserts a scene node into the heirarchy, than when an actor moves (transform component), the scene node is moved as well through an event.
      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
    • Both ways are perfectly fine, decoupling is a nice an easy way to separate your rendering from your game logic which I find makes it much cleaner. In my own engine I do have an actor hierarchy which is mirrored in the scene graph, and it works quite well. If I had to have the rendering tightly coupled to my actors it would be much more cluttered. I think in this case it's more personal preference as both can work, although I would say the decoupled version is easier to use and better to look at.
      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
    • When I say game logic I am referring to the actor-component system in general, which contains the transform heirarchy. The decoupling is between another layer which interfaces with a scene graph, which may be an in house renderer, or something like Ogre. The important thing here that I meant is that it is easier to drop in a new renderer with a decoupled interface, I find tightly joining classes sets that are so different in function ugly to use.
      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
    • I would make it a single render component attached to the player actor, probably to save a draw call I would make the floating arms a single mesh.
      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
    • Thanks for your input Mr. Holley. That is, I believe, the long term goal. I would like for my 'hands' to be able to interact with objects in the game world and your suggestion sounds like the way to go in order to enable that vision.

      Being that I am a noob and taking this in baby steps, my first approach is to have left hand and right hand actors attached to the human view and place them directly in front of the camera in sort of a HUD type solution.

      Thanks!
      -Troy