Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (109)
games submitted by our members
Games in WIP (536)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2 3
  ignore  |  Print  
  Problem displaying a triangle array/mesh  (Read 12029 times)
0 Members and 1 Guest are viewing this topic.
Offline elect

Junior Member





« Posted 2011-12-14 10:21:18 »

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 >.>)
Offline elect

Junior Member





« Reply #1 - Posted 2011-12-14 10:44:25 »

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

But unfortunately it still doesnt work..
Offline theagentd
« Reply #2 - Posted 2011-12-14 12:18:04 »

 - 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.

Myomyomyo.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline elect

Junior Member





« Reply #3 - Posted 2011-12-14 13:38:59 »

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! Smiley

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?
Offline elect

Junior Member





« Reply #4 - Posted 2011-12-14 13:43:35 »


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
Offline theagentd
« Reply #5 - Posted 2011-12-14 14:51:10 »

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! Smiley

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

Myomyomyo.
Offline elect

Junior Member





« Reply #6 - Posted 2011-12-14 15:05:30 »

Thanks theagentd, you are surprisingly exhaustive!  Shocked

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! Wink
Offline theagentd
« Reply #7 - Posted 2011-12-14 15:13:50 »

Thanks theagentd, you are surprisingly exhaustive!  Shocked

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! Wink
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

Myomyomyo.
Offline elect

Junior Member





« Reply #8 - Posted 2011-12-14 15:17:57 »


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  Cool

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
Offline elect

Junior Member





« Reply #9 - Posted 2011-12-15 14:54:21 »

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!
Legends of Yore - The Casual Retro Roguelike
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #10 - Posted 2011-12-15 14:59:12 »

- 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

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline elect

Junior Member





« Reply #11 - Posted 2011-12-15 15:22:11 »

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?).


Quote
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?
Offline theagentd
« Reply #12 - Posted 2011-12-15 15:27:17 »

@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.

Myomyomyo.
Offline elect

Junior Member





« Reply #13 - Posted 2011-12-15 15:44:40 »

@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?
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #14 - Posted 2011-12-15 16:16:11 »

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?

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline theagentd
« Reply #15 - Posted 2011-12-15 18:57:08 »

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? >_>

Myomyomyo.
Offline gouessej
« Reply #16 - Posted 2011-12-15 19:59:00 »

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.

Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #17 - Posted 2011-12-15 20:11:42 »

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 Smiley

Offline Riven
« League of Dukes »

JGO Overlord


Medals: 755
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #18 - Posted 2011-12-15 20:16:31 »

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.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline theagentd
« Reply #19 - Posted 2011-12-15 21:32:59 »

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...

Myomyomyo.
Offline gouessej
« Reply #20 - Posted 2011-12-15 21:37:24 »

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.

Offline theagentd
« Reply #21 - Posted 2011-12-15 23:34:27 »

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.  Grin

...

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... ._.


Myomyomyo.
Offline elect

Junior Member





« Reply #22 - Posted 2011-12-16 09:15:25 »

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 Cheesy, 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 Sad

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 Wink


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:

Quote
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)
Offline elect

Junior Member





« Reply #23 - Posted 2011-12-16 09:30:17 »

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:

Quote
#
# 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

Quote
#
# 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)
Offline gouessej
« Reply #24 - Posted 2011-12-16 12:55:38 »

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.

Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #25 - Posted 2011-12-16 12:59:56 »

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

Cas Smiley

Offline elect

Junior Member





« Reply #26 - Posted 2011-12-16 13:04:20 »

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 Smiley

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?
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #27 - Posted 2011-12-16 14:22:37 »

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

Cas Smiley

Offline theagentd
« Reply #28 - Posted 2011-12-16 14:58:49 »

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

Cas Smiley
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?

Myomyomyo.
Offline sproingie

JGO Kernel


Medals: 202



« Reply #29 - Posted 2011-12-16 18:21:55 »

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.
Pages: [1] 2 3
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

CogWheelz (18 views)
2014-07-30 21:08:39

Riven (25 views)
2014-07-29 18:09:19

Riven (15 views)
2014-07-29 18:08:52

Dwinin (12 views)
2014-07-29 10:59:34

E.R. Fleming (33 views)
2014-07-29 03:07:13

E.R. Fleming (12 views)
2014-07-29 03:06:25

pw (43 views)
2014-07-24 01:59:36

Riven (43 views)
2014-07-23 21:16:32

Riven (30 views)
2014-07-23 21:07:15

Riven (31 views)
2014-07-23 20:56:16
List of Learning Resources
by SilverTiger
2014-07-31 18:29:50

List of Learning Resources
by SilverTiger
2014-07-31 18:26:06

List of Learning Resources
by SilverTiger
2014-07-31 13:54:12

HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!