Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (603)
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 1398 times)
0 Members and 1 Guest are viewing this topic.
Offline nerb
« Posted 2013-11-08 00:41:45 »

Howdy,

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,
nerb.
Offline theagentd

« JGO Bitwise Duke »


Medals: 366
Projects: 2
Exp: 8 years



« 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.

Myomyomyo.
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  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

rwatson462 (37 views)
2014-12-15 00:26:44

Mr.CodeIt (30 views)
2014-12-14 10:50:38

BurntPizza (61 views)
2014-12-09 13:41:13

BurntPizza (98 views)
2014-12-07 19:46:31

JscottyBieshaar (59 views)
2014-12-05 03:39:02

SHC (74 views)
2014-12-03 07:27:13

CopyableCougar4 (77 views)
2014-11-29 12:32:03

toopeicgaming1999 (137 views)
2014-11-26 06:22:04

toopeicgaming1999 (127 views)
2014-11-26 06:20:36

toopeicgaming1999 (37 views)
2014-11-26 06:20:08
Resources for WIP games
by kpars
2014-12-18 01:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 13:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 13:36:02

List of Learning Resources
by Longor1996
2014-08-16 01:40:00

List of Learning Resources
by SilverTiger
2014-08-05 10:33:27

Resources for WIP games
by CogWheelz
2014-08-01 07:20:17

Resources for WIP games
by CogWheelz
2014-08-01 07:19:50

List of Learning Resources
by SilverTiger
2014-07-31 07:29:50
java-gaming.org 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‑gaming.org
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!