i’m building an application around the jogl library that is very performance oriented, and after looking at a LOT of material i have a few questions about how opengl fits into a larger application system.
opengl looks like a streaming, synchronous subsystem that basically takes a bunch of flags and input to drive a very specific process. it’s kind of like an engine that you can tweak, amp, tinker and modify while it’s running, but similarly, its form us somewhat set. sure, you can bore it out, add a metric adapter, add a turbo; but you aren’t going to add a cyclinder, etc. (sorry about beating the car analogy to death). yet, java, is multi-threaded, loose, modular, mutable. how are these guys mated together most effeciently? specifically:
basically, it seems that jogl has a simple, four-part connection to the rest of the java world (in terms of logic, not resources such as textures, or plug-ins like vertex shaders): init(), display(), reshape(), and displayChanged(). what is the most effecient way for java to interact? do you insert a method call from a java object inside the display() method and have a single entry point as in: display() { myJavaRenderingObject.doEverything() }. further, does myJavaRenderingObject gather a chunk of GL commands to stream back as vertex arrays, etc. or does it call the GL object’s methods directly as needed (i.e. glTranslatef())?
is the goal to have the java code perform a lot of setting up and optimizing first, then releasing big chunks of commands, or constantly updating?
when i’m inside the GLEventListener’s display() method, should i be avoiding interacting with java memory and object structures related to other tasks or windowing?
so, basically, what’s the best way to interface with the display() method, and what kind of compartmentalization is optimal? as you can tell, i’m in the design phase of my project. also, i realize that my basic understanding of JOGL may be flawed, etc.; but i’m basically trying to understand where the pitfalls and advantages are in sending data or calling methods between these two areas might be.
Put simply, it’s a state machine (so the engine analogy isn’t far off). You setup the state and subsequent calls are effected by that state until the state is changed again.
init() - The first step - it’s called once by JOGL - you setup the basic configuration of values you won’t typically be changing such as shade model, depth values, normalization, etc.
reshape() - called when the window size changes, you can may adjust your perspective, etc.
displayChanged() - if the mode changes. (not used yet).
display() - the core where you do your rendering. This is the method where it’s safe to make GL calls. Typically this is called from a tight loop. You can use the Animator class to get display() called or you can create your own.
For top performance, you use Vertex Buffer Objects, vertex arrays or display lists. Each support a means of creating a batch of commands that can be quickly executed by the video hardware. The Java code will try to determine which objects should be drawn, creates the objects (VBO, VA, DL from above), then executes them. Various other things like occlusion, collision detection, etc are done to filter what is drawn and manipulate the interactions - this is done by changing the GL matrix, or by manipulating the vertex data being sent to the hardware (of the above only VBO allows direct manipulation on the video card).
Within the display call you want to be focused primarily on rendering. You can however do just about any other calls (changing window size wouldn’t be good though). You can operate on the memory etc. The key here is that whatever you are doing in there, you want it to execute fast. If your application is multi-threaded, you can do those operations in other places UNLESS they involve OpenGL calls.
The key to performance is getting the data to the video card as fast as possible. Rendering itself tends to be the bottle neck, but it really depends on what you are trying to create. For video games, it’s usually fine to do everything as a branch from the display() method, prior to making your GL calls. It’s a balancing act of providing the least amount of data to the card to achieve the results you want. This is done using a combination of Open GL’s capabilities and your own application logic. I would describe more, but beyond that basic description is a heck of alot of math, algorithms, data manipulation and alot more
great stuff vorax. thx. so my basic understanding is that i might simplistically structure things like so:
class ObjectModel - store my representation of the objects i’m working on. to be subclassed or whatever.
class ProceduralAnimation - simulation part (how i’m animating)
class World - database of my world
class WorldWhacker - focused code to break down world into effecient groups of flags and vertex buffers.
class Renderer (a GLEventListener) - from within it’s display() method, call WorldWhacker’s shootThoseFlagsAndTriangles() method to send my data to float down the rendering stream
this is very abridged of course! but seriously, a couple of questions:
since WorldWhacker will store my optimized representation of the world for rendering, and will clearly connect with several OpenGL data structures and methods, is this object REQUIRED to be part of (instantiated inside) my Renderer; therefore on it’s thread? everything else: the world, it’s objects, and the animation logic can all exist on other threads and have their own little existence. once a frame the Animator tells the WorldWhacker to get to work translating an optimized view of the world into a series of matrix calls, flags, and data to be rendered by OpenGL.
so it seems that you need a kind of highly effecient conductor, and probably a couple of helper objects to effeciently work on translating the current camera view of the World in to OpenGL commands. it seems another primary of this task this conductor is to let the Animator know when it has a frame’s worth of information to send to the GPU. specifically, Animator tells the Renderer to display(), which in turn calls WorldWhacker.shootThoseFlagsAndTriangles(). with this scheme it seems that there is no need for thread synchronization between Application and JOGL. is that true?
