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?
RTTI in render loop
Author
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.
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
1) move / update all objects
2) collide all objects
3) draw all objects
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).
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?
1) Will anything renderable ever NOT move according to physics?
2) Will anything needing physics ever NOT be drawn?
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]
Author
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).
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?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
