Sign in to follow this  
Opwiz

RTTI in render loop

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
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
yes, the double (or single) dispatch method is pretty clever and is a good way to naturally avoid typing problems ( i.e. GetType() ) and i'm currently using it for a few places in my project. But i not a scenegraph expert since i'm not using one, so i won't pretend i know the final answer to your question ;-)

What object types do you have and what do they do exactly?

Share this post


Link to post
Share on other sites
Currently the only object type I have is "Renderable" that is inherited by renderable scene objects (duh). In the future there will be atleast one more object type "Physical" that physical scene objects will inherit (the physics engine will perform calculations, collision detection etc. on these objects). Scene objects will probably usually be be renderable, or both renderable and physical.

Share this post


Link to post
Share on other sites
Consider this then: can you consolidate the two? I mean, if it's renderable and isn't part of the GUI, it has a physical world location, right? Thus making it a "PhysicalObject"? All your drawing objects can also be physical objects. You can then flag each one to react this way or that way for collision detection, or not at all, but doing that seperately from the drawing phase. you will have to seperate drawing and collision detection anyway, so consider that. You cannot do both at once. You must

1) move / update all objects
2) collide all objects
3) draw all objects

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Both renderables and physical objects has a physical location (and transform) but physical objects also has mass, inertia, velocity, etc. If I consolidate the two into one class "PhysicalObject" the renderer is no longer seperated from the physics engine (intuitively it feels wrong).

Share this post


Link to post
Share on other sites
I understand the concern. But you might ask:

1) Will anything renderable ever NOT move according to physics?

2) Will anything needing physics ever NOT be drawn?

Share this post


Link to post
Share on other sites
Quote:
Original post by leiavoia
I understand the concern. But you might ask:

1) Will anything renderable ever NOT move according to physics?

Yes, the HUD
Quote:
2) Will anything needing physics ever NOT be drawn?

"Unknown Objects" on that should appear in my ship's radar, but have no method no render function for the main scene.

My main qualms about a single "Object" or "Entity" that everything derives from comes from the lack of reusability - no rather, shareability (since it'd be easy enough to slice out the unused parts) - of that code. If you're going to stick physics and rendering in, you'd probably want to stick in just about everything (audio, input events, etc) - IMHO anyways.

Then, if an object dosn't produce a component or use a feature, it would just have that part stubbed out (probably by having non pure virtual functions in the base class).

[Edited by - MaulingMonkey on October 4, 2004 12:26:53 AM]

Share this post


Link to post
Share on other sites
Quote:
Will anything renderable ever NOT move according to physics?


Static objects and lights.

Quote:
Will anything needing physics ever NOT be drawn?


Probably not very common. Can't think of any right now. But there might be instances where we are not interested in rendering the scene at all (e.g. in a dedicated server).



Share this post


Link to post
Share on other sites
Quote:
Original post by leiavoia
2) Will anything needing physics ever NOT be drawn?


something can be hidden, but still needs physics updating...


how fast is rtti? does it depend on class hierarchy?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this