Jump to content
  • Advertisement
Sign in to follow this  
Opwiz

RTTI in render loop

This topic is 5038 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
If it's fast enough then there is no problem. If you later find out that it is indeed a performance bottleneck then there is an easy optimization fix.

Use a seperate container for renderables and non-renderables.

This way you only need to do the dynamic_cast once, when you add an object to the world, and then you add it to the appropriate container.

Then in your main loop you don't need a dynamic_cast. you simply iterate through the render list and render each element without the dynamic_cast.

If your code is encapsulated well enough then this will only be an internal implementation change, and you won't have to modify any other game code.

I hope this is clear.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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
}
}

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 :]

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!