🔒 Locked

Class Relationships

Started by aqez Jun 9, 2010 at 1:41 AM 1 replies 1.1k views

Original Post

Jun 9, 2010 at 1:41 AM

So I'm mapping out a few classes that might be good starting points to an engine I'd like to write. Something simple to get me running again, been a long while since I've done any game-related programming. Basically I've hit a relationship wall between some of my classes, and was hoping for some input. One example of this is the Renderer class and Model/Mesh classes.. I'd like to keep things neat if I can, and have possibly a base class which renderable classes will derive from:

class IRenderable{public:   virtual void Render() = 0; //Possibly another return type, I'm not that far along yet.};class CModel : public IRenderable{public:   void Render();};

This way I can use dynamic binding to pass objects to the renderer, as well as call the Render() function from the class itself.

However the problem is that these classes would need a pointer to the rendering device/class which for some reason strikes me as annoying.. Can't explain it, it just does. What would be a good solution to this? I'm trying to keep things as abstract as possible for the obvious reason that things will change in later stages of development.

Another example of this would be a file/resource manager class which would load files/parse meshes/etc. I'd like to keep the load() function in the class which needs to be loaded itself.. Construct an empty object, call load() with a file name parameter, then go from there. However again, the class would need a reference to the loader/resource manager.

What would be the best way around having all these references passed around to different objects? Or is this a problem in the first place?(It annoys me..)

Ariste

Jun 9, 2010 at 2:05 AM

To answer your last question:

If the dependency must exist, then it's not a problem. In fact, passing around pointers/references is probably the cleanest way to deal with these kinds of dependencies. It's not "unclean" that one class depends on another class; such dependency is a product of the natural relationship between the two objects you're trying to encapsulate. In your design, a Renderable does depend on a Renderer. The best way to represent this in code is to require that Renderable be passed a reference to a Renderer.

Having said that, you can eliminate the dependency between Renderer and Renderable by making Renderable more like a container for geometry and material data which is read and interpreted by the renderer.

In your design, what is the distinction between mesh and model? Why do you need a hierarchy of renderable objects? And why must Renderables know how to render themselves?

If, instead, you eliminate the hierarchy and turn Renderable into a geometry container to be interpreted by Renderer, you eliminate the need for the dependency between them. Renderable then need only be supplied with raw geometry and material data, not a reference to a Renderer.

aqez

Jun 9, 2010 at 2:15 AM

Thanks for the quick reply, I'm thinking thats the way I might go with this. The difference between mesh and model was basically the models themselves would have a list of meshes they encompassed, much like a mesh has subsets. As for further advice on the Renderable interface, if I did use it as a container to pass to the Renderer, how would I go about doing this? Just like say..

class Renderer{  ...  void Render( IRenderable* renderableObject );  ...};

And if so, how will it know what to do with say a CAnimatedModel instead of say CStaticModel? That was the reason I was thinking of the hierarchy I was using. Any ideas on how I would implement the Render function to be independent of which derived class is passed in?

Edit:
While thinking about it I realized I don't believe thats possible since the specific class code should actually be in the derived classes themselves, so I guess I will go with the references. As for why having the interface while also using the overridden Render() functions, it's so that I can maintain a list/vector/tree/whatever of Renderable objects, and call their overridden Render() functions at run time.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.