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

[dmotd]

On Tue, 2012-02-07 at 17:31 +0100, Cyrille Henry wrote:
> > the buffer is initialized with a default size 256*256 (not huge i know,
> > but enough to push graphics memory in small devices), it's okay to
> > fallback on a default but really the buffer size should be taken from an
> > argument to the object.
> the buffer size IS taken from the object argument. 256x256 is only the default if no argument is provided.

sorry, this was true for the version i ran from the mailing-list, not of
the version in the gem git.

> the help patch was not design to run on very low memory device. I don't know any GEM policy around this question.
> What is the minimum device help patch should run to?

not a criticism of your patch, and i have no problems with demonstrating
more demanding functionality. it was more that it began rendering before
the patch had even completed loading on screen - this is resolved.

> > one thought is that the buffer and drawing routines could be separated
> > to different objects, so you could run more simple drawing routines
> > (DrawElements) with lists from the client (and if i understand hans
> > right, i think that would make him happy too). i also think it's
> > potentially confusing that a buffer has a built in display routine and
> > inconsistent with other forms of storage throughout pd.
> 
> see this object as a (flexible) primitive, not aform of storage...

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

> >
> > i'd like to see the vertexbuffer placed on an independent gemhead (like
> > world_light), and called by named by a vertexdraw object. that way the
> > vertexdraw object could easily switch between buffers
> 
> i don't understand why this would be better than different gemvertexbuffer
> 
> 
> > and draw from the
> > strengths of having it stored in graphics memory,
> curently, buffer are stored in GPU.

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.

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.

> >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.

> > 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.


> what about Antoine and Iohannes?

...