Hi Cyrille, all,

Compiling Gem for Windows is pretty similar to compiling any library for Windows... you usually have to chase down all the dependencies, install them, update the project to reflect the dependency paths and then compile. A bit of a pain but par for the course.

For GEM, many of the requisite libraries can be found in the ZIP of GemLibs available at IEM. If you want to use the more recent font support, you'll have to install that separately. There is often a small lag in updating the project after CVS changes too of course... but it's usually just a matter of adding the relevant files to the project.

There are two Windows projects in GEM CVS - a Visual Studio .NET solution and a Visual Studio 6 workspace. The VS.NET is kept reasonably up-to-date. The VS 6 workspace is out of date but still a good start if you're compiling in that environment.

It is certainly possible to write external libraries for GEM but you probably still need to compile GEM itself in order to build an export library that matches the GEM DLL you're using. I have a bunch of very messy GEM externals that I keep separate from GEM itself because they're buggy, peculiar and probably never should have been written ;-)

If you haven't compiled any externals for PD itself before, you should probably start there and more on to GEM once you have that working. The source and requisite headers and export library are available with the usual distro of PD. There are a number of sample workspaces around to build PD externals in Visual Studio.

To answer your final question... model animation is not really supported in Gem as it is. This is obviously a significant deficiency but the world of 3d file formats and animation systems being what it is... it's a hard thing to implement well and/or cleanly. If you have the time to work on this for Gem that would be wonderful.

One possible workaround would be break your model into static parts that move relative to each other. Then you can load each one and animate their relative arrangements using Gem. This might work okay for something like a simple skeleton but not for anything really complicated. If you're doing more procedural animation, perhaps you might consider making a particle system generator that corresponds to the sort of animation or generative algorithm that you're employing.

Hope some of this helps, Daniel

----- Original Message ----- From: "Cyrille Henry" cyrille.henry@la-kitchen.fr To: "guenter geiger" geiger@xdv.org Cc: gem-dev@iem.kug.ac.at Sent: Wednesday, September 17, 2003 8:47 PM Subject: Re: [GEM-dev] compilling Gem with visual C++

...

You might consider using a model file in order to build complex objects.

well, I make moving shape. So I use to compute position off all point of my surface for each frame. prim_tri are used for the creation of the surface. the point are always moving, so the surface is changing. so, I don't think a model can do surch things(?).

...

Compiling gem on Windows is hard (I gave up after trying for three hours ... ).

not a very good news...

...

It is possible to compile gem externals though, ..

ok, does anybody have done surch thing?

thanks Cyrille

...

Guenter

On Wed, 17 Sep 2003, Cyrille Henry wrote:

...

Hello,

I really love Gem, but I think I miss some object. my last patch use 3000 prim_tri for drowing a moving shape, but it kill my computer CPU. programing complex goes objects can be a good way to improve efficientcy of my patch.

So I would like to make some object for gem, but I have somes problems for compilation.

I would like to know if there is some kind of m_pd.h that I can use to make gem compatible object? or should I add my object to gem source and compille the whole lib?

I didn't succed to compille Gem with visual C++ on win 2K. does a documentation exist how to compile Gem?

thank's

sorry for my poor english,

Cyrille

---

GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev

---

GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev

hello everybody,

I downloaded the CVS version of gem and tried to compile. I think I'll nead some more help!

I had some errors due to some missing lib. So I add wintab, tiff, gltt, jpeg directory that I found on the standart 0.87 release. But I still have :

C:\pd\Gem\Gem\src\Pixes\DSgrabber.cpp(12) : fatal error C1083: Cannot open include file: 'streams.h': No such file or directory

and

C:\pd\Gem\Gem\src\Pixes\pix_videoDS.h(21) : fatal error C1083: Cannot open include file: 'dshow.h': No such file or directory

streams.h and dshow.h are not on my computer.

So : where can I find them? why does all this libs are not on GemLibs CVS?

thank's

Cyrille

Hello everybody,

I didn't spend enough time to compile the cvs version of gem, but I began working on the gem primitive object with 0.87. the first one is simple, but it will be very usefull for my patch.

I made a kind of tube : a cylinder with variable diameter and inclination of both circle of the cylinder.

so, I want to know now if gem communauty is interested with this object (and next object) or sould I keep it only for me? this can change my developement priorities...

I think that if it's working on 0.87 it will work on curent version. am I right?

I put diferent stuff on :

http://drpichon.free.fr/pure-data/GEM/

a gem.dll file (old version of gem with tube object) tube.c + tube.h : source file tube.pd : an exemple patch some pict of the object.

Cyrille

Daniel Heckenberg wrote:

Hi Cyrille,

These files use DirectShow (hence. the DS in their names) and require the DirectX SDK to be installed. Version 8.1 or 9 will work. They're not included in GemLibs for licence reasons and because the SDKs are very large (~100Mbs from memory). You need to install the SDK and build the "Stream Base Classes" library.

You can disable the compilation of these DS-dependent Gem objects by removing the relevant symbol in the compiler options. From memory it's called HAVE_DIRECTSHOW.

As I mentioned earlier, you might also have issues with font support - using FTGL requires a separate install of that library. The older GLTT system is in the GemLibs. You can select which font system you want to use via compiler defines as well.

Good luck, Daniel

----- Original Message ----- From: "Cyrille Henry" cyrille.henry@la-kitchen.fr To: gem-dev@iem.kug.ac.at Sent: Sunday, September 21, 2003 8:26 AM Subject: [GEM-dev] More compilling Gem with visual C++

...

hello everybody,

I downloaded the CVS version of gem and tried to compile. I think I'll nead some more help!

I had some errors due to some missing lib. So I add wintab, tiff, gltt, jpeg directory that I found on the standart 0.87 release. But I still have :

C:\pd\Gem\Gem\src\Pixes\DSgrabber.cpp(12) : fatal error C1083: Cannot open include file: 'streams.h': No such file or directory

and

C:\pd\Gem\Gem\src\Pixes\pix_videoDS.h(21) : fatal error C1083: Cannot open include file: 'dshow.h': No such file or directory

streams.h and dshow.h are not on my computer.

So : where can I find them? why does all this libs are not on GemLibs CVS?

thank's

Cyrille

---

GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev

---

GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev

hi,

tigital wrote:

...right! well, at least I know "right" cuz I just downloaded and tested it :-) Very nice...

thanks

...if ya want, I can commit it to the cvs?

yes, that would be cool. thanks

next one soon...

Cyrille

...

...

I think that if it's working on 0.87 it will work on curent version. am I right?

...right! well, at least I know "right" cuz I just downloaded and tested it :-) Very nice...

...if ya want, I can commit it to the cvs?

I fear this will lead to a proliveration of this kind of objects. Can't the tube functionality be added to the cylinder ..?

cylinder use an open GL primitive (gluCylinder). tube use GL_TRIANGLE_STRIP, and compute the position of all point independantly.

I think tube is less efficient than cylinder.

so I'm not sure remplacing cylinder with tube is a good thing.

(I made this primitive because I use to do the same thing with gemglbegin / gemglend etc. wich is a good way to do it, but not very efficient...)

well, don't really know what to do...

Cyrille

I did not mean to replace it, but to add the functionality to cylinder.

yes, I say replace because I think it's easyer to replace than to adapt...

Anyhow, this stuff should be thought out well, it would be nice to have a common interface for changing objects.

what do you mean by "changing" : distortion? yes, that would be very great, but don't know how to do.

The gluXXX are not Open GL commands, but utility functions that just set up a display list, so depending on the implementation you won't loose too much. If the performance loss really matters you can still switch between the static and dynamic cylinder inside cylinder, depending on the fact if the parameters changed ...

ok

well, don't really know what to do...

Me neither ... after all it was only a suggestion, maybe it was stupid and you just ignore it .. :)

well, I aggre that too much primitive is not good. but i think some important stuff is still missing...

Cyrille

A New GEM Render method.

All of the recent discussion about Cyrille's cool new tubes object has prompted me to reveal what I have been working on the past six weeks a little early. I have added vertex arrays to the GEM render chain. This allows for client side CPU processing of vertex, color, normal, and texture coordinate data. The advantage is instead of a Geo issue drawing commands directly via glVertex etc, the vertex, color, texcoord and normal data is passed via GemState for manipulation of the data by other objects. The final part of the chain is a drawing object that uses glDrawArrays to send the arrays to the card all at once. This is a big optimization for most platforms, so in addition to far more flexibility, GEM also gets a nice speed boost in many situations.

Here's an example chain of objects I have already written:

vertex_model - loads a .obj model into vertex, color, normal and texcoord arrays | | vertex_offset - adds an offset value to a single vertex, a range of vertices or the entire array | | color_set - sets the RGBA color of a single vertex, a range or the entire array | | vertex_draw - draws the array

This chain allows the individual vertices and their color data to be changed. A single vertex can be moved and it's color (including alpha) can be set. If vertex_quad was used instead of vertex_model then the quad could be pushed into a parallelogram or rhombus shape quite easily. Of course the more complex the object the more intricate the possible manipulations. RIght now I use a counter connected to vertex_offset to translate each vertex one at a time in space, which for the venus.obj model looks like the object is moved piece by piece between positions. It is also possible to have shifting gradients of color and transparency with a few color_set objects in the chain. All the standard rotate, translate, and scale objects work as well.

other objects coded to this point: vertex_grid : a variable 2D grid of vertices (probably will be a 3D version too) vertex_quad : a simple quad vertex_combine : blends/morphs two vertex arrays (potentially very slick) vertex_info : give some info about the arrays plus more...

The structure of the arrays is as follows:

VertexArray : an array of x,y,z,w values for each vertex ColorArray : an array of r,g,b,a values for each vertex color NormalArray : an array of the three normal values (not much done on this yet) TexCoordArray : an array of s,t values for each vertex

You will notice that the vertex array has the 4th w value - this is almost purely for the purpose of making SIMD processing code easier to write. I'm sure w has some useful function (it scales values using value/w), but it will make Altivec coding that much faster with a 16 byte data structure vs a 12 byte x,y,z. There will be a ton of Altivec written for these processing objects as it was a major part of the design decisions so far. Color is naturally 16 bytes and TexCoords can be easily paired. I don't foresee doing an excessive amount of coding for normal manipulation objects, but I might well be wrong about that. There are some other flags and values passed via GemState like the vertex array length, stride and a flag for which arrays have been enabled.

I think all of this directly relates to the tube/cylinder object issue for two reasons: 1) all of the glu functions (sphere, cylinder, disk) have to be replaced with vertex array compatible objects. 2) The manipulation of the cylinder/tube length and size could either be a part of the vertex_tube object or possibly implemented as a separate processing object (vertex_bend or stretch ??).

As with any new feature there are lots of questions, and some thought needs to be put forth into their resolution. I'm not sure about my initial naming convention - vertex_ color_ normal_ etc. My thought is that each object should have the name of which array it uses, but this leads to some semi-redundancy like [vertex_offset], [color_offset] and so on. Perhaps more general objects could be written? The problem I see is how to distinguish them from other GEM and non-GEM objects (like [scale]).

Also, the data in these arrays should be displayed in some graphic manner that's not the final gemwin output. Pd's current structures like array are far too inadequate for our purposes. The only way I see to make any acceptable data visualization for such data is using OpenGL. This would require multiple windows attached to the context and it will cause some hassles to implement. I would love to hear any alternate methods of efficient data display.

The array data needs a buffering system similar to pix_buffer that multiple render chains can write to and read from in order to make complex objects and scenes. The combining, concatenation, and removal of specific array sections will further allow users to get away from the current static structures in GEM.

Of course this system adds complexity, which requires clarity in the implementation and thorough documentation. The degree of flexibility that I hope this offers GEM users should be quite liberating. The current features start to put GEM closer to serious content creation applications like Maya, yet are tuned for the speed required for real-time use. I plan on writing a routine to save .obj files back to disk using glm, which will allow the saving of render chain data, and remove the need for a 3D content creation app for model creation (although Maya and the others are very nice tools).

I had not planned to bring this up until after the release of 0.888, but it seems appropriate given the current discussion. I will not commit any of the code to CVS until 0.888 is out since it adds to the basic structure of GemState and gemhead which have not been tested for long term stability. Nothing is changed or removed from the current Geos or classes - this is an addition not a replacement for the current objects.

Give this a little time to sink in and perhaps check out the Red Book section of Vertex Arrays (it's in the first 100 pages) to start getting a grasp on the possibilities. I have already done some pretty exciting stuff with the primitive (pardon the pun) objects created thus far.

cgc

ps - the subject line was Jamie's idea. ;)

ok, I solve my problem with directshow and gltt. now, I have one more compilation error that I don't understand : it's with GemPixUtil :

... C:\pd\Gem\Gem\src\Base\GemPixUtil.cpp(626) : error C2065: 'GL_BGR' : undeclared identifier C:\pd\Gem\Gem\src\Base\GemPixUtil.cpp(626) : error C2051: case expression not constant C:\pd\Gem\Gem\src\Base\GemPixUtil.cpp(661) : error C2065: 'GL_BGRA' : undeclared identifier C:\pd\Gem\Gem\src\Base\GemPixUtil.cpp(661) : error C2051: case expression not constant C:\pd\Gem\Gem\src\Base\GemPixUtil.cpp(726) : error C2051: case expression not constant C:\pd\Gem\Gem\src\Base\GemPixUtil.cpp(761) : error C2051: case expression not constant C:\pd\Gem\Gem\src\Base\GemPixUtil.cpp(826) : error C2051: case expression not constant C:\pd\Gem\Gem\src\Base\GemPixUtil.cpp(861) : error C2051: case expression not constant Error executing cl.exe.

does anyone can help me?

thanks Cyrille

Daniel Heckenberg wrote:

Hi Cyrille,

These files use DirectShow (hence. the DS in their names) and require the DirectX SDK to be installed. Version 8.1 or 9 will work. They're not included in GemLibs for licence reasons and because the SDKs are very large (~100Mbs from memory). You need to install the SDK and build the "Stream Base Classes" library.

You can disable the compilation of these DS-dependent Gem objects by removing the relevant symbol in the compiler options. From memory it's called HAVE_DIRECTSHOW.

As I mentioned earlier, you might also have issues with font support - using FTGL requires a separate install of that library. The older GLTT system is in the GemLibs. You can select which font system you want to use via compiler defines as well.

Good luck, Daniel

----- Original Message ----- From: "Cyrille Henry" cyrille.henry@la-kitchen.fr To: gem-dev@iem.kug.ac.at Sent: Sunday, September 21, 2003 8:26 AM Subject: [GEM-dev] More compilling Gem with visual C++

...

hello everybody,

I downloaded the CVS version of gem and tried to compile. I think I'll nead some more help!

I had some errors due to some missing lib. So I add wintab, tiff, gltt, jpeg directory that I found on the standart 0.87 release. But I still have :

C:\pd\Gem\Gem\src\Pixes\DSgrabber.cpp(12) : fatal error C1083: Cannot open include file: 'streams.h': No such file or directory

and

C:\pd\Gem\Gem\src\Pixes\pix_videoDS.h(21) : fatal error C1083: Cannot open include file: 'dshow.h': No such file or directory

streams.h and dshow.h are not on my computer.

So : where can I find them? why does all this libs are not on GemLibs CVS?

thank's

Cyrille

---

GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev