# Draw and fill triangles in 3d space on a 2D plane

Hi all,

my target is simple. I have an array of triangles, each triangle has 3 vertex, each vertex 3 float values: x, y and z coordinate. I already calculated the section points for each triangle on a plane (xy, z=0) from a “source” point: basically for each triangle, I calculated a line between this source and each vertex of the current triangle and I calculate the intersection with my xy plane.

Now the hard part comes ^^

I have the section points and the plane. The plane is a matrix of cells (little squares) that is a boolean matrix, i.e. a cell can be true/false (shadow or not). I need to drawn and fill (or flood-fill) all the matrix-projected triangles…

First I thought to do this on Cuda. Cuda was surprisingly fast for the section points calculating… but when it came the time to draw and fill them, then the ways that I implemented were all ore or less slow…

Looking over the web, many results always lead me to graphic libraries and so on…

So why not using Cuda for the section points and OpenGL for drawing/filling them?

I would like to ask if this makes sense or not

And if yes, where should I start from with JOGL?

At the moment I am studing the JCudaRuntimeGLSample3 example…

Hello

I’m not sure whether I understood the problem correctly … I’ll probably have to read it a few more times (Is this part of some Raytracing application or so?).

One could consider filling the triangles with OpenGL - that’s exactly what the fragment shaders are for, and they are fast. However, I’m not sure whether it is possible, and IF it is possible, I can hardly estimate the required effort or the best approach.

Since there is no way of directly obtaining the output from a shader, I think that it might be possible to let OpenGL render the triangles into an FBO. This FBO could be shared with CUDA for efficient data transfer. In this case, the result would probably not be a boolean array, but an array of „colors“ (int values). It might be challenging, but worth a try. The GL sample from the website shows the basic setup and buffer sharing. For FBOs, there are probably GL-specific examples on the web, but the interaction with CUDA should be similar.

Whether you use JOGL or LWJGL is up to you. The example on the website is using JOGL, but I already planned to create the same example with LWJGL once I find the time for that but it does not have so high priority, because it would be rather similar to the existing example. I did the same (two examples, for JOGL and for LWJGL) for OpenCL at jocl.org - Samples , it should not be so hard to port the JCuda-JOGL sample to LWJGL.

bye
Marco

[QUOTE=Marco13]Hello

I’m not sure whether I understood the problem correctly … I’ll probably have to read it a few more times (Is this part of some Raytracing application or so?). [/QUOTE]

Yeah sorry, my fault, unfortunately my english is not so good

Ok, lets try with an example, lets suppose to have a 5x10 boolean matrix:

and a triangle on this matrix having the following coordinates ( origin in left lower corner)

x = [1,0]
y = [8,0]
z = [1,3]

that on the matrix are situated as follow:

.z…

.x…y.

Then I need to drawn and fill this triangle by marking to true (or false, it doesnt matter) the correspondent cells

For example, if I decide to assign # to true, then this should be the result (the layout is a little mess, sorry):

. . . . . . . . . .
. # . . . . . . . .
. ### . . . . . .
. ###### . . .
. ######## .

And that’s it…

However **at the moment **I dont need any render, i just need the filled triangles on a custom matrix

Right now I am looking the examples on the JOGL website, since as you said I guess (and I hope ^^) the Cuda integration wont be that hard…

What do you think?

Depending on how large the Matrix is, this could possibly be done easily in CUDA, since you could use 2D workspace consisting of Grids and Blocks, and the kernel would then be something like

``````
if (indexX < sizeX && indexY < sizeY)
{
matrix[indexY + indexX * sizeY] = pointIsInTriangle(indexX, indexY, someTriangleData...);
}

``````

Then it all depends on the efficiency of the ‘pointIsInTriangle’ function. I think it would be “easier” concerning the general structure, because it would not involve any GL/CUDA buffer sharing and FBO magic, but I can not make any guesses concerning the efficiency…

[QUOTE=Marco13]Depending on how large the Matrix is, this could possibly be done easily in CUDA, since you could use 2D workspace consisting of Grids and Blocks, and the kernel would then be something like

``````
if (indexX < sizeX && indexY < sizeY)
{
matrix[indexY + indexX * sizeY] = pointIsInTriangle(indexX, indexY, someTriangleData...);
}

``````

Then it all depends on the efficiency of the ‘pointIsInTriangle’ function. I think it would be “easier” concerning the general structure, because it would not involve any GL/CUDA buffer sharing and FBO magic, but I can not make any guesses concerning the efficiency…[/QUOTE]

I already tried this way, on a 9400 GT it was slower than the cpu…

Surely I did not write the best implemention, however I would like to give a try using the JOGL with VBOs…

I found this paper over internet, about rendering huge mesh of triangles

http://www.sci.utah.edu/~bavoil/opengl/bavoil_trimeshes_2005.pdf

It looks very interesting, but it is dated 2005…

However I am trying to implement something with the glDrawArrays using GL3 but unfortunately material over internet is not so much, and one founds also stuff in other language, in GL1-2, etc…

I ll let you know

Ok, it doesnt display anything

Here a summary:

``````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);

// Create the main frame
frame = new JFrame("JCuda / JOGL interaction sample");
{
@Override
public void windowClosing(WindowEvent e)
{
runExit();
}
});
frame.setLayout(new BorderLayout());
glComponent.setPreferredSize(new Dimension(800, 800));
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;
}
``````

Where am I wrong?

I guess the problem could be that 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

I can try to have a closer look at this (although a compileable sample would be preferred), but a general remark: In GL3, you always have to create a VAO when you want to display a VBO. You can have a look at the sample on the website. Although the VAO seems to be superflous, and many tutorials (that are built on GL<3) do NOT create a VAO, it is necessary when you want to see anything in GL>=3

Aaaaaah… Indeed I did not implement the VAO because I thought I didnt need it… >.>

Ok, i’ll try

And what about the animator and a view? Shall I need them?

Ps: can deliver you the whole program, but the problem is that it needs in input a large .stl file (300 MB)… but maybe I can make a schrink it, in a thin version

The animator should not be necessary when you trigger the repaints yourself, but it’s concenient. But I’m not sure what you mean by ‘view’ in this case…

Yeah sorry, I meant the point of view, because I am loading in the VBO 3d-triangle (i.e: each vertex has 3 dimensions)

So the graphic cards should order them (a kind of z-raster if I am right) regarding the point of view and then display them on a 2d plane (the monitor)

Basically the setupView(drawable); call in the JCuda example

Ah well - in this case you would probably use a simple, orthographic projection (glOrtho), so that you only see the xy-plane. The coordinates for glOrtho will probably depend on the area that is covered by the triangles in the 2D plane.

Ok, I take note of this and do later, because I am a beginner with JOGL and so I need to start with a very easy implementation… I will leave GL3 for the moment and focus on the 2, since it is so much more complicated (and I guess also powerful)

Edit

Ok Marco,

I am implementing a very basic test program, no VAO or VBO, just Vertex Array at the moment, I initialized the gl context and everything but within the **glVertexPointer
**

``````
FloatBuffer data = Buffers.newDirectFloatBuffer(size);

private void initVertexArray(GL2 gl)
{
FloatBuffer vertexData = GLBuffers.newDirectFloatBuffer(6);
vertexData.put(new float[]{0, 0, 1, 0, 0, 1});
vertexData.flip();

gl.glVertexPointer(size, GL_FLOAT, size, data);```

GL_FLOAT cannot be found... any tip?``````

Solved, gl.GL_FLOAT

Btw at the moment I am using just Vertex Array, not yet VAO

I have a problem

This

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

crashes for out of memory when the number of triangles rise over 2 milions…

I tried with the -XX:MaxDirectMemorySize=256m without any success…

any tip?

Not really, actually I did not know that “MaxDirectMemorySize” flag - what happens if you write it manually, as

FloatBuffer f = ByteBuffer.allocateDirect(n33).order(ByteOrder.nativeOrder()).asFloatBuffer();

?

[QUOTE=Marco13]Not really, actually I did not know that “MaxDirectMemorySize” flag - what happens if you write it manually, as

FloatBuffer f = ByteBuffer.allocateDirect(n33).order(ByteOrder.nativeOrder()).asFloatBuffer();

?[/QUOTE]

Reshape
Reshape
Display

# 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)
Java Result: 1

This link http://forum.chip.de/java-delphi-pascal/error-java-nio-bufferoverflowexception-1116238.html says something about the buffer closing… is this my case? At the end of the for I just flip it

``````
for(int i=0; i<triangleNumber; i++) {
Triangle tmp = triangleArray.get(i);
vertexData.put(new float[]{tmp.x1/12000.0f, tmp.y1/12000.0f, tmp.z1/12000.0f,
tmp.x2/12000.0f, tmp.y2/12000.0f, tmp.z2/12000.0f,
tmp.x3/12000.0f, tmp.y3/12000.0f, tmp.z3/12000.0f  });   }
vertexData.flip();```

The weird thing is that it doesnt matter how many triangles I put in it, because also when I try to load very fews I get the same error, so I guess it am missing still some line of code?``````

Ok, I solved the overflow, I forgot to multiply times four (Float->Byte)

I also rewrote it like:

``````        vvb.order(ByteOrder.nativeOrder());
FloatBuffer vertexData = vvb.asFloatBuffer();```

Now I get **only** the memory violation :/

It is funny because if I use use the

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

No problem, but if I use what you suggested me and I copied above I get:

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

If I open the .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  ---------------
>
>
>
> 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.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
> v  ~StubRoutines::call_stub
>
> ---------------  P R O C E S S  ---------------
>
>
>   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
> tdll.dll
> 0x7c800000 - 0x7c908000 	H:\WINDOWS\system32\kernel32.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
> etapi32.dll
> 0x6d6c0000 - 0x6d6d3000 	H:\Programme\Java\jdk1.6.0_18\jre\bin
> et.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
> 0x66f70000 - 0x66f9b000 	H:\Dokumente und Einstellungen\gbarbieri\Lokale Einstellungen\Temp\JCudaDriver-windows-x861267435476727095117.dll
> 0x66fb0000 - 0x674ef000 	H:\WINDOWS\system32
> vcuda.dll
> 0x67520000 - 0x67733000 	H:\WINDOWS\system32
> vapi.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
> io.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
> ativewindow_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
> ativewindow_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
> voglnt.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\
> 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
>``````