hello, here are some code I made for gem : http://drpichon.free.fr/gem/
as usual, it's only proposition submited to your critisism.
description :
gemlist_info : --------------- this object get a gemlist and decompose the transformation matrix in basic transformations : translation, rotation, scale and shear. very usful for video -> audio interaction while using iterative process in the gem render chain (this object was made using cut/past from Iohannes code and Chris sugestion)
ShearXY, shearXZ ... ------------------ a collection of transformation objects that shear the deformation matrix. shear can be created with rotation and scale, but it's easier to use this specifics objects. this objects are also usefull to create a specific transformation matrix using gemlist_info output.
newWave : --------- newWave has a big problem : it is sensitive to denormal bug. (newWave deformation can become very small after some time, and denormal can apear in both position and forces.) adding some very low ampliture (about 1e-20) random noise to a node fix the problem : the noise does propagate in the all structure avoiding denormal. maybe some ifdef could be add for this procedure, but it is fast enough to leave it like this.
I just copy the random() procedure from randF object. maybee someone can tell me how to use the original one (sorry, it's a newbee question, but I never had time to learn C++ !)
I also found that newWave share it's dimension on all instances of this object : it was not possible to have a "newWave 5" and a "newWave 23" in the same time. While fixing this I made the X/Y dimention independant to be able to create rectangular newWave.
I fixed also a X/Y texturing inversion and I limited Z position of points to prevent instability of the system.
tube : ------ just a small modification in order to be able to change the number of faces used to draw the shape.
You'll find gem help file for all of this.
Hope you'll like them.
Cyrille
On Sep 11, 2004, at 3:02 PM, cyrille henry wrote:
hello, here are some code I made for gem : http://drpichon.free.fr/gem/
as usual, it's only proposition submited to your critisism.
...is there any reason you didn't just put these into cvs? Stuff like this doesn't really seem to warrant a new branch or anything, if that's scaring you off :-)
james
James Tittle II wrote:
On Sep 11, 2004, at 3:02 PM, cyrille henry wrote:
...is there any reason you didn't just put these into cvs? Stuff like this doesn't really seem to warrant a new branch or anything, if that's scaring you off :-)
i think it is, because cyrille isn't a developper yet. should i add you ?
mfg.a.dsr IOhannes
...is there any reason you didn't just put these into cvs? Stuff like this doesn't really seem to warrant a new branch or anything, if that's scaring you off :-)
i think it is, because cyrille isn't a developper yet. should i add you ?
I am currently doing some stuff about OpenGL extensions and Vertex Shaders (Coming for Fragment Shaders). Some of you may be interrested. But on one hand i am not yet a developper too, and on a nother hand i dont know what is a branch :) and how to set it in cvs.
Any one could help me to understand that ?
Ronan
On Sep 15, 2004, at 4:40 AM, Ronan Puce Muse wrote:
...is there any reason you didn't just put these into cvs? Stuff like this doesn't really seem to warrant a new branch or anything, if that's scaring you off :-)
i think it is, because cyrille isn't a developper yet. should i add you ?
I am currently doing some stuff about OpenGL extensions and Vertex Shaders (Coming for Fragment Shaders). Some of you may be interrested. But on one hand i am not yet a developper too, and on a nother hand i dont know what is a branch :) and how to set it in cvs.
hi Ronan,
...sounds great, but could you be a bit more specific? I've also been working on extensions (specifically multitexture) and ARB_vertex_program...I don't recall you contributing code, or talking about anything other than questions, so we probably wouldn't want to give you full access atm (I think cyrille is really being demure when he says he's not a programmer :-) )...
...also, there's tons of documentation on cvs, and you should really be familiar with it so as to minimize mistakes: I recommend "man cvs"...
looking forward to what you're thinking about, james
I am currently doing some stuff about OpenGL extensions and Vertex Shaders (Coming for Fragment Shaders). Some of you may be interrested. But on one hand i am not yet a developper too, and on a nother hand i dont know what is a branch :) and how to set it in cvs.
hi Ronan,
...sounds great, but could you be a bit more specific? I've also been working on extensions (specifically multitexture) and ARB_vertex_program...
Hi James,
Well the main extension i added is the possibility to render to a texture using the extension WGL_ARB_RENDER_TEXTURE which works pretty well now.
I also coded some tests about Cg Vertex Programs. Those programs work quite well but are not yet enough flexible to be commited. I'm actually facing a difficulty that brings me to study more deeper the Gem project architecture:
What i'd like to achieve is something like a Cg "wrapper" for Gem. And i've thought that i had to instanciate Cg programs with names. This way, if i want to add a new vertexProgram to my patch, i would create an object like the following [GEMcgVertexProgram toto cgfilename]. Then if i want to set the value of a parameter from anywhere in the patch i would set an object like [GEMcgGLSetParameter1f toto parameterName parameterValue]. (i used pd_bind from within the GEMcgVertexProgram class)
My object GEMcgVertexProgram just work very well, even with multiple objects referencing the same Cg program. But i just cant set the parameter with GEMcgGLSetParameter1f because i cant link to the program "toto" from it.
The Solution i think the best is to Create a new Class GEMCgProgram that will be the base class to all my Cg wrapper Objects. But I really dont know how to achieve that and i feel quite lost in the Gem project architecture.
Is there a class which is quite close to what i want to do. This way i could set it as a "re"-starting point ?
I can also upload somewhere my sources and/or gem.dll and .pd files for examples.
I just hope to be clear enough Thanks Ronan
------------------------------------------------- This mail sent through IMP: http://horde.org/imp/
On Sep 15, 2004, at 10:06 AM, r.leboite.pm@birdsinplane.com wrote:
Well the main extension i added is the possibility to render to a texture using the extension WGL_ARB_RENDER_TEXTURE which works pretty well now.
I also coded some tests about Cg Vertex Programs. Those programs work quite well but are not yet enough flexible to be commited.
These are interesting things you are working on; however, they are also part of some core changes we have been planning for GEM. Because of this, I don't think either of your two developments should be committed now.
Specifically, render-to-texture is part of the multiple windows and targets, and I think we will look at pBuffers to help achieve this. As for shaders, I would prefer not to use Cg for two reasons: one it's not part of ARB OpenGL, and not equally supported between platforms or vendors. Also, I think GLSL has potentially a superior architecture, although it might take ages for it to even be implemented fully on all three of GEM's target platforms. Both of these projects are still really in the planning stages, and various people are experimenting with potential solutions.
You should become a developer since you are interested in working on advanced features, and also seem to be working on Windows. It would be good to have someone to help out with the render targets and shading, and you will get some help with figuring out GEM's internal architecture.
cgc
On Sep 15, 2004, at 12:10 PM, chris clepper wrote:
On Sep 15, 2004, at 10:06 AM, r.leboite.pm@birdsinplane.com wrote:
Well the main extension i added is the possibility to render to a texture using the extension WGL_ARB_RENDER_TEXTURE which works pretty well now.
I also coded some tests about Cg Vertex Programs. Those programs work quite well but are not yet enough flexible to be commited.
Specifically, render-to-texture is part of the multiple windows and targets, and I think we will look at pBuffers to help achieve this. As for shaders, I would prefer not to use Cg for two reasons: one it's not part of ARB OpenGL, and not equally supported between platforms or vendors. Also, I think GLSL has potentially a superior architecture, although it might take ages for it to even be implemented fully on all three of GEM's target platforms. Both of these projects are still really in the planning stages, and various people are experimenting with potential solutions.
...I'm not familiar much with the ARB_Render_Texture api: a quick look at apple's OGL extensions guide doesn't list it, so that's a strike against implementing it in GEM (maybe it's covered under something else)...we'd already planned on doing other offscreen rendering targets via pbuffers...
...I'm not against have Cg capabilities, I just know from experience that it can be tricky to use cross-platform, and pretty much forget about using it with ATI cards (they have much different expectations)...that said, how are you implementing it? Are you intending to use the Cg runtime? I'd really be against that at this point...
...otoh, GLSL will definitely get implemented, but it's not available atm on OSX, so we're waiting...until then, what I've been working towards is just supporting the loading of ARB_vp and ARB_fp programs, which we can definitely do crossplatform atm...of course, this means that you have to write the shader in something other than the nicely intelligible GLSL or Cg :-)
You should become a developer since you are interested in working on advanced features, and also seem to be working on Windows. It would be good to have someone to help out with the render targets and shading, and you will get some help with figuring out GEM's internal architecture.
...I agree: at this point, you should make the code available somewhere online, or send it to the list (or just me: is anyone else working on this, too?) perhaps...then we can set up a branch to deal with these, get ya access, and then start digging!
james
You should become a developer since you are interested in working on advanced features, and also seem to be working on Windows. It would be good to have someone to help out with the render targets and shading, and you will get some help with figuring out GEM's internal architecture.
Hello Chris,
I am very interrested in getting involved in the project, and as you suggest it, help on undertanding Gem's internal architecture is quite "critical" for me, because the only structure graph i got was from the "gem for max" project page and this wasn't so educative as it's quite easy to build from any advanced IDE.
I think that i'll continue to work on Cg though as i really need this at this moment. But if i can get a good Shader bunch of classes, i bet that it wont be very hard for me to port it to the official OpenGL shading language (tell me if i'm wrong).
I have also studied pBuffers, as i needed one to render to texture (even if i'm using the wgl extension). But the pbuffer I implemented is internal to the object i did. This is also due to the fact that i dont know much about the Gem's architecture.
Again, if someone using windows is interrested in looking what i did, i can provide sources, dll and pd files.
Greetings Ronan
On Sep 15, 2004, at 1:01 PM, Ronan Puce Muse wrote:
Hello Chris,
I am very interrested in getting involved in the project, and as you suggest it, help on undertanding Gem's internal architecture is quite "critical" for me, because the only structure graph i got was from the "gem for max" project page and this wasn't so educative as it's quite easy to build from any advanced IDE.
I have no idea how gem4max (or whatever it's called) corresponds to the latest GEM, although I saw that he took some of the quicktime code I wrote for it.
I think that i'll continue to work on Cg though as i really need this at this moment. But if i can get a good Shader bunch of classes, i bet that it wont be very hard for me to port it to the official OpenGL shading language (tell me if i'm wrong).
I have no idea about the ease of porting Cg to GLSL, but the option to use Cg as an addition to GEM might prove useful to some in the meantime. As Jamie points out, we are still waiting on Apple to fully support GLSL on OSX, and that's only the first step.
It would be good for the developers to start discussing how the addition of shaders will affect the overall structure of GEM from both a code and user standpoint. One of my primary concerns with GEM is making the potentially complex interactions possible with vertex_arrays (and shaders) not overwhelmingly complex to use and also present data in a clear and concise manner. Tom Schouten has been in touch about his ideas on the former, which also may allow greater interoperability between video and graphics libraries like GEM and PDP.
I have also studied pBuffers, as i needed one to render to texture (even if i'm using the wgl extension). But the pbuffer I implemented is internal to the object i did. This is also due to the fact that i dont know much about the Gem's architecture.
In the discussions so far, the idea put forth is to have pbuffers as user configurable render targets just like a display window. I don't know if any of the code to do this exists anywhere yet, but it was somewhat agreed upon as a good path to take.
Again, if someone using windows is interrested in looking what i did, i can provide sources, dll and pd files.
Please post them somewhere, and I'm sure we will all want to have a look.
cgc
Greetings Ronan
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
In the discussions so far, the idea put forth is to have pbuffers as user configurable render targets just like a display window. I don't know if any of the code to do this exists anywhere yet, but it was somewhat agreed upon as a good path to take.
i had pbuffers in 3dp at some point but i cut them out. (0.11 i think) i don't remember why exactly. possibly it had to do something with threads & context switches i couldn't get to work right.
i'm planning to dig into this again soon..
you can do a lot with multipass rendering. i use this in 3dp to fake a texture target: just render to a part of the buffer as large as the tex, and grab it. it's fast & convenient. the only drawback is that it doesn't work when the window is obscured by another one, but i think there should be a way to prevent this..
IOhannes m zmoelnig wrote:
James Tittle II wrote:
On Sep 11, 2004, at 3:02 PM, cyrille henry wrote:
...is there any reason you didn't just put these into cvs? Stuff like this doesn't really seem to warrant a new branch or anything, if that's scaring you off :-)
i think it is, because cyrille isn't a developper yet. should i add you ?
well... I do not feel like a programmer, so I prefer developpers to check that code befor commiting it. If you don't mind, I prefer not having a developper acces (yet?).
of course, if you prefer to add me to the developper list, and if this code is ok for everybody, i could commit them.
thanks,
Cyrille
mfg.a.dsr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
-
chris clepper -
cyrille henry -
IOhannes m zmoelnig -
James Tittle II -
r.leboite.pm＠birdsinplane.com -
Ronan Puce Muse
-
Tom Schouten