   Shall entities know how to render itself?
  Hi all,This is more of an architecture/OOP problem. Let suppose I have an Entity class, which in term composes a Sprite object. The question is -- whose responsbility it is to render the Sprite?The issue is while working on a 2d game project, in a team of three, the guy in charge of the graphics library implemented it such that the entity is added to a scene graph, then the scene graph will extract the sprite out from Entity, then render it with the Entity's position.My take is -- how are you going to render different types of Entities then? There's a whole lot of difference between a particle emitter and 2d animating sprite. The Entity knows how it is represented.If it is using a spirte, it will render the sprite to the buffer. If it is an particle, then it will draw the particles to the buffer.From my research, AFAIK, 2 game engines use "add to scene graph" -- Panda3D and Truevision3D. Is there any more compelling reasons why shall rendering to seperated out from an Entity? Is there something I am missing out?Many thanks in advance!   
  Well, the way I see it, you should have something where Sprite inehrits from entity (just as maybe Billboard or Mesh would). For example:class Entity{public:    const Vector2D &getPosition() const;    virtual void render() = 0;    // .... whatever else all entities should have .....};class Sprite : public Entity{public:    void render() { /* Render the sprite */ };}That way, the sprite is responsible for rendering itself and all changes to rendering the sprite are made in the sprite class. And you can just keep a container of entity pointers and call render for each of them.   ;  What you want is a 'Render Entity' that is derived from Entity. The Render Entity class will have such methods as Render(), PreRender(), PostRender(), SetShaders(), SetShaderParams() etc.... Any form of object, such as a sprite or a particle, will derive from the Render Entity and will override all of its rendering methods. It is the Render Entity that you would pass into the scene graph. The scene graph would then render each Render Entity accordingly, and because of derivation, the object -- sprites/particles etc... -- will get rendered correctly, without the scene graph knowing much about what is being rendered.If there is any information that the scene graph needs about that entity that is being rendered, then have that information be extractable through the Render Entity class.   ;  An alternative solution is to create a "Shape" class.  The game Entities have a Shape member (they "know what shape they are").  Then, a graphics/rendering manager can look at the list of all entities, see what shape they are, and draw those shapes in appropriate positions.  The managing class knows how to DRAW a shape.  The Shape class itself can help the drawing manager know how to draw it, either with references to model numbers, or with some actual drawing code (e.g. OpenGL API calls), or with some other scheme.  The Entity class doesn't know how to draw a Shape - it can just request different Shapes and sometimes modify them (some Shapes can change color, some Shapes can turn decals on or off, etc).This solution makes some scenarios much easier to deal with.  Say you want to make an individual entity 50% transparent.  With each Entity rendering itself, you have no real way of sorting them by depth, but with a rendering manager, you can do that sort of operation prior to rendering.  Or, say you want to switch to flat shading for the entire scene, or change a culling option or a fill option.  With a rendering manager, that's a trivial task, but with each object rendering itself, it's much harder.  Say you want to draw everything that uses a given texture in one batch, and then draw everything that uses another - again, very easy when you have a managing class that can check to see which Shapes use a particular model.Another, more immediate benefit is that different kinds of entities can easily share shapes and combine shapes, and that your drawing code is no longer linked to any other code to which it doesn't need to be.  I am creating a game that relies heavily on scripting, so I *CAN'T* hard-code the rendering code into the entity classes, and this solution is working very well for me.   ;  I'm not sure about extending Sprite from Entity. The author of this , blog article, make some good points about whether if inheritance is a good way to model the relationship.I prettly much agree with rileyriley, as he gives some good examples how rendering manager (ie. scenegraph) makes sense. But still, I am not sure how the render manage can differenate between the types of entities.Let say we have two form of representation, an image, and a vector shape (say, a line, for a laser beam). I suppose both will need to derive from a common interface, say IShape.Now, the render manager only knows that an Entity has an IShape. How does it knows the specific type of IShape? RTTI is expensive (and bad OOP, according to many books). But the IShape itself knows how to draw itself. (I guess 'shape' is a term for a lack of better word. It can represent a particle system too). I guess that solves the problem nicely.Anything I missing here?[Edited by - Extrakun on June 2, 2006 3:55:18 AM];  I think the visitor pattern would be useful in this situation.   ;Quote:Original post by ExtrakunI prettly much agree with rileyriley, as he gives some good examples how rendering manager (ie. scenegraph) makes sense. But still, I am not sure how the render manage can differenate between the types of entities.Let say we have two form of representation, an image, and a vector shape (say, a line, for a laser beam). I suppose both will need to derive from a common interface, say IShape.Now, the render manager only knows that an Entity has an IShape. How does it knows the specific type of IShape? RTTI is expensive (and bad OOP, according to many books). But the IShape itself knows how to draw itself. (I guess 'shape' is a term for a lack of better word. It can represent a particle system too). I guess that solves the problem nicely.Anything I missing here?Don't forget that IShape is an interface. It is not a shape in itself, only a template for one. You would derieve shapes from this interface. The render manager should really not need to know what shape IShape is, all it needs to know is that it is an IShape.IEclass IShape{public:// render methodsvirtual void PreRender( void ) = 0;virtual void Render( void ) = 0;virtual void PostRender( void ) = 0;}; // end IShapeclass CImage : IShape{// a made up bitmap classCBitmap m_Bitmap;public:void PreRender( void ){// pre render...}void Render( void ){// render this imagem_Bitmap.Render( m_x, m_y );}void PostRender( void ){// post render....}}; // end class CImageclass CCube : IShape{public:void PreRender( void ){// setup lighting...}void Render( void ){// render this cubegl.....}void PostRender( void ){// reset shaders etc....}}; // end CCubeclass CRenderManager{vector< IShape* > m_pShapes; // the shapes in this render managerpublic:// this renders the scenevoid RenderScene( void ){for( int i = 0; i < m_pShapes.Size(); i++ ){m_pShapes-&gt;PreRender();<br>m_pShapes-&gt;Render();<br>m_pShapes-&gt;PostRender();<br>} <span class="cpp-comment">// end for</span><br>} <span class="cpp-comment">// end RenderScene</span><br>}; <span class="cpp-comment">// end CRenderManager</span><br><br><br></pre></div><!–ENDSCRIPT–> ;Quote:...then the scene graph will extract the sprite out from Entity, then render it with the Entity's position.That's the bad side to that approach (from an OOP point of view). It's like saying, "I'll extract the engine from the car and start turning the crank shaft to get the pistons going." Uh... no. How about car.Start() ? So the problem is: should you have one object know how to draw every other object or should all objects draw themselves? Either way, somebody has to know how to draw something. I think there are advantages to both ways.I would go with a render manager if you have a complicated scene that is too complex for any one object to really understand by itself (or even be aware of). A 3D scene where you are doing culling and blending and some other fancy things might be good for this. On the other hand, you mentioned specifically doing a 2D sprite-based drawing. I recommend you do what i did: put the drawing code in the sprite itself and have objects draw themselves. That way, there is no "manager" and all objects can be interfaced easily with object.Draw(). Like so:// somewhere in the game loop:foreach object {   object->Draw();   }// then this for each object:Object::Draw() {   my_sprite->Blit( x_pos, y_pos );   }// Only the sprite class itself knows how to "draw" as far as the graphics lib is concerned:Sprite::Blit(int x, int y) {   // do underlying API-specific drawing code here   };  Personally I've seperated things out in to more layers.You have your actual object, sayMonkeyMan... which has attributes and sizes and all the things you would ever want to know about a MonkeyMan.Then you have a MonkeyManViewMonkey man view visualises the MonkeyMan.  It knows how to draw MonkeyManWhy did I do that?Well, Means I can have...MonkeyMan2DView, MonkeyMan3DView, MonkeyManConsoleView... all those views on a single MonkeyMan.  MonkeyMan shouldn't care whom is looking at it, it goes about it's business like Monkey men do.Means you can lift the business logic out of a game and plonk it in to a different rendering engine just by implementing different view classes.Kind of model view controller pattern I guess.  MonkeyMan being the model, MonkeyManView being the view and Controller being the engine.   ;Quote:Original post by ExtrakunMy take is -- how are you going to render different types of Entities then? There's a whole lot of difference between a particle emitter and 2d animating sprite. The Entity knows how it is represented.If it is using a spirte, it will render the sprite to the buffer. If it is an particle, then it will draw the particles to the buffer.From my research, AFAIK, 2 game engines use "add to scene graph" -- Panda3D and Truevision3D. Is there any more compelling reasons why shall rendering to seperated out from an Entity? Is there something I am missing out?Ah the classic The expression problem always the case with OO style scene graphs, the need for open data types and open functions.Yes there can be compelling reasons why you would want to separate rendering (as well as other operations) code from representation and it's to do with how generic and extendable you want your library/framework to be.One of the reasons why is you do not want rendering code literred about a OO class hierarchy this is not maintable or elegant. You want operations such as rendering to be isolated and abstracted out. Isolated because this makes your code more easy to manage and maintain, "abstracted out" so you can plugin alternatives like using either opengl or directx forinstance.You want to be able to add new operations easily without effecting a class hierarchy but also you want the ability to added new data types easily, this is what the need for open data types and open functins are about. There is various solutions to the problem each with there own advantages and disadvantages. Some of the options are:classic Visitor pattern (and all it's variants).Multimethods.Virtual Types (i think).Type Switch and/or Casting.   