Hello Guest

Problem rendering from buffers [SOLVED]

  • 7 Replies
  • 14700 Views
Problem rendering from buffers [SOLVED]
« on: March 04, 2012, 21:43:26 »
edit:

FOR FUTUTE PEOPLE:
If you want to use openGL 3.3+ (and render from video memory), take a look at the lwjgl version of the openGL superbible examples and tools:
http://code.google.com/p/opengl-superbible-java/source/browse/

The GLBatch implementation is really usefull if you want to learn how to render from video memory in openGL 3.3 core and above.


I'm trying to get a few vertices rendered from a buffer in video memory.
I've tried to turn all sorts of things on and off and have chaked a lot of errors, but if I run the following code, nothing is drawn to the screen.

the draw function:

Code: [Select]
draw(){
        glEnableVertexAttribArray(texCoordLocation); //texCoordLocation is retrieved using the getAttribLocation() function.
        glBindBuffer(GL_ARRAY_BUFFER, buffers.get(1));
        
        glEnableVertexAttribArray(vertexLocation); //same here as above
        glBindBuffer(GL_ARRAY_BUFFER, buffers.get(0));
        
        glDrawArrays(GL_TRIANGLE_STRIP, 0, numVerts);
        
        glDisableVertexAttribArray(texCoordLocation);
        glDisableVertexAttribArray(vertexLocation);
    }

I'm pretty sure the texture is not the problem, because the fragment shader is currently assigning a static color value to each fargment -_-

Anyway, here is the code where I fill the buffers:

Code: [Select]
   public void End(){

        //Create two buffer handles:
        buffers = ByteBuffer.allocateDirect(2*4).asIntBuffer();
        glGenBuffers(buffers);
        
        //Put the obtained vertex data into FloatBuffers:
        FloatBuffer vertexB = ByteBuffer.allocateDirect(numVerts*4*4).asFloatBuffer();
        FloatBuffer texB = ByteBuffer.allocateDirect(numVerts*2*4).asFloatBuffer();
        
        vertexB.put(verts).rewind();
        texB.put(texCoords).rewind();
        
        //Allocate the two buffers and fill them with data:
        glBindBuffer(GL_ARRAY_BUFFER, buffers.get(0));
        glBufferData(GL_ARRAY_BUFFER, vertexB, GL_DYNAMIC_DRAW); //Buffer 0 contains the vertex data
        
        glBindBuffer(GL_ARRAY_BUFFER, buffers.get(1));
        glBufferData(GL_ARRAY_BUFFER, texB, GL_DYNAMIC_DRAW); //Buffer 1 contains the texture coordinates
        
        glBindBuffer(GL_ARRAY_BUFFER, 0); //unbind the buffer
}

I'm pretty sure the error is in one of these parts of the code, but atteched are the shaders and the whole source code.

Does anyone know what I'm doing wrong here?
« Last Edit: March 06, 2012, 06:51:11 by Rednax »

Re: Problem rendering from buffers
« Reply #1 on: March 04, 2012, 23:13:03 »
I don't do anything exactly like what you're doing, but I do know I couldn't get buffers to work without using the .nativeOrder() function. I'm using them for lighting and materials, not textures, but it might be relevant.

*

Offline spasi

  • *****
  • 2192
    • WebHotelier
Re: Problem rendering from buffers
« Reply #2 on: March 05, 2012, 01:18:30 »
LWJGL provides the BufferUtils class, that simplifies buffer creation. Instead of:

Code: [Select]
ByteBuffer.allocateDirect(size * 4).order(ByteOrder.nativeOrder()).asIntBuffer();
you can write this:

Code: [Select]
BufferUtils.createIntBuffer(size);

Re: Problem rendering from buffers
« Reply #3 on: March 05, 2012, 14:59:14 »
Thanks for the tips, but all this has caused the jvm to crash.

I noticed I filled one of the arrays with three elements, while expecting a 4 elements vector in the shader. So I changed the buffer and everything to get 4 values (even though the 4th value is always 1.0f).
Now my program crashes on the glDrawArrays call, IF I select anything else than GL_QUADS. GL_QUADS doesn't draw anywhting at all.

A GL_TRIANGLE_STRIP should work on 4 vertexes right?

anyway, the jvm is giving me an error dump. with the error msg: EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00000000692a43c0, pid=4356, tid=3344

Im starting to feel that programming in java is actually slower than c++. Simply because its harded to do anything not in the default toy box of tools. Java makes everything a lot easier, IF you can get things to work :( . And yes, I've already had something similar working in c++.

Anyway, here is the full log:

output in console:
Quote
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00000000692a43c0, pid=4356, tid=3344
#
# JRE version: 7.0_03-b05
# Java VM: Java HotSpot(TM) 64-Bit Server VM (22.1-b02 mixed mode windows-amd64 compressed oops)
# Problematic frame:
# C  [atio6axx.dll+0x2743c0]
#
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
#
# An error report file with more information is saved as:
# C:\Users\Administrator\Documents\NetBeansProjects\PrGame\hs_err_pid4356.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

Output in given log dump:
Quote
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00000000692a43c0, pid=4356, tid=3344
#
# JRE version: 7.0_03-b05
# Java VM: Java HotSpot(TM) 64-Bit Server VM (22.1-b02 mixed mode windows-amd64 compressed oops)
# Problematic frame:
# C  [atio6axx.dll+0x2743c0]
#
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/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 (0x0000000001d3b800):  JavaThread "main" [_thread_in_native, id=3344, stack(0x0000000002210000,0x0000000002310000)]

siginfo: ExceptionCode=0xc0000005, reading address 0x0000000000000000

Registers:
RAX=0x0000000000000010, RBX=0x0000000000000000, RCX=0x000000000ccfd000, RDX=0x0000000000000000
RSP=0x000000000230f180, RBP=0x000000000ccfd000, RSI=0x0000000000000002, RDI=0x0000000000000004
R8 =0x000000000ccfd009, R9 =0x000000000230f1c0, R10=0x000000000ccfd010, R11=0x0000000000000002
R12=0x000000006a6b2080, R13=0x000000006a6d6ad8, R14=0x0000000000000004, R15=0x0000000000000001
RIP=0x00000000692a43c0, EFLAGS=0x0000000000010293

Top of Stack: (sp=0x000000000230f180)
0x000000000230f180:   0000000000000010 000000000b2a80f0
0x000000000230f190:   000000000b2a8100 000000006a2ec8eb
0x000000000230f1a0:   0000000000000002 0000000000000010
0x000000000230f1b0:   0000000000000000 0000000069ad43be
0x000000000230f1c0:   0000000000000000 0000001000000010
0x000000000230f1d0:   0000000000000000 0000001000000010
0x000000000230f1e0:   0000000000000030 000000000b32c7e0
0x000000000230f1f0:   000000000a2fcf90 000000006a2ec8eb
0x000000000230f200:   0000000000000002 0000000000000030
0x000000000230f210:   0000000000000040 0000000000000000
0x000000000230f220:   0000000000000008 0000000069ad43be
0x000000000230f230:   0000000000000000 000000000b32c7e0
0x000000000230f240:   000000000b4beda8 000000000b324b30
0x000000000230f250:   000000000a2cab80 0000000069894752
0x000000000230f260:   000000000b2a80e0 0000000000000000
0x000000000230f270:   000000000b304460 00000000698951b7

Instructions: (pc=0x00000000692a43c0)
0x00000000692a43a0:   45 8b 51 0c 49 8b 19 4c 03 d1 48 8b d3 4d 8d 42
0x00000000692a43b0:   f9 49 3b c8 73 1e 66 66 0f 1f 84 00 00 00 00 00
0x00000000692a43c0:   48 8b 02 48 83 c1 08 48 83 c2 08 48 89 41 f8 49
0x00000000692a43d0:   3b c8 72 ec 4d 8d 42 fd 49 3b c8 73 15 0f 1f 00


Register to memory mapping:

RAX=0x0000000000000010 is an unknown value
RBX=0x0000000000000000 is an unknown value
RCX=0x000000000ccfd000 is an unknown value
RDX=0x0000000000000000 is an unknown value
RSP=0x000000000230f180 is pointing into the stack for thread: 0x0000000001d3b800
RBP=0x000000000ccfd000 is an unknown value
RSI=0x0000000000000002 is an unknown value
RDI=0x0000000000000004 is an unknown value
R8 =0x000000000ccfd009 is an unknown value
R9 =0x000000000230f1c0 is pointing into the stack for thread: 0x0000000001d3b800
R10=0x000000000ccfd010 is an unknown value
R11=0x0000000000000002 is an unknown value
R12=0x000000006a6b2080 is an unknown value
R13=0x000000006a6d6ad8 is an unknown value
R14=0x0000000000000004 is an unknown value
R15=0x0000000000000001 is an unknown value


Stack: [0x0000000002210000,0x0000000002310000],  sp=0x000000000230f180,  free space=1020k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [atio6axx.dll+0x2743c0]  DrvPresentBuffers+0x211500

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  org.lwjgl.opengl.GL11.nglDrawArrays(IIIJ)V+0
j  org.lwjgl.opengl.GL11.glDrawArrays(III)V+20
j  com.grootmoeders.pgame.client.graphics.BufferedObject.draw()V+60
j  com.grootmoeders.pgame.testMain.run()V+158
j  com.grootmoeders.pgame.testMain.main([Ljava/lang/String;)V+15
v  ~StubRoutines::call_stub

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

Java Threads: ( => current thread )
  0x0000000006ac9000 JavaThread "Service Thread" daemon [_thread_blocked, id=3512, stack(0x0000000007490000,0x0000000007590000)]
  0x0000000006ac8000 JavaThread "C2 CompilerThread1" daemon [_thread_blocked, id=4224, stack(0x00000000078d0000,0x00000000079d0000)]
  0x0000000006ac2000 JavaThread "C2 CompilerThread0" daemon [_thread_blocked, id=4648, stack(0x00000000076d0000,0x00000000077d0000)]
  0x0000000006abf000 JavaThread "Attach Listener" daemon [_thread_blocked, id=2868, stack(0x0000000007590000,0x0000000007690000)]
  0x0000000006ab9800 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=3104, stack(0x0000000007270000,0x0000000007370000)]
  0x0000000001d03800 JavaThread "Finalizer" daemon [_thread_blocked, id=4024, stack(0x0000000007370000,0x0000000007470000)]
  0x0000000001cfc800 JavaThread "Reference Handler" daemon [_thread_blocked, id=2704, stack(0x0000000007140000,0x0000000007240000)]
=>0x0000000001d3b800 JavaThread "main" [_thread_in_native, id=3344, stack(0x0000000002210000,0x0000000002310000)]

Other Threads:
  0x0000000001cf5000 VMThread [stack: 0x0000000006e90000,0x0000000006f90000] [id=3128]
  0x0000000006ae0000 WatcherThread [stack: 0x0000000007a60000,0x0000000007b60000] [id=3948]

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: None

Heap
 PSYoungGen      total 76480K, used 6274K [0x00000007aaab0000, 0x00000007b0000000, 0x0000000800000000)
  eden space 65600K, 9% used [0x00000007aaab0000,0x00000007ab0d0bb0,0x00000007aeac0000)
  from space 10880K, 0% used [0x00000007af560000,0x00000007af560000,0x00000007b0000000)
  to   space 10880K, 0% used [0x00000007aeac0000,0x00000007aeac0000,0x00000007af560000)
 PSOldGen        total 174784K, used 0K [0x0000000700000000, 0x000000070aab0000, 0x00000007aaab0000)
  object space 174784K, 0% used [0x0000000700000000,0x0000000700000000,0x000000070aab0000)
 PSPermGen       total 21248K, used 4996K [0x00000006fae00000, 0x00000006fc2c0000, 0x0000000700000000)
  object space 21248K, 23% used [0x00000006fae00000,0x00000006fb2e1060,0x00000006fc2c0000)

Code Cache  [0x0000000002310000, 0x0000000002580000, 0x0000000005310000)
 total_blobs=351 nmethods=22 adapters=282 free_code_cache=48663Kb largest_free_block=49811072

Dynamic libraries:
0x000000013fbc0000 - 0x000000013fbf3000    C:\Program Files\Java\jdk1.7.0_03\bin\java.exe
0x0000000076d10000 - 0x0000000076ebc000    C:\Windows\SYSTEM32\ntdll.dll
0x0000000076af0000 - 0x0000000076c0f000    C:\Windows\system32\kernel32.dll
0x000007fefcf10000 - 0x000007fefcf7b000    C:\Windows\system32\KERNELBASE.dll
0x000007fefe880000 - 0x000007fefe95b000    C:\Windows\system32\ADVAPI32.dll
0x000007fefed90000 - 0x000007fefee2f000    C:\Windows\system32\msvcrt.dll
0x000007fefed60000 - 0x000007fefed7f000    C:\Windows\SYSTEM32\sechost.dll
0x000007fefd180000 - 0x000007fefd2ae000    C:\Windows\system32\RPCRT4.dll
0x0000000076c10000 - 0x0000000076d0a000    C:\Windows\system32\USER32.dll
0x000007fefefb0000 - 0x000007feff017000    C:\Windows\system32\GDI32.dll
0x000007fefed80000 - 0x000007fefed8e000    C:\Windows\system32\LPK.dll
0x000007fefda20000 - 0x000007fefdaea000    C:\Windows\system32\USP10.dll
0x000007fefb510000 - 0x000007fefb704000    C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7600.16661_none_fa62ad231704eab7\COMCTL32.dll
0x000007fefead0000 - 0x000007fefeb41000    C:\Windows\system32\SHLWAPI.dll
0x000007fefe960000 - 0x000007fefe98e000    C:\Windows\system32\IMM32.DLL
0x000007fefd5d0000 - 0x000007fefd6d9000    C:\Windows\system32\MSCTF.dll
0x0000000073ca0000 - 0x0000000073d71000    C:\Program Files\Java\jdk1.7.0_03\jre\bin\msvcr100.dll
0x0000000067ae0000 - 0x00000000681ba000    C:\Program Files\Java\jdk1.7.0_03\jre\bin\server\jvm.dll
0x000007fefb4f0000 - 0x000007fefb4f9000    C:\Windows\system32\WSOCK32.dll
0x000007fefd040000 - 0x000007fefd08d000    C:\Windows\system32\WS2_32.dll
0x000007fefd5c0000 - 0x000007fefd5c8000    C:\Windows\system32\NSI.dll
0x000007fefaa20000 - 0x000007fefaa5b000    C:\Windows\system32\WINMM.dll
0x0000000076ed0000 - 0x0000000076ed7000    C:\Windows\system32\PSAPI.DLL
0x00000000744f0000 - 0x00000000744ff000    C:\Program Files\Java\jdk1.7.0_03\jre\bin\verify.dll
0x0000000073c70000 - 0x0000000073c98000    C:\Program Files\Java\jdk1.7.0_03\jre\bin\java.dll
0x00000000744d0000 - 0x00000000744e5000    C:\Program Files\Java\jdk1.7.0_03\jre\bin\zip.dll
0x0000000180000000 - 0x000000018004f000    C:\Users\Administrator\.netbeans\7.1\lwjgl-2.8.3\native\windows\lwjgl64.dll
0x000007fef7030000 - 0x000007fef714d000    C:\Windows\system32\OPENGL32.dll
0x000007fef7000000 - 0x000007fef702d000    C:\Windows\system32\GLU32.dll
0x000007fef6f00000 - 0x000007fef6ff1000    C:\Windows\system32\DDRAW.dll
0x000007fef6ef0000 - 0x000007fef6ef8000    C:\Windows\system32\DCIMAN32.dll
0x000007fefd3e0000 - 0x000007fefd5b7000    C:\Windows\system32\SETUPAPI.dll
0x000007fefce90000 - 0x000007fefcec6000    C:\Windows\system32\CFGMGR32.dll
0x000007fefd940000 - 0x000007fefda17000    C:\Windows\system32\OLEAUT32.dll
0x000007fefeb50000 - 0x000007fefed52000    C:\Windows\system32\ole32.dll
0x000007fefcf80000 - 0x000007fefcf9a000    C:\Windows\system32\DEVOBJ.dll
0x000007fefafc0000 - 0x000007fefafd8000    C:\Windows\system32\dwmapi.dll
0x000007fefbbd0000 - 0x000007fefbbdc000    C:\Windows\system32\VERSION.dll
0x000007fefb8c0000 - 0x000007fefb916000    C:\Windows\system32\uxtheme.dll
0x000007fefb500000 - 0x000007fefb509000    C:\Windows\system32\atig6pxx.dll
0x0000000069030000 - 0x000000006a838000    C:\Windows\system32\atio6axx.dll
0x000007fef8ec0000 - 0x000007fef8ece000    C:\Windows\system32\atig6txx.dll
0x00000000723e0000 - 0x00000000724ba000    C:\Windows\system32\aticfx64.dll
0x0000000006920000 - 0x00000000069a2000    C:\Windows\system32\atiadlxx.dll
0x000007fefdaf0000 - 0x000007fefe876000    C:\Windows\system32\SHELL32.dll
0x000007fefbfc0000 - 0x000007fefbfde000    C:\Windows\system32\USERENV.dll
0x000007fefcc70000 - 0x000007fefcc7f000    C:\Windows\system32\profapi.dll
0x000007fefbbe0000 - 0x000007fefbbf1000    C:\Windows\system32\WTSAPI32.dll
0x000007fefced0000 - 0x000007fefcf0a000    C:\Windows\system32\WINTRUST.dll
0x000007fefcd20000 - 0x000007fefce86000    C:\Windows\system32\CRYPT32.dll
0x000007fefcd10000 - 0x000007fefcd1f000    C:\Windows\system32\MSASN1.dll
0x000007fefcba0000 - 0x000007fefcbaf000    C:\Windows\system32\CRYPTBASE.dll
0x000007fef6df0000 - 0x000007fef6e8c000    C:\Windows\system32\mscms.dll
0x000007fef4290000 - 0x000007fef42d2000    C:\Windows\system32\icm32.dll
0x0000000073c50000 - 0x0000000073c69000    C:\Program Files\Java\jdk1.7.0_03\jre\bin\net.dll
0x000007fefc4e0000 - 0x000007fefc534000    C:\Windows\system32\mswsock.dll
0x000007fefc4d0000 - 0x000007fefc4d7000    C:\Windows\System32\wship6.dll
0x0000000073c30000 - 0x0000000073c41000    C:\Program Files\Java\jdk1.7.0_03\jre\bin\nio.dll

VM Arguments:
jvm_args: -Dfile.encoding=UTF-8 -Djava.library.path=C:/Users/Administrator/.netbeans/7.1\lwjgl-2.8.3/native/windows
java_command: com.grootmoeders.pgame.testMain
Launcher Type: SUN_STANDARD

Environment Variables:
PATH=C:\Program Files (x86)\AMD APP\bin\x86_64;C:\Program Files (x86)\AMD APP\bin\x86;C:\Program Files (x86)\CollabNet\Subversion Client;C:\PHP\;C:\Program Files\Common Files\Microsoft Shared\Windows Live;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Drivers\ATI Technologies\ATI.ACE\Core-Static;C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\;C:\Program Files\Microsoft SQL Server\100\Tools\Binn\;C:\Program Files\Microsoft SQL Server\100\DTS\Binn\;C:\Program Files\MySQL\MySQL Server 5.5\bin;C:\Program Files\Common Files\Microsoft Shared\Windows Live
USERNAME=Administrator
OS=Windows_NT
PROCESSOR_IDENTIFIER=AMD64 Family 16 Model 4 Stepping 3, AuthenticAMD



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

OS: Windows 7 , 64 bit Build 7600

CPU:total 4 (4 cores per cpu, 1 threads per core) family 16 model 4 stepping 3, cmov, cx8, fxsr, mmx, sse, sse2, sse3, popcnt, mmxext, 3dnowpref, lzcnt, sse4a

Memory: 4k page, physical 16775672k(13419056k free), swap 33549448k(29656168k free)

vm_info: Java HotSpot(TM) 64-Bit Server VM (22.1-b02) for windows-amd64 JRE (1.7.0_03-b05), built on Feb  3 2012 20:43:56 by "java_re" with unknown MS VC++:1600

time: Mon Mar 05 15:52:37 2012
elapsed time: 0 seconds


Re: Problem rendering from buffers
« Reply #4 on: March 05, 2012, 15:20:42 »
Ah, I now know why GL_QUADS is not crashing the program: it is not recognized as a proper enum.

The biggest problem is that openGL does not have any way of showing me the error. I have no clue what is going wrong here, since the jvm instantly catches an access violation.

Re: Problem rendering from buffers
« Reply #5 on: March 06, 2012, 06:48:50 »
I found the problem.

Best way to describe it for futute people:
take a look at the lwjgl implementation of the OpenGL superbible example programs and the utilities:
http://code.google.com/p/opengl-superbible-java/source/browse/

The GLBatch implementation is really usefull if you want to learn how to render from video memory in openGL 3.3 core and above.

*

Offline spasi

  • *****
  • 2192
    • WebHotelier
Re: Problem rendering from buffers [SOLVED]
« Reply #6 on: March 06, 2012, 12:12:35 »
Could you share what the problem was and the solution that fixed it? Ideally use of LWJGL should never crash the JVM and we need such info to be able to add the right runtime checks.

Re: Problem rendering from buffers [SOLVED]
« Reply #7 on: March 06, 2012, 14:54:51 »
The code above misses calls to glVertexAttribPointer
The crash happend because the calls to these functions had the wrong order of arguments.
I think I copy pasted a GL_TRIANGLE_STRIP, where an offset was meant. (stride is the name for that right?).
Problem is that you cannot prevent the error as it is generated by opengl when opengl figures out that the offset is bigger than the entire array it crashes the program.
This value must be possible however, since the array can also be bigger than this value.

A solution is to print a warning when someone is using a value that is also used as enumerate value.
That way the problem can be determined while the program can still run if it is the purpose.

Just a suggestion, but if you guys really want to make the library easy to use, you should add some sort of debugging mode that checks this sort of stuff and warns the user.
Turning this mode off and recompiling makes the program faster, and without warning msgs.

Something like LWJGL.setDebug(true/false);

If this already exists, please add it to the tutorials.