GEM-dev October 2003

gem-dev@lists.iem.at

8 participants
11 discussions

more new primitive for gem...
by Cyrille Henry 25 Mar '04

25 Mar '04

hello, I made a new primitive for gem : curve3D.... juste like curve, but in 3D! you may find stuff here : http://drpichon.free.fr/pure-data/GEM/curve3D/ picts, source, exemple and gem.dll for windows user... hope you'll like it... Cyrille

4 6

CVS-checkins; marching towards release
by IOhannes m zmoelnig 26 Nov '03

26 Nov '03

hi all. i have just checked in further changes: [pix_texture]: i have removed the texture-flipping defines for __APPLE__. instead the flipping is depending on a variable "upsidedown" which is now part of the imageStruct. i have defaulted it to "true" on __APPLE__ and "false" otherwise, but it really should be set in the pix_source-object. [pix_film] (actually [pix_filmNEW] which is now the default for linux: added the "colourspace" message filmQT4L/filmMPEG3/filmMPEG1/filmAVIPLAY all set the "upsidedown" according to the orientation of the images they produce. all of them support all 3 colourspaces; furthermore they all output these 3 colourspaces *only*, which makes the stupid [pix_rgba] object in the example-patch obsolete (so i have removed it from 05.film.pd). fixed various bugs in these film*-objects, so you can now play back mpeg/quicktime/avi/divx and even asf files from within linux. i was very happy, seeing the homer.avi and even proprietary codecs like cinepak (ok, its old) under linux. however some bugs remain, but i have no idea how to fix them, since i think they are bugs in the used libraries: libavifile (0.7) randomly crashes when playing back mpegs (haven't yet found a way how to reveal "concealed errors". libmpeg1 still crashes when you try to load another format, but there is no way provided by the lib that would detect whether a file is really mpeg or not. [pix_movieNEW] (which is the default in linux) inherits [pix_filmNEW] but uses the texturing engine of [pix_texture] (so changes to pix_texture are immediately applied to pix_movieNEW too. therefore i have made pix_movieNEW a friend class of pix_texture. so which release-critical bugs are still around ? (the RGB output of [pix_film] was one) mfg.as.rd IOhannes

3 2

Re: [GEM-dev] more new primitive for gem...
by B. Bogart 29 Oct '03

29 Oct '03

Hi Cyrille, What I'm making right now as an abstraction made out of 6 of your curve surfaces, each representing a face of a cube. Of course thic cube can be deformed to become a curve, but the edges between faces will always be 90 degrees. (hard edge) So is there the possibility of having an enclosed shape (like the cube example above, where there is an intererior and an exterior that are non-continuous. A torus, cone, sphere, cube are all enclosed. A plane, your curve, and circle are not enclosed because they have only one surface (no interior). A blob would be different than the above example because it would not have any hard edges. A bubble is a blob... Basically I'm asking for a sphere primitive that you can move control points to destort the surface. I'm CCing on the gem-dev so perhaps someone with better french can explain what I'm talking about. Thanks for the good work. Ben ----- Original Message ----- From: "Cyrille Henry" <cyrille.henry(a)la-kitchen.fr> To: "B. Bogart" <ben(a)ekran.org> Sent: Tuesday, October 28, 2003 8:14 AM Subject: Re: [GEM-dev] more new primitive for gem... > Hello Ben, > > I'm not sure to understand everything. > (still nead to progresse in english.) > google does not have a good translation... > > what's an "enclosed curvy shape"? > > what's a blob? > > cyrille > > B. Bogart wrote: > > >Hey Cyrille, > > > >I'm just patching up an abstraction for an enclosed curvy shape. But as I > >mess around I realize it would make much more sense as an external. Are > >there any plans for an enclosed version of curve3d? (which would be > >basically like a blob) I'd really like this... > > > thank's > > > > >Thanks again for the good work. > > > > > well, I just copy my open GL book! > > > Ben ----- Original Message ----- From: "Cyrille Henry" > <cyrille.henry(a)la-kitchen.fr> To: <gem-dev(a)iem.kug.ac.at> > > >Sent: Monday, October 27, 2003 4:42 PM > >Subject: [GEM-dev] more new primitive for gem... > > > > > > > > > >>hello, > >> > >>I made a new primitive for gem : curve3D.... > >>juste like curve, but in 3D! > >> > >>you may find stuff here : > >> > >>http://drpichon.free.fr/pure-data/GEM/curve3D/ > >> > >>picts, source, exemple and gem.dll for windows user... > >> > >>hope you'll like it... > >> > >> > >>Cyrille > >> > >> > >> > >> > >>_______________________________________________ > >>GEM-dev mailing list > >>GEM-dev(a)iem.at > >>http://iem.at/cgi-bin/mailman/listinfo/gem-dev > >> > >> > > > > > > > > > > > >

3 4

Re: [GEM-dev] more new primitive for gem...
by cgc＠humboldtblvd.com 28 Oct '03

28 Oct '03

Quoting Cyrille Henry <cyrille.henry(a)la-kitchen.fr>: > > > >1. Will this be integrated into the Gem CVS? Perhaps for v.89? > > > I'd like to. but it depend of what the other developper think of it. > It's fine by me. The code could use some changes like getting most of that case statement in the render function. > >2. Will this be integrated into the stuff that Chris is doing with > vertex > >arrays? > > > I'd like to. don't know much more now. > Unfortunately, the GL evaluators used in cube3d aren't compatible with the vertex arrays. Similar things can be accomplished with vertex/polygon approaches (see newwave as an example), but for defining simple bezier type curves, evaluators are probably simpler and faster. The next step would be NURBS, for which glu has a library of functions that I've never really looked at. > >3. No makefile? How to build in linux/osx? > > > I don't know, I juste add it to gem project and compille everything. > Although I haven't built cube3d, it looks like it will work fine with the current CVS.

1 0

Re: [GEM-dev] Z-Buffer Render Order
by B. Bogart 27 Oct '03

27 Oct '03

Hey Chris, Well I was using linux at the time, but basically when you have a cube (for example) the faces of the cube has different render orders, so when transparency is on you can only see through some of the sides because they are rendered before the ones behind it. I've not tried it on OSX to see the same behavior. But stupid me only noticied a "depth" object much later that does reorder the rendering order my Z-buffer!! I just never noticed it before. So I guess this is a non-question? Thanks Chris, Ben ----- Original Message ----- From: "chris clepper" <cgc(a)humboldtblvd.com> To: "B. Bogart" <ben(a)ekran.org> Sent: Monday, October 27, 2003 12:00 AM Subject: Re: [GEM-dev] Z-Buffer Render Order > >Hey all, > > > >I was just curious if anyone was working on Z-buffering for so that we can > >have nice render ordering that works from all angles? (So that faces in the > >background are rendered first based on the Z distance) > > Are you having some sort of specific problem with depth buffering? > OpenGL in general will obey the depth buffer and render everything > back to front properly. Blending can do odd things to the depth > buffer, but I think that the current [alpha] object has the requisite > hacks to get around this. > > Do you have a patch that illustrates z-buffer problems in GEM? > > >I think it would be a nice option... (not always on) > > > >Ben > > > > > >_______________________________________________ > >GEM-dev mailing list > >GEM-dev(a)iem.at > >http://iem.at/cgi-bin/mailman/listinfo/gem-dev >

1 0

Changes in setup() functions
by guenter geiger 27 Oct '03

27 Oct '03

Hi there, I just comitted some changes in how the setup() stuff is handled for Gem. The new system registers the classes automatically, by instantiating a t_class C++ wrapper class. The magic happens in Base/CPPExtern.h The changes make the setup.h files obsolete, because every class is automatically registered as soon as it is compiled, and the other way round, if a file doesn't compile, you can still load Gem, but without that object. Hope this doesn't cause problems, otherwise I will roll it back, so please let me know. Ah, and I removed my name form the startup splash, cause I think there are too many names in there and I am not doing too much after all. Guenter

3 2

Z-Buffer Render Order
by B. Bogart 23 Oct '03

23 Oct '03

Hey all, I was just curious if anyone was working on Z-buffering for so that we can have nice render ordering that works from all angles? (So that faces in the background are rendered first based on the Z distance) I think it would be a nice option... (not always on) Ben

1 0

[Fwd: Re: [GEM-dev] Changes in setup() functions]
by Cyrille Henry 23 Oct '03

23 Oct '03

hello, thank's gunter for this change. gem cvs compill fine on my computer for the first time! please, don't roll back! ;-) cyrille guenter geiger wrote: >Hi there, > >I just comitted some changes in how the setup() stuff is handled for Gem. >The new system registers the classes automatically, by instantiating >a t_class C++ wrapper class. >The magic happens in Base/CPPExtern.h >The changes make the setup.h files obsolete, because every class is >automatically registered as soon as it is compiled, and the other way >round, if a file doesn't compile, you can still load Gem, but without >that object. > >Hope this doesn't cause problems, otherwise I will roll >it back, so please let me know. > >Ah, and I removed my name form the startup splash, cause I think >there are too many names in there and I am not doing too much after all. > >Guenter > > >_______________________________________________ >GEM-dev mailing list >GEM-dev(a)iem.at >http://iem.at/cgi-bin/mailman/listinfo/gem-dev > > > >

1 0

gem cvs question: altivec (SIMD) conventions
by IOhannes m zmoelnig 07 Oct '03

07 Oct '03

hi gemers. about pix_altivec functions: right now, altivec support in Gem looks like this: <snip pix_text.h> virtual void pix_test :: processImage(imageStruct &image); virtual void pix_test :: processImageAltivec(imageStruct &image); </snip> <snip pix_text.cpp> void pix_test :: processImage(imageStruct &image) { #ifdef ALTIVEC processImageAltivec(image); return #else // some slow code #endif } void pix_test :: processImageAltivec(imageStruct &image) { #ifdef ALTIVEC // some fast code #endif } </snip> now my question: wouldn't it be better to make more use of inheritance ? and call the altivec-processing directly from GemPixObj, if altivec is supported by the machine ? i write this with MMX and SSE2 in mind: i guess, all modern apple-computers have altivec; all modern pcs have mmx, but only some of them have sse2 (i guess pentium-4 only, but amd will support it in the future). i would rather decide at runtime whether any parallel processing is available, and then call the appropriate function. the fallback of all those altivec/mmx-functions would of course be the generic-processing. so i was thinking of something like <snip GemPixObj.h> virtual void processYUVImage(imageStruct &image); virtual void processYUVImageAltivec(imageStruct &image); </snip> <snip GemPixObj.cpp> void GemPixObj :: render(GemState *state){ //... switch(state->image->image.format){ //... case GL_YCBCR_422_GEM: switch (m_haveSIMD){ case SIMD_ALTIVEC: processYUVImageAltivec(state->image->image); break; default: processYUVImage(state->image->image); } //... } } void GemPixObj :: processYUVImage(imageStruct &image){ processImage(image); } void GemPixObj :: processYUVImageAltivec(imageStruct &image) processYUVImage(image); } </snip> <snip pix_test.h> virtual void pix_test :: processImage(imageStruct &image); #ifdef ALTIVEC virtual void pix_test :: processImageAltivec(imageStruct &image); #endif </snip> <snip pix_test.cpp> void pix_test :: processImage(imageStruct &image) { // some slow code } #ifdef ALTIVEC void pix_test :: processImageAltivec(imageStruct &image) { // some fast code } #endif </snip> GemPixObj::m_haveSIMD could be SIMD_ALTIVEC, SIMD_MMX, SIMD_SSE2 (or whatever) pros (i can think of right now): code that is the same is rather in the parent-class than in each child. this would make it possible to turn on/off SIMD on the fly. (probably not a very good argument, but handy for profiling / showing the advantages of SIMD). furthermore it would keep the #ifdef-nightmare a bit more clean ( i believe) the number of function-calls would be reduced by one (at the cost of one case-loop) i don't know whether G5-ALTIVEC-compiles can be executed on G4's - would it be possible if the PPC970-code would be capsuled in an if-clause ? drawbacks: - a little work to be done (i have already started to do so, but haven't yet committed it because i don't know, whether my idea is really good) - there has to be a naming scheme for SIMD-processing. i have noticed, that in PixDualObj's the naming is rather arbitrary: pix_subtract::processYUVAltivec() vs. pix_chroma_key::processYUV_YUVAltivec() any comments ? mfg.as.r IOhannes

2 2

libmpeg3
by rat＠telecoma.net 05 Oct '03

05 Oct '03

hi, yesterdays mysterious error on startup was because of an old libavifile, everything loads fine now. but playing mpeg movies almost freezes my machine. no matter if i use the mpeg1 ot mpeg3 packages from debian. heroine seems not to deliver libraries anymore in his libmpeg3. what are u using out there ? btw the new help patches are a big improvement cheers erich ---------------------------------- http://randomseed.org

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

GEM-dev October 2003