GEM-dev

gem-dev@lists.iem.at

2417 discussions

debian woody, gem und ich
by Gerald Leier 08 Aug '03

08 Aug '03

servus mitnand, ich versuche seit ein paar tagen gem zu installieren. zur zeit verwende ich die cvs version von vor 4 tagen. beim starten von pd erhalte ich folgende fehlermeldung: bubble:/usr/src/cvs# pd -lib /usr/src/cvs/Gem/Gem.pd_linux using OSS audio interface /usr/src/cvs/Gem/Gem.pd_linux.pd_linux: /usr/src/cvs/Gem/Gem.pd_linux.pd_linux: undefined symbol: _16pix_kaleidoscope.g_pCurrentCosTable /usr/src/cvs/Gem/Gem.pd_linux: can't load library jemand eine idee woran das liegen koennte ? danke gerald

2 1

Re: [GEM-dev] alpha
by cgc＠humboldtblvd.com 31 Jul '03

31 Jul '03

Quoting rat(a)telecoma.net: > thx a lot for checking and solving, > i guess gige is also looking for the problem, maybe we should inform > the > others that u found the problem ? > damn webmail interfaces. ;) hopefully this will make it to the list. > On Thu, 31 Jul 2003 cgc(a)humboldtblvd.com wrote: > > > Quoting rat(a)telecoma.net: > > > > > more info: > > > the change which leads to the non alpha thingi > > > must have happend after 15th of may. > > > i m helping a student with a project and he uses the bogusfront > > > windows > > > binaries, and with the 2003-05-15 ones it still works. > > > > > > erich > > > > > > > Ok, this helped a ton in finding the problem. In pix_texture I > hardcoded GL_RGB > > as the internal texture format, and forgot to add in the code to have > it switch > > on the fly. The previous code for setting the internal GL format was > wrong, so > > I will try and correct this tonight when I get back on a GEM CVS > machine. > > > > If you need to fix this ASAP and can't wait for a commit, then change > the > > GL_RGB8 in glTexImage2D to GL_RGBA (it's about line 265 in > pix_texture). > > > > Sorry about this, I was mainly trying to assure the fastest possible > YUV and > > rectangle texture path on OSX and forgot to test alpha functions > before the commit. > > > > cgc > > > >

2 2

loop-y question
by tigital 28 Jul '03

28 Jul '03

here's something a bit different from what we've been talking about: I'm trying to create a patch that would show some typical uses of the OpenGL wrapper objects, but I'm stuck on creating the looping mechanism: basically, I'd like to draw one object many times in different translations (imagine a cube made of sub-triangles where the row size of sub-triangles can be changed)...so I'm trying to do 3 nested for loops to produce xyz coordinates, and then send them to a GEMglTranslatef within a routine for drawing a triangle... ...the accompanying patch uses 3 [until]'s, but doesn't produce the desired result; has anyone figured out a way to do this? I figure that this would be a first step toward better documentation, and would like to also do it for things such as the newWave, ripple, etc geos, so that we don't get object bloat ;-) thanx, jamie

4 8

changes to alpha
by guenter geiger 27 Jul '03

27 Jul '03

I just comitted some changes to the alpha object, that turns off depth buffer testing for transparent objects. This way blending does not depend from the drawing order anymore. There is a message with the bad name "auto 1|0" that turns this off. It is still important to draw all [alpha] chains after the chains that don't have alpha ... this could be automatic too at some point, but it would involve some sort of render chain scheduling ... Hope this doens't brake anything ... please let me know if so. Greetings, Guenter

1 0

pix'es in CVS
by IOhannes m zmoelnig 22 Jul '03

22 Jul '03

i have committed another bunch of file-changes to the CVS. mainly they are: checks for non-null pointers before freeing memory. grey-scale support for [pix_movement] and hopefully fixed the bug fixed [pix_resize] (it always crashed on my machine) but gosh, it is so slow.... fixed [pix_scanline] for interleave=0 did crash my machine with floating point exception. removed all the references to YUV/altivec/Grey-processing in jamie's port of pete's plugins. these are virtual functions and have a defined behaviour (call imageProcess which outputs some warning). mfg.a.srd IOhannes

1 0

part_render
by guenter geiger 22 Jul '03

22 Jul '03

When using part_render there is one problem left, and that is that the object (the circle in the example) gets drawn with default values at the center,and is not actually a particle (You can check this by setting the part_size value in the 07.render.pd examples of the particle patches to a small value like 0.1) To get rid of that problem, some chances in GemBase.cpp have to be introduced. There are several possibilities: 1) make gem_renderMess a virtual function and reimplement it in part_render.cpp without the problematic gem_state message drawback: virtual functions are slow 2) provide some mechanism to suppress the message (setting a flag in the GemBase class) drawback: a bit hacky 3) call continueRender at the end of every render() call drawback: lots of work I have implemented the first version already, could commit it, but I want to hear what you think first. Guenter

2 3

CVS checkins
by IOhannes zmoelnig 22 Jul '03

22 Jul '03

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

7 37

"blend"-messages
by IOhannes m zmoelnig 22 Jul '03

22 Jul '03

hi i just noticed, that jamie has committed changes to the "cube"-Geos, to allow a [blend 1/0( message. however, to avoid restarting this and to save everyone a lot of programming time, i would suggest: 1) using inheritance rather than putting the same piece of code in each Geo. 2) (more important): why not use [alpha] and [polygon_smooth] ? i think this has been discussed. [alpha] certainly needs more attention to make the blending-style-setting more consistent. i don't think, that there is any performance-issue in this, and it could save us all (jamie) a lot of time... mfg.as.rd IOhannes ps:here is my last email regarding this, from 25/02/03: chris clepper wrote: >> and another two changes: >> >> 1. [alpha] >> now you can set the blending-function >> 0..GL_ONE_MINUS_SRC_ALPHA that's the (old) default >> 1..GL_ONE (as would be enabled by the "blend" message to various objects. > > > perhaps we should add some of the other options for glBlend and allow both the source and destination to be changed. yes definitely. it was just done very quickly. > >> 2. [polygon_smooth] >> enables polygon smoothing >> > > the only difference i found is that [polygon_smooth] sets blending for the entire render chain it's attached to while the "blend" method would actually work on individual objects in the same chain. it's probably not a big deal, and maybe not even a big feature to warrant keeping "blend". it's definitely easier to do the [polygon_smooth] rather than add glBlend to each Geo. it enables aa'ing for everything that comes below the [polygon_smoothing]. Maybe we should just add a another state that disables aa'ing: suggestion: 1 .. enable smoothing 0 .. disbale smoothing -1 .. leave unchanged >> i think [polygon_smooth] is a bad name. but which one would be better ? > > still no suggestions for the name... maybe wrapping [alpha], [color] well, yes it is not that bad. (at least better than [pix_a_2grey]) > and [polygon_smooth] up in an abstraction called [geo_blend] would be something to try? ;-) mfg.ads.r IOhannes

2 4

FTGL working on OSX!
by tigital 20 Jul '03

20 Jul '03

hey, ...just figured out the linking problem, and tested the extruded text: yay! now for biking/picnicking ;-) l8r, jamie

2 2

cvs additions
by tigital 16 Jul '03

16 Jul '03

ok, ...I'll join in with committing my latest fooling around: gempiximageload: cleanup, changed to __APPLE__, fixed cast problem gempixObj.h: added PeteHelpers.h stuff (defines, inline functions) pix_filmDarwin.cpp: fixed cast problem (UInt8* instead of Str255) pix_filmDarwinYUV.cpp: fixed cast problem (UInt8* instead of Str255) Pixes/setup.h: alphabetized functions; also added new setup functions: pix_colorreduce, pix_halftone, pix_kaleidoscope, pix_levels, pix_lumaoffset, pix_metaimage, pix_refraction, and pix_backlight initial import of Pete's_Plugins ports (RGBA only so far): pix_colorreduce, pix_halftone, pix_kaleidoscope, pix_levels, pix_lumaoffset, pix_metaimage, pix_refraction, and pix_backlight worldlight.cpp: OSX only change: made a check for glcontext in destructor (would crash if window was never created, like during editing) help/pix_halftone.pd help/pix_kaleidoscope.pd help/pix_metaimage.pd help/pix_refraction.pd ...and more on the way l8r, jamie ps: I'd like to have future #ifdef's be __APPLE__ instead of MACOSX ps: IOhannes, could you update the FTGL to 2.04? I can't find the older 1.3/1.4...

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

GEM-dev