i guess i better add some primitives then...

which leads me to a few questions..

as gles removes fixed primitives in favour of vertex arrays, i thought i'd look at the code from src/Vertex.

the draw function looks promising but vertex_model relies on GLM/GLSL to build. i can safely build around it but does that defeat the purpose of the extension? can i generate a geo without vertex_model? there's no examples for how to build a rendering chain but i assume it's something like: [model]-->[manipulator]-->[draw]

is the Vertex code obsolete? there's a lot of references to apple/altivec which suggests that it was designed for a certain arch/gfxcard and browsing the ml logs seems to support that (with some references to building on windows). my last major forays into Gem were with some pretty bogus cards with typically flakey linux drivers, so please excuse my ignorance.

thanks, dmotd

On Fri, 2012-02-03 at 17:04 +0100, IOhannes zmölnig wrote:

On 02/03/2012 01:53 PM, dmotd wrote:

...

is the Vertex code obsolete? there's a lot of references to apple/altivec which suggests that it was designed for a certain

i don't think there was a release ever that included the [vertex_*] objectfamily. as you guessed, they were developped mainly (almost: exclusively) by our apple faction (chris & jamie), and have not been touched for years.

I've always been curious about those, it seems like a promising idea, anyone know if that's true, and why that stuff was abandoned?

.hc

On Fri, 2012-02-03 at 17:04 +0100, IOhannes zmölnig wrote:

On 02/03/2012 01:53 PM, dmotd wrote:

...

is the Vertex code obsolete? there's a lot of references to apple/altivec which suggests that it was designed for a certain

i don't think there was a release ever that included the [vertex_*] objectfamily. as you guessed, they were developped mainly (almost: exclusively) by our apple faction (chris & jamie), and have not been touched for years.

okay, i think i'm up to speed, been reading through mailing list logs and browsing the code, so i have a better understanding of the intentions of cgc and tigital with their vertex experiments..

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 a pretty limited scope and the structure is a bit loose and abstracted. i also don't want to break anyones patches who might still be using their code, or require it for running legacy work.

perhaps a good compromise is to create a separate set of lower level vertex objects and in future wrap the vertex_* code in abstractions or a general purpose vertex class?

is the vtx_ prefix available, a quick scan suggests so? if so i'll start naming new vertex related objects thus to differentiate (and it matches nicely to the three letter shortening of pix).

in related news, i now have a simple vertex-array triangle interacting with gem manips and i can confirm that 'view' and 'perspec' messages to the gemwin are operational. good fun!

i'm currently thinking the best way to replace basic geos is to wrap a vtx_array/draw procedure in a pd abstraction instead of hard coded objects. the abstractions could be included using autotools when a combination of --disable-Geos and --enbable-Vertex are set. any thoughts or am i being short sighted?

cheers! dmotd

ps.. i'll cleanup the code tomorrow or monday and push to github. still haven't tested a qemu environment either, but both tasks should be good motivation for the other.

-----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?)

fgmadsr IOhannes

hi cyrille, antoine,

thanks to both of you for the gemvertexbuffer code, i have it working in opengl-es on my phone.

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.

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.

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 and draw from the strengths of having it stored in graphics memory, and multiple draw routines could bind to the same buffer.

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.

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

---

GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev

On Wed, 2012-02-08 at 00:34 +1000, Patrick King wrote:

oops, i grabbed the code from the ml instead of from the branch, didn't see the follow up in the archives.. not sure if my observations still stand, sorry if things have changed massively! checkout now..

checked out master.. same comments apply (except the note about rendering loadbang)

amd i'm not convinced this should be categorized as a geo.

cheers, dmotd

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?

...

Le 08/02/2012 09:32, IOhannes m zmoelnig a écrit : ...

no problems from my side. i don't especially like the _name_ [gemvertexbuffer] (it is too similar to [gemframebuffer] (which goes well with [gemwin]), but the functionality/usage is very different), and if it was made into an abstraction, all the better.

i don't have any objection changing this name : this object is so new that nobody should have already used it.

cheers cyrille

one could also use something like [pix_texture], that applies textures that it either generated itself (from a pix) or that was generated somehow else (by taking the texture id in it's 2nd inlet). but i'm not so sure that this scales well for the different VBO types.

fgmasdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8yMy0ACgkQkX2Xpv6ydvTSEgCeOrsIy34fUJO0K7K1yxxZ0+Tz d5sAnigbwBE47x3mq7zrhxkYlo7sUI+7 =0fBX -----END PGP SIGNATURE-----

---

GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev

Le 08/02/2012 04:44, dmotd a écrit : ...

and of course i object ;) i see it as a flexible storage object which has a basic primitive routine attached.

that's why we do not agree ;-) it's the same the difference than between cube and gl_begin/gl_vertex/gl_vertex/gl_vertex/gl_vertex/gl_end. The 1st is simpler to user, but less flexible. Most peoples use the cube object. here, we choose the easiest solution, not the most flexible. (less work for most functionality). the most flexible solution (vertex_* object) was deprecated before being part of main.

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.

it's possible to add this functionality to the curent gemvertexobject.

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.

this feature can also be added.

...

...

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.

because most people don't need optimisation. using pd/Gem is because it's fast to develop, even if execution is slower than a C code.

...

...

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.

thanks for taking time to improve Gem.

cheers Cyrille

...

what about Antoine and Iohannes?

...

---

GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev

One thing that shaders really don't cover is doing this stuff with boxes and lines. That's why I was excited about the vertex objects. I think that it would be possible to make the vertex objects the easy way into all this stuff, for people who are likely to never touch shaders. I teach a lot of people who really try to avoid writing C/Java like code, they dislike even things like Processing and switch to Pd/Max because it fits there brain.

.hc

On Feb 6, 2012, at 9:33 AM, chris clepper wrote:

Go ahead and remove it. It was abandoned when it became clear the VBO option with shaders is the better solution.

On Mon, Feb 6, 2012 at 8:35 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote: -----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?)

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

---

GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev

----------------------------------------------------------------------------

If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it. - Thomas Jefferson

Wow, nice, well done! Each Hello World still seems to be as fun as the first :)

.hc

On Feb 3, 2012, at 3:32 AM, dmotd wrote:

i have [random] colour cycling the gemwin..

[color $1 $2 $3(--->[gemwin]

so we have a render context albeit a pretty rudimentary one.

i think i could watch it for hours ;)

i am however getting a repeated "invalid enumeration" error.. not sure where that's from but it doesn't seem to effect operation, then again there's no objects in the rendering chain.. it must be somewhere in the rendering context though or else it would be cleared.

i guess i better add some primitives then...

On Thu, 2012-02-02 at 03:30 +1000, dmotd wrote:

...

hi gem folks,

i've had a bit of free time to begin porting gem to opengl-es.

i'm building and testing with a nokia-n900/RX51 tablet - a debian based arm arch which supports both opengl-es 1.1 common and opengl-es 2.0.

initial hacking is concentrated on opengl-es 1.1, which is generally compatible to the opengl 1.0 spec. opengl-es 2.0 uses shaders to replace fixed functions so there is a lot more work involved in replacing core gem functions.

i'm using the egl spec for windowing/surface/buffer support, it is cross platform (although afaik apple uses its own modification 'aegl'). it provides basic functionality for reading and writing gl functions to buffer (along the lines of glx), and like glx still relies on operating system apis to supply other interfaces (keyboard / mouse etc).

so far:

cloned gem git, checkout 0.93 tag, created es branch.

using glues for basic (incomplete) glu functionality

using libglutes for basic (incomplete) glut functionality

added additional autoconf tricks to find and test libraries

merged the latest git ES branch of GLEW which has experimental support for GLES/EGL

added egl drop in for GemWinCreate

successful build against pd-0.43 using enable-Controls and others disabled. --

reports:

libxxf86vm doesn't seem to work properly on the tablet, so for the time being the window modelines are hard coded. there are some other window manager hints that are specific to the device too.

gemwin successfully creates the egl window buffer and rendering context.

gem crashes when glClearDepthf and glFrustumf are called (both are floating-point variations to the base GL functions and part of the GL-ES spec). furthermore looking at the output of 'nm -C Gem.pd_linux' shows that these functions are not present in the compiled lib, what does this mean?

commenting these functions out allows the gemwin to complete init and create successfully. a call to render causes a crash somewhere in the rendering chain (GemMan::render), but i have had little success debugging this issue. --

notes:

i'm developing with an eye on the raspberry pi project which should bring affordable opengl-es architecture to a small form factor, perfect for installations of (audio)visual artwork - but there's no reason why any recent (jailbroken) mobile/tablet technologies wouldn't be applicable for creative repurposing.

before anyone get's excited, the apple 'app store' is still afaik not compatible with gpl code, so it is unlikely there will be a 'rjdj' style app using gem, or likewise any gem based vj app, i don't think the same can be said for google's android platform, but i'm not a user or developer of said platform (or the fruit for that matter).

i am coding on a linux-amd64 pc, cross-compiling in scratchbox and testing on the device, using git/scp as a go-between.. this is a bit cumbersome/inefficient - can anyone suggest a virtual machine image (linux based) that provides a graphical gl-es environment and a minimal editor/ide to build and test with? --

i'll keep everyone up to speed as i make developments, and if anyone can replicate my dev environment and wants to contribute i'll happily push to a public git sooner rather than later.

cheers, dmotd

---

GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev

---

GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev

----------------------------------------------------------------------------

Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams