gl4java-usergroup

Re: [gl4java-usergroup] One more JOGL question

[Kenneth B. R. <kbr...@al...>]

> However, I'd glad to convert some nehe lessons to JOGL
> But where can I put the files ?

For the time being if you point me to the converted lessons I can
check them in to the jogl-demos project. If you'd like to become
a developer on this or one of the other core game projects please
sign and fax in the contributor agreement at
http://games-core.dev.java.net/sun_contrib_051903_javagames.pdf
which basically indicates that you have the right to check in the
code you're contributing.

-Ken

Re: [gl4java-usergroup] Re: moving to jogl

[Kenneth B. R. <kbr...@al...>]

> Have we the "right" to reuse the GLAnimCanvas code to do this ?

I think the code will have to be rewritten from scratch though I
suspect this won't be too difficult.

-Ken

[gl4java-usergroup] Re: moving to jogl

[Enrique D. <enr...@ya...>]

Have we the "right" to reuse the GLAnimCanvas code to do this ?
___________________________________________________________________
 
> Well I moved my app to jogl this week and all is working fine ;)
 > 
 > I didn't noticed that my app is faster but it is no slower !
 > 
 > It seems that it is not possible to control the framerate in the app as with GL4JAVA 
 > 
 > I think that it is an interesting option to avoid application
 > "eating" all CPU ressources
 
 We aimed to keep the initial Jogl animation API very minimal
 because this can be done at the application level. However if you
 decide to extend the Animator class to support this please let us
 know.
 
 -Ken
 




---------------------------------
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!

[gl4java-usergroup] One more JOGL question

[Enrique D. <enr...@ya...>]

Well, converting a GL4JAVA app to JOGL is really easy
 
However, I'd glad to convert some nehe lessons to JOGL
 
But where can I put the files ?


---------------------------------
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!

Re: [gl4java-usergroup] JOGL questions

[Kenneth B. R. <kbr...@al...>]

> 2) Didn't someone mention that there was some scripts for converting a
> gl4java -> jogl?

The JOGL source tree contains a program
net.java.games.gluegen.opengl.ConvertFromGL4Java which takes care
of many of the syntactic conversions, though the API changes
(like the fact that JOGL's GLDrawableFactory doesn't take a width
and height in any of its methods) will still require manual code
changes.

-Ken

[gl4java-usergroup] One more JOGL question

[Drake W. <dr...@er...>]

Also, anyone looking at converting over the NeHe lessons to Jogl?

These are some GREAT examples!  I used them to their fullest when working on
my little 3d engine.

[gl4java-usergroup] JOGL questions

[Drake W. <dr...@er...>]

Hi, some quick questions... (and is this still the best place to ask Jogl
questions?)

1) How do you load textures?  Is there any texture loaders other then the
pcx one?

2) Didn't someone mention that there was some scripts for converting a
gl4java -> jogl?

Thanks!

Re: [gl4java-usergroup] gl4java crash

[Kenneth B. R. <kbr...@al...>]

>  My gl4java programs all crash wen I open them.....I can found few others
> on this group having these problems (But I couldnt find replies 
> for them).....Can any one tell me why this is happening.....
> It would be really really helpful if any one can help me with this!

The problem is that GL4Java's OpenGL context on X11 is relying on
glXGetCurrentContext to function properly and it doesn't with
some of NVidia's drivers. There is a workaround in the GL4Java
CVS repository but I would instead recommend that you switch to
the new JOGL OpenGL binding, which has a simpler and more robust
implementation which has been pretty thoroughly tested on X11.

http://jogl.dev.java.net/

Note we don't have precompiled binaries yet but the build process
is pretty straightforward. Discussion forums are available on
http;//community.java.net/games/ .

-Ken

[gl4java-usergroup] gl4java crash

[Nagender B. <nag...@cs...>]

Hi all,
 My gl4java programs all crash wen I open them.....I can found few others
on this group having these problems (But I couldnt find replies 
for them).....Can any one tell me why this is happening.....
It would be really really helpful if any one can help me with this!

thanx a lot,
Nagender.



An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : 11 occurred at PC=0x4a5dc314
Function name=glXGetCurrentContext
Library=/usr/X11R6/lib/libGL.so

Current Java thread:
	at gl4java.GLContext.gljMakeCurrentNative(Native Method)
	at gl4java.GLContext.gljMakeCurrent(GLContext.java:2472)
	at GLLandScape1.display(GLLandScape1.java:191)
	at gl4java.awt.GLCanvas.sDisplay(GLCanvas.java:715)
	at gl4java.awt.GLAnimCanvas.run(GLAnimCanvas.java:466)
	at java.lang.Thread.run(Thread.java:484)

Dynamic libraries:
08048000-0804c000 r-xp 00000000 03:01 2730798    
/oracle/9.2.0.1/jdk/bin/i386/native_threads/appletviewer
0804c000-0804d000 rw-p 00003000 03:01 2730798    
/oracle/9.2.0.1/jdk/bin/i386/native_threads/appletviewer
40000000-40014000 r-xp 00000000 21:06 701946     /lib/ld-2.2.4.so
40014000-40015000 rw-p 00013000 21:06 701946     /lib/ld-2.2.4.so
40026000-40034000 r-xp 00000000 21:06 701920     /lib/libpthread-0.9.so
40034000-4003c000 rw-p 0000d000 21:06 701920     /lib/libpthread-0.9.so
4003c000-40045000 r-xp 00000000 03:01 3074180    
/oracle/9.2.0.1/jdk/jre/lib/i386/native_threads/libhpi.so
40045000-40046000 rw-p 00008000 03:01 3074180    
/oracle/9.2.0.1/jdk/jre/lib/i386/native_threads/libhpi.so
40047000-40234000 r-xp 00000000 03:01 3025124    
/oracle/9.2.0.1/jdk/jre/lib/i386/client/libjvm.so
40234000-4032a000 rw-p 001ec000 03:01 3025124    
/oracle/9.2.0.1/jdk/jre/lib/i386/client/libjvm.so
40341000-40405000 r-xp 00000000 21:06 570130     
/usr/X11R6/lib/libX11.so.6.2
40405000-40408000 rw-p 000c3000 21:06 570130     
/usr/X11R6/lib/libX11.so.6.2
40408000-4040a000 r-xp 00000000 21:06 700406     /lib/libdl-2.2.4.so
4040a000-4040b000 rw-p 00001000 21:06 700406     /lib/libdl-2.2.4.so
4040b000-4053d000 r-xp 00000000 21:06 700394     /lib/libc-2.2.4.so
4053d000-40543000 rw-p 00131000 21:06 700394     /lib/libc-2.2.4.so
40547000-40559000 r-xp 00000000 21:06 700433     /lib/libnsl-2.2.4.so
40559000-4055b000 rw-p 00011000 21:06 700433     /lib/libnsl-2.2.4.so
4055d000-4057e000 r-xp 00000000 21:06 700422     /lib/libm-2.2.4.so
4057e000-4057f000 rw-p 00020000 21:06 700422     /lib/libm-2.2.4.so
40580000-405b9000 r-xp 00000000 21:06 863333     
/usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
405b9000-405ca000 rw-p 00038000 21:06 863333     
/usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
405cd000-405de000 r-xp 00000000 03:01 2534579    
/oracle/9.2.0.1/jdk/jre/lib/i386/libverify.so
405de000-405e0000 rw-p 00010000 03:01 2534579    
/oracle/9.2.0.1/jdk/jre/lib/i386/libverify.so
405e0000-40601000 r-xp 00000000 03:01 2534570    
/oracle/9.2.0.1/jdk/jre/lib/i386/libjava.so
40601000-40603000 rw-p 00020000 03:01 2534570    
/oracle/9.2.0.1/jdk/jre/lib/i386/libjava.so
40604000-40618000 r-xp 00000000 03:01 2534568    
/oracle/9.2.0.1/jdk/jre/lib/i386/libzip.so
40618000-4061b000 rw-p 00013000 03:01 2534568    
/oracle/9.2.0.1/jdk/jre/lib/i386/libzip.so
4061b000-41349000 r--s 00000000 03:01 1275461    
/oracle/9.2.0.1/jdk/jre/lib/rt.jar
41376000-4161b000 r--s 00000000 03:01 1275465    
/oracle/9.2.0.1/jdk/jre/lib/i18n.jar
4161b000-41631000 r--s 00000000 03:01 1275463    
/oracle/9.2.0.1/jdk/jre/lib/sunrsasign.jar
436d9000-436da000 r--p 00000000 21:06 456087     
/usr/share/locale/en_US/LC_IDENTIFICATION
436da000-436db000 r--p 00000000 21:06 456086     
/usr/share/locale/en_US/LC_MEASUREMENT
436db000-436dc000 r--p 00000000 21:06 456082     
/usr/share/locale/en_US/LC_TELEPHONE
436dc000-436dd000 r--p 00000000 21:06 456088     
/usr/share/locale/en_US/LC_ADDRESS
436dd000-436de000 r--p 00000000 21:06 456084     
/usr/share/locale/en_US/LC_NAME
436de000-436df000 r--p 00000000 21:06 456083     
/usr/share/locale/en_US/LC_PAPER
436df000-436e0000 r--p 00000000 21:06 765559     
/usr/share/locale/en_US/LC_MESSAGES/SYS_LC_MESSAGES
4972f000-4975a000 r--p 00000000 21:06 1091301    
/usr/share/locale/ISO-8859-1/LC_CTYPE
4975a000-4975b000 r--p 00000000 21:06 456085     
/usr/share/locale/en_US/LC_MONETARY
4975b000-49761000 r--p 00000000 21:06 1091300    
/usr/share/locale/ISO-8859-1/LC_COLLATE
49761000-49762000 r--p 00000000 21:06 456081     /usr/share/locale/

[gl4java-usergroup] Loading compressed DDS files in GL4Java

[<dom...@so...>]

Hi all, 

I'm trying to use compressed DDS files in my program. I started by writing 
my own DDS file reader, referencing nVidia's tutorial 
(http://developer.nvidia.com/view.asp?IO=OpenGL_S3TC_tutorial) together with 
the source code of DevIL, and information on MSDN. 

I can now load the file successfully, and I've checked that all the data 
loaded are correct (where I verify the header items one-by-one, and sampling 
the image data for correctness). The problem is, after loading the data into 
the texture object using glCompressedTexImage2D, I see nothing on there 
screen (where a simple triangle is rendered). 

I've double checked that the rendering code is correct (if I map a .tga 
texture using the tga loader, the triangle is displayed with texture 
mapped). So I have no idea what's the problem for now. I suspected that I'm 
not using the correct data type for the data array, but after trying all 
possible choice I still got nothing on the screen. Could anyone please give 
me some hints about this? Thank you. 

Regards,
Dominic 

The source code I used for loading the DDS file are listed below. Currently 
I'm only handling file compressed by the DXT3 format. 

// This class represents the header of a DDS file.
public class DDSFormatDescriptor
{
   public static final int DDSD_CAPS = 0x00000001;
   public static final int DDSD_HEIGHT = 0x00000002;
   public static final int DDSD_WIDTH = 0x00000004;
   public static final int DDSD_PITCH = 0x00000008;
   public static final int DDSD_PIXELFORMAT = 0x00001000;
   public static final int DDSD_MIPMAPCOUNT = 0x00020000;
   public static final int DDSD_LINEARSIZE = 0x00080000;
   public static final int DDSD_DEPTH = 0x00800000;

   public static final int DDPF_ALPHAPIXELS = 0x00000001;
   public static final int DDPF_FOURCC = 0x00000004;
   public static final int DDPF_RGB = 0x00000040;

   public static final int DDSCAPS_COMPLEX = 0x00000008;
   public static final int DDSCAPS_TEXTURE = 0x00001000;
   public static final int DDSCAPS_MIPMAP = 0x00400000; 

   public char [] signature = new char[4];

   public int size;
   public int flags;
   public int height;
   public int width; 

   public int linearSize;
   public int depth;
   public int mipMapCount;

   public int alphaBitDepth;
   public int [] reserved1 = new int[10];

   public int size2;
   public int flags2;
   public char [] fourCC = new char[4];
   public int rgbBitCount;
   public int rBitMask;
   public int gBitMask;
   public int bBitMask;
   public int rgbaAlphaBitMask;

   public int ddsCaps1;
   public int ddsCaps2;
   public int ddsCaps3;
   public int ddsCaps4;
   public int textureStage;
}; 

// This is the file object. Consisted of the header, and the data array.
public class DDSFile
{
   public DDSFormatDescriptor ddsfd;
   public byte [][] data;
} 

// This class actually load the dds file from this.
public class DDSHandler
{
   public DDSHandler()
   {
   }

   public int readIntSwapped(DataInputStream dataInputStream)
   {
       try
       {
           int a, b, c, d;
           a = dataInputStream.read();
           b = dataInputStream.read();
           c = dataInputStream.read();
           d = dataInputStream.read(); 

           return (((d & 0xff) << 24) | ((c & 0xff) << 16) |
               ((b & 0xff) << 8) | (a & 0xff));
       }
       catch (Exception e)
       {
           return (-1);
       }
   }

   public DDSFile load(String fileName)
   {
       try
       {
           File file = new File(fileName);
           FileInputStream in = new FileInputStream(file);
           DataInputStream din = new DataInputStream(in);

           DDSFormatDescriptor ddsfd = new DDSFormatDescriptor(); 

           ddsfd.signature[0] = (char) din.readUnsignedByte();
           ddsfd.signature[1] = (char) din.readUnsignedByte();
           ddsfd.signature[2] = (char) din.readUnsignedByte();
           ddsfd.signature[3] = (char) din.readUnsignedByte(); 

           ddsfd.size = readIntSwapped(din);
           ddsfd.flags = readIntSwapped(din);
           ddsfd.height = readIntSwapped(din);
           ddsfd.width = readIntSwapped(din);
           ddsfd.linearSize = readIntSwapped(din);
           ddsfd.depth = readIntSwapped(din);
           ddsfd.mipMapCount = readIntSwapped(din);
           ddsfd.alphaBitDepth = readIntSwapped(din);
           for (int i = 0; i < 10; i++)
           {
               ddsfd.reserved1[i] = readIntSwapped(din);
           }

           ddsfd.size2 = readIntSwapped(din);
           ddsfd.flags2 = readIntSwapped(din);
           for (int i = 0; i < 4; i++)
           {
               ddsfd.fourCC[i] = (char) din.readUnsignedByte();
           }
           ddsfd.rgbBitCount = readIntSwapped(din);
           ddsfd.rBitMask = readIntSwapped(din);
           ddsfd.gBitMask = readIntSwapped(din);
           ddsfd.bBitMask = readIntSwapped(din);
           ddsfd.rgbaAlphaBitMask = readIntSwapped(din);

           ddsfd.ddsCaps1 = readIntSwapped(din);
           ddsfd.ddsCaps2 = readIntSwapped(din);
           ddsfd.ddsCaps3 = readIntSwapped(din);
           ddsfd.ddsCaps4 = readIntSwapped(din);
           ddsfd.textureStage = readIntSwapped(din);

           DDSFile ddsFile = new DDSFile(ddsfd);

           int mipMapCount = ddsfd.mipMapCount; 

           ddsFile.data = new byte[mipMapCount][];
           int mipMapWidth = ddsfd.width;
           int mipMapHeight = ddsfd.height;

           for (int i = 0; i < mipMapCount; i++)
           {
               int size = (mipMapWidth / 4) * (mipMapHeight / 4) * 16;

               int bufferSize = size;
               if (size < 16)
               {
                   bufferSize = 16;
               }

               ddsFile.data[i] = new byte[bufferSize];

               for (int j = 0; j < bufferSize; j++)
               {
                   ddsFile.data[i][j] = (byte) din.readUnsignedByte(); 

                   // I use this line to verify that my data is correct.
                   System.out.println(ddsFile.data[i][j]);
               }

               mipMapWidth /= 2;
               mipMapHeight /= 2;
           }

           return (ddsFile);
       }
       catch (Exception e)
       {
           e.printStackTrace();
           return (null);
       }
   }

   public static void main(String[] args)
   {
       new DDSHandler().load("c:/test.dds");
   }
} 

// Finally, the code in the GLEventListener for loading the texture, and 
render it. 

   // Started with something else... 

       DDSFile ddsFile = 
ddsHandler.load("c:/data/skybox/bluedream_negx.dds"); 

       gl.glGenTextures(1, compressedTextureID);
       gl.glBindTexture(GL_TEXTURE_2D, compressedTextureID[0]);

       int width = ddsFile.getWidth();
       int height = ddsFile.getHeight();

       for (int i = 0; i < 1; i++)
       {
           gl.glCompressedTexImage2D(GL_TEXTURE_2D, 0,
               GL_COMPRESSED_RGBA_S3TC_DXT3_EXT,
               width, height, 0, ddsFile.data[i].length, ddsFile.data[i]); 

           width /= 2;
           height /= 2;
       } 

   // And then in the rendering loop...
       gl.glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
       gl.glLoadIdentity();

       gl.glTranslatef(-1.0f, 0.0f, -10.0f);
       gl.glColor3f(1.0f, 1.0f, 1.0f);
       gl.glEnable(gl.GL_TEXTURE_2D);
       gl.glPushMatrix();
           gl.glBindTexture(GL_TEXTURE_2D, compressedTextureID);
           gl.glBegin(GL_TRIANGLES);
               gl.glTexCoord2f(0.0f, 0.0f); gl.glVertex3f(0.0f, 0.0f, 0.0f);
               gl.glTexCoord2f(10.0f, 0.0f); gl.glVertex3f(1.0f, 0.0f, 
0.0f);
               gl.glTexCoord2f(0.0f, 10.0f); gl.glVertex3f(0.0f, 1.0f, 
0.0f);
           gl.glEnd();
       gl.glPopMatrix();

       glDrawable.repaint();

Re: [gl4java-usergroup] gl4java, jogl, and JFree-D

[Kenneth B. R. <kbr...@al...>]

> Sounds like some folks on Apple's java-dev list have had more
> success building JOGL on Mac OS X, but it still does not run
> there.  If any of you are working on this, you should
> coordinate with a couple of them.

Gerard Ziemski and I have been working on the OS X port of Jogl
anew for a few days; what's checked in to the Jogl source tree at
the moment does work with Apple's NSOpenGLView, but the GLCanvas
and GLJPanel aren't implemented. Gerard sent email this weekend
indicating the OS X GLCanvas implementation is working, so
hopefully this should be checked in soon, at which point the OS X
build should work pretty smoothly.

-Ken

Re: [gl4java-usergroup] Re: moving to jogl

[Kenneth B. R. <kbr...@al...>]

> Well I moved my app to jogl this week and all is working fine ;)
> 
> I didn't noticed that my app is faster but it is no slower !
> 
> It seems that it is not possible to control the framerate in the app as with GL4JAVA 
> 
> I think that it is an interesting option to avoid application
> "eating" all CPU ressources

We aimed to keep the initial Jogl animation API very minimal
because this can be done at the application level. However if you
decide to extend the Animator class to support this please let us
know.

-Ken

Re: [gl4java-usergroup] gl4java, jogl, and JFree-D

[Scott V. <vo...@nc...>]

OK, sorry for the noise.  I fixed my scene graph implementation.  I'm guessing from your silence that Java3d over JOGL or gl4java is not interesting to you... or your just not reading this over the weekend.  ;-)

Sounds like some folks on Apple's java-dev list have had more success building JOGL on Mac OS X, but it still does not run there.  If any of you are working on this, you should coordinate with a couple of them.

I still want to be able to build gl4java on Mac OS X, particularly now that I know JOGL is not ready for Mac OS X yet.  Anyone done this recently?

Scott


At 11:07 PM -0400 6/21/03, Scott Vorthmann wrote:
>I misstated the problem with GLFunc.glCallList... my scene graph implementation in terms of display lists is almost certainly naive.  I'm sure glCallList works, but I'm somehow compiling the lists at the wrong time, or calling the wrong lists.
>
>The symptom is this: I'm trying to render 6 different polyhedra in 6 different materials (colors), but when I render the Nth of the polyhedra, all N-1 previous polyhedra take on the new material.
>
>Anyway, I still need help with building JOGL, and review of my scene graph implementation.
>
>Thank you,
>
>Scott
>
>
>>Hi, all,
>>
>>I've been using a combination of gl4java and a slightly modified JFree-D, to achieve a measure of Java3d support on Mac OS X.  There are lots of features unimplemented in JFree-D, but the thing I miss most is the performance of a real Java3d implementation.  When I watch my app run on Windows, there's at least a 10X speedup during rotations of complex 3D objects.
>>
>>So, I rolled up my sleeves to see if I could fix JFree-D, or just code directly to gl4java or jogl.  Basically, I started reading up on OpenGL.
>>
>>I soon discovered display lists, and soon thereafter discovered that JFree-D largely ignores this optimization.  This means that where I could be sending one integer across the JNI boundary, I'm sending thousands of 4x4 double arrays!
>>
>>Now, I've cleaned up and reorganized JFree-D, and implemented the obvious mapping from a scene graph to display lists, using a visitor pattern.  (This allows me to encapsulate the gl4java dependency in one or two classes, rather than having it sprinkled throughout JFree-D.)
>>
>>However... GLFunc.glCallList does not seem to work.  Ever.  Nothing happens.
>>
>>I want to share my improved JFree-D with the world, so others can improve upon it and benefit from it.  (Particularly since the folks at Apple and Sun cannot seem to get over whatever their problem is to bring out a real Java3d on Mac OS X.)  But I can't go forward until I can get the DLs to work.
>>
>>I've tried building gl4java on Mac OS X, with little success... so I can't really determine if the problem is there (I doubt it) or in JFree-D (almost certainly).
>>
>>One way to check would be to build a jogl version of JFree-D, which will be fairly easy with my visitor encapsulation of the rendering.  However, I have been unable to get jogl to build on Mac OS X either.
>>
>>So, I need help building gl4java or jogl or both.  The benefit would be a new, optimized, free Java3d implementation.  I know most of you folks prefer to stay "close to the renderer", so you may not care.  But I'm hoping I'm wrong.
>>
>>It would also be great if someone could look over my gl4java calls in JFree-D, to point out whatever obvious thing I seem to have missed.  I can send a snapshot to anyone who wants to take a look.
>>
>>Thank you in advance,
>>
>>Scott
>>--
>>Scott Vorthmann
>>vo...@cs...
>>http://www.vorthmann.org/
>>
>>716 Carl Dr
>>Chapel Hill, NC 27516
>>
>>919 960 8583
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: INetU
>>Attention Web Developers & Consultants: Become An INetU Hosting Partner.
>>Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
>>INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
>>_______________________________________________
>>gl4java-usergroup mailing list
>>gl4...@li...
>>https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup

Re: [gl4java-usergroup] gl4java, jogl, and JFree-D

[Scott V. <vo...@nc...>]

I misstated the problem with GLFunc.glCallList... my scene graph implementation in terms of display lists is almost certainly naive.  I'm sure glCallList works, but I'm somehow compiling the lists at the wrong time, or calling the wrong lists.

The symptom is this: I'm trying to render 6 different polyhedra in 6 different materials (colors), but when I render the Nth of the polyhedra, all N-1 previous polyhedra take on the new material.

Anyway, I still need help with building JOGL, and review of my scene graph implementation.

Thank you,

Scott


>Hi, all,
>
>I've been using a combination of gl4java and a slightly modified JFree-D, to achieve a measure of Java3d support on Mac OS X.  There are lots of features unimplemented in JFree-D, but the thing I miss most is the performance of a real Java3d implementation.  When I watch my app run on Windows, there's at least a 10X speedup during rotations of complex 3D objects.
>
>So, I rolled up my sleeves to see if I could fix JFree-D, or just code directly to gl4java or jogl.  Basically, I started reading up on OpenGL.
>
>I soon discovered display lists, and soon thereafter discovered that JFree-D largely ignores this optimization.  This means that where I could be sending one integer across the JNI boundary, I'm sending thousands of 4x4 double arrays!
>
>Now, I've cleaned up and reorganized JFree-D, and implemented the obvious mapping from a scene graph to display lists, using a visitor pattern.  (This allows me to encapsulate the gl4java dependency in one or two classes, rather than having it sprinkled throughout JFree-D.)
>
>However... GLFunc.glCallList does not seem to work.  Ever.  Nothing happens.
>
>I want to share my improved JFree-D with the world, so others can improve upon it and benefit from it.  (Particularly since the folks at Apple and Sun cannot seem to get over whatever their problem is to bring out a real Java3d on Mac OS X.)  But I can't go forward until I can get the DLs to work.
>
>I've tried building gl4java on Mac OS X, with little success... so I can't really determine if the problem is there (I doubt it) or in JFree-D (almost certainly).
>
>One way to check would be to build a jogl version of JFree-D, which will be fairly easy with my visitor encapsulation of the rendering.  However, I have been unable to get jogl to build on Mac OS X either.
>
>So, I need help building gl4java or jogl or both.  The benefit would be a new, optimized, free Java3d implementation.  I know most of you folks prefer to stay "close to the renderer", so you may not care.  But I'm hoping I'm wrong.
>
>It would also be great if someone could look over my gl4java calls in JFree-D, to point out whatever obvious thing I seem to have missed.  I can send a snapshot to anyone who wants to take a look.
>
>Thank you in advance,
>
>Scott
>--
>Scott Vorthmann
>vo...@cs...
>http://www.vorthmann.org/
>
>716 Carl Dr
>Chapel Hill, NC 27516
>
>919 960 8583
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: INetU
>Attention Web Developers & Consultants: Become An INetU Hosting Partner.
>Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
>INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
>_______________________________________________
>gl4java-usergroup mailing list
>gl4...@li...
>https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup

[gl4java-usergroup] gl4java, jogl, and JFree-D

[Scott V. <vo...@cs...>]

Hi, all,

I've been using a combination of gl4java and a slightly modified JFree-D, to achieve a measure of Java3d support on Mac OS X.  There are lots of features unimplemented in JFree-D, but the thing I miss most is the performance of a real Java3d implementation.  When I watch my app run on Windows, there's at least a 10X speedup during rotations of complex 3D objects.

So, I rolled up my sleeves to see if I could fix JFree-D, or just code directly to gl4java or jogl.  Basically, I started reading up on OpenGL.

I soon discovered display lists, and soon thereafter discovered that JFree-D largely ignores this optimization.  This means that where I could be sending one integer across the JNI boundary, I'm sending thousands of 4x4 double arrays!

Now, I've cleaned up and reorganized JFree-D, and implemented the obvious mapping from a scene graph to display lists, using a visitor pattern.  (This allows me to encapsulate the gl4java dependency in one or two classes, rather than having it sprinkled throughout JFree-D.)

However... GLFunc.glCallList does not seem to work.  Ever.  Nothing happens.

I want to share my improved JFree-D with the world, so others can improve upon it and benefit from it.  (Particularly since the folks at Apple and Sun cannot seem to get over whatever their problem is to bring out a real Java3d on Mac OS X.)  But I can't go forward until I can get the DLs to work.

I've tried building gl4java on Mac OS X, with little success... so I can't really determine if the problem is there (I doubt it) or in JFree-D (almost certainly).

One way to check would be to build a jogl version of JFree-D, which will be fairly easy with my visitor encapsulation of the rendering.  However, I have been unable to get jogl to build on Mac OS X either.

So, I need help building gl4java or jogl or both.  The benefit would be a new, optimized, free Java3d implementation.  I know most of you folks prefer to stay "close to the renderer", so you may not care.  But I'm hoping I'm wrong.

It would also be great if someone could look over my gl4java calls in JFree-D, to point out whatever obvious thing I seem to have missed.  I can send a snapshot to anyone who wants to take a look.

Thank you in advance,

Scott
-- 
Scott Vorthmann
vo...@cs...
http://www.vorthmann.org/

716 Carl Dr
Chapel Hill, NC 27516

919 960 8583

[gl4java-usergroup] Re: moving to jogl

[Enrique D. <enr...@ya...>]

Well I moved my app to jogl this week and all is working fine ;)

I didn't noticed that my app is faster but it is no slower !

It seems that it is not possible to control the framerate in the app as with GL4JAVA 

I think that it is an interesting option to avoid application "eating" all CPU ressources

 


---------------------------------
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!

Re: [gl4java-usergroup] Java Binding Mess . . . or . . . Why GL4Java AND JoGL currently SUCK

[Pepijn V. E. <pep...@lu...>]

Kenneth B. Russell wrote:

> 
> Would you consider implementing this in Jogl?
> 

Sure, I'll try to take a look at the source code tonight...

Pepijn

> -Ken
> 
> 

Re: [gl4java-usergroup] Java Binding Mess . . . or . . . Why GL4Java AND JoGL currently SUCK

[Kenneth B. R. <kbr...@al...>]

> I implemented context creation/destruction in GL4Java by overriding 
> addNotify and removeNotify. The java api docs state that in these method 
> components are hooked up to and detached from their native peers 
> respectively.
> I haven't checked when exactly everything is created and destroyed in 
> jogl, so it might already be doing this. :)

No, we definitely aren't handling this correctly yet.

Would you consider implementing this in Jogl?

-Ken

Re: [gl4java-usergroup] Java Binding Mess . . . or . . . Why GL4Java AND JoGL currently SUCK

[Pepijn V. E. <pep...@lu...>]

> 
> I think we might need to override something like dispose() in
> GLCanvas to get earlier notifications that the component has been
> removed from the hierarchy; I'll try to ask the AWT developers
> about this this week. (I work on the JVM and am not an AWT
> expert.)
> 

I implemented context creation/destruction in GL4Java by overriding 
addNotify and removeNotify. The java api docs state that in these method 
components are hooked up to and detached from their native peers 
respectively.
I haven't checked when exactly everything is created and destroyed in 
jogl, so it might already be doing this. :)

Pepijn

RE: [gl4java-usergroup] moving to jogl

[Combe, C. <C....@na...>]

b.t.w., i didn't mean to imply that the existence of this bug was a sign of
incompetence on behalf of the developers - just that I could try to fix it
myself even though I'm not the most experienced of programmers. In general I
would like to be more involved with the developemnt of the java/Gl binding
but tend to think that not knowing C would limit my usefulness. 
I will look at the area of code you highlighted when I start working with
JoGL,
cheers,
colin
-----Original Message-----
From: Kenneth B. Russell
To: Colin Combe
Cc: gl4...@li...
Sent: 6/16/03 4:01 PM
Subject: Re: [gl4java-usergroup] moving to jogl


> However, does the fact that :
> >The OpenGL context handling and 
> >interaction with the window system has been
> >completely redesigned and is in fact now written in Java instead
> >of in C. 
> mean that a reasonably competent java programmer might be able to fix
it? 
> What exactly is the problem?

I just checked the source code and it looks like we planned ahead
for this but just haven't stress tested it yet.

See roughly line 156 in
src/net/java/games/jogl/impl/windows/WindowsOnscreenGLContext.java
and roughly line 142 in
src/net/java/games/jogl/impl/x11/X11OnscreenGLContext.java, in
particular the checking for JAWT_LOCK_SURFACE_CHANGED. I don't
know whether that will be sufficient; in particular I think if a
canvas is being animated and it's removed from its parent it will
probably start returning JAWT_LOCK_ERROR, which will cause the
GLException a few lines earlier to be thrown.

-Ken

Re: [gl4java-usergroup] Java Binding Mess . . . or . . . Why GL4Java AND JoGL currently SUCK

[Kenneth B. R. <kbr...@al...>]

> There are 2 killer bugs right now for the use of GL4Java in medical
> imaging software.  They are, the inability to safely add and remove
> GL enabled canvases from a parent, and the inability to work on
> multiple heterogeneous monitors.  These are not problems in the java
> side code of GL4Java,
> the problem is in the actual JVM source code.  My company has the
> source code to the JRE.  We can compare it to the SWT source.  We
> even see the problem.  My boss is done waiting though.  So we made
> our own binding under SWT.

Could you please provide more details on where exactly you think
the bug is in the JRE?

> JoGL STILL has the add and remove bug.  Although to their credit,
> the code is FAR more clean, and GlueGen is something I think EVERY
> developer should be looking at right now, and not just for GL.  I did,
> however, have hopes that since Ken was one of the developers the
> internal machinery at Sun or JavaSoft would fix those problems.  They
> did not.

We didn't have time to stress test this before JavaOne. Now that
that rush is over we can do so. As I've mentioned in another mail
to this mailing list, there was already some amount of planning
ahead in the Jogl sources for this case; see roughly line 156 in
src/net/java/games/jogl/impl/windows/WindowsOnscreenGLContext.java
and roughly line 142 in
src/net/java/games/jogl/impl/x11/X11OnscreenGLContext.java, in
particular the checking for JAWT_LOCK_SURFACE_CHANGED. I don't
know whether that will be sufficient; in particular I think if a
canvas is being animated and it's removed from its parent it will
probably start returning JAWT_LOCK_ERROR, which will cause the
GLException a few lines earlier to be thrown.

I think we might need to override something like dispose() in
GLCanvas to get earlier notifications that the component has been
removed from the hierarchy; I'll try to ask the AWT developers
about this this week. (I work on the JVM and am not an AWT
expert.)

> I hope JoGL or GL4Java will rectify this insane situation in
> the very near future.  If you need my help or our binding code,
> just let me know

Yes, please do help us out. Jogl is a community effort which is
why it's open source on a collaborative site. If you can provide
a test case illustrating an error, help fix the bug, show where
in the JRE any underlying bug is, or any or all of the above,
we'd appreciate your help.

-Ken

Re: [gl4java-usergroup] moving to jogl

[Kenneth B. R. <kbr...@al...>]

> However, does the fact that :
> >The OpenGL context handling and 
> >interaction with the window system has been
> >completely redesigned and is in fact now written in Java instead
> >of in C. 
> mean that a reasonably competent java programmer might be able to fix it? 
> What exactly is the problem?

I just checked the source code and it looks like we planned ahead
for this but just haven't stress tested it yet.

See roughly line 156 in
src/net/java/games/jogl/impl/windows/WindowsOnscreenGLContext.java
and roughly line 142 in
src/net/java/games/jogl/impl/x11/X11OnscreenGLContext.java, in
particular the checking for JAWT_LOCK_SURFACE_CHANGED. I don't
know whether that will be sufficient; in particular I think if a
canvas is being animated and it's removed from its parent it will
probably start returning JAWT_LOCK_ERROR, which will cause the
GLException a few lines earlier to be thrown.

-Ken

RE : [gl4java-usergroup] Java Binding Mess . . . or . . . Why GL4Java AND JoGL currently SUCK

[<aco...@mi...>]

Hi Tobias,

You should fill an issue at
http://jogl.dev.java.net/servlets/ProjectIssues
requesting for that multiple canvas add/remove feature. And if you have
an idea of were the problem is located in the JRE, explain it so it may
speed up the fix !

Alban Cousini=E9
Mind2Machine



-----Message d'origine-----
De=A0: gl4...@li...
[mailto:gl4...@li...] De la part de
Tobias L. George
Envoy=E9=A0: lundi 16 juin 2003 15:32
=C0=A0: gl4...@li...
Objet=A0: [gl4java-usergroup] Java Binding Mess . . . or . . . Why =
GL4Java
AND JoGL currently SUCK

Sorry for the inflammatory subject line.

However, for a while now I have been working with OpenGL from
the Java platform.  To keep a long story short, because of the bugs,
my company's direction has turned to making a FAR more stable
binding under SWT.  That is where I've been for the past two weeks
Pepjin.

Why ?

Read on . . .

There are 2 killer bugs right now for the use of GL4Java in medical
imaging software.  They are, the inability to safely add and remove
GL enabled canvases from a parent, and the inability to work on
multiple heterogeneous monitors.  These are not problems in the java
side code of GL4Java,
the problem is in the actual JVM source code.  My company has the
source code to the JRE.  We can compare it to the SWT source.  We
even see the problem.  My boss is done waiting though.  So we made
our own binding under SWT.

Just when I finished that binding and got it debugged and going through
QA in house, along came JoGL.  I thought, GREAT let me integrate
this and I won't have to support our own binding.  FALSE.  It was the
Almighty toying with me again.  He likes to do that from time to time.

JoGL STILL has the add and remove bug.  Although to their credit,
the code is FAR more clean, and GlueGen is something I think EVERY
developer should be looking at right now, and not just for GL.  I did,
however, have hopes that since Ken was one of the developers the
internal machinery at Sun or JavaSoft would fix those problems.  They
did not.

What you need to understand about MY industry is that it is regulated
by the FDA.  That JoGL or GL4Java kind of work is not good enough.
My applications have to work completely.  Now working completely is
something that can be done with Java, I know, because we're doing it
with SWT.  So why does Sun not just fix these problems and let me
concentrate on my imaging and pathology algorithms.  I am a
mathemetician
by training, and we are notoriously lazy.  So anything that obliges us=20
to work
engenders no end of ill-will in our minds.  I have often told my niece
to
remember in her nightly prayers to beseech the Almighty to consign those
at Sun responsible for this situation to the darkest depths of
Perdition.

I'm sorry, I'm black, when we get a little worked up, we get poetic, but
I think you all know the point I'm making.  Working in GL under Java
should NOT be this frustrating.  And you should DEFINITELY NOT
have to make your own bindings.  I hope JoGL or GL4Java will rectify
this insane situation in the very near future.  If you need my help or
our
binding code, just let me know, but my since is that the last major bugs
will have to be addressed from JavaSoft's side to be done elegantly.  I
am going to integrate GlueGen into the SWT binding however, and some
of the little coding tricks for Cg will be usefull here too.  But=20
overall it is
too early for me to integrate an open source binding with our product.

In closing, I'd like to say that my little open source odyssey has been
enjoyable despite the frustrations.  It is good to see that open source
GL
bindings are at least moving forward in terms of code quality and
community
interest.  I do believe the remaining bugs will be addressed by Sun, but

they
will not be addressed on my time frame, and so I will reconsider
integration
with an open source package later.  In the end though, my company
will be using an open source binding because the quality will be there=20
in the
future.  So this e-mail should not be taken as a knock against that.
The
quality is there right now, the remaining bugs are JRE bugs in my
opinion.
They just happen to be bugs that won't pass QA here.  So you guys are
doing
a great job, and I hope to be integrating with you sooner rather than
later.



                                                Peace, Love, and Hair
Grease

                                                               -TOBY



-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
_______________________________________________
gl4java-usergroup mailing list
gl4...@li...
https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup

[gl4java-usergroup] Java Binding Mess . . . or . . . Why GL4Java AND JoGL currently SUCK

[Tobias L. G. <tg...@ul...>]

Sorry for the inflammatory subject line.

However, for a while now I have been working with OpenGL from
the Java platform.  To keep a long story short, because of the bugs,
my company's direction has turned to making a FAR more stable
binding under SWT.  That is where I've been for the past two weeks
Pepjin.

Why ?

Read on . . .

There are 2 killer bugs right now for the use of GL4Java in medical
imaging software.  They are, the inability to safely add and remove
GL enabled canvases from a parent, and the inability to work on
multiple heterogeneous monitors.  These are not problems in the java
side code of GL4Java,
the problem is in the actual JVM source code.  My company has the
source code to the JRE.  We can compare it to the SWT source.  We
even see the problem.  My boss is done waiting though.  So we made
our own binding under SWT.

Just when I finished that binding and got it debugged and going through
QA in house, along came JoGL.  I thought, GREAT let me integrate
this and I won't have to support our own binding.  FALSE.  It was the
Almighty toying with me again.  He likes to do that from time to time.

JoGL STILL has the add and remove bug.  Although to their credit,
the code is FAR more clean, and GlueGen is something I think EVERY
developer should be looking at right now, and not just for GL.  I did,
however, have hopes that since Ken was one of the developers the
internal machinery at Sun or JavaSoft would fix those problems.  They
did not.

What you need to understand about MY industry is that it is regulated
by the FDA.  That JoGL or GL4Java kind of work is not good enough.
My applications have to work completely.  Now working completely is
something that can be done with Java, I know, because we're doing it
with SWT.  So why does Sun not just fix these problems and let me
concentrate on my imaging and pathology algorithms.  I am a mathemetician
by training, and we are notoriously lazy.  So anything that obliges us 
to work
engenders no end of ill-will in our minds.  I have often told my niece to
remember in her nightly prayers to beseech the Almighty to consign those
at Sun responsible for this situation to the darkest depths of Perdition.

I'm sorry, I'm black, when we get a little worked up, we get poetic, but
I think you all know the point I'm making.  Working in GL under Java
should NOT be this frustrating.  And you should DEFINITELY NOT
have to make your own bindings.  I hope JoGL or GL4Java will rectify
this insane situation in the very near future.  If you need my help or our
binding code, just let me know, but my since is that the last major bugs
will have to be addressed from JavaSoft's side to be done elegantly.  I
am going to integrate GlueGen into the SWT binding however, and some
of the little coding tricks for Cg will be usefull here too.  But 
overall it is
too early for me to integrate an open source binding with our product.

In closing, I'd like to say that my little open source odyssey has been
enjoyable despite the frustrations.  It is good to see that open source GL
bindings are at least moving forward in terms of code quality and community
interest.  I do believe the remaining bugs will be addressed by Sun, but 
they
will not be addressed on my time frame, and so I will reconsider integration
with an open source package later.  In the end though, my company
will be using an open source binding because the quality will be there 
in the
future.  So this e-mail should not be taken as a knock against that.  The
quality is there right now, the remaining bugs are JRE bugs in my opinion.
They just happen to be bugs that won't pass QA here.  So you guys are doing
a great job, and I hope to be integrating with you sooner rather than later.



                                                Peace, Love, and Hair Grease

                                                               -TOBY

RE: [gl4java-usergroup] moving to jogl

[Combe, C. <C....@na...>]

hi,
first of all, thanks to all the people who put so much time and effort into
providing a java/openGL binding. Without it i might end up being forced into
learning a language other than Java ;)

secondly, Ken Russell wrote:
> There are still some features missing like correct
>support of adding/removing GLCanvas objects from a frame over and
>over again, but this should be a relatively small addition and
>I'm hopeful that it can be done without changes to the public
>API.
oh no, not again :)
this caused me quite a lot of grief when using gl4java.
However, does the fact that :
>The OpenGL context handling and 
>interaction with the window system has been
>completely redesigned and is in fact now written in Java instead
>of in C. 
mean that a reasonably competent java programmer might be able to fix it? 
What exactly is the problem?
cheers,
colin