In my render-loop I iterate through all the objects in the view frustum and draw those that are renderable. To do this I use dynamic_cast. As far as I can tell by profiling the rendering-loop, dynamic_cast is very fast. So is there any good reason not to use dynamic_cast in my render-loop?

Quote:Original post by leiavoia

Quote:In my render-loop I iterate through all the objects in the view frustum and draw those that are renderable. To do this I use dynamic_cast. As far as I can tell by profiling the rendering-loop, dynamic_cast is very fast. So is there any good reason not to use dynamic_cast in my render-loop?

Well, fast or not, you really shouldn't have to do it in the first place. I would also consider keeping renderables in their own list to iterate over.

4 days... it have been puzzling for 4 days straight to try and make a scene graph that wouldn't require RTTI. No way! It either required RTTI, or I implemented my own kind of RTTI in some odd manner.

The power of a scenegraph lies in the fact that an object (or node in the tree) can have children of any other type. So renderables, physics objects, state commands, all mixed in one tree. If your subsystems itterate through the tree they will need to identify the type to determine if the can do something with it. The second you put a function "getType()" in your node, you're trying to make your own RTTI.

At this moment I register each object individually too. So, Rendererables register themselves in their constructor with the graphics subsystem, physics object register themselves with the physics subsystem. It works, but I can't have a hierarchical structure in my scene.

RTTI is handy to fix stuff like this, but is often frowned upon. They say it implies bad design. I disagree. If you have a central management (you scene graph) and have specialised systems to operate the objects in this central management (graphics/physics subsystem) you need some way to determine what you're dealing with at run-time. Seperating the subsystems from the central management is in my book good design. Needing RTTI for it doesn't make it bad.

Quote:Well, fast or not, you really shouldn't have to do it in the first place. I would also consider keeping renderables in their own list to iterate over.

Not really possible in my current design. All scene objects are kept in a scene manager (a container of spatially organized scene objects - e.g. a loose octree). Scene objects are usually renderable (with some exceptions). The scene manager provide a way to iterate through the objects in a certain bound (e.g. a frustum). This way the scene manager is completely seperated from the renderer and physics engine.

Hi,

you should look up the double dispatch pattern.

class Visitor{public:  void apply(class Base* );  void apply(class Special* );  void next(class Base* b)  {      b->call( this );  }};class Base{public:  virtual void call( Visitor* v )  {     v->apply( this );     //for each child call next  }}class Special : public Base{  virtual void call( Visitor* v )  {     v->apply( this );     //for each child call next  }}

Interesting :). I'll check it out.

Heh, why not simply virtualize things?

I'd done something akin to dynamic_casting for my render tree, and it was just... cumbersome.

Make everything that will ever fit into a scene graph inherite from a common class [likely the class which arranges the n-tree]:

class render_object{private:    render_object_pointer parent;    array_of_render_object_pointers children;public:    virtual void    render();    void            renderchildren(){        foreach(children){            child->render();        }    }}

Then for each renderable class, the render function can be redefined to be specific to each context. If the object isn't renderable, render() for that specific object is just this->renderchildren().

That said of course, there's probably no good reason not to do it the dynamic_cast way.

Yes. Most of the scene objects are renderable so a virtual Draw() method in the scene object's base class is not a bad idea at first thought. But then I would have to have similar methods that the physics engine will call (for collision testing), and Update() methods for the game logic engine, etc. and suddenly my scene manager no longer seperated from the rest of the engine.

Ah, personally I seperate things more than that. My renderable objects are seperate from game objects. An image object shouldn't care if it represents a dog or a tank or a planet.

But yes, inheritance becomes less ideal in that case :]