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
p.
On 03/14/2015 09:01 PM, pierre@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
Le 16/03/15 21:54, IOhannes m zmölnig a écrit :
On 03/14/2015 09:01 PM, pierre@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@lists.iem.at http://lists.puredata.info/listinfo/gem-dev
hi,
I don't see any useful case where automatically resizing the VBO when giving an offset is needed and I think I never use the offset value yet. btw, if an offset is useful, a size of data-to-update should be useful too thus we can make some "table mapping"
+ a
-
Antoine Villeret -
IOhannes m zmölnig -
Pierre -
pierre＠314r.net