Re: [sdljava-users] Usage example for glGetDoublev
Status: Beta
Brought to you by:
ivan_ganza
Menu
▾
▴
Re: [sdljava-users] Usage example for glGetDoublev
|
From: Ivan Z. G. <iva...@ya...> - 2005-09-11 13:47:41
|
Hi Gregor,
I appreciate all feedback so don't worry. Please keep it coming. The
API needs to be actually _usable_ by others. You make a good point that
I did not consider. From what your saying it sounds like there should
be methods provided that just copy the data since it is so small. It
also seems like all OpenGL functions which are similar would want to
operate in a similar fashion. The problem is I'm not sure what all the
functions are which would operate on a small data set. I'm still very
new to OpenGL myself.
Would you give me a list of the funtions you need which should just copy
the data and I will add methods which do so.
Please send me back anything which can make the OpenGL layer more usable.
Thanks,
-Ivan/
Gregor M=FCckl wrote:
>Hi!
>
>My problem is that I really have to allocate these direct buffers on dem=
and=20
>for something like one or two opengl calls each. Furthermore, they reall=
y are=20
>quite small. The biggest buffer I use that way is there to store a matri=
x of=20
>4x4 doubles, that is, 128 bytes.
>
>Using byte buffers may be a valid approach when working on large, unifor=
m=20
>amounts of data like framebuffers. But that is not the case with geometr=
y=20
>data for OpenGL. Using vertex arrays is almost out of question for me si=
nce=20
>the geometry data I have is very dynamic in every way.
>
>Well, this is not trying to be a rant. I'm just not yet convinced that t=
his is=20
>the right approach. It looks like far too much overhead to me, making al=
l the=20
>OpenGL functions taking (small) arrays practically useless. Maybe some=20
>benchmarking is in order to get some definitive answers, but I don't hav=
e=20
>enough time for that.
>
>Regards,
>Gregor
>
>On Saturday 10 September 2005 23:39, Ivan Z. Ganza wrote:
> =20
>
>>Hi Gregor,
>>
>>The direct buffers introduced with NIO are better than sliced
>>bread...:-) Without them I don't think it would be possible to achiev=
e
>>any level of meaningfully performance.
>>
>>A direct buffer is mapped directly to a region of memory inside the
>>JVM's memory space. When you perform operations on a direct buffer the=
y
>>effect the memory directly and thus and are very fast. The other optio=
n
>>is to copy the data each time from the JVM's memory space into the
>>native code space (or visa versa). The copy method is an order of
>>magnitude slower. First the new array must be allocated. Then the dat=
a
>>must be copied into the array each time.
>>
>>For an idea of the speed difference look at the difference in execution
>>time between updating the screen using the two methods:
>>
>> ByteBuffer getPixelData()
>>
>>and
>>
>> public void setPixelData32(int[] pixelData)
>>
>>
>>If you are using these direct buffers you should allocate all the
>>buffers you need before doing anything. Then utilize them later howeve=
r
>>you wish. Otherwise the performance will be much worse if a new one is
>>constantly created. Notice that getPixelData() only creates the buffer
>>once. The buffer directly has access to the data of the surface!
>>
>>-Ivan/
>>
>>Gregor M=FCckl wrote:
>> =20
>>
>>>Hi, Ivan!
>>>
>>>Thanks for your help. Indeed, ByteBuffer.allocateDirect() is the right
>>>solution and it seems to work now. I cannot tell for sure yet as the
>>>gtk-based input handling is still not working properly and I therefore
>>>can't navigate the 3D view.
>>>
>>>However, I feel that relyinig on java.nio.ByteBuffer and derivates is =
a
>>>bit strange, especially given their somewhat peculiar design. Looking =
at
>>>the code I have now which has to copy data to newly created buffers ev=
ery
>>>time I need to pass an array to OpenGL, I get the feeling that this
>>>slower than dealing directly with arrays, which are readiy available i=
n
>>>my case and probably more optimizeable by the Java compiler and JVM.
>>>
>>>What was the reason for using these buffers instead of arrays? Am I
>>>missing something here?
>>>
>>>Regards,
>>>Gregor
>>>
>>>On Saturday 10 September 2005 01:37, Ivan Z. Ganza wrote:
>>> =20
>>>
>>>>Gregor,
>>>>
>>>>I had a look in the code and intact SDLSurface isn't a good example
>>>>because the buffer is created in the native code. Have a look at
>>>>ByteBufferPool instead.
>>>>
>>>>-Ivan/
>>>>
>>>>Gregor M=FCckl wrote:
>>>> =20
>>>>
>>>>>Hi!
>>>>>
>>>>>I"m trying to use glGetDoublev to read back the modelview and projec=
tion
>>>>>matrices from OpenGL. However, it looks like I'm doing something wro=
ng
>>>>>with the DoubleBuffers required for that.
>>>>>
>>>>>What I'm doing basically is in this code:
>>>>>
>>>>> GlewImpl gl;
>>>>> private ml.math.Matrix4 modelViewMatrix;
>>>>> private ml.math.Matrix4 projectionMatrix;
>>>>> private double viewFieldOfView;
>>>>> private DoubleBuffer matrixBuffer;
>>>>>
>>>>> public ViewWindowSpace(Widget parent)
>>>>> {
>>>>> super();
>>>>>
>>>>> matrixBuffer=3DDoubleBuffer.allocate(16);
>>>>> modelViewMatrix=3Dnew Matrix4();
>>>>> projectionMatrix=3Dnew Matrix4();
>>>>>
>>>>> currentRenderMode=3DRenderMode.Solid;
>>>>>
>>>>> initGLContext();
>>>>>
>>>>> // snip: unrelated code
>>>>>
>>>>> addListener(new LifeCycleListener() {
>>>>>
>>>>> public void lifeCycleEvent(LifeCycleEvent e)
>>>>> {
>>>>> // TODO Auto-generated method stub
>>>>> if(e.getType()=3D=3DLifeCycleEvent.Type.REALIZE) {
>>>>> setupViewingAreaInitial();
>>>>> }
>>>>>
>>>>> }
>>>>> }
>>>>>
>>>>> // snip: unrelated code
>>>>> }
>>>>>
>>>>> protected void setupViewingAreaInitial()
>>>>> {
>>>>> viewFieldOfView=3D45.0;
>>>>>
>>>>> glBegin();
>>>>> GlewJNI.SWIG_glew_init();
>>>>> gl=3Dnew GlewImpl();
>>>>> int width =3D getWidth();
>>>>> int height =3D getHeight();
>>>>> gl.glViewport(0, 0, width, height);
>>>>> gl.glMatrixMode(GL.GL_PROJECTION); // select the projecti=
on
>>>>>matrix
>>>>> gl.glLoadIdentity(); // reset the
>>>>>projection matrix
>>>>> float fAspect =3D (float) width / (float) height;
>>>>> gl.gluPerspective(viewFieldOfView, fAspect, 0.5f, 400.0f);
>>>>> gl.glMatrixMode(GL.GL_MODELVIEW); // select the modelvie=
w
>>>>>matrix gl.glLoadIdentity();
>>>>>
>>>>> gl.glGetDoublev(GL.GL_MODELVIEW_MATRIX,matrixBuffer);
>>>>> modelViewMatrix.setFromOpenGLMatrix(matrixBuffer);
>>>>> gl.glGetDoublev(GL.GL_PROJECTION_MATRIX,matrixBuffer);
>>>>> projectionMatrix.setFromOpenGLMatrix(matrixBuffer);
>>>>>
>>>>> glEnd();
>>>>> }
>>>>>
>>>>>What this does:
>>>>>
>>>>>The constructor allocates the DoubleBuffer in question and registers=
an
>>>>>event handler to do the rest of the initialilsation once the opengl
>>>>>context can actually be used. When this is the case,
>>>>>setupViewingAreaInitial is called to perform the init of the gl cont=
ext.
>>>>>This fails with a NullPointerException in the first call to
>>>>>gl.glGetDoublev(). The console output for this exception is as follo=
ws:
>>>>>
>>>>>Exception in thread "main" java.lang.NullPointerException: null addr=
ess
>>>>>returned from GetDirectBufferAddress() call. Make sure the buffer i=
s a
>>>>>_direct_ buffer.
>>>>> at org.gljava.opengl.x.swig.GlewJNI.glGetDoublev(Native Method)
>>>>> at org.gljava.opengl.impl.glew.GlewImpl.glGetDoublev(GlewImpl.java:=
143)
>>>>> at
>>>>>ml.ui.plugins.view.ViewWindowSpace.setupViewingAreaInitial(ViewWindo=
wSpa
>>>>>ce .java:322) at
>>>>>ml.ui.plugins.view.ViewWindowSpace$2.lifeCycleEvent(ViewWindowSpace.=
java
>>>>>:2 77) at org.gnu.gtk.Widget.fireLifeCycleEvent(Widget.java:735)
>>>>> at org.gnu.gtk.Widget.handleRealize(Widget.java:764)
>>>>> at org.gnu.gtk.Widget.gtk_widget_show(Native Method)
>>>>> at org.gnu.gtk.Widget.show(Widget.java:119)
>>>>> at ml.core.State.createMainWindow(State.java:158)
>>>>> at ml.ML3D.<init>(ML3D.java:49)
>>>>> at ml.ML3D.main(ML3D.java:66)
>>>>>
>>>>>I have no clue why this happens. Do I initialize the DoubleBuffer in
>>>>>question badly? Is there any example that shows how it should be don=
e?
>>>>>Any help would be appreciated.
>>>>>
>>>>>Regards,
>>>>>Gregor
>>>>>
>>>>>
>>>>>-------------------------------------------------------
>>>>>SF.Net email is Sponsored by the Better Software Conference & EXPO
>>>>>September 19-22, 2005 * San Francisco, CA * Development Lifecycle
>>>>>Practices Agile & Plan-Driven Development * Managing Projects & Team=
s *
>>>>>Testing & QA Security * Process Improvement & Measurement *
>>>>>http://www.sqe.com/bsce5sf
>>>>>_______________________________________________
>>>>>sdljava-users mailing list
>>>>>sdl...@li...
>>>>>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>>>> =20
>>>>>
>>>>-------------------------------------------------------
>>>>SF.Net email is Sponsored by the Better Software Conference & EXPO
>>>>September 19-22, 2005 * San Francisco, CA * Development Lifecycle
>>>>Practices Agile & Plan-Driven Development * Managing Projects & Teams=
*
>>>>Testing & QA Security * Process Improvement & Measurement *
>>>>http://www.sqe.com/bsce5sf
>>>>_______________________________________________
>>>>sdljava-users mailing list
>>>>sdl...@li...
>>>>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>>> =20
>>>>
>>>-------------------------------------------------------
>>>SF.Net email is Sponsored by the Better Software Conference & EXPO
>>>September 19-22, 2005 * San Francisco, CA * Development Lifecycle
>>>Practices Agile & Plan-Driven Development * Managing Projects & Teams =
*
>>>Testing & QA Security * Process Improvement & Measurement *
>>>http://www.sqe.com/bsce5sf
>>>_______________________________________________
>>>sdljava-users mailing list
>>>sdl...@li...
>>>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>>> =20
>>>
>>-------------------------------------------------------
>>SF.Net email is Sponsored by the Better Software Conference & EXPO
>>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Pract=
ices
>>Agile & Plan-Driven Development * Managing Projects & Teams * Testing &=
QA
>>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5=
sf
>>_______________________________________________
>>sdljava-users mailing list
>>sdl...@li...
>>https://lists.sourceforge.net/lists/listinfo/sdljava-users
>> =20
>>
>
>
>-------------------------------------------------------
>SF.Net email is Sponsored by the Better Software Conference & EXPO
>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practi=
ces
>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & =
QA
>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5s=
f
>_______________________________________________
>sdljava-users mailing list
>sdl...@li...
>https://lists.sourceforge.net/lists/listinfo/sdljava-users
> =20
>
|
