[GEM-dev] gemvertexbuffer (prev.. vertex operations / vertex_* (prev.. gem port to opengl-es - initial developments..))

Cyrille Henry ch at chnry.net
Wed Feb 8 13:06:10 CET 2012



Le 08/02/2012 04:44, dmotd a écrit :
...

> and of course i object ;)
> i see it as a flexible storage object which has a basic primitive
> routine attached.

that's why we do not agree ;-)
it's the same the difference than between cube and gl_begin/gl_vertex/gl_vertex/gl_vertex/gl_vertex/gl_end.
The 1st is simpler to user, but less flexible.  Most peoples use the cube object.
here, we choose the easiest solution, not the most flexible. (less work for most functionality).
the most flexible solution (vertex_* object) was deprecated before being part of main.


>
> yes precisely, that's my argument for separating, part of the reason why
> you'd use a vbo is that it's stored on gpu and fast for that reason. the
> vbo is designed as persistent storage, a model can be loaded once and
> bound as many times as needed.
>
> i think it's a similar argument for using soundfiler to load audio into
> tables, as opposed to working directly off a disk (with readsf~ etc),
> and there are obvious non-linear benefits to using tables as storage.
>
> futher a vbo can be used to store more than one model, we can
> selectively edit only part of the buffer with a BufferSubData, or
> selectively display part of a buffer with a different offset/size to
> DrawArrays.
it's possible to add this functionality to the curent gemvertexobject.

>
> for example, we may just want to edit the position of a single vertex
> (or color/texcoord/etc), instead of reloading the entire model from
> client to the buffer, we can edit the vbo in vram at a specified offset
> for a size of one.
this feature can also be added.

>
>>> and multiple draw
>>> routines could bind to the same buffer.
>>>
>> as any other primitive, you can connectmultiple gemhead to a single gemvertexbuffer.
>
> that's true, but i'm not sure it's a widely used feature, my sense is
> that people will create multiple gemvertexbuffer instead.

because most people don't need optimisation.
using pd/Gem is because it's fast to develop, even if execution is slower than a C code.



>
>>> i think this should certainly be integrated into the core gem, and while
>>> the name makes sense for an outside external simply vertexbuffer or
>>> vtx_buffer would be more appropriate?
>>>
>>> i'll happily put these thoughts into code, but would like some feedback
>>> before i do.
>>
>> i don't really see a strong interest splinting gemvertexbuffer in 2 different objects, but if you do so, and if you are ready to code it, then i have no objection, as long as you can provide a compatible abstraction that replace the current gemvertexbuffer object.
>
> of course, i wouldn't want to break your current functionality.
>
> thanks for taking the time to reply.
thanks for taking time to improve Gem.

cheers
Cyrille

>
>
>> what about Antoine and Iohannes?
>
> ...
>
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev
>



More information about the GEM-dev mailing list