[GEM-dev] gemvertexbuffer bug ?

[Pierre]

Le 16/03/15 21:54, IOhannes m zmölnig a écrit :
> 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.

Hi,
thanks,
it seems ok now

p.


> 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
>
>
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at lists.iem.at
> http://lists.puredata.info/listinfo/gem-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20150320/9c729a9d/attachment.html>