GEM-dev

gem-dev@lists.iem.at

2417 discussions

Compiling Vertex Arrays on Linux
by B. Bogart 29 Nov '05

29 Nov '05

Hey Johannes, I hope you can help me with this. I'm trying to compile the vertex branch of Gem but the compile fails with: make[1]: Leaving directory `/home/bbogart/pd-stuff/Gem.vertex/src/openGL' rm -f Gem.pd_linux *~ make -C Base -f ..//Makefile.subdir -j4 make[1]: Entering directory `/home/bbogart/pd-stuff/Gem.vertex/src/Base' make[1]: *** No rule to make target `/usr/X11R6/include/X11/extensions/xf86vmode.h', needed by `GemWinCreateXWin.d'. Stop. make[1]: Leaving directory `/home/bbogart/pd-stuff/Gem.vertex/src/Base' make: *** [Base] Error 2 indeed there is no such file xf86vmode.h on my system. According to the debian package search the package that provides that header is: xlibs-static-dev_4.3.0.dfsg.1-14sarge1 I have xlibs-static-dev installed: ||/ Name Version Description +++-==============-==============-============================================ ii xlibs-static-d 6.8.2.dfsg.1-1 X Window System client library development f but it only provides the following extension headers: /usr/X11R6/include/X11/extensions/bigreqstr.h /usr/X11R6/include/X11/extensions/xf86bigfont.h /usr/X11R6/include/X11/extensions/xf86bigfstr.h I tried to install the version 4.3.0 of the static libs but apt says my other packages depend on the newer version: libs-static-dev: libxinerama-dev conflicts with xlibs-static-dev (<< 6.8.1-0ubuntu1) xlibs-static-dev (version 4.3.0.dfsg.1-14sarge1) is to be installed. dpkg: error processing /home/bbogart/Desktop/Downloads/xlibs-static-dev_4.3.0.dfsg.1-14sarge1_i386.deb (--install): conflicting packages - not installing xlibs-static-dev Errors were encountered while processing: Note I have no unbuntu repositories on my machine, I guess those are taken from ubuntu and put into sarge. Why the new version of xlibs-static-dev does not provide the same headers I have no idea. What is this header for and how could I disable it? Thanks. b.

3 3

compiling gem with mingw
by Thoralf Schulze 28 Nov '05

28 Nov '05

Hi there, kicked off by hcs's new extended builds, I fired up msys again to build gem with mingw. I ditched my efforts with dev-c++ in favour of the (more) usual ./configure && make && make install way of compiling ... I stumbled upon the following problems - it would be great if someone could help out here: 1.) the build target is recognized as MINGW32_NT-5.0, which is the output of uname -s . I'm worried about two things here: first, the -5.0 seemingly refers to the version of nt mingw is running on, which might not be what we want. And secondly, there is no configMINGW32_NT-5.0.h.in file in src/Base - I just copied over configNT.in for the time being. In dev-c++, the target was GNUWIN32, which seems to be the better choice to me. 2.) configure checks for opengl by checking the presence of libGL.a (configure:5321: checking for glInitNames in -lGL ) . afaik, this is libopengl32.a in mingw . but I have to verify this again ... 3.) m_pd.h doesn't get found unless the appropriate path is exported via CPPFLAGS. now this file can be literally anywhere on a windows installation ... 4.) where is the right place to define platform-specific compiler- / linker options? I guess we need at least the -mms-bitfields option somewhere ... thank you very much for your help, thoralf. ___________________________________________________________ Yahoo! Model Search 2005 - Find the next catwalk superstars - http://uk.news.yahoo.com/hot/model-search/

2 1

curve3d CPU usage
by B. Bogart 26 Nov '05

26 Nov '05

Hey all, I'm trying to get slightly better resolution out of my curve3d objects, so I'm using them in array. Strange thing I'm seeing is that each curve3d rendered seems to use up about 20% of my AMD64 CPU. (3200+, Nvidia N6600) (on linux) running 60fps. Though I'm not manipulating the points at all, just connecting the gemhead straight to the curve3d and thats it, 20%. I'm aiming to use a grid of 4x3 curve3ds, but my test patch has only 4 and its already using up about 80% of my CPU without even sending new control-point data. Any ideas on how to make this object more optimized? I'd really like to be able to use more than a few of these objects... (no wonder my performance patch with a cube of 6 curve3d objects uses up 100% CPU of my 1.25Ghz g4 powerbook.) Thanks all. b.

2 2

Re: [GEM-cvs] Gem/src/Pixes pix_filmDarwin.cpp,1.25,1.26
by james tittle 26 Nov '05

26 Nov '05

On Nov 26, 2005, at 12:08 AM, christopher clepper wrote: > Update of /cvsroot/pd-gem/Gem/src/Pixes > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv3227 > > Modified Files: > pix_filmDarwin.cpp > Log Message: > Added the first check for HD format clips to deal with their > trickster frame sizes. Also, a fix for sound continuing after > rendering stops. ...snip... > + void pix_filmDarwin :: startRendering() > + { > + //bit of a hack related to stopRendering() > + SetMovieVolume(m_movie, kFullVolume); > + } > + > + void pix_filmDarwin :: stopRendering() > + { > + //bit of a hack to keep the sound from playing after rendering > stops > + SetMovieVolume(m_movie, kNoVolume); > + } > + ...I think you need to commit the new pix_filmDarwin.h, because these are not defined currently... james

1 0

glsl- test patch
by james tittle 26 Nov '05

26 Nov '05

...to go along with the commits, here's a test patch and a glsl vert/ frag combo that I've been using to see if everything works: the shader is the toon shader (again!?!) from the orange book, with a coupla changes: I changed most of the uniform variables to const's, because I haven't done a vec3 uniform changer, and since uniform variables are always zeroed by the glsl linkage, even though the shader might be working, ya wouldn't likely see any output ;-\ ...does it work elsewhere? ;-) jamie

2 1

2 gem windows?
by myrssini 23 Nov '05

23 Nov '05

Hi there is there a way to get 2 gem windows displaying at the same time from one pc? thanks m

1 0

Re: [GEM-dev] Re: GEM shader usage
by Tebjan Halm 22 Nov '05

22 Nov '05

by the way, there is an amazing code to calculate raytraced quaternion julia sets on the GPU. you need a PS 3.0 card (nvidia 6200 or higher) to get it to run. i rendered this video in only 2 hours on a nvidia 6800 card: http://vvvv.meso.net/tiki-index.php?page=TonfilmsPatches a nice detail: http://vvvv.meso.net/tiki-browse_image.php?imageId=1511 and from somebody else a pic: http://vvvv.meso.net/tiki-browse_image.php?imageId=1509 the code can be found here: http://graphics.cs.uiuc.edu/svn/kcrane/web/project_qjulia.html keep on codin' tebjan

3 4

vertices...questions without answers
by IOhannes m zmoelnig 22 Nov '05

22 Nov '05

hi i am currently trying to re-do the vertex stuff in a manner that everybody can live with. i think we agree on following (synching brains): everything is a float! (even color; see matju's thoughts about out-of-gamut colors; and i think it is a very hard restriction for processing if we stick to 256 values (we already see problems with pix-processing)) vertices, color: 4 floats (x,y,z,w; r,g,b,a) normals: 3 floats (x,y,z) texcoords: 2 floats (u,v) data is tightly packed. however, some things are a bit unclear to me, and i'd like to have your advice on this topic. i have 2 base classes for vertex unops and binops. unary operation (excerpt from Base/GemVertexObj.h) <GemVertexObj.h> ////////// // which vertices to manipulate // this is a generic routine for all arrays (whether they have 2, 3 or 4 elements) // note: you should really implement the optimized routines below virtual void processVertex(GLfloat*array, int count, int stride); ////////// // optimized routines // note: the SIMD-optimized routines fall-back to the non-SIMD routines // note: these routines fall back to the generic processVertex // texCoords are only (u,v) virtual void processVertex2 (GLfloat*array, int count); virtual void processVertex2Altivec(GLfloat*array, int count); virtual void processVertex2SSE (GLfloat*array, int count); // normals are (x,y,z) virtual void processVertex3 (GLfloat*array, int count); virtual void processVertex3Altivec(GLfloat*array, int count); virtual void processVertex3SSE (GLfloat*array, int count); // vertices are (x,y,z,w); colors are (r,g,b,a) virtual void processVertex4 (GLfloat*array, int count); virtual void processVertex4Altivec(GLfloat*array, int count); virtual void processVertex4SSE (GLfloat*array, int count); </GemVertexObj.h> so there are specialized functions for processing an array (without a notion of what the data actually represents; however there is a notion about the "array-width"; there are SIMD-optimized functions which fallback to the generic ones. there is an optional super-generic function which normally just prints an error message if it ever gets called. this is just a fallback for more specialized functions (and most likely will never get really implemented) the render() function calls the appropriate processVertex*() function. if the user specified to process just a sub-array of the data, this is handled by render() (so the processVertex*() functions don't know anything about offsets,...) that was the easy part. however i have some problem with the binop: <GemVertexDualObj.h> ////////// // Do the rendering virtual void processVertices(float*larray, int lsize, int lstride, float*rarray, int rsize, int rstride); virtual void processVertices2(float*larray, int lsize, float*rarray, int rsize); virtual void processVertices2SSE(float*larray, int lsize, float*rarray, int rsize); virtual void processVertices2Altivec(float*larray, int lsize, float*rarray, int rsize); virtual void processVertices3(float*larray, int lsize, float*rarray, int rsize); virtual void processVertices4(float*larray, int lsize, float*rarray, int rsize); </GemVertexDualObj.h> so the basic concept is the same (i just stripped some SIMD-function declarations to make it more readable) i thought it would be very nice, to be able to "merge" 2 arrays of different lengths, so there are "lsize" and "rsize". but when i converted the first code snippets, i just started to wonder, whether this is a good idea? most likely SIMD-optimization (especially streaming extensions) will be disabled with such feature turned on. so would it be better to just have a dedicated [vertex_resize] object that does the extrapolation to bigger/smaller arrays (however well this might work), and enforce the 2 arrays to be of the same size?? quite minor question, but i'd like to get some feedback. additionally, what do you think of it in general? as for now, the coder would have to write the functions for each type of arrays. does anybody know of a way how to faciliate this task? it is basically a copynpaste of the same code-snippet with very minor modifications. it would be nice if the function would have to be coded only once and the compiler/preprocessor would expand it to all eventualities. i would hate to use weird preprocessor magic. and the resulting code must be as fast as if it was written explicitely. anybody has any ressources on this? fma.dsr. IOhannes

2 1

OSX command-line compile fails?
by B. Bogart 22 Nov '05

22 Nov '05

Hey all, I'm trying to compile gemCVS from today on OSX via terminal and running into some problems. I'm not sure, now that I think about it, if I ever got the terminal build to work. Anyhow I tried compiling gem with: cd src/ autoconf #does nothing it seems ./configure # seems ok... make end of the make output looks like: g++ -o Gem.pd_darwin -framework QuickTime -framework Carbon -framework AGL -framework OpenGL Base/*.o Controls/*.o Geos/*.o Manips/*.o MarkEx/*.o Nongeos/*.o Particles/*.o Pixes/*.o openGL/*.o -ldl -lz -lm -lpthread ld: Undefined symbols: _main _canvas_getcurrent _error _gensym _atom_getint _class_addmethod _outlet_anything _outlet_free _outlet_new _inlet_free _inlet_new _clock_delay _clock_getsystime _clock_gettimesince _clock_new _clock_unset _post _atom_getfloat _atom_getsymbol _class_doaddfloat _garray_class _pd_findbyclass _s_float _atom_string _class_addlist _class_addcreator _class_new _class_sethelpsymbol _pd_new _class_addbang _outlet_float _outlet_symbol _outlet_list _s_list _clock_free _s_ _outlet_bang _canvas_makefilename _class_addanything _dsp_add _nullfn _s_signal _garray_getfloatarray _atom_getfloatarg _freebytes _getbytes _s_bang _floatinlet_new _class_addsymbol _resizebytes _startpost _pd_bind _pd_unbind _canvas_getdir _open_via_path _s_symbol _garray_redraw make: *** [Gem.pd_darwin] Error 1 I think think pthread should be in there. ./configure did label a few things as cached but I don't see a config.cache (indeed there is none) in Gem/src/ Any ideas? Anyone know how Erich could compile Gem for G4 on the source-forge compile farm? Thanks! b.

2 1

OpenGL wrapper question
by cyrille henry 16 Nov '05

16 Nov '05

hello again, for the project i'm curently working on, i nead the GEMglBlendEquation object. i was surprised not to find it in the openGL wrapper stuf. is there a good reason not to have it? could it be add? (the attached code was succesfully tested on linux and osX, and should work also on windows as it's only cut&paste from the GEMglBegin object). and one last question for today : there is lot's of nice new stuf in gem CVS that i would like to use, unfortunatly i really want to use only stable releases of pd and Gem as i really nead to run my patch on lot's of diferents computer without compilling stuff everytime. So : is there any plan to have a gem 0.91 soon? thanks cyrille

3 4

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