follow-up course on JOGL

Hi everybody,
just to let you know that I have added to my website containing my course lecture notes a new course on graphics with Java and JOGL. It is the follow-up course of my first course on graphics in Java (with GUIs, Swing and an introduction to JOGL) and presents more advanced features of JOGL (textures, NURBS). It also presents an approach to the gimbal lock problem and an introduction to animation (kinematic animation based on cubic spline interpolation using M. T. Flanagan's mathematical library in Java).

I opened the course only this Fall semester, so it is just the very first version with some parts still pretty embryonic (especially the chapter on animation...). I would be very glad to receive some feedback to help me improve and develop this course in the future.

Here are the links to my two courses on graphics:

http://eng.eul.edu.tr/manuel/Course_on_Graphics_in_Java/Course_on_Graphics_in_Java.htm

http://eng.eul.edu.tr/manuel/Course_on_Advanced_Graphics_in_Java_and_JOGL/Course_on_Advanced_Graphics_in_Java_and_JOGL.htm

Hoping it will help.

Manuel Carcenac
Computer Engineering Department
European University of Lefke

Hi

I worked with a researcher on the problem of gimbal lock, we use non eulerian transforms. I'm going to look at your course with a particular attention as many sources on the Web say wrong things about it. The 2 ways to work around this problem are a non linear approach based on singularities on some poles and a linear approach based on non eulerian transforms easy to use with quaternions. Using quaternions is not enough. Best regards.

Edit.: Maybe you should have a look at JCuda and JOCL...

Maybe you should add a section to explain how to install JOGL on Linux and Mac OS X too, keep in mind that it might evolve a bit with JOGL 2.0 RC6.

Please remove obsolete references for the Java documentation of the API, this one is... old:
http://download.java.net/media/jogl/jogl-2.x-docs/

Why not speaking about NEWT too?

Please advise the use of a more recent version of Java.

You don't need anymore to set the Java Library Path, just add jogl.all.jar and gluegen-rt.jar to the classpath, put the JARs containing the native libraries into the same directory and that's all. If you want, I can provide you a template project to ease that task in Eclipse.

Maybe using GLProfile.getDefault() is not a good idea for pedagogical reasons. Why not using GLProfile.getMaxFixedFunc() or GLProfile.getMaxProgrammable()? It would be the occasion to explain what is a backward compatible profile and what is a forward compatible profile.

Don't forget to speak about the gimbal lock below the example that performs 3 calls to glRotate.

Don't call glFlush().

Maybe speak about vertex arrays and VBOs or I assume it is done in another course.

UVW cameras suffer of Gimbal Lock too because their operations are mathematically equivalent to what is done with Euler angles in a naive use, I prove that in 2006 during my licence degree in computer science. You can find an example of workaround based on singularities in Ardor3D and an example of non eulerian transform here:
http://jeux.developpez.com/faq/math/?page=transformations#Q34b

I already told you that some years ago:
http://forum.jogamp.org/course-on-Graphics-in-Java-GUIs-2D-graphics-JOGL2-available-online-tp3072181p3075816.html

Nice courses! I especially like the NURBs part -- I haven't seen many tutorials about that on the web before.

Hi!
thank you so much for the precious comments. I am going to put the improvements suggested in my to-do list (unfortunately, I won't be able to work on it immediately since I have a number of courses to open next semester).

I have a few questions:

>>  Please remove obsolete references for the Java documentation of the API, this one is... old:
>>  http://download.java.net/media/jogl/jogl-2.x-docs/
Could you please provide me with a link to the most recent reference for JOGL classes? I had great difficulties finding relevant documentation on the web.

>> Don't call glFlush().
I thought it was a good thing to flush all the buffers at the end of display()... Can it really be avoided in OpenGL?
Or is there something specific about it with JOGL? Or is it really just needed for a distributed execution on a network? If yes, maybe it is still good practice to call it when running on a single PC?

>> If you want, I can provide you a template project to ease that task in Eclipse.
Yes, I am interested. I don't use Eclipse but I will distribute it to my students who do.
(my email:  manuel.carcenac@gmail.com)

About Quaternions, I got myself stuck in a dilemma since you suggested it last June. Indeed, I was to open this course as an undergraduate course, an elective one in addition. So I figured out a general approach  to spatial orientation with that kind of intimidating math would not be appropriate.

I finally chose a pretty basic and practical approach: through a real-time animation, i.e. a sequence of small rotations controled by the keyboard and applied relatively to the axes of the camera coordinate system, the user can gradually orient himself as if he were inside a  spacecraft and firing attitude rockets. I do not see how there could be any gimbal lock like that. Of course, from a mathematical standpoint, that's heavy: the orientation is defined by the 9 coordinates of u,v,w and these coordinates are modified progressively by the user. So, there is no clear, static, description of the spatial orientation. But in practice, I believe it is a good building block for a video game. Well, I admit I am far from being a real specialist of the field, so I hope I don't talk too much nonsense...  ;-)

I had fun for some time navigating around the earth and the moon with the program under the link "textures earth, moon, sun, heaven and spacecraft" and I never got stuck in any gimbal lock. It kept behaving exactly as I wanted  (orient yourself by the milky way when no planet is in sight). Notice that I am planning in the future to add the physical animation part that is missing to this code (time integration of earth and moon gravity, no big deal...)

Sorry, I wish I could have made a general presentation of the issue of spatial orientation.

PS: JCUDA is intriguing indeed.

Many thanks for your appreciation!

Hi

The documentation of the API is here:
http://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/

Of course, using glFlush() is not mandatory, I never use it. It is useful in only some very particular cases and it can even have a bad impact on performances if you use it when it is not appropriate (it may break the internal synchronization of the pipeline in the driver). I know several engines including mine which don't use it. glFlush was mainly used when the rendering was done on remote servers more than ten years ago and even in this case nowadays it is very rarely used, I only sometimes see some programmers using glFinish() to be alerted when OpenGL has done its job.

I will try to provide you a template project as soon as possible.

I know that quaternions are difficult to explain to students. However, you could have explained a bit the singularities on poles with a workaround not relying on quaternions like Ardor3D does. Maybe I will translate my report about gimbal lock when I'm less tired. UVW matrices and Euler angles are mathematically 2 "different" ways to express angles but if you use them with eulerian transforms, you obtain gimbal lock. Your approach does not allow to reduce the risk of gimbal lock, you only try to do something to prevent cases close to singularities on poles. If some students want to see a good example of building blocks to make games, they should have a look at existing 3D engines written in Java, especially Ardor3D. If a student tried to use your approach in a more general case to rotate a given object close to any singularity, he would have some gimbal lock. Your example doesn't prove anything as you won't have any gimbal lock if your input modifies only 2 rotations at a time and if you don't try to test problematic cases. Using unclear methods to work around gimbal lock just makes it harder to test the cases of singularities, it does not mean that there is no gimbal lock.

JCuda is nice but I really prefer using OpenCL and JOCL in order to avoid using only Nvidia graphics cards.

Yes, I would be very interested in your report on gimbal lock.

> If a student tried to use your approach in a more general case to rotate
> a given object close to any singularity, he would have some gimbal lock.

That is precisely the point, my approach is by no way meant to be general. It simply relies on the assumption that we have an animation with yaw, pitch, roll rotations of at most a few degrees per time step. So the 3 rotation axes remain pretty much orthogonal and we remain far from any singularity.

Again, that is not meant to be general but to me the assumption seems reasonable within the framework of an animation.

My report is somewhere on the world wide web, maybe Google Translate can give you a first translation:
http://membres.lycos.fr/javalution/download/gimballock.zip

I had weaker math knowledge when I wrote it but I did my best.

It's not reasonable within a real framework of animation, that's why Ardor3D has a simple fix for singularities and this engine is used by the NASA. The problem is that when a student reads your lesson, he might think that you provide a general solution to work around gimbal lock whereas you only put yourself into a case far from singularities, these are 2 different things. Of course, your "framework" is enough in some cases but in my humble opinion you should write something clear about this limitation to avoid confusion.

On Friday, December 23, 2011 10:10:31 AM Manuel [via jogamp] wrote:
Excellent!

Updated your entry!

https://jogamp.org/wiki/index.php/Jogl_Tutorial#Courses

Thank you for making the information freely available!

~Sven

Oups! there is a problem with your link:
>Dangerous Page
>Trend Micro has confirmed that this website can transmit malicious software or has been involved in online scams or >fraud
Are you sure it is really safe?

If the language is French, it's ok for me...   ;-)


> It's not reasonable within a real framework of animation
Well, a rotation of more than a few degrees per time step, that must be a hell of an animation...    :-)

In any case, even with the assumption of no more than a few degrees per time step to remain very far from singularities, it is still a very practical tool and a huge improvement over basic Euler angles. It is reliable, and it is a pleasure to orient swiftly the camera with it, especially after the headaches Euler angles had given me (what I found most vexing was actually the couplings between these Euler angles).

Please remember this was just the first version of my course and it was just intended for undergraduate students. And I did make it clear that it works only under the assumption of small rotations per time step (in slides 4 and 6, "incremental approach", "rotate gradually", "at each time step, apply small rotations...", "axes of rotation remain practically orthogonal over a time step ...  remain far away from any gimbal lock configuration", "small rotations over  roll , pitch , yaw  at each time step").

But I understand your point, you are worried it might be considered by fast readers as a general solution to the gimbal lock issue, which of course it was never meant to be. Since this course is likely to be given to graduate students in the future, I am thinking of studying your report and adding to the course a general section about it. That way, the presentation will be complete. About Ardor3D, I am not in favour of teaching black boxes to students, at least not without a decent theoretical presentation first. That's why I would like to use your report, if you don't mind (as you had noted, it is difficult to find a good presentation on the web).

Thank you for your precious help. It has been a pleasure discussing with you and it will help me enrich the course.

This site is safe even though it displays a lot of annoying popups :(

Of course, you're right about black boxes, I don't advise you to use Ardor3D with your students as it would not allow them to understand how 3D works underneath, I suggest you to look at the source code just to use the same fix in your own code. I first learned OpenGL before using high level engines, I agree with you. Let me know whether you need some help. I would like to contact my former teacher of computer graphics as she wrote an excellent course about OpenGL, it would be nice to share it.

Hello,
I have downloaded gimballock.zip but I found inside it only some jpeg images and a source code projet.cpp.
I could not find the report in it.

I wish I can work right now on updating and developing this course. Unfortunately, I have a huge heap of other works in front of me. That's my biggest problem right now, and very frustrating. I should give it again next Fall semester, so I have to update it by then, to the very least...

Hi

Sorry, I have just found my report, I'm going to send it to you immediately...

I've got it. It's excellent. Exactly what I need.
Thanks!
PS: it would be great if you could translate it in English and put it on the web (and advertise it). I am sure it would help a number of people.

You're welcome. I will translate the report, improve it a little bit and publish it both in French and in English on my personal blog in some months.