Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (777)
Games in Android Showcase (231)
games submitted by our members
Games in WIP (856)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  OpenGL/LWJGL program structure  (Read 3965 times)
0 Members and 1 Guest are viewing this topic.
Offline nerb
« Posted 2013-11-08 00:41:45 »


I've been learning the OpenGL ropes via LWJGL (programmable pipeline), and have got to the point that I'd like to create a more complex scene than just the odd rotating cube or two. However, I've become aware that there aren't many resources out there that actually focus on OpenGL program organisation/structure, particularly in terms of OOP (not that I can find anyway!). I've had a good googling, but the results are limited or vague; It could've been that I wasn't using the right terminology in my search. I've got some general ideas about how I'll go about it, but want to run it past the JGO community for opinions & suggestion.

I gather that the most important thing is to try and minimise state changes and pushing data to the GPU; as such, it's best to render similar objects consecutively (other fancy words like 'geometry batching' also popped out at me). So as an example, I was thinking of doing the following:

- Lets say I created a farming program, with a Sheep, Pig and Cow class. Each of these classes holds a static list/reference to every instance of the class (i.e. instances are added or removed from the list when they are created or destroyed).

- The class statically holds all OpenGL state common to each instance (i.e. VAO's, VBO's, shaders, textures).

- When it comes time to render, I call a static render() method on each class (i.e. Sheep.render(), Pig.render(), Cow.render()). This method sets the common OpenGL state once, then runs through each instance and renders it, perhaps by calling a non-static render() method on each instance. The instances themselves are responsible for setting uniforms particular to that instance, such as transformations or texture coords, and making the final draw call.

So in general, my questions are:

- Does this sounds like a decent approach, and do you guys do things simillar or differently?
- Is there a better, or more accepted way to do this?
- Will this scale well as my program increases in size &/or complexity? (Keeping in mind at this stage I'll just be messing around whilst learning, but with a view to creating a full-blown program in the future).
- Are there any good resources out there on the net that focus on OpenGL program organisation, that I should be looking at?

Cheers muchly,
Offline theagentd
« Reply #1 - Posted 2013-11-08 01:26:30 »

Your design sounds good, but static lists and OpenGL resources aren't very "clean" in object oriented programs. You could instead store your VBOs, shaders etc in a Mesh object (or something similar) that is shared by a certain animal type, and keep lists of them in the main game class (as normal fields, not static fields). Such a design should scale to a few hundred if not a thousand meshes. If you're interested in rendering an extreme number of meshes you should look up geometry instancing.

Offline nerb
« Reply #2 - Posted 2013-11-08 04:11:23 »

Thanks for the reply theagentd. A more general mesh class makes more sense than what I was planning, and as you mentioned, cleaner. (Not to mention more usable, flexible, extensible, and all those other lovely OOP words). I think I could have run into some strife with my inital idea; if not immediately, certainly down the track.

I've touched on instanced drawing whilst learning OpenGL and intend to have a play with it in the next couple of months.

Much appreciated.
Pages: [1]
  ignore  |  Print  

hadezbladez (336 views)
2018-11-16 13:46:03

hadezbladez (180 views)
2018-11-16 13:41:33

hadezbladez (336 views)
2018-11-16 13:35:35

hadezbladez (83 views)
2018-11-16 13:32:03

EgonOlsen (2177 views)
2018-06-10 19:43:48

EgonOlsen (2205 views)
2018-06-10 19:43:44

EgonOlsen (1378 views)
2018-06-10 19:43:20

DesertCoockie (2010 views)
2018-05-13 18:23:11

nelsongames (1654 views)
2018-04-24 18:15:36

nelsongames (2299 views)
2018-04-24 18:14:32
Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45

Deployment and Packaging
by philfrei
2018-08-20 02:33:38

Deployment and Packaging
by philfrei
2018-08-20 02:29:55

Deployment and Packaging
by philfrei
2018-08-19 23:56:20

Deployment and Packaging
by philfrei
2018-08-19 23:54:46 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!