hi all.
just added several things to the CVS:
1. text i did it again, rewrote big parts of the text-engine we now have support for both GLTT and FTGL i have moved a lot of code from the various Geos/text* classes into Base/TextBase i haven't yet compiled it under different platforms, but i have done a lot of (again) ifdefs, which should keep the both parts apart. all the GLTT stuff is within "#ifdef GLTT", and vice-versa the FTGL stuff is within "#ifdef FTGL" i can compile and run Gem with either of them enabled or both disabled, so guess it's done allright. what's so good about FTGL: .don't know .cross platform (i guess, there is no GLTT under macOS ?) .cleaner API (i really don't know, why GLTT is c++, as it doesn't use inheritance, which makes it a pain in the) .looks nicer .new features: extruded text (see the new object [textextrude]), and textured text (don't look for this yet...)
2. particle added several new objects: [part_veldomain] let's you set the velocity domain (more flexible than [part_velsphere] and friend) [part_velocity] sets the velocity into a certain direction most notable: [part_vertex] emits one (only 1) particle each rendering cycle, but the offset-position of these particles can be set. this allows moving particle-sources without moving the whole particle system.
3. hmm, i think that's it
mfg.as.dr IOhannes
On Tue, 15 Jul 2003, IOhannes zmoelnig wrote:
hi all.
just added several things to the CVS:
- text
i did it again, rewrote big parts of the text-engine we now have support for both GLTT and FTGL i have moved a lot of code from the various Geos/text* classes into Base/TextBase i haven't yet compiled it under different platforms, but i have done a lot of (again) ifdefs, which should keep the both parts apart. all the GLTT stuff is within "#ifdef GLTT", and vice-versa the FTGL stuff is within "#ifdef FTGL" i can compile and run Gem with either of them enabled or both disabled, so guess it's done allright. what's so good about FTGL: .don't know .cross platform (i guess, there is no GLTT under macOS ?) .cleaner API (i really don't know, why GLTT is c++, as it doesn't use inheritance, which makes it a pain in the) .looks nicer .new features: extruded text (see the new object [textextrude]), and textured text (don't look for this yet...)
arghh, this ifdef stuff is really, really a pain and a hack.
Please, either just drop the GLTT things or sort them out into a new class. I can't believe that you did it again :)
- particle
added several new objects: [part_veldomain] let's you set the velocity domain (more flexible than [part_velsphere] and friend) [part_velocity] sets the velocity into a certain direction most notable: [part_vertex] emits one (only 1) particle each rendering cycle, but the offset-position of these particles can be set. this allows moving particle-sources without moving the whole particle system.
great, I have just done almost the same things yesterday :(
I would have liked to have the part_veldomain thing only and deprecate part_velsphere, part_velcone and part_velocity.
Actuall only keeping an object called part_velocity with domain support. THis matches closer the particle API and people can directly use the particle documentation if they want to understand what is going on.
Then it would be great to have domain support for the other operations too (like part_source, etc ...)
Anyhow, good job.
Guenter
- hmm, i think that's it
mfg.as.dr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
guenter geiger wrote:
On Tue, 15 Jul 2003, IOhannes zmoelnig wrote:
hi all.
arghh, this ifdef stuff is really, really a pain and a hack.
Please, either just drop the GLTT things or sort them out into a new class. I can't believe that you did it again :)
yes, i can't either... however, i would have dropped the GLTT-stuff completely if and only if everybody things it's ok. so, dev's out there, get to your computer (probably you are already there), download the new CVS-things, make it compile. you will need the FTGL-package (which will move into GemLibs/) http://homepages.paradise.net.nz/henryj/code/ and probably you will need the freetype-lib too.
as soon as it works everywhere we should delete all the gltt-stuff. (so, please, inform this list if it works)
- particle
added several new objects: [part_veldomain] let's you set the velocity domain (more flexible than [part_velsphere] and friend) [part_velocity] sets the velocity into a certain direction most notable: [part_vertex] emits one (only 1) particle each rendering cycle, but the offset-position of these particles can be set. this allows moving particle-sources without moving the whole particle system.
great, I have just done almost the same things yesterday :(
seems like we are doing the same things quite often in the past few days.
I would have liked to have the part_veldomain thing only and deprecate part_velsphere, part_velcone and part_velocity.
Actuall only keeping an object called part_velocity with domain support. THis matches closer the particle API and people can directly use the particle documentation if they want to understand what is going on.
i have put the [part_velocity] object only in, because it is a separate function in the particle-API (papi.h). but i agree...
Then it would be great to have domain support for the other operations too (like part_source, etc ...)
i have already put the domain-support into [part_source], but have forgotten to make the arguments setable....that's why i haven't mentioned it...
mfg.asd.r IOhannes
IOhannes zmoelnig wrote:
- particle
added several new objects: [part_veldomain] let's you set the velocity domain (more flexible than [part_velsphere] and friend) [part_velocity] sets the velocity into a certain direction most notable: [part_vertex] emits one (only 1) particle each rendering cycle, but the offset-position of these particles can be set. this allows moving particle-sources without moving the whole particle system.
Then it would be great to have domain support for the other operations too (like part_source, etc ...)
i have already put the domain-support into [part_source], but have forgotten to make the arguments setable....that's why i haven't mentioned it...
ok, hold on then. [part_veldomain] is gone. instead [part_velocity] can now be used to set the type and specifics of the velocity-domain. (see reference-files) [part_source] now has 2 extra inputs, that let's you specify the domain and domain-specifics.
i just noticed, that you can set the "point of emittance" now, which is even better for moving particle-sources than [part_vertex] (which i won't delete)
mfg.asd.r IOhannes
On Tue, 15 Jul 2003, IOhannes zmoelnig wrote:
ok, hold on then. [part_veldomain] is gone. instead [part_velocity] can now be used to set the type and specifics of the velocity-domain. (see reference-files) [part_source] now has 2 extra inputs, that let's you specify the domain and domain-specifics.
i just noticed, that you can set the "point of emittance" now, which is even better for moving particle-sources than [part_vertex] (which i won't delete)
cool, I have two suggestions though. I think it would make more sense to combine the domain and the vector (domain parameters) message. Mainly because if I want to change the domain I would like to change the domain parameters too, in one message as "sphere 0 0.2 0 0.3".
Can the m_numberToAdd parameter be changed to float (libparticle supports float for this parameter) and will happily emit 1/2 particle per frame.
Greetings,
Guenter
Zitiere guenter geiger geiger@xdv.org:
i just noticed, that you can set the "point of emittance" now, which
is
even better for moving particle-sources than [part_vertex] (which i won't delete)
cool, I have two suggestions though. I think it would make more sense to combine the domain and the vector (domain parameters) message. Mainly because if I want to change the domain I would like to change the domain parameters too, in one message as "sphere 0 0.2 0 0.3".
well, i'm sure, you most probably will want to change the domain parameters when changing the domain. however, it is likely, that you will want to change *only* the domain parameters and not touch the domain-type itself quite often. so 2 separate inlets make sense. i agree that the "first" of these could eat arguments like "sphere 0 0.2 0 0.3". but how again was the solution to get "anythings" into "right" (not-leftmost) inlets ? i think "list sphere 0 0.2 0 0.3" is even more clumsy than two separate messages "symbol sphere" and "0 0.2 0 0.3" (ok, "symbol sphere" looks clumsy too, but there are ways to generate symbols out of anythings, whereas there are none to convert anythings to lists (in plain pd!))
Can the m_numberToAdd parameter be changed to float (libparticle supports float for this parameter) and will happily emit 1/2 particle per frame.
of course, but since i don't have access to the CVS right now, feel free to change it yourself ;-)
mfg.as.rd IOhannes
On Wed, 16 Jul 2003 zmoelnig@iem.at wrote:
i agree that the "first" of these could eat arguments like "sphere 0 0.2 0 0.3". but how again was the solution to get "anythings" into "right" (not-leftmost) inlets ?
ok, didn't think about that, you are probably right.
Guenter
i think "list sphere 0 0.2 0 0.3" is even more clumsy than two separate messages "symbol sphere" and "0 0.2 0 0.3" (ok, "symbol sphere" looks clumsy too, but there are ways to generate symbols out of anythings, whereas there are none to convert anythings to lists (in plain pd!))
Can the m_numberToAdd parameter be changed to float (libparticle supports float for this parameter) and will happily emit 1/2 particle per frame.
of course, but since i don't have access to the CVS right now, feel free to change it yourself ;-)
mfg.as.rd IOhannes
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
On Tuesday, July 15, 2003, at 06:50 AM, IOhannes zmoelnig wrote:
guenter geiger wrote:
On Tue, 15 Jul 2003, IOhannes zmoelnig wrote:
hi all.
arghh, this ifdef stuff is really, really a pain and a hack. Please, either just drop the GLTT things or sort them out into a new class. I can't believe that you did it again :)
yes, i can't either... however, i would have dropped the GLTT-stuff completely if and only if everybody things it's ok. so, dev's out there, get to your computer (probably you are already there), download the new CVS-things, make it compile. you will need the FTGL-package (which will move into GemLibs/) http://homepages.paradise.net.nz/henryj/code/ and probably you will need the freetype-lib too.
as soon as it works everywhere we should delete all the gltt-stuff. (so, please, inform this list if it works)
...ok, I'm trying to compile now without GLTT, but am having some problems:
src/Base/TextBase.cpp:125: no matching function for call to `FTFont::Open(char[1000], bool)'
...I've got FTGL 2.04: what version are you working from? Also, does this require freetype2 or freetype? Since neither of these comes installed on OSX, can we link it into the Gem.pd_darwin so people don't have to download and install another library?
thanx, jamie
On Tue, 15 Jul 2003, tigital wrote:
...ok, I'm trying to compile now without GLTT, but am having some problems:
src/Base/TextBase.cpp:125: no matching function for call to `FTFont::Open(char[1000], bool)'
Wow, this prototype looks scary. Is it possible that the compiler on OSX just refuses to accept char[1000] types as char* ?
Guenter
...I've got FTGL 2.04: what version are you working from? Also, does this require freetype2 or freetype? Since neither of these comes installed on OSX, can we link it into the Gem.pd_darwin so people don't have to download and install another library?
thanx, jamie
On Tuesday, July 15, 2003, at 07:54 PM, guenter geiger wrote:
On Tue, 15 Jul 2003, tigital wrote:
...ok, I'm trying to compile now without GLTT, but am having some problems:
src/Base/TextBase.cpp:125: no matching function for call to `FTFont::Open(char[1000], bool)'
Wow, this prototype looks scary. Is it possible that the compiler on OSX just refuses to accept char[1000] types as char* ?
hi guenter,
...dunno, but I don't think that's the problem; in FTGL 2.04, I look at the FTFont.h & .cpp, and there is no "Open" function...I'm looking at the FTGLdemo code, and it declares fonts this way: fonts[FTGL_BITMAP] = new FTGLBitmapFont( fontfile);
...but IOhannes has this in text2d.cpp: m_bfont = new FTGLBitmapFont; m_pfont = new FTGLPixmapFont;
..so something is going on that I don't understand...what version of FTGL are you using?
l8r, jamie
On Tue, 15 Jul 2003, tigital wrote:
hi guenter,
...dunno, but I don't think that's the problem; in FTGL 2.04, I look at the FTFont.h & .cpp, and there is no "Open" function...I'm looking at the FTGLdemo code, and it declares fonts this way: fonts[FTGL_BITMAP] = new FTGLBitmapFont( fontfile);
...but IOhannes has this in text2d.cpp: m_bfont = new FTGLBitmapFont; m_pfont = new FTGLPixmapFont;
..so something is going on that I don't understand...what version of FTGL are you using?
could be 1.4 :( .. this is the version packaged for Debian.
Guenter
Zitiere tigital tigital@mac.com:
...dunno, but I don't think that's the problem; in FTGL 2.04, I look at the FTFont.h & .cpp, and there is no "Open" function...I'm looking at the FTGLdemo code, and it declares fonts this way: fonts[FTGL_BITMAP] = new FTGLBitmapFont( fontfile);
...but IOhannes has this in text2d.cpp: m_bfont = new FTGLBitmapFont; m_pfont = new FTGLPixmapFont;
to have no more "Open" is bad news for me.i really liked the idea of being able to change the font-file without actually having to recreate the FTGLFont. why did he change the API....
..so something is going on that I don't understand...what version of FTGL are you using?
1.4 as mentioned in one of my last mails.
l8r, jamie
Zitiere tigital tigital@mac.com:
...ok, I'm trying to compile now without GLTT, but am having some problems:
src/Base/TextBase.cpp:125: no matching function for call to `FTFont::Open(char[1000], bool)'
...I've got FTGL 2.04: what version are you working from? Also, does
oh, damned.... i used the inofficial debian-packages from http://people.debian.org/~mmagallo/ and thought they would be fairly recent. but, of course they are not *that* recent, but 1.4 (jan2003) - but since i saw a mail from guenter to magallo, i thought this would be ok for me to use. i knew! should have compiled against an own download of ftgl and put it into the GemLibs.
this require freetype2 or freetype? Since neither of these comes
freetype2
installed on OSX, can we link it into the Gem.pd_darwin so people don't have to download and install another library?
this shouldn't be a real problem. i guess you project-builder allows you to define which libraries to link statically and which ones to link dynamically. so "static" is your choice then.
speaking of dynamic/static linking: what is the simple way to make gcc link in a specified lib statically while linking other libs dynamically (günter ?) ?
thanx,
sorry
mfg.as.rd IOhannes
...I've got FTGL 2.04: what version are you working from? Also, does
ok, i have committed changes to work with FTGL-2.04 i really don't understand what he (the ftgl-guy) was saying about <<no consistent way for "destroy()", so i have removed "open()">> and he was changing "render()" to "Render()" and, and, and... good, to have another stable API to support (like ffmpeg)
so go, and give it a try...
ad particle: i have changed the part_source argument (emitting rate) to float.
mfg.a.srd IOhannes
On Sat, 19 Jul 2003, IOhannes m zmoelnig wrote:
...I've got FTGL 2.04: what version are you working from? Also, does
ok, i have committed changes to work with FTGL-2.04 i really don't understand what he (the ftgl-guy) was saying about <<no consistent way for "destroy()", so i have removed "open()">> and he was changing "render()" to "Render()" and, and, and... good, to have another stable API to support (like ffmpeg)
so go, and give it a try...
Great :) Good news is that there will be soon a Debian package for FTGL (and it will be 2.04).
ad particle: i have changed the part_source argument (emitting rate) to float.
I have another patch lying around against libparticle, which makes it behave better if the emitting rate is higher than 1. Currently if you have a point domain it will emit all particles at the same point, the patch takes velocity into acount in order to place them at the position where they are supposed to be. (Hard to explain, but if you try it you'll see what the problem is).
Guenter
mfg.a.srd IOhannes
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
To getting a final release out the door?
I have recently completed the major points on my code check-list for a functional release:
- pix_write works on OSX - pix_film will load both YUV and RGB films using the 'colorspace 0/1' message - pix_video switches color-spaces on the fly using the same 'colorspace 0/1' message - texturing is now assured the fastest path (though the code is fugly) - most of the useful yuv_ objects are now in pix_ - just about every pix_ object does YUV (not the latest commits from Jamie tho) - enough Altivec code is in place to make a difference (still need to do RGB) - overall performance on OSX seems acceptable
Some things are still on the list:
- full scene motion-blur using render to texture - whole list of pix_ objects (color-correction and analysis in particular) - a Quicktime .mov recording object - a few more yuv_ to pix_ conversions (luma_key) - various tweaks and tunings
What does everyone else's TODO list look like right now?
Some of the documentation still remains. Both example and help patches are lacking, and I would like to do more tutorials and get that included in the distribution.
Stability seems pretty good recently on the OSX side, how are the other platforms running?
On a somewhat related note, I have been researching some of the latest developments with vertex-arrays, texturing and shaders, and think that GEM could take advantage of these. It might require a lot of reworking of the render chain to make it happen. I will post more on this later.
cgc
Zitiere chris clepper cgc@humboldtblvd.com:
To getting a final release out the door?
hmm..;-)
I have recently completed the major points on my code check-list for a functional release:
- pix_write works on OSX
cool
- pix_film will load both YUV and RGB films using the 'colorspace 0/1'
message
- pix_video switches color-spaces on the fly using the same
'colorspace 0/1' message
ok, so we have done double work... my [pix_*NEW] objects (video/movie) do (hopefully, not quite sure about movie right now) support something like "color rgba" and "color yuv" messages. they also have a "color grey" message (which i found very handy sometimes)
would it be possible to add grey-image support too ? (guess i hear a sigh from you) don't know, but i guess the symbolic reference "rgba"/"yuv"/"grey" might be more intuitive then 0/1/?
- texturing is now assured the fastest path (though the code is fugly)
- most of the useful yuv_ objects are now in pix_
- just about every pix_ object does YUV (not the latest commits from
Jamie tho)
- enough Altivec code is in place to make a difference (still need to do
RGB)
- overall performance on OSX seems acceptable
cool.
Some things are still on the list:
- full scene motion-blur using render to texture
- whole list of pix_ objects (color-correction and analysis in
particular)
- a Quicktime .mov recording object
- a few more yuv_ to pix_ conversions (luma_key)
- various tweaks and tunings
most of these could wait for the next release then (if we manage to release soon ;-))
What does everyone else's TODO list look like right now?
stability of [pix_] objects ([pix_rtx] seems to be unstable sometimes, same for [pix_sig2pix~] and [pix_pix2sig~]) need beta-testers for [pix_video] ieee1394-support under linux.
Stability seems pretty good recently on the OSX side, how are the other platforms running?
Gem is sometimes quite peculiar when developing patches under linux. however, it runs rockstable in, say, installations.
mfg.a.srd IOhannes
ok, so we have done double work... my [pix_*NEW] objects (video/movie) do (hopefully, not quite sure about movie right now) support something like "color rgba" and "color yuv" messages. they also have a "color grey" message (which i found very handy sometimes)
i forgot to say that my changes were to the old pix_filmDarwin way of loading films. the old method is in good enough shape to transfer to pix_filmNEW i suppose. is it your intention to have the pix_filmNEW included with the next release?
would it be possible to add grey-image support too ? (guess i hear a sigh from you)
i can check and see what the QT support for 8bit greyscale is. i guess there's no reason not to include it... the YUV to grey using pix_grey should be really efficient way to do this too. it may even be faster than the QT internal conversion.
don't know, but i guess the symbolic reference "rgba"/"yuv"/"grey" might be more intuitive then 0/1/?
i fully agree with this. how about 'colorspace rgb/yuv/grey'?
Some things are still on the list:
most of these could wait for the next release then (if we manage to release soon ;-))
sure. at this point, i would rather have the release come sooner without those features than later with them.
What does everyone else's TODO list look like right now?
stability of [pix_] objects ([pix_rtx] seems to be unstable sometimes, same for [pix_sig2pix~] and [pix_pix2sig~]) need beta-testers for [pix_video] ieee1394-support under linux.
i played around with the pix_rtx example last night and it did crash when resizing the video input every once and a while. the log always pointed to line 195, which is the pixels[chRed] = rp[chRed] in the RGBA inner loop. obviously a pointer going off into no-man's land.
Stability seems pretty good recently on the OSX side, how are the other platforms running?
Gem is sometimes quite peculiar when developing patches under linux. however, it runs rockstable in, say, installations.
are those usually pd crashes? i had a whole string of those for a while a month or two ago, but they seem to have stopped.
quite a few of these:
Thread 0 Crashed: #0 0x8fe01280 in halt #1 0x8fe106b4 in link_in_need_modules #2 0x8fe12230 in _dyld_link_module #3 0x90016ae8 in NSLinkModule #4 0x0003bfe4 in sys_load_lib #5 0x00038b28 in glob_initfromgui #6 0x0003281c in pd_typedmess #7 0x000357bc in binbuf_eval #8 0x0003a138 in socketreceiver_read #9 0x00039c84 in sys_domicrosleep #10 0x0003ac00 in sys_pollgui #11 0x000387f4 in m_scheduler #12 0x00038d70 in sys_main #13 0x000026b4 in _start #14 0x000024e4 in start
i never traced it back to anything specific.
Re: [GEM-dev] how close are we... i played around with the pix_rtx example last night and it did crash when resizing the video input every once and a while. the log always pointed to line 195, which is the pixels[chRed] = rp[chRed] in the RGBA inner loop. obviously a pointer going off into no-man's land.
yeah - the "while (count--)" is at least one of the causes of that. I tracked that down last week. I'll check the change in now.
with regards to things on the release to-do: for Windows:
DirectShow film loading is really a must. I've written the object but am unsure whether to include it as a separate object or rework it into the filmNEW style. Is that stable and usable? I haven't looked at the code there for a while. Ditto for the QT for Windows stuff.
Fonts. I've been letting that one sort itself out. I'll see whether the latest checkins work on windows sometime soon.
Big one: Documentation.
Daniel
On Monday, July 21, 2003, at 03:31 AM, Daniel Heckenberg wrote:
Fonts. I've been letting that one sort itself out. I'll see whether the latest checkins work on windows sometime soon. Big one: Documentation.
...i think this is the biggest too, because we are way behind on it ;-) I'm not sure what we should do about merging the extant docs with what chris has been doing, and IOhannes' "GEM primer" is also nice, but really all three of these docs cover the same basics, and a more cogent distillation could result, perhaps with a more "designed" look...also might be nice to have some overall intro, or at least links to, info about image processing, because the use of things like convolutions and filters is pretty intimidating to the uninitiated (and there has been mention that GEM should have a "teaching" function)...
...there are plenty of other doc/example things that could be done to make introduction to pd/gem concepts more playful, such as an example multi-movie player with multiple effects and blending (which I already have something like)...along these lines, we've talked about doing "abstractions", but none have really appeared: I'm thinking about things like: - a camera abstraction that would make movement more like a "normal" 3d engine/game (ie. pitch, roll, yaw): but do we go sin/cos and suffer gimbal lock, or have an all out quaternion setup? - vertex manipulations via the OpenGL wrappers that would do similar things to the geos newWave, ripple, rubber, etc. - perhaps general tutors for the OpenGL wrappers (ala nehe's stuff)? - fonts as particles, or individual control over sub-string characters - other things that haven't even occurred to me ;-)...we all use GEM somewhat differently, so we could all use some example that exhibits methods of working that aren't elsewhere covered...
...besides the above, does everyone like the example patches? From the questions we get about use, it's sometimes hard to see that newbies actually look at them, but just the same they should be a robust set of examples...also, I just compared the help files with actual source files, and here's a list of objects that don't seem to have help files built: GEOS cuboid newWave ripple rubber slideSquares
MANIPS polygon_smooth
MARKEX abs m_control? multiselect? reson? strcat?
PARTICLES part_info part_render part_vector?
PIX's pix_background pix_backlight pix_blur pix_buffer (read/write?) pix_chroma_key pix_color pix_colorreduce pix_compare pix_convert pix_crop pix_delay pix_depot (get/put?) pix_dot pix_duotone pix_dv pix_emboss pix_grey pix_info pix_levels pix_lumaoffset pix_mix pix_motionblur pix_pix2sig~.pd or pix_pix2sig.pd? pix_posterize pix_rds pix_roll pix_scanline pix_sig2pix~.pd or pix_sig2pix.pd? pix_snap2tex pix_test pix_tIIR pix_yuv
...so I guess we all have a little bit of effort to put forth here...plus, existing objects such as gemwin, pix_film, pix_texture, and others have undergone major changes, so they also need to be reviewed/updated...
...beyond that, some of my "soon todo" list includes: - adding other model formats - fullscreen motion blur - "snap to tex" that results in a further processable image - quicktime vr (is there anything like this on linux?) - vertex/fragment programming/shaders
...enough of a job to keep us busy for awhile!
l8r, jamie
On Mon, 21 Jul 2003, tigital wrote:
...besides the above, does everyone like the example patches? From the questions we get about use, it's sometimes hard to see that newbies actually look at them, but just the same they should be a robust set of examples...also, I just compared the help files with actual source files, and here's a list of objects that don't seem to have help files
.. the html documentation needs an update too.
built: GEOS cuboid newWave ripple rubber slideSquares
MANIPS polygon_smooth
I think the naming concept is a bit strange with that. The underscore suggests that it belongs to a group of objects (like pix_ part_ ext), while it doesn't, and it is rather a "normal" gem OpenGL command.
It would be more consistent to call it "smooth", plain, like "alpha".
MARKEX abs m_control? multiselect? reson? strcat?
I think they should go away ...
PARTICLES part_info part_render part_vector?
PIX's pix_background pix_backlight pix_blur pix_buffer (read/write?) pix_chroma_key pix_color pix_colorreduce pix_compare pix_convert pix_crop pix_delay pix_depot (get/put?) pix_dot pix_duotone pix_dv pix_emboss pix_grey pix_info pix_levels pix_lumaoffset pix_mix pix_motionblur pix_pix2sig~.pd or pix_pix2sig.pd? pix_posterize pix_rds pix_roll pix_scanline pix_sig2pix~.pd or pix_sig2pix.pd? pix_snap2tex pix_test pix_tIIR pix_yuv
...so I guess we all have a little bit of effort to put forth here...plus, existing objects such as gemwin, pix_film, pix_texture, and others have undergone major changes, so they also need to be reviewed/updated...
Yep. What about producing a template for the help-* patches (we have to rename them for pd-0.37 too, right ?) and ask gem users to help with the documentation effort.
I think it would be nice if the help patches have a minimal functionality too, so the user can see the effect directly.
...beyond that, some of my "soon todo" list includes:
- adding other model formats
- fullscreen motion blur
- "snap to tex" that results in a further processable image
isn't that what pix_snap does ?
- quicktime vr (is there anything like this on linux?)
- vertex/fragment programming/shaders
...enough of a job to keep us busy for awhile!
thats for sure.
Guenter
guenter geiger wrote:
MANIPS polygon_smooth
I think the naming concept is a bit strange with that. The underscore suggests that it belongs to a group of objects (like pix_ part_ ext), while it doesn't, and it is rather a "normal" gem OpenGL command.
It would be more consistent to call it "smooth", plain, like "alpha".
very right, in my last mail, concerning the "blend" functionality, i have forwarded this old email, where "polygon_smooth" was considered a bad name (but better than "pix_a_2grey") but i had no other idea.
so i will remove "polygon_smooth" and call it "smooth", as i guess nobody has really used it - chris ? (i think you might be the only one...). and we could really add an alias for compatibilty.
MARKEX abs m_control? multiselect? reson? strcat?
I think they should go away ...
should go away from GEM ?
probably we should really remove all the markEX-objects that are not referred too by the help/example-patches (and as time permits, rewrite them, so that they don't need markEX)
Yep. What about producing a template for the help-* patches (we have to rename them for pd-0.37 too, right ?)
i don't fully understand this.
and ask gem users to help
with the documentation effort.
yes, this would probably result in better help-patches (because they might show real needs)
I think it would be nice if the help patches have a minimal functionality too, so the user can see the effect directly.
so, without a [gemwin] but with a [gemhead] ?
...beyond that, some of my "soon todo" list includes:
- adding other model formats
right, i have been talking about this for years. btw. is quake2 available for macOS ? are quake2-models used ? this might be a common format for animated models.
- fullscreen motion blur
i think i even added a message to [gemwin] for this (but i stopped working...)
- "snap to tex" that results in a further processable image
isn't that what pix_snap does ?
that's what i thought too. but probably it's more like snapping to texture *and* getting the image into user-space.
mfg.as.rd IOhannes
On Tue, 22 Jul 2003, IOhannes m zmoelnig wrote:
abs m_control? multiselect? reson? strcat?
I think they should go away ...
should go away from GEM ?
probably we should really remove all the markEX-objects that are not referred too by the help/example-patches (and as time permits, rewrite them, so that they don't need markEX)
yes, thats what I meant. They are not gem specific, therefore they do not really fit. Don't know how many people use them. I think some people complained that they have to load Gem in order to use these externals. Putting them in CVS together with the externals we could avoid this.
Yep. What about producing a template for the help-* patches (we have to rename them for pd-0.37 too, right ?)
i don't fully understand this.
Well, we design a help-template, more or less defining how help patches should look like, and volunteers can help us documenting the single objects using that template. (See attachment for a proposal describing circle)
and ask gem users to help
with the documentation effort.
yes, this would probably result in better help-patches (because they might show real needs)
I think it would be nice if the help patches have a minimal functionality too, so the user can see the effect directly.
so, without a [gemwin] but with a [gemhead] ?
I would say with gemwin too. Doesn't hurt, does it ?
Guenter
On Tuesday, July 22, 2003, at 09:47 AM, guenter geiger wrote:
On Tue, 22 Jul 2003, IOhannes m zmoelnig wrote:
abs m_control? multiselect? reson? strcat?
I think they should go away ...
should go away from GEM ?
probably we should really remove all the markEX-objects that are not referred too by the help/example-patches (and as time permits, rewrite them, so that they don't need markEX)
yes, thats what I meant. They are not gem specific, therefore they do not really fit. Don't know how many people use them. I think some people complained that they have to load Gem in order to use these externals. Putting them in CVS together with the externals we could avoid this.
...this sounds fine to me, but I use counter alot...
Yep. What about producing a template for the help-* patches (we have to rename them for pd-0.37 too, right ?)
i don't fully understand this.
Well, we design a help-template, more or less defining how help patches should look like, and volunteers can help us documenting the single objects using that template. (See attachment for a proposal describing circle)
...I think what IOhannes meant by not understanding is that you seem to imply that pd-0.37 has some new criteria for naming that is different than < pd-0.36 : is this true, and if so, what's the new way of doing things?
and ask gem users to help
with the documentation effort.
yes, this would probably result in better help-patches (because they might show real needs)
I think it would be nice if the help patches have a minimal functionality too, so the user can see the effect directly.
so, without a [gemwin] but with a [gemhead] ?
I would say with gemwin too. Doesn't hurt, does it ?
...[gemhead]'s would make for easier first time use/exploration, but also can make for unexpected renders if ya don't close the help patch before you test your new patch...sure a gemwin wouldn't hurt, just a copy/paste, but it can take up lots of space with all the possible messages, so maybe we need an abstraction, something like [pd window]? Also, I'm a big fan of making sure that all number boxes are set to the correct limits (ex. pix_kaleidoscope), thereby reducing the amount of work in the future for cut&paster's...I certainly don't like the way alot of the help patches are at the moment, that is, without functionality; that seems better for a manual than a reference patch...
l8r, jamie
On Tue, 22 Jul 2003, tigital wrote:
...I think what IOhannes meant by not understanding is that you seem to imply that pd-0.37 has some new criteria for naming that is different than < pd-0.36 : is this true, and if so, what's the new way of doing things?
oops, and my nice template was for nothing then :( The new help patches have a "help-" prefix. so we'd have to rename them to help-whatever.pd
and ask gem users to help
with the documentation effort.
yes, this would probably result in better help-patches (because they might show real needs)
I think it would be nice if the help patches have a minimal functionality too, so the user can see the effect directly.
so, without a [gemwin] but with a [gemhead] ?
I would say with gemwin too. Doesn't hurt, does it ?
...[gemhead]'s would make for easier first time use/exploration, but also can make for unexpected renders if ya don't close the help patch before you test your new patch...sure a gemwin wouldn't hurt, just a copy/paste, but it can take up lots of space with all the possible messages, so maybe we need an abstraction, something like [pd window]?
You took a look at the template, by chance ? I think people are accostumed to change close the help patches after looking at them.
Also, I'm a big fan of making sure that all number boxes are set to the correct limits (ex. pix_kaleidoscope), thereby reducing the amount of work in the future for cut&paster's...I certainly don't like the way alot of the help patches are at the moment, that is, without functionality; that seems better for a manual than a reference patch...
I think that some of the help patches can take the role of the simple examples in the future. Would be nice if the examples would be more in a tutorial style, like the the once that are included with pd.
Guenter
On Tuesday, July 22, 2003, at 01:10 PM, guenter geiger wrote:
On Tue, 22 Jul 2003, tigital wrote:
...I think what IOhannes meant by not understanding is that you seem to imply that pd-0.37 has some new criteria for naming that is different than < pd-0.36 : is this true, and if so, what's the new way of doing things?
oops, and my nice template was for nothing then :( The new help patches have a "help-" prefix. so we'd have to rename them to help-whatever.pd
...nonono! I'm at work, and haven't been able to take the time to check the patch: it's much easier to sneak in email ;-) Now you've got me even MORE curious as to what ya cooked up for the template...
l8r, jamie
oops, and my nice template was for nothing then :( The new help patches have a "help-" prefix. so we'd have to rename them to help-whatever.pd
You took a look at the template, by chance ? I think people are accostumed to change close the help patches after looking at them.
i had a look and i like it. the only question is have multiple gemwins trying to go at once. apart from the potential confusion, is it stable? maybe we should stress test about a dozen of these going at once to find out.
I think that some of the help patches can take the role of the simple examples in the future. Would be nice if the examples would be more in a tutorial style, like the the once that are included with pd.
i agree with the help file as an example file, but not with the tutorial approach. one of the big problems i have with the pd tutorials (and pd in general) is how cluttered the patches get. some of those example/tutorial patches are total cluster-fuck style that are difficult to read and nearly impossible to follow (the fft ones in particular). that's why my approach was to separate the patch from the text in such a way that it aids usability of the patch and still makes the doc's text clear. hopefully the correlation between what the text is referring to in the patch is helped by the inclusion of the images of the patch contents. i haven't gotten very much in-depth feedback on the approach.
another thing about my tutorial style was designing it so that the text could elucidate various theoretical and conceptual issues, which would be unwieldy to do in the patch itself. i also feel that the modular approach to the patches makes them easier to comprehend, more useful to pick apart, and demonstrates one of the inherent strengths of pd.
cgc
Guenter
chris clepper wrote:
oops, and my nice template was for nothing then :( The new help patches have a "help-" prefix. so we'd have to rename them to help-whatever.pd
You took a look at the template, by chance ? I think people are accostumed to change close the help patches after looking at them.
i had a look and i like it. the only question is have multiple gemwins trying to go at once. apart from the potential confusion, is it stable? maybe we should stress test about a dozen of these going at once to find out.
all the gemwin's refer to the same context (GemMan), to the same gem-window (i think it is the same under macOS ?) there is this counter that counts, whether there is at least one [gemwin], and if not (the last one destroyed), it destroys the gem-window. i don't think anything might break. i have just opened 11 of guenter's circle.pd and it did fine.... (apart from the confusion, that you can click on [create( although the window is created or on [destroy( after it is destroyed...)
now, does macOS already has multiple gem-wins ? (i haven't noticed last time i saw macOS-gem, but this might be due to the fact, that the gem-windows were hiding each other (?))
anyhow, i'd like to have multiple gem-windows (each gemwin connected to each own window/output (like ieee1394, file) in the future (after this release)
mfg.a.srd IOhannes
guenter geiger wrote:
On Tue, 22 Jul 2003, tigital wrote:
...I think what IOhannes meant by not understanding is that you seem to imply that pd-0.37 has some new criteria for naming that is different than < pd-0.36 : is this true, and if so, what's the new way of doing things?
oops, and my nice template was for nothing then :( The new help patches have a "help-" prefix. so we'd have to rename them to help-whatever.pd
but Gem sets the helpsymbol to prepend the "Gem/"-directory. will this be affected than too (something like "help-Gem/part_source.pd") ????
mfg.,asrd IOhannes
On Tue, 22 Jul 2003, IOhannes m zmoelnig wrote:
but Gem sets the helpsymbol to prepend the "Gem/"-directory. will this be affected than too (something like "help-Gem/part_source.pd") ????
yes, you are right, forgot about that. tested and works, so we have to make a link from Gem to help-Gem only and support both styles.
Guenter
guenter geiger wrote:
MANIPS polygon_smooth
I think the naming concept is a bit strange with that. The underscore suggests that it belongs to a group of objects (like pix_ part_ ext), while it doesn't, and it is rather a "normal" gem OpenGL command.
It would be more consistent to call it "smooth", plain, like "alpha".
very right, in my last mail, concerning the "blend" functionality, i have forwarded this old email, where "polygon_smooth" was considered a bad name (but better than "pix_a_2grey") but i had no other idea.
so i will remove "polygon_smooth" and call it "smooth", as i guess nobody has really used it - chris ? (i think you might be the only one...). and we could really add an alias for compatibilty.
i think there might be a smooth object already. i know my friend had to name his smoothing object for float streams 'smoooth' to avoid conflicts - this may have only been for Max, I'll double check. maybe geo_smooth (geosmooth? polysmooth?) is more descriptive? i suppose another option is adding FSAA to the whole scene, but this may not be an option on all platforms and hardware.
chris clepper wrote:
ok, so we have done double work... my [pix_*NEW] objects (video/movie) do (hopefully, not quite sure about movie right now) support something like "color rgba" and "color yuv" messages. they also have a "color grey" message (which i found very handy sometimes)
i forgot to say that my changes were to the old pix_filmDarwin way of loading films. the old method is in good enough shape to transfer to pix_filmNEW i suppose. is it your intention to have the pix_filmNEW included with the next release?
personally, i would like to have the very next release rather sooner than later. so wouldn't enforce the pix_filmNEW and friends for gem-0.888, since it should be transparent for the user anyhow.
don't know, but i guess the symbolic reference "rgba"/"yuv"/"grey" might be
more intuitive then 0/1/?
i fully agree with this. how about 'colorspace rgb/yuv/grey'?
ok, will change it, then
sure. at this point, i would rather have the release come sooner without those features than later with them.
so we go d'accord
What does everyone else's TODO list look like right now?
Gem is sometimes quite peculiar when developing patches under linux.
however, it runs rockstable in, say, installations.
are those usually pd crashes? i had a whole string of those for a while a month or two ago, but they seem to have stopped.
unfortunately i cannot really say, whether they have stopped or not. in may/june they certainly appeared. then i did a gem-patching-performance in late july and it never ever did think of crashing (but things were quite simplistic -- no pix_ or whatever)
mfg.a.rd IOhannes
Zitiere guenter geiger geiger@xdv.org:
Great :) Good news is that there will be soon a Debian package for FTGL (and it will be 2.04).
so who is packaging it ? you or marcello ? i have build the package too, so if someone would like to save some time (but he might have to wait ;-))
speaking of gltt/ftgl: under linux, the font-rendering stuff is the only problem when trying to compile gem with gcc-3.3 marcello seems to compile all his packages with gcc-2.95 which then resolves in undefined symbols if gem is compiled with gcc>3.0 the solution is as simple as getting the sources and compiling the packages with a recent compiler et voila.
i understand that there might be some dependencies on gltt compiled with gcc- 2.95, but since ftgl would be very new, i would suggest to start with a gcc-3.3 version...
mfg.a.drs IOhannes
On Sun, 20 Jul 2003 zmoelnig@iem.at wrote:
Zitiere guenter geiger geiger@xdv.org:
Great :) Good news is that there will be soon a Debian package for FTGL (and it will be 2.04).
so who is packaging it ? you or marcello ?
Marcello told me he uploaded it.
Guenter
i have build the package too, so if someone would like to save some time (but he might have to wait ;-))
speaking of gltt/ftgl: under linux, the font-rendering stuff is the only problem when trying to compile gem with gcc-3.3 marcello seems to compile all his packages with gcc-2.95 which then resolves in undefined symbols if gem is compiled with gcc>3.0 the solution is as simple as getting the sources and compiling the packages with a recent compiler et voila.
i understand that there might be some dependencies on gltt compiled with gcc- 2.95, but since ftgl would be very new, i would suggest to start with a gcc-3.3 version...
mfg.a.drs IOhannes
On Saturday, July 19, 2003, at 01:09 PM, IOhannes m zmoelnig wrote:
...I've got FTGL 2.04: what version are you working from? Also, does
ok, i have committed changes to work with FTGL-2.04 i really don't understand what he (the ftgl-guy) was saying about <<no consistent way for "destroy()", so i have removed "open()">> and he was changing "render()" to "Render()" and, and, and... good, to have another stable API to support (like ffmpeg)
so go, and give it a try...
...giving it a try, but have a question: are we supposed to try to do this with just -DFTGL, or is it necessary to include both -DGLTT & -DFTGL? I'm having problems with just using -DFTGL:
In file included from src/Geos/text2d.cpp:17: src/Geos/text2d.h:65: warning: ISO C++ forbids declaration of `FTFont' with no type src/Geos/text2d.h:65: `FTFont' declared as a `virtual' field src/Geos/text2d.h:65: parse error before `*' token src/Geos/text2d.h:66: syntax error before `*' token src/Geos/text2d.cpp: In function `void* _classtext2d(t_symbol*, int, t_atom*)': src/Geos/text2d.cpp:24: cannot allocate an object of type `text2d' src/Geos/text2d.cpp:24: because the following virtual functions are abstract: /Users/tigital/puredataDev/Gem/src/Base/TextBase.h:64: virtual void TextBase::fontNameMess(const char*) /Users/tigital/puredataDev/Gem/src/Base/TextBase.h:68: virtual void TextBase::setFontSize(int) /Users/tigital/puredataDev/Gem/src/Base/TextBase.h:72: virtual void TextBase::setPrecision(float) src/Geos/text2d.cpp: In constructor `text2d::text2d(int, t_atom*)': src/Geos/text2d.cpp:36: class `text2d' does not have any field named `m_afont' src/Geos/text2d.cpp:37: abstract virtual `virtual void TextBase::fontNameMess(const char*)' called from constructor src/Geos/text2d.cpp: In destructor `virtual text2d::~text2d()': src/Geos/text2d.cpp:40: `m_font' undeclared (first use this function) src/Geos/text2d.cpp:40: (Each undeclared identifier is reported only once for each function it appears in.) src/Geos/text2d.cpp:41: `m_afont' undeclared (first use this function) src/Geos/text2d.cpp: At global scope: src/Geos/text2d.cpp:43: no `FTFont* text2d::makeFont(const char*)' member function declared in class `text2d' src/Geos/text2d.cpp: In member function `void text2d::setFontSize(float)': src/Geos/text2d.cpp:65: warning: assignment to `int' from `t_float' src/Geos/text2d.cpp:65: warning: argument to `int' from `t_float' src/Geos/text2d.cpp: In member function `virtual void text2d::render(GemState*)': src/Geos/text2d.cpp:100: `m_depthJus' undeclared (first use this function) src/Geos/text2d.cpp:100: `FRONT' undeclared (first use this function) src/Geos/text2d.cpp:101: `BACK' undeclared (first use this function) src/Geos/text2d.cpp:102: `HALFWAY' undeclared (first use this function) src/Geos/text2d.cpp:108: `justifyFont' undeclared (first use this function) src/Geos/text2d.cpp: In static member function `static void text2d::obj_setupCallback(_class*)': src/Geos/text2d.cpp:299: `aliasMessCallback' is not a member of type `text2d' ...failed CompileCplusplus /Users/tigital/puredataDev/Gem/build/GEM_darwin.build/ gem_darwin+FTGL.build/Objects-normal/ppc/text2d.o ...
l8r, jamie
sorry,
...figured it out and changed cvs: typo in TextBase.h:
virtual FTFont*makeFont(const char*fontname)=0;
should be:
virtual FTFont* makeFont(const char*fontname)=0;
...well, now there's a problem with the library loader in pd:
dyld: /usr/local/pd/bin/pd Undefined symbols: _FT_Stream_OpenGzip _bdf_driver_class _pfr_driver_class _pshinter_module_class _t42_driver_class
...some of this seems like it comes from libfreetype.a, which I've linking against...
hmmm, jamie
On Saturday, July 19, 2003, at 05:15 PM, tigital wrote:
On Saturday, July 19, 2003, at 01:09 PM, IOhannes m zmoelnig wrote:
...I've got FTGL 2.04: what version are you working from? Also, does
ok, i have committed changes to work with FTGL-2.04 i really don't understand what he (the ftgl-guy) was saying about <<no consistent way for "destroy()", so i have removed "open()">> and he was changing "render()" to "Render()" and, and, and... good, to have another stable API to support (like ffmpeg)
so go, and give it a try...
...giving it a try, but have a question: are we supposed to try to do this with just -DFTGL, or is it necessary to include both -DGLTT & -DFTGL? I'm having problems with just using -DFTGL:
In file included from src/Geos/text2d.cpp:17: src/Geos/text2d.h:65: warning: ISO C++ forbids declaration of `FTFont' with no type src/Geos/text2d.h:65: `FTFont' declared as a `virtual' field src/Geos/text2d.h:65: parse error before `*' token src/Geos/text2d.h:66: syntax error before `*' token src/Geos/text2d.cpp: In function `void* _classtext2d(t_symbol*, int, t_atom*)': src/Geos/text2d.cpp:24: cannot allocate an object of type `text2d' src/Geos/text2d.cpp:24: because the following virtual functions are abstract: /Users/tigital/puredataDev/Gem/src/Base/TextBase.h:64: virtual void TextBase::fontNameMess(const char*) /Users/tigital/puredataDev/Gem/src/Base/TextBase.h:68: virtual void TextBase::setFontSize(int) /Users/tigital/puredataDev/Gem/src/Base/TextBase.h:72: virtual void TextBase::setPrecision(float) src/Geos/text2d.cpp: In constructor `text2d::text2d(int, t_atom*)': src/Geos/text2d.cpp:36: class `text2d' does not have any field named `m_afont' src/Geos/text2d.cpp:37: abstract virtual `virtual void TextBase::fontNameMess(const char*)' called from constructor src/Geos/text2d.cpp: In destructor `virtual text2d::~text2d()': src/Geos/text2d.cpp:40: `m_font' undeclared (first use this function) src/Geos/text2d.cpp:40: (Each undeclared identifier is reported only once for each function it appears in.) src/Geos/text2d.cpp:41: `m_afont' undeclared (first use this function) src/Geos/text2d.cpp: At global scope: src/Geos/text2d.cpp:43: no `FTFont* text2d::makeFont(const char*)' member function declared in class `text2d' src/Geos/text2d.cpp: In member function `void text2d::setFontSize(float)': src/Geos/text2d.cpp:65: warning: assignment to `int' from `t_float' src/Geos/text2d.cpp:65: warning: argument to `int' from `t_float' src/Geos/text2d.cpp: In member function `virtual void text2d::render(GemState*)': src/Geos/text2d.cpp:100: `m_depthJus' undeclared (first use this function) src/Geos/text2d.cpp:100: `FRONT' undeclared (first use this function) src/Geos/text2d.cpp:101: `BACK' undeclared (first use this function) src/Geos/text2d.cpp:102: `HALFWAY' undeclared (first use this function) src/Geos/text2d.cpp:108: `justifyFont' undeclared (first use this function) src/Geos/text2d.cpp: In static member function `static void text2d::obj_setupCallback(_class*)': src/Geos/text2d.cpp:299: `aliasMessCallback' is not a member of type `text2d' ...failed CompileCplusplus /Users/tigital/puredataDev/Gem/build/GEM_darwin.build/ gem_darwin+FTGL.build/Objects-normal/ppc/text2d.o ...
l8r, jamie
Zitiere tigital tigital@mac.com:
sorry,
...figured it out and changed cvs: typo in TextBase.h:
virtual FTFont*makeFont(const char*fontname)=0;
i see, gcc doesn't complain about this...
should be:
virtual FTFont* makeFont(const char*fontname)=0;
...well, now there's a problem with the library loader in pd:
of course you have to link to freetype, but what else ?
mfg.,as.rd IOhannes
Zitiere tigital tigital@mac.com:
On Saturday, July 19, 2003, at 01:09 PM, IOhannes m zmoelnig wrote:
...I've got FTGL 2.04: what version are you working from? Also,
does
ok, i have committed changes to work with FTGL-2.04 i really don't understand what he (the ftgl-guy) was saying about <<no
consistent way for "destroy()", so i have removed "open()">> and he was changing "render()" to "Render()" and, and, and... good, to have another stable API to support (like ffmpeg)
so go, and give it a try...
...giving it a try, but have a question: are we supposed to try to do
this with just -DFTGL, or is it necessary to include both -DGLTT & -DFTGL? I'm having problems with just using -DFTGL:
hi. 1. you should either use "-DFTGL" or "-DGLTT" but not both at a time. 2. i have also updated hte Base/TextBase.* files, ( i guess you are still using the old ones?) 3. in Base/TextBase.h there is already a define for FTGL when using __APPLE__ (please remove it at your will)
else: the "FTFont.h" should be included in Base/TextBase.h too, so most of your problems might be gone then...
mfg.as.rd IOhannes
-
chris clepper -
Daniel Heckenberg -
guenter geiger -
IOhannes m zmoelnig -
IOhannes zmoelnig -
tigital -
zmoelnig＠iem.at