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