extending ogre with custom game classes

[Robber]

greetings!

I am new to ogre and to c++ aswell, I aim to develop a program for veejay / live video performance
for me this also will be a learning project with C++, which is probably not recommended but yeah i really like
to learn c++ and realtime 3d graphics and ogre seems be the key. I do have a lot of experience with 3d modeling and
some highter languages, i've gone through the tutorials and everything is working fine sofar..

I'm searching for the right approach to continue with implementing my own classes and objects,
say i would like to have a lot of objects floating around in space, each with there own behaviours an such depending
on things like mass, max speed, user input etc

I understand that Ogre is not a game but a graphics engine, what would be the recommended way to extend
the entity and scenenodes classes with game/control logic ?

I've read on the extending the entity or node class, and adding custom elements is not recommended, so I found and
and implementen a custom object class derived from the character class as in this great post:
http://www.ogre3d.org/tikiwiki/tiki-ind ... =Tutorials

so this class is working and i have about 50 test banana's in the scene, now i would like to have each of them update each frame and move
according to there own speed and rotation parameters from this new class

I found that i could iterate over all my nodes with the childnodeIterator,

Ogre::Degree lAngle(0.5);
Ogre::SceneNode::ChildNodeIterator n = lRootSceneNode->getChildIterator();
while ( n.hasMoreElements() ) {
Ogre::SceneNode* child = static_cast<Ogre::SceneNode*>(n.getNext());
child->roll(lAngle);
}

but in fact i would like to iterate over my own object/classes, is there a way to get my custom object
out of the scenenode it is connected to ? or would i have to implement my own groups for all objects
and iterate over them ? is there a way to use the scenenodes efficiently for using this task ?

sorry for the long story, but what would be the recommended way to extend the scene manager
and connect it to my own custom classes ? hope you guys can give me some tips on how to get this going..
with kind regards
robber

[frostbyte]

well, don't know about extending sceneManager or sceneNode factories...
deriving your game glasses from Ogre::sceneNodes is a realy bad idea for so many reasons i won't even start...
way to go is MovableOBJECTS....
http://www.ogre3d.org/forums/viewtopic.php?f=3&t=24925

[Robber]

thanx!

yeah i've decided to go for my own classes containing pointers to scenenodes and their corresponding entities in stead,

what is recommended approach to keep a container of (game)objects ?
right now i'm using the following approach with unique_ptr so i do not have to worry about deleting..or does one generally keep a list containing the objects themselves? I'm pretty new to C++ so if you guys can give me some heads up that would be great

Code: Select all

//we have class 'Banana' which inherits from general 'Thing' class

//create container for bananas
std::list<std::unique_ptr<Banana>> bananas;

	
int lNumberOfEntities = 50;
for(int iter = 0; iter < lNumberOfEntities; ++iter) {
    bananas.push_back(std::move(std::unique_ptr<Banana>(new Banana(iter, lScene))));
}

//for updating	
std::list<std::unique_ptr<Banana>>::iterator it;
for(it = bananas.begin(); it !=bananas.end(); it++){
   (*it)->update(1);
}
//and to clean up
bananas.clear();

kind regards,
Robber

[Kojack]

What I tend to do is use an std::map of id numbers as the key and game object pointers as the data. You can still iterate through them the same way, but now you can search for object by it's id number very fast.

Or go more of a component/entity system style (not talking about ogre entities). It's a bit long to explain, but the short version is you have different managers (physics manager, visual manager (for ogre), logic manager, etc). Each manager keeps it's own map of id numbers to objects that hold just enough info for their manager (physics object knows about a bullet body, visual object knows about ogre scene node and entity, etc). Each manager iterates through it's map, doing some update. The id number can be used to look up other managers. So there is no single game object, it's split over multiple optional managers.

There's a good article here (where I first learned about them): http://t-machine.org/index.php/2007/09/ ... nt-part-1/

[Robber]

wow, very interesting approach, especially for the vj-program i have in mind,
thank you very much for pointing this out..

[frostbyte]

+1 for kojack - word of wisdom...
using a map is the best way to achive control...never the less remember u have to update the map yourself whenever a change happens - either to your game entity of ogre's...
regarding managers each contibuting its part: it's called ' modular programming ' - and is the best way to build maintainable software
my tip is : just imagine each modul to have a different programmer - how will they cooperate?

TIP: regarding the map : in case performance is critical, like for example :
if u use alot of sceneRayQuery( find entities is in the way of the ray... ) which returns an array of type: MovableObjects[]....
map may produce an overhead - in which case - attaching a pointer of your 'game entity' to the movableObject may be a good idea...
TIP2:
you can take an example from other entity-systems like openSource gamekit, unity... whatever has a gameEntity system inside....
Ogitor is a good example of modularity in c++/qt

Eventualy you will use...
1)a tree to contain your game entities
2)a map to map between game-entities - ogre nodes ( or other memory structures-thats what they realy are and that is why it's a bad idea to use them as game-entities... )
3)possibly a pointer from ogre's nodes to your game-entities...not a requirement though...
in the end a 'tree and a map' thats what you need...( sounds like treasure hunting... )

[Robber]

thanks a lot for getting me going with this!
I've read some of the compononent/entity post on the forums,
it is still a bit overwhelming

I've created my first 'component ?' a meshmanager, which can create entities and will keep the connection to ogre objects:
I've declaired the maps as:
(h)

Code: Select all

 
std::unordered_map<int, Ogre::SceneNode*> nodemap;
 std::unordered_map<int, Ogre::Entity*> entitymap;

(cpp)

Code: Select all

void meshManager::create(int ID) {
	std::stringstream ss;
	ss << ID;
	nodemap[ID]=sceneMgr->getRootSceneNode()->createChildSceneNode("node" + ss.str());
	entitymap[ID]=sceneMgr->createEntity("ent" + ss.str(), "banana.mesh");
	nodemap[ID]->attachObject(entitymap[ID]);
}

now what is still puzzelling me is how to keep track of of the different gameobject variables
say I make another component for my own physics system, which will then also have a map of entity ids that have this component.
each object will have some individual parameters, like mass/velocity/steering/maxspeed for example,
how woud I put these in a map ? put all the variables in a a struct maybe or a subclass and map that ?
I think I will be using a lot of scene's so it would be my goal to load/save these component tables/maps and
recreate the scene's again from that.

kind regards,
Rob

[frostbyte]

my tip is : just imagine each module to have a different programmer - how will they cooperate?

answer:

Eventualy you will use...
1)a tree to contain your game entities

the tree will enable you to have good control of 'game entities' groups - for purpose of batch-processing
the tree can also be used as a place where modules meet each other...
it's nice quoting myself...anyway...

your 'game entity' tree nodes will contain any contribution from Managers - physicsMgr, renderingMgr( ogre ), soundMgr behaviorMgr ScriptMgr etc...
contributions by managers can be hard-coded( fields- pointers etc...) to your 'game entity' class...

it will look somthing like:
class gameEntity extends some:std:treeNode
{
String title;
OgreEntity* render_entity;
SoundEntity* sound;
PhysicsCollision* physics_col;
PhysicsBody* physics_body;
BehaviorMgr* miss_behaveMgr;
void init()
{
title = 'some title'
render_entity = OgreEntityMgr.init( this );
sound = OgreSoundEntityMgr.init( this );
physicsBody = PhysicsBodyMgr.init this );
physics_col = PhysicsCollisionMgr.inti( this );
}
void process( long timeFromlastFrame )
{
OgreEntityMgr->process( this )
OgreSoundEntityMgr->process( this )
physics_col->process( physicsBody )
etc...
}
~destroy()
{
OgreEntityMgr.release( this )
OgreSoundEntityMgr.release( this )
etc...
}

class processCore
void init_loop
{
init/load all managers entitys etc...

}
void process_loop
{
//for each manager that needs one time updating...
behaviorMgr->process()
...etc
AnyMagnager.process()
//for your 'game entity' tree
do process() on all 'game entities' tree-nodes


}

~destroy
{
release all that needs to be released by iterating on Manager's release method....
}

}

A more generic solution can be achived by adding the 'Managers contribution' as a child of your 'game entity' tree-node...but that is FAR more complex - time consuming etc...

[Robber]

thanks frostbyte, your code example makes your tips it more clear,
but it will take me some time to 'process this'

I like this approach but it is different from the component/entity approach
as kojack mentioned here, where the entitiy is just a string or id:

http://t-machine.org/index.php/2007/09/ ... nt-part-1/

either way in both approaches one thing i do not understand is who keeps the data/variables, the article in t-machine mentions the data is kept by the managers,
will each manager then have a map (entity,list of variables) (like mass, velocity etc) ?

and if the manager already has a list of which entities to process and their variables
why would i need the entity tree ? perhaps i am mistaken..

in the entity tree approach, would each manager add a variable to the individual entities by something like entity.addvar(speed,10) / entity.setvar(speed,10) or keep the data inside the manager aswell?

very sorry if i am not making myself clear, following my first post,
i'm now trying the implement the component / entity system as kojack suggest
much appreciated!
Rob

[Robber]

thinking about this some more i decided to follow a different approach,
but i will leave the post above, the train of thought might be usefull for other
newbies on this subject

i intended to put all logic and data inside the components,
where each entity is simply a string or an id
and then have each component do update all their entities

but i've relealised that for my system as veejaying / visual effects program
the order in which the components are processed is quite essential
as i would have an object that had might have a translation, a rotation, scaling, and then
again a translation to achieve a specific visual motion

so i'm going to implement an entity class which holds a container of components
in the way frostbyte suggest

thank you

[frostbyte]

i'm sure there are hundreds of diffrent way of achiving the same thing....eventualy you decide how to do it...
you have some good points - why do i need the tree if i already have every thing in maps...
better to keep as many structures as needed...somtimes you prefer to use a vector and some times a map....
the tree will hold a structre of such that any of your "game entities"( shold realy say 'vj-entity' nodes ) will function as a container to other "vj-entity" nodes
it will also be used in batching init/process/update/release/whatever methods of your 'vj-entities'
for sake of modularity you can treat mainClass( mentioned above... ) as a MainPluginProcessUnitManager....which contains a tree of vj-nodes and a bunch of plugins...
common thing to all plugins is the need to load/init/update/release/state managment( start/pause/play ) etc...

either it be a map/tree/whatever... you will need one place to tie all the managers together...this will keep your code maintainable and well structured...
eventualy all this structures are just pointers to data that is created by "different" libraries/modules so the real purpose of this structures is to help you keep your code neet, tidy and modular...any way u manage to achieve this is fine...my suggestion is only one way of doing so....

for me the main reason for using a Tree is simplicty and 'clear mind' - when you have a Tree structure - its much easier and faster to understand what you are doing and how to achive it...working with trees is very rewarding...
also it's like a logical extension of programming as you can look on this as: C++ Class = TreeNode( object* ) + vector of TreeNodes( fields* )
imagine what would happen if googleMaps had millions of separates map and nothing to tie them together....
plus vector is faster to iterate on than maps...( doesn't realy matter for non time critical apps....) and you can have control on treeNodes order....

to sum it up: trees give you a good structure to work with( do some processing ) instead of getting lost between maps and plugins...
try to write every thing as generic and modular as you can...
i suggest you to do some heavy thinking/sketching of your'e whole software-flow-design before you start coding...
- a vj application is no joke...if you'll want it to 'grow' you will need a good basic structure and you will defently need some sort of generic pluginSystem...
thats for another topic....

happy "processing"...

Edit: tried to read link above: too long and boring for me....
r u building an mmog-vJ'aing application???....

[Robber]

no it will not be mmo, though that would be a very interesting and new idea aswell
or maybe cool for expansion later where you can join and build/modify visuals live together

anyway i guess the technique described in the article would be most suitable for mmo..
but it seemed a nice idea to me as all data is put in tables and organised by the components
this did seem a nice approach to be as it would be easy to load and save a lot of scenes,
as a vj-program will be kind of like and editor and game in the same thing

still the order of the components on an enity is very important or even crucial
as i would have a lot of motion / effect components on an object and duplicate components as well
for different result.

I understand your posts and a map of components in each entity feels like the right approach to me
now im looking into how to build a proper tree structure for this

Im not sure where this project will be going yet.
but i figure it would be a very cool learning experience
where i can gradually add more functionally and components as i get better with ogre and c++

thanks for your help and suggestions,
Rob

[drwbns]

I got a little lost in FrostByte's example, but why would in processCore->processLoop() we have a component->process() as well as a gameEntity->process() that also updates components ?

[Robber]

correct me if i'm wrong, but I think this is more of a rough sketch,
something like that would be for managers that are not entity specific,
something like a global game state manager, input processing

although in theory you could make a gamestate entity and attach the
necessary components in the same way as a gameobject-entity

[frostbyte]

robber is right...( my pleasure... )
generaly speaking you are also right...
for modularity : the processing of separate entities should be done on a separate Manager
why do i need a tree with separate entities... for convinence....and becuse i like trees...trees unlike map have a structure - so you can easly cut/add/iterate/process groups of 'game-entities'....
it's true this is a rough sketch...

lets refer to the so called Managers in there true name Plugins....so Manager=Plugin....
you can do whatever u want - you can do the processing in the Plugin or in the entities....i do both....
for some plugins the order and structure matters - for example i keep a tree structure so i can easly iterate over the tree and do stuff...( process )
it is true that is is a better and cleaner design to keep the Tree structure in a separate plugins and not in the "processCore"....lets call it TreePlugin
( this way the TreePlugin can also be responsible of notifying other plugins when 'game entities' are removed/added etc... )
for sake of modularity processCore can be kind of a plugin itself...PluginContainerPlugin....

the general idea is to have a plugin system where each plugin contribute some Functionality to the 'game-entity' and a way of processing this functionality.
'game-entities' mainly contributes "Sharable Data" to the plugin's not Functunality....
the tree is the best structure to help you organize and find your way in a complex hostile enviroment....
how you get it done is up to you...this are just tips...


Tip of the day: do every thing in a Single Thread...

[drwbns]

Can you actually inherit from std::treeNode or was that just an example? Also, would you inherit it driectly from your gameEntity class like you show? If you can, is there a higher level treeNode manager that we would use to add, delete, update, etc.?

[frostbyte]

i dont think stl has a tree structure....
any way its easy to implement:
warning ...just a sketch...not real code....
class TreeNode
{
<T*> data;
std:Vector <TreeNode*>childrenTreeNodesVector;

public:
void addChild( TreeNode* treeNode );
TreeNode* removeChild( TreeNode* treeNode );
TreeNode* getChild( int index );
TreeNode* findChildTreeNode( void* data );
void setData( <T*> data );
<T*> getData();
}

you can either use the <T*> as gameEntity* or you can extend TreeNode to your gameEntity
the first way is more recommended as the tree is just a container to hold your data in a meaningful structure...( for example: somtimes for various tasks you want to have multiple trees organized differently but containing the same gameEntities.... )

thank you for your questions...our little discussion have triggered me to do some thinking....
now i feel we are convoving torward a clean nice logical design...
my basic idea is combining both approaches where:
1) gameEntity* = IDString( maybe with some basic info such as Title...or possibly some data to share data between plugins... )
2)having a TreePlugin containing gameEntity* treeNodes , the TreePlugin will be incharged of notifying other Plugins regarding gameEntities tree structure changes( add,remove etc...)
3)having a PluginProcessor( Plugin ) which will hold a tree structure( where each plugin will contribute a treeNode representing itself ) and which will iterate over the tree in order to do some PluginX->process()/init/destroy etc...
4)each Plugin will be responsible of maintaning and processing the data it produce in general and in relation to specific gameEntities....
5)each plugin will also have the ability to dispatch events and also to respond to other plugins events...
5)TreePlugin and PluginProcessor - are also just Plugins...so they can dispatch events( eg: TreePlugin:add/remove etc , PluginProcessor: init/process/destroy...
that other plugins can respond to...

...it looks like i've switched sides...going more toward the direction that Mr kojack offered
please tell me what u think of this design...( be gentle please... )

Tip of the day:
this tip is mainly for big large - complex projects which demands extendabillity and generalization....
try and seperate between data, structures and functionality ....
this approch is quite opposed to OO-Programming - and it is called - Aspect oriented programming...http://en.wikipedia.org/wiki/Aspect-ori ... rogramming

[Robber]

ok but what about this case, I have an object with the following plugin structure:
how will you implent the order in which plugins are processed for each entity

entity
transform-plugin
rotation-plugin
transform-plugin
render-plugin

(edit:)

I'm leaning more to the idea where each entity has a plugin-list or plugin-map
and you can add / remove plugins or change the order in which they are processed dynamicly

then indeed there is the question of where the data is stored, inside the plugin, inside the entity or somewhere else,
like a big datatable. I think the big datatable would be nice since it would make it easy to save and load scenes with all current
settings

Rob

[frostbyte]

plugins will add them selves to the PluginProcessor Tree structure... which will iterate over the tree and call each Plugin->process()
this way each plugin can choose where to put itself and thus determining the order in which it will be processed...
in processing - each plugin will iterate over the gameEntities tree( it may read the tree directly from TreePlugin, or build its own tree in respond to events from TreePlugin... ) and do its stuff...

transform-plugin : for each gameEntity treeNode: SceneNode ogreSceneNode = RenderPlugin->getSceneNode( TreeNode ).....ogreSceneNode->tranform()....
rotate-plugin : for each gameEntity treeNode: SceneNode ogreSceneNode = RenderPlugin->getSceneNode( TreeNode ).....ogreSceneNode->rotate()....
render-plugin : OgreRoot->renderOneFrame()...

edit:
ok i see that u're going with gameEntity containing plugins...
entity->render() is unnecessery because ogre batch renders all entities in one call - so better to do this in a seperate plugin which will be processed after all others...
regarding the order of processing - in your case where order matters you can have each gameEntity to contain a tree structure of plugins and iterate over them...
i understand that you need a flexible solution - so forget about hard-coding and use trees...more work...more time...more flexible...

[frostbyte]

then indeed there is the question of where the data is stored, inside the plugin, inside the entity or somewhere else

indeed this is the rock bottom question...
i like to think: why choose this or that when you can have both...
regarding what structures to use...same answer...

as i said i'm in the process of changing my mind toward what kojack mentioned...
it is a more clean solution....
in an ideal situation plugins should be mostly seperated from one another preferbly unaware of each-other and take care of the data they produce...
your situation is not an ideal one since you need the plugins to behave differently for each entity( somtimes called more then once and in a particular order )
so the gameEntity containing plugins is a better approch for this( you will still need the generic plugin system for other situations... )
never the less dont forget that it is you who decide what the plugin will be...

In the other( cleaner ) approch i would put all the transform/rotate/XX to one plugin which will hold a map of gameEntity<-->functionX and do manipulations on functionX...

just a thought...
would'nt it be great if someone wrote a clean neat modular implementation of a generic plugin/entity system for all to use and extend....
maybe even as an integral part of ogre( which will benefit from as well...)

Tip of the day: in software design There is nothing u can't represent using a tree...