Original Post
Let us start with a diagram of the structure, so you know what the hell I am talking about:
I have designed a SceneManager, that I use for my world. It is divided into quadrants, which each hold the objects belonging there. When I want a list of visible objects, I call a GetVisibleObjects()-method, which takes the "seeing" camera as argument, and which returns a list of visible objects.
So far, all I have used the scenemanager for, has been for rendering. And therefore, the objects I have been storing, had rendering in some form (a Render()-method) attached to them. I knew when I designed my RenderObject, that it would give problems conceptually, because the RenderObject derived from a more basic object, and I was forced to derive again from it with classes, for which rendering was irrelevant.
My problem now is, that I want to use the SceneManager for more. For example, I could imagine integrating it with a collision system (or rather, let it become a collision system as well).
Now I have this stupid render-class stuck in the middle of my object-hierarchy, and all it is good for, is rendering, and it is not directly relevant to other objects, that have to derive from it, to participate in the SceneManager, and that irks me. For instance, in my structure, StaticCollisionObject now derives from RenderObject, and that is an eye sore to me.
Also, on the server-side, I don't need rendering at all, meaning RenderObject becomes completely obsolete here.
But then I have thought about the alternatives. If I return a list of BaseObjects, how will I be able to get to rendering in any form? I came up with different solutions:
- virtual bool BaseObject::Render() = 0;
By moving this method from RenderObject to BaseObject, I would maybe be able to get rid of the RenderObject (at least at a so low level as I have it now).
But it is ugly to have it at that level. I would prefer to have methods only directly relevant to each object.
- virtual bool BaseObject::RegisterInformation(ENUM informationnature=RENDERING) = 0; This will call the virtual method until it hits the object that acknowledges RENDERING, and this object will place itself in a singleton register as itself (RenderObject), and from there, the caller can retrieve the list of that specific object.
But it will mean, that through the ENUM informationnature, render-information will again have leaked through. Also I don't like the elaborate registering system.
- put an object's render-information (BaseObjectGraphics, this class would need a link to the BaseObject) in a seperate table, retrieve all the visible objects from SceneManager, and thereafter retrieve the corresponding render-information from the table with the BaseObject::GetID().
It is a possibility. The object will be completely fragmented.
- leave it as it is.
--------------
Right now I am leaning towards either keeping the information seperately in another table and linking through ID or leaving as it is.
--------------
Have any of you encountered this problem? And what was your solution to keep the objects logically intact, and to avoid superflouous classes/methods?
I have designed a SceneManager, that I use for my world. It is divided into quadrants, which each hold the objects belonging there. When I want a list of visible objects, I call a GetVisibleObjects()-method, which takes the "seeing" camera as argument, and which returns a list of visible objects.
So far, all I have used the scenemanager for, has been for rendering. And therefore, the objects I have been storing, had rendering in some form (a Render()-method) attached to them. I knew when I designed my RenderObject, that it would give problems conceptually, because the RenderObject derived from a more basic object, and I was forced to derive again from it with classes, for which rendering was irrelevant.
My problem now is, that I want to use the SceneManager for more. For example, I could imagine integrating it with a collision system (or rather, let it become a collision system as well).
Now I have this stupid render-class stuck in the middle of my object-hierarchy, and all it is good for, is rendering, and it is not directly relevant to other objects, that have to derive from it, to participate in the SceneManager, and that irks me. For instance, in my structure, StaticCollisionObject now derives from RenderObject, and that is an eye sore to me.
Also, on the server-side, I don't need rendering at all, meaning RenderObject becomes completely obsolete here.
But then I have thought about the alternatives. If I return a list of BaseObjects, how will I be able to get to rendering in any form? I came up with different solutions:
- virtual bool BaseObject::Render() = 0;
By moving this method from RenderObject to BaseObject, I would maybe be able to get rid of the RenderObject (at least at a so low level as I have it now).
But it is ugly to have it at that level. I would prefer to have methods only directly relevant to each object.
- virtual bool BaseObject::RegisterInformation(ENUM informationnature=RENDERING) = 0; This will call the virtual method until it hits the object that acknowledges RENDERING, and this object will place itself in a singleton register as itself (RenderObject), and from there, the caller can retrieve the list of that specific object.
But it will mean, that through the ENUM informationnature, render-information will again have leaked through. Also I don't like the elaborate registering system.
- put an object's render-information (BaseObjectGraphics, this class would need a link to the BaseObject) in a seperate table, retrieve all the visible objects from SceneManager, and thereafter retrieve the corresponding render-information from the table with the BaseObject::GetID().
It is a possibility. The object will be completely fragmented.
- leave it as it is.
--------------
Right now I am leaning towards either keeping the information seperately in another table and linking through ID or leaving as it is.
--------------
Have any of you encountered this problem? And what was your solution to keep the objects logically intact, and to avoid superflouous classes/methods?
