Problem displaying a triangle array/mesh

[elect]

Hi all,

I am a beginner in JOGL, I spent almost 2 full days looking online tutorial, examples, etc..

The problem is that there is not so much material about JOGL, and among the results many stuff is outdated, for other programming languages and so on...

Well, I need to display a mesh/array of triangles

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27   28   29   30   31   32   33   34   35   36   37   38   39   40   41   42   43   44   45   46   47   48   49   50   51   52   53   54   55   56   57   58   59   60   61   62   63   64   65   66   67   68   69   70   71   72   73   74   75   76   77   78   79   80   81   82   83   84   85   86   87   88   89   90   91   92

public class CudaImplementation implements GLEventListener{          public static void main(String[] args) throws IOException{                GLProfile profile = GLProfile.get(GLProfile.GL3);                final GLCapabilities capabilities = new GLCapabilities(profile);                GLCanvas canvas = new GLCanvas(capabilities);                        SwingUtilities.invokeLater(new Runnable() {                            @Override                public void run() {                     new CudaImplementation(capabilities);                }                }); } public CudaImplementation(GLCapabilities capabilities) {             // Initialize the GL component and the animator        GLCanvas glComponent = new GLCanvas((GLCapabilitiesImmutable)capabilities);         glComponent.setFocusable(true);         glComponent.addGLEventListener(this);         // Create the main frame        frame = new JFrame("JCuda / JOGL interaction sample");         frame.addWindowListener(new WindowAdapter()         {             @Override             public void windowClosing(WindowEvent e)             {                 runExit();             }         });         frame.setLayout(new BorderLayout());         glComponent.setPreferredSize(new Dimension(800, 800));         frame.add(glComponent, BorderLayout.CENTER);         frame.pack();         frame.setVisible(true);         glComponent.requestFocus();     @Override     public void init(GLAutoDrawable gLAutoDrawable) {                 // Perform the default GL initialization        GL3 gl = gLAutoDrawable.getGL().getGL3();         gl.setSwapInterval(0);         gl.glEnable(GL3.GL_DEPTH_TEST);         gl.glClearColor(0.0f, 0.0f, 0.0f, 1.0f);         //setupView(GLAutoDrawable);         // Create the VBO containing the vertex data        initVBO(gl);     }     @Override     public void display(GLAutoDrawable gLAutoDrawable) {         GL3 gl = gLAutoDrawable.getGL().getGL3();         gl.glBindBuffer(GL.GL_ARRAY_BUFFER, vertexArray);         gl.glEnableClientState(GL3.GL_VERTEX_ARRAY_BINDING);         gl.glDrawArrays(GL.GL_TRIANGLES, 0, array.size());     } FloatBuffer data = Buffers.newDirectFloatBuffer(size);         private void initVBO(GL3 gl)     {         int buffer[] = new int[1];         // Create the vertex buffer object        gl.glGenBuffers(1, IntBuffer.wrap(buffer));         vertexArray = buffer[0];         // Initialize the vertex buffer object        gl.glBindBuffer(GL.GL_ARRAY_BUFFER, vertexArray);                 for(Triangle t : array) {             data.put(t.x1);             data.put(t.y1);             data.put(t.z1);             data.put(t.x2);             data.put(t.y2);             data.put(t.z2);             data.put(t.x3);             data.put(t.y3);             data.put(t.z3);         }         data.rewind();                 // Fill the vertex buffer object        gl.glBufferData(GL.GL_ARRAY_BUFFER, size * Sizeof.FLOAT, data, GL.GL_STATIC_DRAW);         // data are in the GPU, data is no longer necessary        data = null; }

The problem is that I dont see anything, I guess the main reasons could be:

- no color info in the Vertex Buffer Array (but when I used the glBegin/End it was displaying them white)
- shall I need an animator?
- shall I need to specify the view? (there is not a default one?)
- OpenGL does not know which data, or better the memory layout, of the vertex buffer array data.

In OpenGL 2.x you just write

glVertexPointer(3,GL_FLOAT,16,0);

if you have:

- 3 coordinates
- float type
- 16 the total length for triangle (vertex+color)
- 0 the offset where the 3 coordinates start in this 16 Bytes

But in GL3 I dont have anything like that




Please I would need some help from people more skilled than me (and it is not difficult >.>)

[elect]

Just discovered that in GL3 a VAO is mandatory although it seems superflous...

But unfortunately it still doesnt work..

[theagentd]

 - For OpenGL3, you need a shader. There is no fixed functionality if you haven't requested the compatibility profile (which defeats the purpose of OpenGL 3 in the first place IMO).
 - Use .flip(), not rewind() (Just make this a habit...).
 - You aren't using your vertex array object. Just creating one without configuring it is about as productive as creating a texture handle and not allocating it. You need to setup your shader attribute bindings in your vertex array object, so that OpenGL knows what data to put in the shader variables. Obviously, you also have no shader. >_>

If you're a beginner, drop OGL3 immediately. You don't want to dive into shaders, buffer objects and vertex array objects when you're a newbie. Look up some old tutorials on the Internet (preferably does using glBegin()-glEnd()) to get a basic knowledge of how it works. OpenGL 3 has removed 99% of the convenience functions that were in the previous OpenGL versions, forcing you to do everything manually. This is a lot more powerful as you can do everything you could with the earlier OpenGL versions but with a lot more flexibility and better performance, but it takes hundreds of lines of code just to get a triangle on the screen.

PS: I also recommend LWJGL. It is more similar to standard C/C++ OpenGL so it's easier to port other tutorials to Java with it.

EDIT2: To answer your color question: There is no built-in color variable in OpenGL 3. If you want a color, you create your own shader attribute for it and store bindings between data and variables in your vertex array buffer. When you then call glDrawArrays(...) or whatever, the data is loaded into the shader and you can treat it as whatever you want (in this case a color). This is what OpenGL has always done for you since almost everything needs a color, but now you have to do it manually.

Games published by our own members! Check 'em out!

[elect]

If you're a beginner, drop OGL3 immediately. You don't want to dive into shaders, buffer objects and vertex array objects when you're a newbie. Look up some old tutorials on the Internet (preferably does using glBegin()-glEnd()) to get a basic knowledge of how it works. OpenGL 3 has removed 99% of the convenience functions that were in the previous OpenGL versions, forcing you to do everything manually. This is a lot more powerful as you can do everything you could with the earlier OpenGL versions but with a lot more flexibility and better performance, but it takes hundreds of lines of code just to get a triangle on the screen.

This is something that I should have known before, but I never found, thank!

However, I already did many tutorials with the glBegin/End and since I have milions of triangles I need to implement some fast method, and I read that VBO is the solution.. is it right?

[elect]

PS: I also recommend LWJGL. It is more similar to standard C/C++ OpenGL so it's easier to port other tutorials to Java with it.

However I think I am forced to use JOGL, since I need also the binding for Cuda

[theagentd]

If you're a beginner, drop OGL3 immediately. You don't want to dive into shaders, buffer objects and vertex array objects when you're a newbie. Look up some old tutorials on the Internet (preferably does using glBegin()-glEnd()) to get a basic knowledge of how it works. OpenGL 3 has removed 99% of the convenience functions that were in the previous OpenGL versions, forcing you to do everything manually. This is a lot more powerful as you can do everything you could with the earlier OpenGL versions but with a lot more flexibility and better performance, but it takes hundreds of lines of code just to get a triangle on the screen.

This is something that I should have known before, but I never found, thank!

However, I already did many tutorials with the glBegin/End and since I have milions of triangles I need to implement some fast method, and I read that VBO is the solution.. is it right?

The real problem is interacting too much with the graphics driver, limiting the performance you can get out of your graphics card by the very high CPU overhead of actually issuing commands. glBegin()-glEnd() is especially tricky to implement on the driver side, as there are so many different attributes that have to be buffered and sent to the GPU. So first it's slow to handle each vertex, then you need an expensive native call to the OpenGL call to submit it to the driver, which then tries store the vertex data as efficiently as possible.

The least intrusive way of implementing this is display lists. Instead of calling all these OpenGL commands, you create a display list which contain those commands and simply tell the driver to run the display list each frame. This allows the driver to optimize the vertex data storing and reduces the number of OpenGL calls to a single call. It's also very simple to implement.

Let's say you have the following code. I've stripped out all GL.blah to only include the raw OpenGL commands. Some command may be slightly different in JOGL though.

1   2   3   4   5   6   7   8   9

//Draw a red triangle public void renderTriangle(){     glColor3f(1, 0, 0);     glBegin(GL_TRIANGLES);     glVertex2f(0, 0);     glVertex2f(1, 0);     glVertex2f(0, 1);     glEnd(); }

Let's say these OpenGL commands do not change between frames. We could optimize this to use a display list instead:

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15

//When initializing the game: //Save this ID int listID = glGenLists(1); //This call may look different in JOGL (this is from LWJGL) glNewList(listID, GL_COMPILE); //This is like glBegin() but for display lists //Commands between glNewList(...) and glEndList() will not be processed immediately. Instead they will be stored in the display list renderTriangle(); glEndList(); //This is like glEnd() for display lists //When rendering: glCallList(listID); //Equal to calling renderTriangle() directly.

This is obviously most effective when rendering big meshes. The above example would not see much of a performance gain, as it's only 3 vertices. We would however see a noticeable performance if we called this method many times.

At first it might seem like this can only be used for static geometry, but it can be moved around in any way you want by modifying the transformation matrix between calls. For example, to draw two triangles at two different locations, we can glTranslate to the first position, call the display list, restore the matrix and glTranslate to a new position and call the display list again. Note that some special calls can not be stored in a display list. Sadly, display lists have been deprecated in OpenGL 3.0

There are other ways of drawing things faster. You can also use vertex arrays (not the same as vertex array objects). They are very easy to use too, but requires us to completely rewrite the above triangle drawing code:

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26

//When initializing the game: FloatBuffer vertexData = BufferUtils.createFloatBuffer(3*2); //If you allocate it manually, make sure it has the correct byte order! vertexData.put(new float[]{     0, 0,     1, 0,     0, 1 }); vertexData.flip(); //DO NOT FORGET THIS!!!!!!!! //When rendering: glColor3f(1, 0, 0); glVertexPointer(2, 0, vertexData); //2 means that we have two floats per vertex (glVertex2f() <- that 2) //0 means that the data is tightly packed, so no data should be skipped //vertexData contains the coordinates we would've sent with glVertex2f() in a FloatBuffer. glEnableClientState(GL_VERTEX_ARRAY); //This tells OpenGL to read data from vertexData instead of the last call to glVertexXX(...). //For example, we have not enabled GL_COLOR_ARRAY, so we can use glColor3f to set all vertices to red above. glDrawArrays(GL_TRIANGLES, 0, 3); //GL_TRIANGLES specifies the primitive type //0 is the first vertex to process. //3 is the number of vertices to process, NOT THE NUMBER OF PRIMITIVES.

I may have forgotten something as I haven't used many of these pre-OpenGL 3 ways of rendering in a while, and I wrote all this in the post (untested), so beware of mistakes from me... xd

[elect]

Thanks theagentd, you are surprisingly exhaustive! 

I would decide to use then the Vertex Array...

However I found that the BufferUtils.createFloatBuffer cannot be found and I am using then the GLBuffers.newDirectIntBuffer (http://stackoverflow.com/questions/3746759/java-bufferutil)

I will let you know, however thanks!

[theagentd]

Thanks theagentd, you are surprisingly exhaustive! 

I would decide to use then the Vertex Array...

However I found that the BufferUtils.createFloatBuffer cannot be found and I am using then the GLBuffers.newDirectIntBuffer (http://stackoverflow.com/questions/3746759/java-bufferutil)

I will let you know, however thanks!

That would be the equivalent class in JOGL, but don't create an IntBuffer! Create a FloatBuffer! =S

The only performance problem with vertex arrays is that you send the vertex data from RAM to the GPU each frame. This is where vertex buffer objects (VBOs) come in. With them you can store the vertex data in the GPU's video memory (VRAM), and tell your draw functions to read from it instead. However, you have 4GBs per second in bandwidth to play with, equaling about 68MBs of data per frame at 60 FPS, so you don't really have to worry about it unless you're making Crysis.

Graphics is my interest, so I just find it fun to help people when it comes to OpenGL. =D

[elect]

That would be the equivalent class in JOGL, but don't create an IntBuffer! Create a FloatBuffer! =S

Yeah sure :p

The only performance problem with vertex arrays is that you send the vertex data from RAM to the GPU each frame. This is where vertex buffer objects (VBOs) come in. With them you can store the vertex data in the GPU's video memory (VRAM), and tell your draw functions to read from it instead.

Ah, that's why, I really wanted I would have met u before ^^

However, you have 4GBs per second in bandwidth to play with, equaling about 68MBs of data per frame at 60 FPS, so you don't really have to worry about it unless you're making Crysis.

Not yet baby 

xD


Btw, regarding the glVertexPointer, I have three ones:

public void glVertexPointer(GLArrayData glad)

public void glVertexPointer(int i, int i1, int i2, Buffer buffer)

public void glVertexPointer(int i, int i1, int i2, long l)


Which should I use?

( http://download.java.net/media/jogl/jogl-2.x-docs/javax/media/opengl/fixedfunc/GLPointerFunc.html )

I guess the second one since I have a Buffer pointer..

Something like this:

1	gl.glVertexPointer(size, GL_FLOAT, 0, data);

But damn, GL_FLOAT cannot be found >.>

Edit: I was joking ^^

GL.GL_FLOAT

[elect]

two things

- vertexData = GLBuffers.newDirectFloatBuffer(triangleNumber*3*3); fails when there are 2 milions of (float 3d) triangles, out of memory
- how can I do if I want to add color? I need a normal vector right?

Should I do something like this:

1   2   3   4   5   6   7   8   9   10   11

normalData = GLBuffers.newDirectFloatBuffer(triangleNumber*3);             for(int i=0; i<triangleNumber; i++) {           Triangle tmp = triangleArray.get(i);           normalData.put(new float[]{tmp.nx, tmp.ny, tmp.nz});       }       normalData.flip();         gl.glEnableClientState(GL2.GL_NORMAL_ARRAY);         gl.glNormalPointer(GL.GL_FLOAT, 0, normalData);

?

Games published by our own members! Check 'em out!

[Orangy Tang]

- vertexData = GLBuffers.newDirectFloatBuffer(triangleNumber*3*3); fails when there are 2 milions of (float 3d) triangles, out of memory

Direct memory is a different pool from the regular JVM heap, and IIRC defaults to 64Mb. Two million triangles would come to about 68Mb, so that's probably why it's failing (I assume you get some kind of out-of-memory exception?).

You can increase the amount of direct memory with a vm arg. Try something like:

1	-XX:MaxDirectMemorySize=256M

[elect]

Two million triangles would come to about 68Mb, so that's probably why it's failing (I assume you get some kind of out-of-memory exception?).

Init
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError
   at sun.misc.Unsafe.allocateMemory(Native Method)
Reshape
Reshape
Display
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6b2efd37, pid=3872, tid=5584
#
# JRE version: 6.0_18-b07
# Java VM: Java HotSpot(TM) Client VM (16.0-b13 mixed mode windows-x86 )
# Problematic frame:
# C  0x6b2efd37
#
# An error report file with more information is saved as:
# H:\Dokumente und Einstellungen\gbarbieri\Eigene Dateien\NetBeansProjects\JOpenGL with Cuda\hs_err_pid3872.log
   at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:99)
   at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:288)
   at com.jogamp.common.nio.Buffers.newDirectByteBuffer(Buffers.java:69)
   at com.jogamp.common.nio.Buffers.newDirectFloatBuffer(Buffers.java:111)
   at Viewer.initVertexArray(Viewer.java:179)
   at Viewer.init(Viewer.java:119)
   at jogamp.opengl.GLDrawableHelper.init(GLDrawableHelper.java:135)
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
   at jogamp.opengl.GLDrawableHelper.init(GLDrawableHelper.java:154)
   at javax.media.opengl.awt.GLCanvas$InitAction.run(GLCanvas.java:886)
   at jogamp.opengl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:379)
   at javax.media.opengl.awt.GLCanvas.maybeDoSingleThreadedWorkaround(GLCanvas.java:799)
   at javax.media.opengl.awt.GLCanvas.display(GLCanvas.java:400)
   at javax.media.opengl.awt.GLCanvas.paint(GLCanvas.java:499)
   at sun.awt.RepaintArea.paintComponent(RepaintArea.java:248)
   at sun.awt.RepaintArea.paint(RepaintArea.java:224)
   at sun.awt.windows.WComponentPeer.handleEvent(WComponentPeer.java:310)java.lang.OutOfMemoryError

   at java.awt.Component.dispatchEventImpl(Component.java:4706)
   at java.awt.Component.dispatchEvent(Component.java:4460)
   at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
   at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
   at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
Java Result: 1

and the at Viewer.initVertexArray(Viewer.java:179) refers to the line of code:

1	vertexData = GLBuffers.newDirectFloatBuffer(triangleNumber*3*3);

I added in the run Option in Netbeans, after -Xmx1500m space -XX:MaxDirectMemorySize=256m (i tried 256M and 256m) but it still fails (also 512m)

these should be "safe" values since 2M(triangle)*3(points)*3(coordinates)*4(Bytes) = 72M/(1024*1024) = 68mb (as you said)

Any other idea?

[theagentd]

@glVertexPointer
The first one would be a JOGL specific one. You'll have to read up on that one by yourself, as I have no idea how it works. The second one is the correct one. It takes a size, type, stride and Buffer object.

size is the number of dimensions (the number you would've used in glVertex*f). THIS IS NOT THE SIZE OF THE BUFFER!!!
type is what format your data is. In your case, that is GL_FLOAT.
stride is how far to jump after reading a value in bytes. With 2 floats per vertex, that'd be 8 (2 x 4 byte floats), but setting it to 0 allows OpenGL to calculate it itself.
the buffer is the data you want to send.

The last one is for specifying a pointer position inside the currently bound buffer, and therefore does not take a Buffer object, but a start index instead.

@adding color:
Normals have nothing to do with color. They define the surface normal for lighting, and unless you use 3D and the built-in lighting of OpenGL (which is not very interesting IMO) you don't need to specify normals. To get colors per vertex, just use glColorPointer() and GL_COLOR_ARRAY. >_>

@buffer size:
You're pushing it if you want to draw 2 000 000 unique triangles on the screen. Crysis 1 was floating at around 1.0 to 1.2 million triangles if I recall correctly, and you're not gonna want to stream that much data to the GPU each frame in the first place. You're actually getting close to the bandwidth of the PCI Express bus, which also has to transmit all the OpenGL commands that are executed on the GPU. Simply put, if you need that much memory, you're doing it wrong.

[elect]

@glVertexPointer
The first one would be a JOGL specific one. You'll have to read up on that one by yourself, as I have no idea how it works. The second one is the correct one. It takes a size, type, stride and Buffer object.

size is the number of dimensions (the number you would've used in glVertex*f). THIS IS NOT THE SIZE OF THE BUFFER!!!
type is what format your data is. In your case, that is GL_FLOAT.
stride is how far to jump after reading a value in bytes. With 2 floats per vertex, that'd be 8 (2 x 4 byte floats), but setting it to 0 allows OpenGL to calculate it itself.
the buffer is the data you want to send.

The last one is for specifying a pointer position inside the currently bound buffer, and therefore does not take a Buffer object, but a start index instead.

Sorry for not explicitely saying, but I solved :p

I copy here, maybe it could be useful for other newbie like me ^^

1   2

gl.glVertexPointer(3, GL.GL_FLOAT, 0, vertexData); gl.glDrawArrays(GL.GL_TRIANGLES, 0, triangleNumber*3);

@adding color:
Normals have nothing to do with color. They define the surface normal for lighting, and unless you use 3D and the built-in lighting of OpenGL (which is not very interesting IMO) you don't need to specify normals. To get colors per vertex, just use glColorPointer() and GL_COLOR_ARRAY. >_>

Ah ok, I would like to somehow perform a (very basic) render, because now I see my model like all white and I would like to see some deep, I guess the normal vectors are needed for this... the graphic cards should calculate somehow the difference between my view vector and the normal vector of each triangle and them color them regarding this difference, the more is the inclination, the darker the triangles should be...

Can I do with something like this:

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23

public void display(GLAutoDrawable glad) { .... initLight(gl); ... } public void initLight(GL gl) {         // Prepare light parameters.        float SHINE_ALL_DIRECTIONS = 1;         float[] lightPos = {1, 1, 2f, SHINE_ALL_DIRECTIONS};         float[] lightColorAmbient = {0.2f, 0.2f, 0.2f, 1f};         float[] lightColorSpecular = {0.8f, 0.8f, 0.8f, 1f};         // Set light parameters.        gl.glLightfv(GL.GL_LIGHT1, GL.GL_POSITION, lightPos, 0);         gl.glLightfv(GL.GL_LIGHT1, GL.GL_AMBIENT, lightColorAmbient, 0);         gl.glLightfv(GL.GL_LIGHT1, GL.GL_SPECULAR, lightColorSpecular, 0);         // Enable lighting in GL.        gl.glEnable(GL.GL_LIGHT1);         gl.glEnable(GL.GL_LIGHTING);     }

?

@buffer size:
You're pushing it if you want to draw 2 000 000 unique triangles on the screen. Crysis 1 was floating at around 1.0 to 1.2 million triangles if I recall correctly, and you're not gonna want to stream that much data to the GPU each frame in the first place. You're actually getting close to the bandwidth of the PCI Express bus, which also has to transmit all the OpenGL commands that are executed on the GPU. Simply put, if you need that much memory, you're doing it wrong.

The problem is that I have to visualize 3d models (based on triangles) and some of them reach 5M of triangles...

I guess the VBO should be the solution for these cases?

[Orangy Tang]

I guess it's also possible that while you have >68Mb of direct memory free, there's not 68Mb in a continuous chunk. Have you tried carving it up into more manageable chunks of (say) 8Mb each?

[theagentd]

You think you messed up the memory commands. They are VM-commands, not run commands. Run commands end up in your main(String[] args). Put -Xmx1500m space -XX:MaxDirectMemorySize=256m in the VM command field instead.

And what the heck is SHINE_ALL_DIRECTIONS? >_>

[gouessej]

Just discovered that in GL3 a VAO is mandatory although it seems superflous...

But unfortunately it still doesnt work..

Why not using the default backward compatible profile? Generally, when using JOGL, we don't ask for a particular profile, we use getMaxFixedFunc() or getMaxProgrammable().

There are some tutorials for JOGL on the official site (JogAmp.org) and you can look at my source code if you still need an example of VBOs.

PS: I also recommend LWJGL. It is more similar to standard C/C++ OpenGL so it's easier to port other tutorials to Java with it.

At first, porting C/C++ OpenGL code to JOGL 2.0 is not difficult and not significantly more difficult than with the competitor of JOGL. Secondly, please don't use this thread to promote the competitor of JOGL. I remind you that when someone asks for help with it, I answer by looking at its documentation if required, I try to give some help or I don't answer but I don't use this opportunity to promote another API as you can see here:
http://www.java-gaming.org/topics/get-matrix/25279/msg/217474/view.html#msg217474

You're in the JOGL section.

[princec]

I'm sure I've asked before that the JOGL and LWJGL forums are collapsed into a single OpenGL forum to stop this sort of pettiness.

Cas

[Riven]

I'm sure I've asked before that the JOGL and LWJGL forums are collapsed into a single OpenGL forum to stop this sort of pettiness.

Merging the boards won't help. As soon as JOGL is mentioned in the initial post, it will be the same story all over again.

[theagentd]

PS: I also recommend LWJGL. It is more similar to standard C/C++ OpenGL so it's easier to port other tutorials to Java with it.

At first, porting C/C++ OpenGL code to JOGL 2.0 is not difficult and not significantly more difficult than with the competitor of JOGL. Secondly, please don't use this thread to promote the competitor of JOGL. I remind you that when someone asks for help with it, I answer by looking at its documentation if required, I try to give some help or I don't answer but I don't use this opportunity to promote another API as you can see here:
http://www.java-gaming.org/topics/get-matrix/25279/msg/217474/view.html#msg217474

You're in the JOGL section.

I wouldn't know exactly how hard it is, because I have never used JOGL. I'm just trying to help.

EDIT: fixed quote...

[gouessej]

I'm sure I've asked before that the JOGL and LWJGL forums are collapsed into a single OpenGL forum to stop this sort of pettiness.

Merging the boards won't help. As soon as JOGL is mentioned in the initial post, it will be the same story all over again.

I agree with you Riven. As soon as a JOGL user asks for help explicitly mentioning it, I will complain if anybody uses this thread to promote its competitor. If I owned a car, if I needed some help to repair it, I would be angry if someone used this "opportunity" to try selling me another car.

There are some tutorials but lots of them use JOGL 1.1.1a, a few still uses an old beta version even older. This is not a problem as it is quite easy to switch from JOGL 1.1.1a to JOGL 2.0 and the API is documented:
http://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/

Anyway, using a Java binding of OpenGL requires some knowledge of plain old OpenGL and you can easily find the documentation of all OpenGL methods on Internet.

Someone else on this forum ported some Nehe tutorials to JOGL 2.0, maybe you could have a look at them.

I wouldn't know exactly how hard it is, because I have never used JOGL. I'm just trying to help.

I know you're trying to help but don't dirty your nice and helpful explanations with advertising. I think you know the programmable part of OpenGL better than me. Personally I have used both bindings, I had even complained about a regression in the competitor of JOGL and it had been fixed.

[theagentd]

I agree with you Riven. As soon as a JOGL user asks for help explicitly mentioning it, I will complain if anybody uses this thread to promote its competitor. If I owned a car, if I needed some help to repair it, I would be angry if someone used this "opportunity" to try selling me another car.

[size=30pt]CAR[/size]

Because downloading a car is so expensive. 

...

The only thing I said was that
A) I currently use LWJGL (or "the competitor of JOGL" as you insist to call it. Afraid of mentioning its name? =S) so that is where my example code is going to come from, and
B) I said he could use the same one as me to make it easier to follow my code, which turned out to be unnecessary as he seems to be able to handle it just fine with JOGL.

I'll avoid doing B again if your gonna be that cranky about it... ._.

[elect]

I guess it's also possible that while you have >68Mb of direct memory free, there's not 68Mb in a continuous chunk. Have you tried carving it up into more manageable chunks of (say) 8Mb each?

What do you mean exactly?

Like creating n-buffers?

You think you messed up the memory commands. They are VM-commands, not run commands. Run commands end up in your main(String[] args). Put -Xmx1500m space -XX:MaxDirectMemorySize=256m in the VM command field instead.

I think I explained it badly, I go on the Project Properties, then in the run tab, then under the VM Options, here to be clear:
http://embeddedfreak.files.wordpress.com/2008/08/projectproperties.png

And what the heck is SHINE_ALL_DIRECTIONS? >_>

LOL , I dont know exaclty, I just took on the fly from an example over internet :p

There are some tutorials for JOGL on the official site (JogAmp.org) and you can look at my source code if you still need an example of VBOs.

Do you mean here:  http://jogamp.org/wiki/index.php/Jogl_Tutorial ?

I found among those examples only one using JOGL2 and VBOs, the second link under Wade

At first, porting C/C++ OpenGL code to JOGL 2.0 is not difficult and not significantly more difficult than with the competitor of JOGL. Secondly, please don't use this thread to promote the competitor of JOGL. I remind you that when someone asks for help with it, I answer by looking at its documentation if required, I try to give some help or I don't answer but I don't use this opportunity to promote another API as you can see here:
http://www.java-gaming.org/topics/get-matrix/25279/msg/217474/view.html#msg217474

You're in the JOGL section.

I am sorry that I have caused a dispute

However, although by a rigorous point of view you are right, theagentd wanted only to help me by suggesting me that and I appreciated it, also if I didnt follow this one of his suggests. He was not obsessive at all, so I would say that there is no problem


Ok, now coming back to my program ^^, I tried this command that another guy suggested me about the buffer creation:

1	vertexData = ByteBuffer.allocateDirect(triangleNumber*9).order(ByteOrder.nativeOrder()).asFloatBuffer();

But I get a:

Exception in thread "AWT-EventQueue-0" java.nio.BufferOverflowException
Reshape
Reshape
Display
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6b38fd72, pid=7144, tid=120
#
# JRE version: 6.0_18-b07
# Java VM: Java HotSpot(TM) Client VM (16.0-b13 mixed mode windows-x86 )
# Problematic frame:
# C  0x6b38fd72
#
# An error report file with more information is saved as:
# H:\Dokumente und Einstellungen\gbarbieri\Eigene Dateien\NetBeansProjects\JOpenGL with Cuda\hs_err_pid7144.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
   at java.nio.DirectFloatBufferU.put(DirectFloatBufferU.java:311)
   at java.nio.FloatBuffer.put(FloatBuffer.java:813)
   at Viewer.initVertexArray(Viewer.java:199)
   at Viewer.init(Viewer.java:131)
   at jogamp.opengl.GLDrawableHelper.init(GLDrawableHelper.java:135)
   at jogamp.opengl.GLDrawableHelper.init(GLDrawableHelper.java:154)
   at javax.media.opengl.awt.GLCanvas$InitAction.run(GLCanvas.java:886)
   at jogamp.opengl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:379)
   at javax.media.opengl.awt.GLCanvas.maybeDoSingleThreadedWorkaround(GLCanvas.java:799)
Java Result: 1

No matter how many triangles (it is the same also with very few of them)

[elect]

Ok, I solved only the overflow with this ( I forgot also the *4):

1   2   3

ByteBuffer vvb = ByteBuffer.allocateDirect(triangleNumber*9*4); vvb.order(ByteOrder.nativeOrder()); FloatBuffer vertexData = vvb.asFloatBuffer();

But I am still getting the memory violation access:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6b38fd72, pid=6412, tid=1808
#
# JRE version: 6.0_18-b07
# Java VM: Java HotSpot(TM) Client VM (16.0-b13 mixed mode windows-x86 )
# Problematic frame:
# C  0x6b38fd72
#
# An error report file with more information is saved as:
# H:\Dokumente und Einstellungen\gbarbieri\Eigene Dateien\NetBeansProjects\JOpenGL with Cuda\hs_err_pid6412.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Java Result: 1

.log

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6b38fd72, pid=6412, tid=1808
#
# JRE version: 6.0_18-b07
# Java VM: Java HotSpot(TM) Client VM (16.0-b13 mixed mode windows-x86 )
# Problematic frame:
# C  0x6b38fd72
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

---------------  T H R E A D  ---------------

Current thread (0x68a40800):  JavaThread "AWT-EventQueue-0" [_thread_in_native, id=1808, stack(0x692a0000,0x692f0000)]

siginfo: ExceptionCode=0xc0000005, reading address 0x00000000

Registers:
EAX=0x6b932ee0, EBX=0x6b8b0000, ECX=0x00000000, EDX=0x000000aa
ESP=0x692ef594, EBP=0x692ef5a0, ESI=0x00000000, EDI=0x00000000
EIP=0x6b38fd72, EFLAGS=0x00010212

Top of Stack: (sp=0x692ef594)
0x692ef594:   000000aa 6b8b0000 00000000 6b473e80
0x692ef5a4:   69c9f47d 6b8b0000 6b932edc 00000000
0x692ef5b4:   000000aa 6b473e80 00000000 00000004
0x692ef5c4:   00000003 00000000 000000aa 6b38fd40
0x692ef5d4:   69c9f5b9 00000004 0009c4d8 0009c582
0x692ef5e4:   6b8b0000 69631ed1 6b8b0000 00000004
0x692ef5f4:   00000000 0009c582 68a40800 60c688c8
0x692ef604:   60c688c8 692ef628 693e8c81 00000004

Instructions: (pc=0x6b38fd72)
0x6b38fd62:   04 8b 35 28 5c 8d 6b 8b 76 04 8d 3c 49 8d 34 be
0x6b38fd72:   8b 3e 8b 6e 04 89 38 89 68 04 8b 7e 08 89 78 08


Stack: [0x692a0000,0x692f0000],  sp=0x692ef594,  free space=13d692ef0c8k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  0x6b38fd72

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  jogamp.opengl.gl4.GL4bcImpl.dispatch_glDrawArrays1(IIIJ)V+0
j  jogamp.opengl.gl4.GL4bcImpl.glDrawArrays(III)V+39
j  Viewer.init(Ljavax/media/opengl/GLAutoDrawable;)V+250
j  jogamp.opengl.GLDrawableHelper.init(Ljavax/media/opengl/GLEventListener;Ljavax/media/opengl/GLAutoDrawable;Z)Z+13
j  jogamp.opengl.GLDrawableHelper.init(Ljavax/media/opengl/GLAutoDrawable;)V+48
j  javax.media.opengl.awt.GLCanvas$InitAction.run()V+11
j  jogamp.opengl.GLDrawableHelper.invokeGL(Ljavax/media/opengl/GLDrawable;Ljavax/media/opengl/GLContext;Ljava/lang/Runnable;Ljava/lang/Runnable;)V+238
j  javax.media.opengl.awt.GLCanvas.maybeDoSingleThreadedWorkaround(Ljava/lang/Runnable;Ljava/lang/Runnable;)V+36
j  javax.media.opengl.awt.GLCanvas.display()V+31
j  javax.media.opengl.awt.GLCanvas.paint(Ljava/awt/Graphics;)V+135
j  sun.awt.RepaintArea.paintComponent(Ljava/awt/Component;Ljava/awt/Graphics;)V+6
j  sun.awt.RepaintArea.paint(Ljava/lang/Object;Z)V+326
j  sun.awt.windows.WComponentPeer.handleEvent(Ljava/awt/AWTEvent;)V+107
j  java.awt.Component.dispatchEventImpl(Ljava/awt/AWTEvent;)V+853
j  java.awt.Component.dispatchEvent(Ljava/awt/AWTEvent;)V+2
j  java.awt.EventQueue.dispatchEvent(Ljava/awt/AWTEvent;)V+46
j  java.awt.EventDispatchThread.pumpOneEventForFilters(I)Z+204
j  java.awt.EventDispatchThread.pumpEventsForFilter(ILjava/awt/Conditional;Ljava/awt/EventFilter;)V+30
j  java.awt.EventDispatchThread.pumpEventsForHierarchy(ILjava/awt/Conditional;Ljava/awt/Component;)V+11
j  java.awt.EventDispatchThread.pumpEvents(ILjava/awt/Conditional;)V+4
j  java.awt.EventDispatchThread.pumpEvents(Ljava/awt/Conditional;)V+3
j  java.awt.EventDispatchThread.run()V+9
v  ~StubRoutines::call_stub

---------------  P R O C E S S  ---------------

Java Threads: ( => current thread )
  0x669d7400 JavaThread "Timer-0" [_thread_blocked, id=6692, stack(0x6be00000,0x6be50000)]
  0x002b8400 JavaThread "DestroyJavaVM" [_thread_blocked, id=5572, stack(0x008c0000,0x00910000)]
  0x68990400 JavaThread "D3D Screen Updater" daemon [_thread_blocked, id=1804, stack(0x6a960000,0x6a9b0000)]
=>0x68a40800 JavaThread "AWT-EventQueue-0" [_thread_in_native, id=1808, stack(0x692a0000,0x692f0000)]
  0x66de8800 JavaThread "AWT-Shutdown" [_thread_blocked, id=4480, stack(0x68e00000,0x68e50000)]
  0x66df8400 JavaThread "main-SharedResourceRunner" daemon [_thread_blocked, id=6788, stack(0x69460000,0x694b0000)]
  0x68a76800 JavaThread "AWT-Windows" daemon [_thread_in_native, id=6380, stack(0x68e50000,0x68ea0000)]
  0x68a5a400 JavaThread "Java2D Disposer" daemon [_thread_blocked, id=6752, stack(0x68db0000,0x68e00000)]
  0x66973000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=7400, stack(0x66bc0000,0x66c10000)]
  0x6696d400 JavaThread "CompilerThread0" daemon [_thread_blocked, id=4392, stack(0x66b70000,0x66bc0000)]
  0x6696bc00 JavaThread "Attach Listener" daemon [_thread_blocked, id=7472, stack(0x66b20000,0x66b70000)]
  0x6696a800 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=4508, stack(0x66ad0000,0x66b20000)]
  0x66956000 JavaThread "Finalizer" daemon [_thread_blocked, id=4296, stack(0x66a80000,0x66ad0000)]
  0x66954800 JavaThread "Reference Handler" daemon [_thread_blocked, id=4428, stack(0x66a30000,0x66a80000)]

Other Threads:
  0x66951c00 VMThread [stack: 0x669e0000,0x66a30000] [id=5968]
  0x6697e000 WatcherThread [stack: 0x66c10000,0x66c60000] [id=6968]

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: None

Heap
 def new generation   total 18688K, used 4569K [0x02990000, 0x03dd0000, 0x21d90000)
  eden space 16640K,  23% used [0x02990000, 0x02d5bc60, 0x039d0000)
  from space 2048K,  33% used [0x039d0000, 0x03a7a810, 0x03bd0000)
  to   space 2048K,   0% used [0x03bd0000, 0x03bd0000, 0x03dd0000)
 tenured generation   total 41396K, used 34742K [0x21d90000, 0x245fd000, 0x60590000)
   the space 41396K,  83% used [0x21d90000, 0x23f7d890, 0x23f7da00, 0x245fd000)
 compacting perm gen  total 12288K, used 11034K [0x60590000, 0x61190000, 0x64590000)
   the space 12288K,  89% used [0x60590000, 0x61056ba8, 0x61056c00, 0x61190000)
No shared spaces configured.

Dynamic libraries:
0x00400000 - 0x00424000    H:\Programme\Java\jdk1.6.0_18\bin\java.exe
0x7c910000 - 0x7c9c9000    H:\WINDOWS\system32\ntdll.dll
0x7c800000 - 0x7c908000    H:\WINDOWS\system32\kernel32.dll
0x77da0000 - 0x77e4a000    H:\WINDOWS\system32\ADVAPI32.dll
0x77e50000 - 0x77ee3000    H:\WINDOWS\system32\RPCRT4.dll
0x77fc0000 - 0x77fd1000    H:\WINDOWS\system32\Secur32.dll
0x7c340000 - 0x7c396000    H:\Programme\Java\jdk1.6.0_18\jre\bin\msvcr71.dll
0x6d8b0000 - 0x6db47000    H:\Programme\Java\jdk1.6.0_18\jre\bin\client\jvm.dll
0x7e360000 - 0x7e3f1000    H:\WINDOWS\system32\USER32.dll
0x77ef0000 - 0x77f39000    H:\WINDOWS\system32\GDI32.dll
0x76af0000 - 0x76b1e000    H:\WINDOWS\system32\WINMM.dll
0x76330000 - 0x7634d000    H:\WINDOWS\system32\IMM32.DLL
0x6d860000 - 0x6d86c000    H:\Programme\Java\jdk1.6.0_18\jre\bin\verify.dll
0x6d3e0000 - 0x6d3ff000    H:\Programme\Java\jdk1.6.0_18\jre\bin\java.dll
0x6d340000 - 0x6d348000    H:\Programme\Java\jdk1.6.0_18\jre\bin\hpi.dll
0x76bb0000 - 0x76bbb000    H:\WINDOWS\system32\PSAPI.DLL
0x6d8a0000 - 0x6d8af000    H:\Programme\Java\jdk1.6.0_18\jre\bin\zip.dll
0x68000000 - 0x68036000    H:\WINDOWS\system32\rsaenh.dll
0x77be0000 - 0x77c38000    H:\WINDOWS\system32\msvcrt.dll
0x76620000 - 0x766d6000    H:\WINDOWS\system32\USERENV.dll
0x66e80000 - 0x66ed5000    H:\WINDOWS\system32\netapi32.dll
0x6d6c0000 - 0x6d6d3000    H:\Programme\Java\jdk1.6.0_18\jre\bin\net.dll
0x71a10000 - 0x71a27000    H:\WINDOWS\system32\WS2_32.dll
0x71a00000 - 0x71a08000    H:\WINDOWS\system32\WS2HELP.dll
0x719b0000 - 0x719f0000    H:\WINDOWS\System32\mswsock.dll
0x76ee0000 - 0x76f07000    H:\WINDOWS\system32\DNSAPI.dll
0x76d20000 - 0x76d39000    H:\WINDOWS\system32\iphlpapi.dll
0x76f70000 - 0x76f78000    H:\WINDOWS\System32\winrnr.dll
0x76f20000 - 0x76f4d000    H:\WINDOWS\system32\WLDAP32.dll
0x76f80000 - 0x76f86000    H:\WINDOWS\system32\rasadhlp.dll
0x66f70000 - 0x66f9b000    H:\Dokumente und Einstellungen\gbarbieri\Lokale Einstellungen\Temp\JCudaDriver-windows-x861267435476727095117.dll
0x66fb0000 - 0x674ef000    H:\WINDOWS\system32\nvcuda.dll
0x67520000 - 0x67733000    H:\WINDOWS\system32\nvapi.dll
0x774b0000 - 0x775ee000    H:\WINDOWS\system32\ole32.dll
0x770f0000 - 0x7717b000    H:\WINDOWS\system32\OLEAUT32.dll
0x77f40000 - 0x77fb6000    H:\WINDOWS\system32\SHLWAPI.dll
0x7e670000 - 0x7ee91000    H:\WINDOWS\system32\SHELL32.dll
0x778f0000 - 0x779e4000    H:\WINDOWS\system32\SETUPAPI.dll
0x77bd0000 - 0x77bd8000    H:\WINDOWS\system32\VERSION.dll
0x773a0000 - 0x774a3000    H:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.6028_x-ww_61e65202\comctl32.dll
0x6d6e0000 - 0x6d6e9000    H:\Programme\Java\jdk1.6.0_18\jre\bin\nio.dll
0x67f50000 - 0x67f5a000    H:\Dokumente und Einstellungen\gbarbieri\Lokale Einstellungen\Temp\jogamp.tmp.cache_000000\jln561151374246547883\jln5225070793958013922\gluegen-rt.dll
0x6d0b0000 - 0x6d1fa000    H:\Programme\Java\jdk1.6.0_18\jre\bin\awt.dll
0x72f70000 - 0x72f96000    H:\WINDOWS\system32\WINSPOOL.DRV
0x67f80000 - 0x67fb8000    H:\WINDOWS\system32\uxtheme.dll
0x746a0000 - 0x746ec000    H:\WINDOWS\system32\MSCTF.dll
0x75250000 - 0x7527e000    H:\WINDOWS\system32\msctfime.ime
0x6d410000 - 0x6d416000    H:\Programme\Java\jdk1.6.0_18\jre\bin\jawt.dll
0x6a440000 - 0x6a44a000    H:\Dokumente und Einstellungen\gbarbieri\Lokale Einstellungen\Temp\jogamp.tmp.cache_000000\jln561151374246547883\jln5225070793958013922\nativewindow_awt.dll
0x6d2e0000 - 0x6d334000    H:\Programme\Java\jdk1.6.0_18\jre\bin\fontmanager.dll
0x68ee0000 - 0x69086000    H:\WINDOWS\system32\d3d9.dll
0x6de80000 - 0x6de86000    H:\WINDOWS\system32\d3d8thk.dll
0x6c100000 - 0x6c110000    H:\Dokumente und Einstellungen\gbarbieri\Lokale Einstellungen\Temp\jogamp.tmp.cache_000000\jln561151374246547883\jln5225070793958013922\nativewindow_win32.dll
0x692f0000 - 0x693bc000    H:\WINDOWS\system32\OpenGL32.dll
0x693c0000 - 0x693e0000    H:\WINDOWS\system32\GLU32.dll
0x736d0000 - 0x7371b000    H:\WINDOWS\system32\DDRAW.dll
0x73b30000 - 0x73b36000    H:\WINDOWS\system32\DCIMAN32.dll
0x693e0000 - 0x69453000    H:\Dokumente und Einstellungen\gbarbieri\Lokale Einstellungen\Temp\jogamp.tmp.cache_000000\jln561151374246547883\jln5225070793958013922\jogl_desktop.dll
0x69500000 - 0x6a34a000    H:\WINDOWS\system32\nvoglnt.dll

VM Arguments:
jvm_args: -Dfile.encoding=UTF-8 -Xmx1500m -XX:MaxDirectMemorySize=256m
java_command: CudaImplementation
Launcher Type: SUN_STANDARD

Environment Variables:
PATH=H:\Programme\NVIDIA GPU Computing Toolkit\CUDA\v4.0\bin\;H:\WINDOWS\system32;H:\WINDOWS;H:\WINDOWS\System32\Wbem;h:\Programme\Microsoft SQL Server\90\Tools\binn\;H:\IFOR\WIN\BIN;H:\IFOR\WIN\BIN\EN_US;H:\Programme\Microsoft Visual Studio 10.0\VC\bin;H:\Programme\Microsoft Visual Studio 10.0\VC\bin\
USERNAME=gbarbieri
OS=Windows_NT
PROCESSOR_IDENTIFIER=x86 Family 6 Model 23 Stepping 10, GenuineIntel



---------------  S Y S T E M  ---------------

OS: Windows XP Build 2600 Service Pack 3

CPU:total 4 (4 cores per cpu, 1 threads per core) family 6 model 23 stepping 10, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1

Memory: 4k page, physical 3144748k(1361480k free), swap 5070780k(3145220k free)

vm_info: Java HotSpot(TM) Client VM (16.0-b13) for windows-x86 JRE (1.6.0_18-b07), built on Dec 17 2009 13:35:55 by "java_re" with MS VC++ 7.1 (VS2003)

time: Fri Dec 16 09:26:00 2011
elapsed time: 17 seconds

The old way vertexData = GLBuffers.newDirectFloatBuffer(triangleNumber*3*3); works like a charm (below 2M triangles)

[gouessej]

Hi

You should always use the class Buffers to create your NIO buffers for JOGL but your source code does almost the same thing:
https://github.com/sgothel/gluegen/blob/master/src/java/com/jogamp/common/nio/Buffers.java

I don't understand why you cannot create a bigger NIO buffer of several MB. I already succeeded in creating bigger ones. Orangy Tang suggests that the direct NIO buffer uses continuous memory, you might have enough memory but not enough continuous memory, that is why he suggests using several smaller NIO buffers instead of a single big one. I do the same when I implement streaming.

[princec]

That is a slightly old version of Java you've got there - maybe this bug has been fixed in a newer release?

Cas

[elect]

I don't understand why you cannot create a bigger NIO buffer of several MB. I already succeeded in creating bigger ones.

Like? More than 64MB you mean? Have you used the -XX:MaxDirectMemorySize=256m option?

That is a slightly old version of Java you've got there - maybe this bug has been fixed in a newer release?

Cas

Ok, im going to install the 6.30, it should be the last one, right?... or do you suggest me to try the 7 or a beta?

@gouessej, what java you have?

[princec]

Use Java 7 if you've not got any good reason not to - it's great.

Cas

[theagentd]

Use Java 7 if you've not got any good reason not to - it's great.

Cas

When I released a small test made in Java 7, everyone started flaming me. Did people suddenly realize that it's actually a newer version of Java?

[sproingie]

Lots of people here write applets, and the standard browser plugin version is STILL 1.6, which is what makes 1.7 such a sticky wicket.  Most of my server apps have been upgraded already (except for one that simply won't work even on 1.7u2 for reasons unknown), but if I were distributing to mass markets, I wouldn't be able to touch 1.7.  I think it's not going to change unless and until they get javafx 2.0 running on linux and mac (still beta on mac, still no sign of it for linux).

Personally I think Oracle simply cannot manage commodity consumer software... and it's not like they even had a high bar to clear what with the previous owner being Sun.