Jump to content


Scene graph implementation


17 replies to this topic

#1 razi3l

    New Member

  • Members
  • PipPip
  • 15 posts

Posted 21 May 2007 - 01:15 PM

Which implementation is better for scene graph?

1.

Node
|
Actor
|
Camera, Entity, ...

2.

Node
|
Actor -> MovableObject
|
Camera
|
Entity
|
...

In first case Node class is base of Actor, and Camera, Entity, ... are subclasses of Actor class.
In second case Node is also base of Actor, but now Camera, Entity, ... are subclasses of MovableObject which
is added to the Actor class in the list of objects.

Right now I use the first case in my engine. I think it's easier to implement and use.

For example if I want to create entity I use:

Entity ent = m_SceneMng.CreateEntity( "player", "models/player/player.mdl" );

ent.Position = new Vector3( 100, 0, 50 );


Now for the second case this would go something like this:

Actor parent = m_Scene.CreateActor( "PlayerParent" );

Entity ent = m_SceneMng.CreateEntity( "player," "models/player/player.mdl" );

parent.AttachObject( ent );

parent.Position = new Vector3( 100, 0, 50 );


I'm open for any sugestion. tnx

#2 g(h)eerko

    Member

  • Members
  • PipPip
  • 40 posts

Posted 25 May 2007 - 09:37 AM

of course,
later on a camera object should simulate a part of the actor like physical props. so its fine to derive it from movable object, but why have the over head of all actor stuff on the camera and entity actor class will have models, animated models, skeleetal animators....

abt the scene graph, lets say it contains only scene elements, more obvious sight.

i just started out a scene management system... donno where its goin, but it looks something like this after 2 weeks.

#3 g(h)eerko

    Member

  • Members
  • PipPip
  • 40 posts

Posted 25 May 2007 - 09:42 AM

C:\Documents and Settings\jayaa0\Desktop\jb\gr.jpg

#4 roel

    Senior Member

  • Members
  • PipPipPipPip
  • 678 posts

Posted 25 May 2007 - 03:24 PM

Funny ;)

#5 g(h)eerko

    Member

  • Members
  • PipPip
  • 40 posts

Posted 27 May 2007 - 07:10 PM

is not funny...
how do i paste a picture up there???

--edit
ok,
please ignore uml usage...

Posted Image

#6 STLDude

    Member

  • Members
  • PipPip
  • 59 posts

Posted 27 May 2007 - 08:32 PM

g(h)eerko said:

is not funny...
how do i paste a picture up there???
You know, on top of this board there is a link to the FAQ. It is amazing what can be learn from reading.

#7 Reedbeta

    DevMaster Staff

  • Administrators
  • 4782 posts
  • LocationBellevue, WA

Posted 27 May 2007 - 11:27 PM

Hint: your picture has to be on the Internet, not on your hard drive, before you can link to it.
reedbeta.com - developer blog, OpenGL demos, and other projects

#8 razi3l

    New Member

  • Members
  • PipPip
  • 15 posts

Posted 29 May 2007 - 02:10 PM

Hi, sorry i didn't reply before.

So, what you think of this..
Posted Image

#9 razi3l

    New Member

  • Members
  • PipPip
  • 15 posts

Posted 30 May 2007 - 03:52 PM

there should have being image in previous post :unsure:
Posted Image

#10 g(h)eerko

    Member

  • Members
  • PipPip
  • 40 posts

Posted 30 May 2007 - 11:08 PM

I bet thats not going to be ur final design,once you code it, and start thinking of more things that your want to do with those objects is when the final picture starts to appear....

before going further can you illustrate what the entity object encapsulates, and why everything in the scane graph needs to be an actor?

#11 razi3l

    New Member

  • Members
  • PipPip
  • 15 posts

Posted 31 May 2007 - 09:26 AM

Not everything is derived from Actor class. They're just members of Actor.
Something like this..

protected List<MovableObject> m_MovableObjects;

This is very similar to Ogre graphics engine, if you're familiar with it.
For now I want to keep it nice and simple. Later on, I will add support for sounds, physics and scripts.

Quote

before going further can you illustrate what the entity object encapsulates

Basically, Entity is animated (or static) object based on mesh. If Entity is animated that it will have it's own copy of skeleton and all the animation states within.

#12 g(h)eerko

    Member

  • Members
  • PipPip
  • 40 posts

Posted 31 May 2007 - 10:54 AM

yes Im familiar with the ogre engine, infact i' used to grep alot through the src code of crystalspace and Irrlicht.

Thats a good move there using templates to hold objects.

razi3l said:

Basically, Entity is animated (or static) object based on mesh. If Entity is animated that it will have it's own copy of skeleton and all the animation states within.

if entity can be either a static or a dynamic mesh, suggest u derive the static(bsp, terrain) and the others from it, but also have the mesh implementing the movable object interface, that would make a generic way of dealing with displaying or updating the mesh states.

Im curious how you plan to implement mesh animators for differnt model types
A. have a native way of representing meshses and animators, or
B. create a custom animator and mesh types to hold for each type of model out there.

would you have a animator attached to the meshes or have a custom animated mesh type at some point.

I think movable object by default means it can be animated.

Have any ideas on animation as yet.

#13 razi3l

    New Member

  • Members
  • PipPip
  • 15 posts

Posted 31 May 2007 - 11:30 AM

Actualy, animation system is already done. I'm using doom 3 md5 files for my models. I have Animation class, and all it holds is animation length in seconds. Every model that need to have anim support, needs to be derived from it, and hold it's own animation properties, like number of frames, frames per sec...
All Animations for specific mesh are stored in the Mesh class, and are controlled through AnimationState class (also similar to Ogre :happy: ).

I don't think it's very good idea to use Entity class as base class of BSP and Terrain. Bsp's and terrains are large objects/world and are rendered/culled differently. Also they can hold many information's that are not specific to rendering. Like player start position, light/entity informations...

#14 g(h)eerko

    Member

  • Members
  • PipPip
  • 40 posts

Posted 31 May 2007 - 11:52 AM

oh ok, thats right , but from the above diagram, it seems that you want to have a multiple type geometric members, ie like movable.meshes and static.meshes. Rather dont u think it can me more clearly painted if you had just one geometric type objects per node, since there is a different way they are rendered, but since and animated object consists of multiple meshes u can have a list of meshes here, but of the same type.

Thats the only reason i was sayin that both geometric types should implement a common interface so that one generic scene object can hold either.

#15 g(h)eerko

    Member

  • Members
  • PipPip
  • 40 posts

Posted 31 May 2007 - 11:54 AM

That kind of animation is quite heavily types, have you come across objects that are simple , but can be put into an animation container and animated if required.

#16 razi3l

    New Member

  • Members
  • PipPip
  • 15 posts

Posted 31 May 2007 - 01:09 PM

i came up with another version

Posted Image

This way large level geometries can have support for physics and scripting by default.

Quote

That kind of animation is quite heavily types, have you come across objects that are simple , but can be put into an animation container and animated if required.

yes, I have AnimationPlayer class that can play/blend two animations at a time. I plan to add support for multiply animations but for now this is ok.

#17 g(h)eerko

    Member

  • Members
  • PipPip
  • 40 posts

Posted 31 May 2007 - 03:41 PM

what exactly is encapsulated by the animation state ? is it the (pos, orientation) thats also there in the mesh object i guess. when u say anination do u say it as in per mesh animation or per entity animation, or are you considering to have a base animator class recurse thru' subclass of movable object and animate it, in that case per mesh animation state is better... right...

#18 razi3l

    New Member

  • Members
  • PipPip
  • 15 posts

Posted 01 June 2007 - 08:00 AM

AnimationState just holds information about current time in the animation, its length and weight.
When entity is created it creates a copy of mesh skeleton that it's based on. Also all animation states are initialized from animations that are stored in the mesh and set to zero time position. Every animation that needs to be updated must be controlled through m_AnimationState.AddTime( timeSinceLastFrame ); If there is need to blend two animations at a time (or more) than it's weight must also be set. This is why i created AnimationPlayer class, because it calculate weight information for you, and update all animations by it self.
When i say 'animation update', what I mean is that it actually update copy of skeleton that is stored in the Entity class.

Hope that helps.





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users