The answer lies here:

glu.gluLookAt(eyeX, eyeY, eyeZ,
            centerX, centerY, centerZ,
            0, 1, 0);

As eyeZ is assigned a negative value of -10, your "camera" resides behind the X/Y-plane at Z=0 and thus everything seems mirrored. Moving the eyeZ to value of 10 should make the world seem normal again.

Yes, you should. Using a surface normal effectively means that all the vertices drawn for the surface will have the same normal - thus making the surface seem flat. You can generate vertex normal simply by averaging your current surface normals for each vertex if they are not provided to you by a modeling package.

So, basically a vertex normal VN for vertex V shared by surfaces A, B and C with normals AN, BN, CN (unit vectors) =

VN = normalize(AN + BN + CN)

...and if that does not please you, take a look at Boostrap, which is a non-intrusive way of launching Java apps neatly on Windows platform:

http://www.g0dmode.com/javastuff/bootstrap-1.0.zip

I think that the call gl.glColor3f(0f,0f,0f) causes them to appear black - this happens because of the texture-color modulation.

Simplest solution is to set the color to white (1, 1, 1).
You may also disable the texture modulation with the following code:

To get you going with super-simple texture loading, you could try out this:

http://www.g0dmode.com/javastuff/jogl-textureio.zip

Use the TextureIO class to load textures from files. Then call initialize and bind methods for the created texture to use it.

That's true. The example embeds the JOGL GLCanvas to a SWT composite by using the bridging SWT_AWT.new_Frame(composite) call.
I've found this approach satisfactory in most cases. However, the bridging may cause some side effects regarding the event loops and threading models in the SWT and AWT libraries.

I have done that in the past. I uploaded an example with source code at:

http://www.g0dmode.com/javastuff/jogl-swt-example.zip

The example can be run in Windows via swt-example.cmd or swt-example.exe (Java Windows launcher).
The program should produce a simple native window with a tree control at the left hand side and a panel rendering a blinking rectangle at right.

I've successfully tested the example with ATI X800 Pro card - please report if you find any bugs or unstability in the program.

Have fun! 

Hi, I experimented with JOGL and SWT quite extensively about a year ago. I can post you the details later on today (I'm in a hurry atm).

Cheers

Hi, I have been successful with the following piece of code:

[CODE]
       gl.glEnable(GL.GL_DEPTH_TEST);
       gl.glDepthFunc(GL.GL_LEQUAL);
       gl.glEnable(GL.GL_TEXTURE_2D);

       // Sphere reflection mapping
       gl.glEnable(GL.GL_TEXTURE_GEN_S);
       gl.glEnable(GL.GL_TEXTURE_GEN_T);
       gl.glTexGeni(GL.GL_S, GL.GL_TEXTURE_GEN_MODE, GL.GL_SPHERE_MAP);
       gl.glTexGeni(GL.GL_T, GL.GL_TEXTURE_GEN_MODE, GL.GL_SPHERE_MAP);
[/CODE]

Edit: I would try to remove those texture matrix mode tricks first...

Cheers

SDV, take a look at a recent discussion about non-pow-2 textures:

http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=jogl;action=display;num=1110639195

I think that this has something to do with the fact that scaling the triangle actually affects its vertices world coordinates and thus the specular highlight computation (since the specular computation is affected by the current viewpoint, vertex position and light position).

Hope this makes some sense.

Edit: You could try to place the light at some distance from the triangle to the direction of the triangle normal. That way, the specular highlights should be equally strong with all scales of the triangle.

I've use GL_TEXTURE_RECTANGLE_EXT with both Radeon 9600 and X800 and it seemed fast to me. See an example here:

http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=LWJGL;action=display;num=1098038144

It's possible, though not convenient. Take a look at this:

http://www.javaranch.com/newsletter/200310/NativeLibraryInstallTutorial.html

ps. If you haven't already compressed your native libraries, you can use UPX for that:

http://upx.sourceforge.net/

Cheers

Agree 100%. It's not worth it really. My model importers assumes certain formats, which is OK because the modelling tools (MAX, etc.) have their own standards anyway.

I think that the easiest (and only) way of getting JOGL work on the platform your friend is using, is to compile JOGL on that platform. Basically, it should not be that difficult - download the source code from (latest, JOGL b09 source release):

https://jogl.dev.java.net/files/documents/27/11497/jogl-src.zip

The source code package comes with the necessary build scripts for the X11 windowing system and thus it should be possible to build it with virtually any standard UNIX system.

The package also comes with a file called HowToBuild.html (in the doc directory), which describes the building process in more detail.

To quote The Fast Show: Grrreaat.

To "bind" your animation to the real world time, you should first ask yourself, what is the desired duration of each frame in the animation. Let's say we want an animation where the frame is changed every 100ms (1/10 of a second), and there are 20 frames altogether:

[CODE]
// The current real world time, in milliseconds
long time = System.currentTimeMillis();

// The current animation frame ((time / duration) mod totalnumberofframes)
int animationFrame = (int) ((time / 100) % 20);
[/CODE]

Hope this helps a bit

I can confirm the same results with an ATI system. I have tried the demo with NVidia setup too, it seems to work great.

My ATI system specs:

- Latest Sun JRE 5.0
- ATI Radeon X800 Pro, with latest (5.2) Catalyst drivers
- WinXP, SP2
- AMD XP 3000+

The demo seems to update the OpenGL panel 1 or 2 times per second, so it clearly suffers of some problems. Notice that I'm using the default OpenGL driver settings.

That's quite nice. I deduced a version of my own some time ago (next power of two, downwards):

[CODE]
   private static int getPowerOfTwo(int a)
   {
       return (int) Math.pow(2, (int) (Math.log(a) / Math.log(2)));
   }
[/CODE]

It would be nice if JOGL included an utility method for these kinds of needs. It seems that this code is asked for once a week now .

Quite true, but you don't need that for sphere mapping.  Here's an example:

[CODE]
       if (sphereMap)
       {
           gl.glEnable(GL.GL_TEXTURE_GEN_S);
           gl.glEnable(GL.GL_TEXTURE_GEN_T);
           gl.glTexGeni(GL.GL_S, GL.GL_TEXTURE_GEN_MODE, GL.GL_SPHERE_MAP);
           gl.glTexGeni(GL.GL_T, GL.GL_TEXTURE_GEN_MODE, GL.GL_SPHERE_MAP);
       }
       else
       {
           gl.glDisable(GL.GL_TEXTURE_GEN_S);
           gl.glDisable(GL.GL_TEXTURE_GEN_T);
       }
[/CODE]

What keeps you from calling glCanvas.repaint() right after you've created it?

Remember, that repaint method does not cause an immediate refresh of the component but an event that requests the refresh in the AWT thread.

Pahidla, you must be referring to this thread:

http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=jogl;action=display;num=1103394116

...in that case, my bad, sorry - I did promise to deliver a simple example that shows the basic usage of "on-demand" usage of JOGL (manual refreshing of GLDrawables).

The thing is I've been busy with my studies lately - I'm currently working on a 100% Java rigid body dynamics framework/library.

But, if there is any specific question about JOGL, that I could help you with, please do ask without hesitation.

See this thread at LWJGL forum:

http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=LWJGL;action=display;num=1098038144

...it contains source code for a motion blur effect which I wrote some time ago. Basically it shows how to make use of non-power-of-two textures. Hopefully you can modify it to fit your needs.

The one not working has wrong content-type, "text/plain". It should be:

application/x-java-jnlp-file

This can be fixed by altering the server configuration or the script providing the file (php, asp, etc.). The following is an example for Apache configuration:

AddType application/x-java-jnlp-file .jnlp
AddType application/x-java-archive-diff .jardiff


With PHP you can do the following to change the content type:

header('Content-type: application/x-java-jnlp-file');

...and then output the JNLP contents.

Thank you for your kind words.
Can you post your initialization code here (Frame/GLCanvas creation, etc.), so we can take a look at it?

Ok, I'll try to explain JOGL and threads in a clear way. Generally, there are two ways in which you can use JOGL to render graphics:

- On-demand -> the GLDrawable (GLCanvas, etc.) is only refreshed when the repaint/display is called by AWT (component resized, etc.) or by the user.

- Continuous -> the GLDrawable is continuously refreshed by another thread (Animator class, etc.).

The possible problems with threads arise when two different threads try to operate on the same OpenGL context.

In JOGL terms, this basically means that if you're rendering the GLDrawable with an Animator (or some other implementation involving multithreading) AND try to invoke OpenGL operations on the same GLDrawable from another thread, problems will occur.

However, if you're only refreshing the GLDrawable manually (no threading involved), it's OK to make OpenGL calls from the GUI thread, since no other thread is using the GLDrawable and its OpenGL context anyway.

So pahidla, you're doing nothing wrong.

I'll post you a simple example tomorrow morning (Finnish time that is [GMT+2] )

Yes, in the AWT/Swing world, the button event is executed in the GUI thread, which probably is not the same thread you're using JOGL from right now.

To go around this, it is easiest to "delay" and delegate the button event to the rendering thread, using a queue of events, for example. So, in general:

1. Event occurs (button was pressed, mouse was moved, etc.)

2. Delegate the event to the queue (you can simply put the event object to the queue)

3. Rendering thread sees that the queue is non-empty and processes the events in the queue (responds to the pressed button, etc.)

I hope this helps

Ken, that is truly excellent news!

This kind of information is exactly what the community needs to see.