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? ... _______________________________________________ GEM-dev mailing list [email protected] http://lists.puredata.info/listinfo/gem-dev
