[GEM-dev] gemvertexbuffer (prev.. vertex operations / vertex_* (prev.. gem port to opengl-es - initial developments..))

Cyrille Henry ch at chnry.net
Tue Feb 7 17:31:03 CET 2012


hello,


Le 07/02/2012 15:09, dmotd a écrit :
> hi cyrille, antoine,
>
> thanks to both of you for the gemvertexbuffer code, i have it working in
> opengl-es on my phone.
good
>
> i started work on a similar object until i saw the message from
> iohannes.
>
> some observations..
>
> kind of trivial, but can i request you not put a loadbang on gemwin
> rendering messages, was a bit of a rude shock for my phone to load an
> example patch with 60000 vertexes across four arrays! ;)
>
> 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.

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?


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

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

>and multiple draw
> routines could bind to the same buffer.
>
as any other primitive, you can connectmultiple gemhead to a single gemvertexbuffer.

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

what about Antoine and Iohannes?

cheers
Cyrille


>
> thanks again for your efforts.
>
> cheers,
> dmotd
>
> On Mon, 2012-02-06 at 14:48 +0100, Cyrille Henry wrote:
>>
>> Le 06/02/2012 14:35, IOhannes m zmoelnig a écrit :
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 2012-02-04 17:23, dmotd wrote:
>>>> it makes sense to resurrect some of vertex_* code and clean it up,
>>>> although i'm a little hesitant about working with it directly as it has
>>>
>>> personally i would like to get rid of it entirely - i simply haven't had
>>> the heart yet to do so...
>>>
>>> i think a simpler approach is taken using the new [gemvertexbuffer]
>>> object (by cyrille and antoine), which basically allows to use a table
>>> as VBO input.
>>> shouldn't that be enough for your needs?
>>> most Geos could be implemented as an abstraction based on
>>> [gemvertexbuffer] (who's first?)
>>
>> I think it would also be nice to have the vertex_model to be ported to gemvertexbuffer.
>> i.e : having a model2table object.
>>
>> except for that functionality, shaders and gemvertexbuffer should be enough for everyone.
>>
>> cyrille
>>
>>>
>>> fgmadsr
>>> IOhannes
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.11 (GNU/Linux)
>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>>
>>> iEYEARECAAYFAk8v1wEACgkQkX2Xpv6ydvSG9wCfXLMG58NwJCVEumrpuDVzzBgC
>>> fkUAnjlVVK07gTQKmanSSrSURqqMNE4b
>>> =xrgn
>>> -----END PGP SIGNATURE-----
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> GEM-dev mailing list
>>> GEM-dev at iem.at
>>> http://lists.puredata.info/listinfo/gem-dev
>>
>> _______________________________________________
>> GEM-dev mailing list
>> GEM-dev at iem.at
>> http://lists.puredata.info/listinfo/gem-dev
>
>
>



More information about the GEM-dev mailing list