Simple JOGL framework + source + tutorial

OpenGL Development JOGL Development
#1

I’m writing the above right now - I need something very lean and simple which shoehorns JOGL into being a more well-behaved OOP affair but WITHOUT changing the fact that all the OGL calls look just like C (hence LWJGL is not an option).

FYI I’m doing some source code for Games Programming Gems 5 where I need to demonstrate some GUI stuff with OpenGL in a way that C programmers will be happy with but which is “good” Java.

Anyway, I’ve got a basic framework working quite nicely (I’ve tried to do this about 3 times before with JOGL) and just wondered if I’m re-inventing the wheel? Has someone else got a simple framework, something akin to providing the developer with Cas’s “simple example LWJGL game loop” he posted a while back which is very short and lets you just slot in OpenGL stuff BUT is not going to have to be ripped out and replaced as soon as your app gets complicated (e.g. I need modular rendering, modular startup, etc)?

If not, I’ll keep going, and once I’ve got the source for the book done (deadlines fast approaching!) I’ll do a tutorial for the framework (which will be pretty short!) and slap it up on the web.

But…I would appreciate any general design comments - especially advice and/or thoughts on designs to avoid - to try and make it as usable as possible before I spend hours on it :).

#2

PS if anyone’s got experience trying to marry JOGL with Xith by hand, please msg me. IIRC Xith doesn’t support dropping down to JOGL at the moment, but Xith’s 2D overlay stuff is sufficiently fubar at the moment that I’ll be wanting to use some of what I’m doing now to provide funky HUD rendering in Xith.

#3

I think it would be great if you pushed ahead and completed this. Please post when you have, and let’s assemble a list of useful pointers for JOGL developers.

#4

I’m working on something similar, but a little more robust (perhaps?) for my Scream and Auriga3D projects. At this point I am investigating the use of Fractal (http://fractal.objectweb.org/), GenericPluginEngine (http://genpluginengine.sourceforge.net/) and the reference implementation of JSR 223 to generically support scripting and initialization of the system.

There is a library of components for the system that support a generic interface to both JOGL and LWJGL that allow the majority of code written for a game/project to be shared. IE you of course write a particular plugin for LWJGL or JOGL for the rendering loop, but the majority of the startup/initialization code is generic across JOGL/LWJGL or .

I am looking at a September release of this framework with Auriga3D being the main example of its use.

#5

Probably :slight_smile:

If this is going to be an open framework, is there any chance you could send me some details? The deadline for source for the CD is way before September, so I probably can’t use it directly, but if there are any simple bits (c.f. my need for framework to be particularly simple) perhaps I could borrow the ideas and reference Auriga in my bibliography for people interested in a better framework? (since the book won’t be published until March, there will be plenty of time for your release)

#6

Thanks for the links. I’m not sure either is quite what I want (fractal looks not-so-well-designed from a first pass, and GPE looks as if it’s not quite mature enough for my needs) but I’ll be taking a careful detailed look at both.

#7

Yes, the framework will be open along with Auriga3D (game using the framework). I haven’t come up with a name for the underlying framework yet.

I’ll have the details of the framework and Auriga3D in your inbox early next week. I’m finishing up my GDC proposal this week… :: fingers crossed :: :slight_smile:

I had a similar feeling about Fractal, but its purpose is to be a stripped down component model not attached to any larger goal (J2EE/enterprise, etc.). I am just finishing up a book on Spring/PicoContainer, to get a feel for other lightweight component models, but those are directed towards J2EE apps.

Generic Plugin Engine will see a M1 release in August. I have been following the project for a while now and it seems things are going to come together there soon.

I’m interested in applying the whole inversion of control pattern to a game framework. Presently it looks like I’ll be combining the above projects to create this tool. Adding in support for JSR 223 and providing configuration of scripting resources at the framework level should prove interesting.

Fractal is the most unknown to me presently… I have read through the spec and related documentation. It’s time to get my hands dirty… I just don’t want to create yet another framework completely from scratch, so I’m looking to leverage from existing projects. :slight_smile:

#8

Yeah, that’s what we did for the GrexEngine. It works well.

Ditto, but the GE framework is far too much overkill for this project, so I can’t even take much in the way of ideas from it :frowning: unless I’m willing to do lots of coding.

#9

Hi,

[quote]PS if anyone’s got experience trying to marry JOGL with Xith by hand, please msg me.
[/quote]
What exactly do you mean by this? I believe I can help a lot in all the points realted to Xith3D, but prefer to answer exact questions.

[quote]IIRC Xith doesn’t support dropping down to JOGL at the moment
[/quote]
That’s true for a moment, but what I can do easily is I can add a special shader (Custom Shader) where you can put your raw OpenGL code. But this is to be separated for two major parts - streaming vertex data to OpenGL is more complicated part to extend, while setting of rendering attributes is much easier.

Or, say, another option: if you have an idea of how this “dropping down to JOGL” may look from the user side, post an example and we will try to find a way how to do this.

Yuri

#10

Good question :slight_smile:

What I really mean is that we’ve had too many problems with the overaly/UIWindow stuff, and it seems that since David made it no-one has yet got around to digging deep inside it and seeing how it works and why it doesn’t work (IIRC, going from posts by you?).

I have to do an OGL GUI framework (this thread is about the low-level stuff needed to support that framework) this month anyway that renders interesting/complex HUD’s, and it would be great if I could do minimal work to port it to Xith to do both our HUD and our menus, neither of which need Xith’s SG stuff (and which would just get in the way, especially since the GUI framework doesn’t “know” Xith at all).

I don’t know (yet) how it would be most desirable to look from the user side until I have the code complete and start working out how I’d like to call it from Xith :slight_smile: but in a basic sense there’s just this innate desire to sometimes go “OK, I’m doing something where I just want to chuck some OGL at the screen, and completely bypass SG’s etc”. I don’t know if that’s feasible - or even sensible - in Xith, and it may be I’m barking up the wrong tree here :(.

#11

[quote]it seems that since David made it no-one has yet got around to digging deep inside it and seeing how it works and why it doesn’t work (IIRC, going from posts by you?).
[/quote]
That’s true…

[quote]“OK, I’m doing something where I just want to chuck some OGL at the screen, and completely bypass SG’s etc”
[/quote]
I am thinking about this from another direction: it would (may) simplify for some OpenGL devs to play around some very custom code that may become potential candidate to integration into SG.

[if moderators will decide this discussion is irrelevant here we can move this discussion to Xith3D forum]

There are possible ways of plain OpenGL integration into Xith3D are:
a). Adding custom appearance attribute, so letting SG to perform state sorting and geometry streaming;
b). Adding custom “Plain GL” leaf node of the same style as Shape3D, so it can perform geometry streaming by itself (SG will set up appearance for it anyway, but node can override it by itself if needed).
c). Extra pre- and post-rendering passes.

The problems with plain OpenGL integration are:
1). Rendering order. One who uses plain OpenGL should either be aware that SG may change the rendering order, or use one of mechanisms to ensure correct rendering order (i.e. turn sorting off, or use OrderedGroups).
2). State save/restore. In order to allow smooth interaction of custom OpenGL code with SG renderer, custom code should save and restore the state it modifies before return, otherwise this will affect the rest, potentially producing completely wrong results.

I can relatively easy to come with preliminary implementation of b) and c), while a) should be designed with a great care, because of it should (?) allow multiple custom appearance attrs to be set on single shape.

Yuri

#12

[quote]Has someone else got a simple framework, something akin to providing the developer with Cas’s “simple example LWJGL game loop” he posted a while back which is very short and lets you just slot in OpenGL stuff BUT is not going to have to be ripped out and replaced as soon as your app gets complicated (e.g. I need modular rendering, modular startup, etc)?
[/quote]
Aviatrix3D is designed pretty much along those lines, but is probably a little too complex for what you need. There are separate app, cull and draw sections to the codebase. The cull section uses a Pipeline class thta allows you to slot in different culling classes and sorting classes. The rendering is then abstracted as a surface and the display callback for processing the output of the cull stage, etc.

I think it will probably be too complex for what you need. However, feel free to have a quick dig through the javadoc at http://aviatrix3d.j3d.org/javadoc/ and see if it suits your needs. Some basic usage tutorials can be found at http://aviatrix3d.j3d.org/using/

#13

[quote]OK, I’m doing something where I just want to chuck some OGL at the screen, and completely bypass SG’s etc". I don’t know if that’s feasible - or even sensible - in Xith, and it may be I’m barking up the wrong tree here
[/quote]
The way Aviatrix3D deals with this is it has a separate interface called RenderEffectsProcessor. This is set as one of the attributes of the Scene and gives you two methods - preDraw() and postDraw() which allow you to insert arbitrary OGL code into the rendering loop before and after AV3D has finished it’s processing. We designed it for exactly this sort of situation where the user wants to do some external drawing such as 2D layers or compositing work. I’m sure a similar concept could work in Xith3D as all you do is just pass this down to the rendering loop and it just makes the calls to the two methods at the start and end of it’s rendering loop.

#14

::slight_smile:

#15

Could you comment on your implementation?

I assume you rolled your own instead of or using an existing lightweight container, etc? Did you evaluate the crop of IoC component models? What about a plugin engine?

I am aware of your general closed source approach which is fine; I’m keeping most of Scream closed source as it is a commercial project, however I am curious if you would consider open sourcing your IoC layer used by GE. Technically, if you did it right this should not expose GE.

Granted my game framework is a client resource and probably won’t be running on the same machine as GE if I ever went this way, but having the same IoC layer in both is a plus as far as I’m concerned.

With the extensions I have planned it might benefit GE as well…

#16

Simply put, IoC is woven directly into the GE architecture: the very architecture (let alone any implementation) wouldn’t work without it. I don’t know when the IoC term was coined (I don’t remember noticing it before 2004), but it’s something we’ve been doing since 2000/2001, without worrying about buzzwords :slight_smile:

Because it’s part of the architecture, there’d be almost no point in adopting someone else’s implementation, because we’d need to rip it apart and inject all the bits that would subsume into the GE - which is more effort than just writing it yourself. To be honest I’m a bit sceptical that there’s any point in making generic IoC frameworks beyond practicing your programming skills - it’s like saying “we’ll make a framework for OOP” - what are you actually DOING? The few IoC things I’ve looked at mostly seem to be just declaring some proprietary javadoc tags and having compilers to check the IoC arrangements; that’s definitely counter-productive in some cases, and potentially removes some of the primary benefits :(. I’m interested in them, but haven’t seen anything in them that screams “adopt me for your next project!”.

As far as openness goes, we have no desire for the GE architecture to be closed - although we made the deliberate decision to retain absolute control over it (much like Sun did with Java) - but until current outstanding patent applications are resolved it’s difficult to talk about it without revealing details of our implementation (which are patent-applied-for), hence not much gets said.

If you’d like to mail me a synopsis, I’ll have a look and get you a brief response; there might be an easy way of making them GE-compatible (without introducing any additional dependencies into your code). We’ve tried before to get other vendors to collaborate on common ground here, but it was a huge struggle trying to resolve their FUD, and at the moment we don’t have the spare resource to look at partnerships formally. At the moment, our in-progress partnership arrangements are all on hold whilst we clear the decks of other stuff.

#17

Oh, and IMHO things like PicoContainer are a waste of space - they should be doing their work at the object-instantiation level NOT at the “write explicit code into your constructor” level. This stuff should be transparent; without transparency, it’s a PITA to develop with, and IMHO you are probably wasting most of the benefit by that point…

#18

Bump. Never received anything :).

#19

Thanks for the bump. Tomorrow… Promise… I am just getting www.egrsoftware.com up and running then the details will come. Just got back from Vegas this morning; Defcon was fun once again… :stuck_out_tongue_winking_eye:

In re of the lightweight container issue I did decide to examine PicoContainer closer and will probably adopt it for constructing the underlying framework to Auriga3D and Scream. constructor injection / PC everywhere is overkill, but to configure a base framework it seems appropriate. I am definitely interested in keeping things working with POJOs rather than adopting a more heavyweight solution (Fractal, EJB, etc.).