Jump to content

  • Log In with Google      Sign In   
  • Create Account


Help with Program Structure


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 Monkan   Members   -  Reputation: 535

Like
0Likes
Like

Posted 04 September 2011 - 04:00 AM

Hi,

So I'm trying to use the new OpenGL stuff and do away with all the old stuff but I'm having trouble structuring my programs and can't find any example programs on the internet that help me.

How do people handle these things? At the moment I have a baseObject class that things inherit from, now I was thinking I would give each object a matrix for its transformations that I can pass to a shader. I then need global access to some sort of camera and perspective matrices so I was thinking I would just have them as global objects even though I have always been told this is not good. I also need to store the vertex batches for all different objects to be able to draw them so I was thinking I would give each object its own vertex batches and store ones that are used a lot like cubes, spheres and rectangles as global objects that I can access anywhere encase I need then.

Basically I am really confused about how to structure my program and still be able to get access to all the things I need from the places in my program. Can someone please tell me how they do it or can someone point me in the direction of an example program please.

Thanks
x
"To know the road ahead, ask those coming back."

Sponsor:

#2 V-man   Members   -  Reputation: 801

Like
0Likes
Like

Posted 04 September 2011 - 06:18 AM

I structure it like this. There is a single class that handles rendering. It makes all the GL calls and it has all the information it needs (camera, projection, etc)

Other people structure it like you do. They have various class objects that render themselves.
Sig: http://glhlib.sourceforge.net
an open source GLU replacement library. Much more modern than GLU.
float matrix[16], inverse_matrix[16];
glhLoadIdentityf2(matrix);
glhTranslatef2(matrix, 0.0, 0.0, 5.0);
glhRotateAboutXf2(matrix, angleInRadians);
glhScalef2(matrix, 1.0, 1.0, -1.0);
glhQuickInvertMatrixf2(matrix, inverse_matrix);
glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);

#3 Monkan   Members   -  Reputation: 535

Like
0Likes
Like

Posted 04 September 2011 - 07:00 AM

Thanks V-man,

yea I think I might re-structure as your way makes a bit more sense to me,

so I'll have a rendering class and then how do you actually draw things? Do you have a rendering list or something similar and loop through drawing each object in the list? Do you store all the drawing info such as verts, normals, texCoords stuff in each object or do you also store all this in your renderer? Can you give me a bit more info as to how you do it or a link to an example of program structuring please.

Thanks
x
"To know the road ahead, ask those coming back."

#4 Monkan   Members   -  Reputation: 535

Like
0Likes
Like

Posted 04 September 2011 - 11:18 AM

Ok so I found this -

http://stackoverflow.com/questions/166356/what-are-some-best-practices-for-opengl-coding-esp-w-r-t-object-orientation


which gives a nice explanation I think. I think what I'm going to do is have a mesh class which will deal with my VBOs etc for each object. A material class which will deal with all my needed shaders and properties for them for each object and then a renderer class which will be used to actually draw using all the information provided inside these two classes.
So each 'gameObject' in my world will not have any openGL functionality in it but will store the information inside these two classes.

Is this a good way of structuring my programs? Can anyone suggest improvements or pitfalls I have not foreseen?

Thanks
x
"To know the road ahead, ask those coming back."

#5 L. Spiro   Crossbones+   -  Reputation: 12317

Like
0Likes
Like

Posted 04 September 2011 - 09:28 PM

It is a good idea not to directly call OpenGL functions from within your models.
You should have a graphics module which handles all of the OpenGL functions and makes sure that, for example, redundant states are not set.
The rest of your modules rely solely on the graphics module for rendering and never directly touch OpenGL.

The graphics module also provides a few helper features such as render queues which it can sort for faster rendering.

The graphics module should provide wrappers for vertex and index buffers that make them easy to create and use. Same goes for shaders.
Your models can and should have their own vertex and index buffers and shaders. The models themselves should decide how they should be drawn. They submit the graphics settings needed for rendering such as lighting on/off and which shader will be used, the graphics module sorts based on these settings, sets these states, and then makes a call back to the model to allow it to perform the actual render on the vertex/index buffers.
Some people prefer to submit the index buffers and vertex buffers along with the rest of the data and let the graphics module perform the entire render. I have found that having the models activate and render their own buffers is both faster and more flexible.


L. Spiro
It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS