[GEM-dev] gemvertexbuffer bug ?

[IOhannes m zmölnig]

On 03/14/2015 09:01 PM, pierre at 314r.net wrote:
> Hello,
> is this a bug or something that I dont understand (?) :
> [gemvertexbuffer] don't update correctly (ie reset to 0) values of the
> last index of the table data :
> - 'posX' values are good, but the last 'posY' value is wrong as the last
> two values of 'posZ' are wrong too
> - with 'position' message, the values are good
> see attached patch

indeed this is a bug.
i think i have fixed it in current git.

i might have broken some things while attempting to fix this, however.
esp. i'm unsure about the "offset" when setting the tables.

the main problem is that it is a bit unclear to me, when the
vertexbuffer (vb) should be resized, when it should be left untouched
and when it should just grow.

if i read the code correctly, the vb is *always* resized, and *wrongly
resized* when you specify an offset.

what is the desired behaviour?
esp. when providing an offset, i think the vb should not be resized to
the table-length (though probably it should grow so the entire table
fits into the vb).
i'm thinking of it in terms of "simple mode" (just provide the table(s)
you want to "be" the vertexbuffer) and "expert mode" (where you want to
have full control, but where you also need to fully control)

e.g. assuming that "foo" holds 24 samples
- [position foo( should resize the position-vb to exactly 8 XYZ values.
- [position foo 10( should ensure that the position-vb can hold at least
18 (10+8) XYZ values.
- [position foo 0( should ensure that the position-vb can hold at least
8 (10+0) XYZ values.

alternatively, we could say that providing an offset will never resize
the vb, making this mode even more "expert" (rather than making it a
half-expert thing).

what do you (mostly: antoine, cyrille; but of course everbody else as
well) think?

gfmadsr
IOhannes

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20150316/67711cdd/attachment.sig>