Sign in to follow this  

3D App Design Question

This topic is 4073 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, I have worked with java to make some small 2D games before. Part of my design scheme for those apps was to have each sprite implement a draw method that would have the sprite draw itself onto the backbuffer image. I am now working with openGL and FLTK. I would like to follow a similar design scheme, by having a draw method for each "DrawableObject." It seems to be working for now, but are there any roadblocks that I should be watching for or reasons why I should not do it this way period? Thanks much, -sevans :EOF

Share this post


Link to post
Share on other sites
Hi,

First of all this is a reasonable approach to the problem and it is used quite a lot. Personally it's not how my objects are designed.

The reason is that it ties your objects to their rendering code. In my opinion this will restrict your use of those objects in the future by that single representation.

E.g. say you have a cube drawable object which implements its ::Draw method using OpenGL. Your editor/game happily renders cubes for ages.

Then you need to add a wireframe mode, or an edge mode, or somehow change the representation of your model in the viewport. But your world is described as cubes... which have their predefined ::Draw method which means you have to hack in ways to render cubes in different ways.

In my opinion you should have an object class (in this example cube) that represents the object. I.e. in our case we could use 8 vertices (although other representations are applicable, e.g. position and width, height, depth parameters).

A renderer class can then be responsible for taking a list (or graph, whatever) of objects and rendering them how you want. The renderer can then have different modes configured (e.g. edge, wireframe, solid) which is much simpler than adding this complexity for each of your drawable objects.

EDIT: of course, the reason I mentioned OpenGL, if you ever want to have objects rendered in DirectX or using a 2D windowing toolkit then have separate rendering code is even more of a plus.

Hopefully that helps,
Cheers,
dhm

Share this post


Link to post
Share on other sites
I do see where this could become and issue. Would it be possible to combine the two ideas? Something like this:


/*
The gl window class that calls the drawable objects methods
*/

class GLWindow;

/*
The DrawableObject class that should be implemented by objects that need to be drawn, ie Cubes
Has a draw method
Has a Renderer member
*/

class DrawableObject;

/*
The Cube class
Implements the draw method of DrawableObject
The implementation of it would only contain methods to set up
the modelview matrix and colors and other gl values that make
up how the object is drawn.
It then would call the Renderer::render() method and pass in
a list of vertices and how to interpret the vertices.
*/

class Cube : public DrawableObject;

/*
A Renderer class to display the objects
Would have different rendering modes that it could be in
that would be stored in a member
Has a method that takes in a list of vertices, render(), and how
to draw those verticies.
Knows of the GLWindow class and object and draws the vertices into it.
This would allow us to set GLRender mode options once for the renderer
and have it apply to all objects.
We could even make a method to set
a render mode property for "the next draw" before a praticular
drawable object is drawn.
*/

class Renderer;






Thanks again for any input.

-Sevans

:EOF

Share this post


Link to post
Share on other sites

This topic is 4073 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

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