Hello,
I would like to ask if jogl will use NIO Buffers(direct memory access-or smoething like that) in the future?
Are NIO buffers could be faster then using arrays as parameters in gl calls?
Thanks.
Er, Jogl does already use NIO bufferes, it just happens to have equivilent methods that accept regular java arrays as well. Is there anything specific you’re after?
Oh, my english is very bad, sorry…
OK, I know there is a variant of every methods using NIO buffers. I mean, that why isn’t the NIO is the default parameter, why other paramter types are needed…
Are they faster then normal arrays?
correct me if I’m wrong, but jogl’s methods are overlead for each one containing an array as a parameter and wrapping a single primitive types into a buffer doesn’t make sense at all.
To my knowloge Buffer are used because without them array data is copied by passing through. As far this is no real enhancement, because one has to copy the dymamic data, which changes and therefore has to be sent every frame to the graphics card, into the buffer instead. What really saves time and resources is that the buffers are usually allocates ones and the JNI had to do that every time a method with an array argument is called in order to copy the data.
Primitives types are copied always (copy by value), which should make ne real difference using JNI. (Probably it does, since leaving the VM problably comes with a certain overhead).
Some OpenGL APIs, such as glVertexPointer, require that the data stay in the same place in memory. Such APIs require direct NIO Buffers as arguments since their storage is allocated outside of the Java heap and does not move. The JOGL APIs which take array arguments are provided as a convenience because they don’t have this requirement.
FYI, the JSR-231 APIs will translate these OpenGL entry points taking void* arguments into only Buffers, and the Javadoc (and run-time checks) will specify that the buffer may or may not be “indirect”.
I tried to pass 3 float to the method: glUniform3fARB
I created a FloatBuffer in the contructor:
buff1 = BufferUtils.newFloatBuffer( 3 );
buff1.put( 0, sun[0] );
buff1.put( 1, sun[1] );
buff1.put( 2, sun[1] );
Then , in the drawing fuction I replaced:
gl.glUniform3fARB( sunpos[0], sun[0], sun[1], sun[2] );
with this: gl.glUniform3fvARB( sunpos[0], 3, buff1 );
and my terrain is black. If I use the old code, the program is working fine. What have I made wrong with FloatBuffer?
Anyway, Is there any differences between glUniform3f and glUniform3fARB?
The above code looks correct to me aside from the z coordinate of the sun’s position in the FloatBuffer.
glUniform3f is only available if your drivers support OpenGL 2.0. glUniform3fARB is available as an extension if your drivers provide it.
Thanks, You are wright. I modefied the sun coordinate, but the code doesn’t still work.
I set in my GLEventListener object: glDrawable.setGL(new DebugGL(glDrawable.getGL()));
and I got this exception:
Caused by: net.java.games.jogl.GLException: glGetError() returned the following error codes after a call to glUniform3fv(): GL_INVALID_VALUE
at this line : gl.glUniform3fv( sunpos[0], 3, buff1 );
Did you replace glUniform3fARB with glUniform3fv? In this case you should probably use glUniform3fvARB. However I think this would have produced a different error. If glUniform3fARB was working for you, I would just leave the code alone. You’re not going to get any performance increase by using an NIO buffer here.
OK, thanks. I replaced the code line with glUniform3fvARB, but the code thrown an exception this time too.
I don’t know the reason of the problem, so I should use the previously working code.