Another variant for glBufferData?

classic Classic list List threaded Threaded
10 messages Options
adi
Reply | Threaded
Open this post in threaded view
|

Another variant for glBufferData?

adi
Hello

I use in the the moment

public void init(GLAutoDrawable glDrawable)
{
...........................
FloatBuffer vertexBuffer     ............................                
final GL4 gl = glDrawable.getGL().getGL4();
gl.glBufferData( GL4.GL_ARRAY_BUFFER, vertexBuffer.capacity()<<2, vertexBuffer, GL4.GL_STATIC_DRAW );

...............

Is there something planned in the future that i can use float arrays instead?
e.g.
float vertexBuffer[]          ..........
with
gl.glBufferData( GL4.GL_ARRAY_BUFFER, vertexBuffer.length<<2 vertexBuffer, GL4.GL_STATIC_DRAW );
  ???


 

 
Reply | Threaded
Open this post in threaded view
|

Re: Another variant for glBufferData?

gouessej
Administrator
Hi

It would be a bad idea as anyway a direct NIO buffer would have to be created under the hood in order to communicate with native OpenGL.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: Another variant for glBufferData?

Sven Gothel
Administrator
On 08/22/2014 01:30 AM, gouessej [via jogamp] wrote:
> Hi
>
> It would be a bad idea as anyway a direct NIO buffer would have to be created
> under the hood in order to communicate with native OpenGL.

+++

Our API doc says:

  /** Entry point to C language function: <code> void {@native
glBufferData}(GLenum target, GLsizeiptr size, const GLvoid *  data, GLenum
usage) </code> <br>Part of <code>GL_VERSION_1_5</code>,
<code>GL_ES_VERSION_2_0</code>, <code>GL_VERSION_ES_CL_CM</code>
      @param data a direct or array-backed {@link java.nio.Buffer}

++

The manual page does not make it specific whether the client storage
must exist past function call:
  https://www.opengl.org/sdk/docs/man/html/glBufferData.xhtml

Hence it would be legal w/ an array-backed client storage,
even though your mileage may vary on certain OpenGL drivers .. (bugs).

In short, if you prefer, use an array backed FloatBuffer (non NIO),
however - AFAIK our unit tests have not covered this variation.

~Sven



signature.asc (828 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Another variant for glBufferData?

jmaasing
Sven Gothel wrote
The manual page does not make it specific whether the client storage
must exist past function call:
  https://www.opengl.org/sdk/docs/man/html/glBufferData.xhtml

Hence it would be legal w/ an array-backed client storage,
even though your mileage may vary on certain OpenGL drivers .. (bugs).
Yes, this was confusing to me also in the beginning. I started out generating meshes into heap memory for processing but then it was unclear to me the best way to pass data into the GL-methods.
Maybe there is some way to include in the javadoc a pointer to a "best practice" description, e.g. "You can use the helper classes in com.jogamp.common.nio.Buffers to create a suitable buffer" in those cases where it makes sense.
Reply | Threaded
Open this post in threaded view
|

Re: Another variant for glBufferData?

Sven Gothel
Administrator
On 08/22/2014 01:37 PM, jmaasing [via jogamp] wrote:

>     Sven Gothel wrote
>     The manual page does not make it specific whether the client storage
>     must exist past function call:
>       https://www.opengl.org/sdk/docs/man/html/glBufferData.xhtml
>
>     Hence it would be legal w/ an array-backed client storage,
>     even though your mileage may vary on certain OpenGL drivers .. (bugs).
>
> Yes, this was confusing to me also in the beginning. I started out generating
> meshes into heap memory for processing but then it was unclear to me the best
> way to pass data into the GL-methods.
> Maybe there is some way to include in the javadoc a pointer to a "best
> practice" description, e.g. "You can use the helper classes in
> com.jogamp.common.nio.Buffers to create a suitable buffer" in those cases
> where it makes sense.
Agreed - do it!

~Sven



signature.asc (828 bytes) Download Attachment
adi
Reply | Threaded
Open this post in threaded view
|

Re: Another variant for glBufferData?

adi
In reply to this post by Sven Gothel
Hi

I see. I have thinked there must be an pointer to datas,
not necessary an nio-Buffer. In C++ there are no nio-buffers
i think, simple float arrays there are adequate.

A little problem is i must first convert all datas to
nio-Buffers. The main problem is, i can not serialize
classes that have datas in nio-buffers.  
 

Reply | Threaded
Open this post in threaded view
|

Re: Another variant for glBufferData?

gouessej
Administrator
You can override the serialization in order to support NIO buffers if you use a Java beans XML encoder. Otherwise, you can override the serialization to add your own code to encode and decode NIO buffers or use another object during serialization.
Julien Gouesse | Personal blog | Website
adi
Reply | Threaded
Open this post in threaded view
|

Re: Another variant for glBufferData?

adi
Hi

The problem is another. If i have put all datas in vbo's, the nio buffers are
all deleted.  There are situations where my complete scenegraph must be serialized.
Now, the nio buffers are gone before, so that the objects can't created from a
de-serialization. Problem in my opinion is the method glBufferData that
can only handle nio-buffers and not simple float array's.
What says the opengl Reference?
Must buffer parameters in opengl functions forced to set with nio buffers in java?
 
Reply | Threaded
Open this post in threaded view
|

Re: Another variant for glBufferData?

Sven Gothel
Administrator
On 08/31/2014 03:30 AM, adi [via jogamp] wrote:

> Hi
>
> The problem is another. If i have put all datas in vbo's, the nio buffers are
> all deleted.  There are situations where my complete scenegraph must be
> serialized.
> Now, the nio buffers are gone before, so that the objects can't created from a
> de-serialization. Problem in my opinion is the method *glBufferData* that
> can only handle nio-buffers and not simple float array's.
> What says the opengl Reference?
> Must buffer parameters in opengl functions forced to set with nio buffers in
> java?
this is answered by the lifecycle requirement
of the data passed to the GL functions,
i.e. is the data/reference still used after
the gl function returns ?
If the answer is YES, you have to use NIO buffers.
Reason: passing a java array will use GC pinned memory
passing to the native function, only valid during function call.

Here: Probably yes .. depending on deferred execution of GL driver.

BTW .. if you like to stream data, maybe you like to use GL mmap,
i.e. glMapBuffer[Range] ?

~Sven



signature.asc (828 bytes) Download Attachment
adi
Reply | Threaded
Open this post in threaded view
|

Re: Another variant for glBufferData?

adi
Ah thanks Sven,

that can be an solution.