GEM-dev

gem-dev@lists.iem.at

2417 discussions

text2d expensive?
by Mirko Petrovich 10 Sep '04

10 Sep '04

Hi, I noticed [text2d] eats 10% of my cpu. This make some patches unusable, like pdtgb01 which shows 200% of cpu usage when using 15 text2d objects. This is strange because [text3d] works well. PB G4 1.33GHz OS X 10.3.5 Gem 0.90 saludos Mirko

2 1

3dp
by Tom Schouten 09 Sep '04

09 Sep '04

hi gemheads, 3dp is working again (with lots of bugs tho) so for those interested in the structure or idea behind it, here's how to get it: http://zwizwa.fartit.com/pd/pdp/overview.html and, of course, all of you are very welcome on the pf-list: http://zwizwa.fartit.com/pipermail/pf-list/2004-September/thread.html time for some more cross-fertilization :) cheers tom

1 0

PD-list archives
by IOhannes m zmoelnig 01 Sep '04

01 Sep '04

hi sorry for cross-posting (but is necessary to test, whether the lists are still working) since people complained about the oh so slow archive-search i have updated it to namazu. drawbacks: no more fance interface each list is kept separately plus: faster thinks yourself of pros/cons. mfg.as.dr IOhannes

1 0

vertex proposals
by IOhannes m zmoelnig 30 Aug '04

30 Aug '04

things i'd like to discuss general ======= [vertex_add] (and all other objects i have done so far) can be applied to all 4 arrays; this is, you can add the vertexArray of the lefthand gemlist to the colorArray to the righthand gemlist. naively i have assumed that all arrays are of the same dimension, which is not true; texCoordArray is [Nx2] and normalArray is [Nx3], the rest is [Nx4]; this is certainly more memory-efficient. however, i would propose to unify all arrays to [Nx4]; why ? 1) i can apply a single processVertex-function to all arrays without having to know anything about the type of data (this reminds me strongly of the "generalized 3d shape synthesizer") 2) there shouldn't be a problem with memory nowadays. 3) operations on the normalArray is probably faster than with [Nx3] (given that SIMD needs aligned memory) why not ? 1) unifying means the the colorArray would most likely stay float instead of becoming int 2) the texCoordArray doubles probably it would be best to define just a number of [Nx4] arrays (with no data types at all) [vertex_model] would then load 4 arrays (vertex, color, normals, texcoords), [vertex_draw] would interprete them according to these defaults. simple generators like [vertex_random] would only create one array which could then be assigned to whatever. objects ======= (just what comes to my mind is useful) _sources_: OBJ-loader, grid, quad, supershape, random, sphere,... _sinks_: draw, OBJ-exporter _manips_(with only a lefthand gemlist): add(=offset), scale, set, matrix-multiplication, rotation _manips2_(with 2 gemlists): add, mul, set, blend _misc_: info, merge (e.g. take array1 of gemlist1 as color and array4 of gemlist2 as vertex) gosh there were so many; i have forgotten them right now... mf.a.sdr IOhannes

4 5

vertex_array branch
by chris clepper 27 Aug '04

27 Aug '04

Hi all I just created a branch called vertex_array in CVS and committed the first set of objects. The only changes to existing files are GemState.h and gemhead.c and the new objects are in the Geos directory. I think I did the tag for the branch correctly, but I was not able to immediately checkout a copy using the -r option; however, cvs update on the existing local files worked fine. cgc

6 24

CVS: checkins and notifications
by IOhannes m zmoelnig 24 Aug '04

24 Aug '04

hi list. i just wanted to inform you what i have done recently: #------------------ 1) branching: there are several branches that i have created, namely "SIMD" (for MMX support) and "multiple_window" 1x) *stupidity*: while branching seems simple, i have experienced that it is a bit beyond my reach. i have done a lot of really stupid things, namely: - branching single files: this is stupid as you cannot update the whole source-tree to the branch (it will delete files that are not in the branch); i hope i have fixed this for now - branching from other branches, that have nothing in common; even worse, only part of the files were branched from another branch, while others were branched from HEAD. this has often lead to an uncompilable source-tree. i *hope* i have fixed this for now - tagging instead of branching: unfortunately "tag" is the default on my graphical cvs-interface, so i have tagged several files instead of branched. with a lot of removing and re-adding i might have fixed this, but i am not sure at all... however, i apologize for my stupidity and hopefully will think before acting in the future. 1a) "SIMD": i have tested it under linux and windows and it works (although i am a bit disapointed of the performance-gain; unfortunately i have no SSE2 machine at hand so i haven't tried this yet); however, i have not tried to compile it under osX yet. the SIMD-functions are named uniformly for all subclasses of GemPixObj (and GemDualObj) and are called automatically if present. 1b) "multiple_window": (there is also a TAG with this name, so beware!) this separates the functionality of [gemwin] (which has vanished) into 2 objects [gemcontrol] and [gemwindow], where [gemcontrol] is the interface to the rendering-engine (GemMan) and [gemwindow] handles the window-management. a lot of code has moved from GemMan to gemwindow; there is a new directory src/Output for alternative output-modules. currently it only holds [gemextwin] which can be used to replace [gemwindow] to render into an externally created window (this really works: http://iem.at/~zmoelnig/GEM/plugin/ ); currently this object compiles under windows & linux but is working only under linux. multiple output-modules can be connected to a [gemcontrol]. there are still a *lot* of problems, so i guess it is not ready for testing. #--------------- 2) new directories: apart from the Gem/src/Output directory i have also created the long awaited Gem/abstractions directory. currently it is empty (it holds a [gemwin]-replacement in the multiple_window branch) and waits to be populated #--------------- 3) i have just created a mailinglist pd-gem-cvs(a)lists.sourceforge.net for email-notifications on CVS-changes (like the pd-cvs list); it will take some hours until it is online i have received email-notification on the CVS-changes for some time and probably someone else is interested too. +++++++++++ mfg.a.asdr IOhannes

3 6

Re: [GEM-dev] vertex_array branch
by IOhannes m zmoelnig 12 Aug '04

12 Aug '04

<oops, this was meant for the list too> chris clepper wrote: > There might be a need to have some objects that only work with a single > data type, which would raise some questions. If I wrote an object that > only made sense for colors or texcoords then how would those be > distinguished? i cannot think of such an object right now (as long as it is about mathematical transformation of the arrays) : even if some functions do not "make sense" there is no reason to prohibit them. on the other hand, sometimes you might want to generate e.g. normals out of the vertex-positions, and probably you would need the same for color *very* seldom; so i would imagine an object [vertex_normalsgenerator] (or whatever name) that only applies to the normals. mfg.a.sdr IOhannes

1 0

GEM: the nVidia bug with pix_film
by Etienne Desautels 10 Aug '04

10 Aug '04

Hi, just to let know, the famous display bug when using pix_film with an nVidia card on os X is solve with the last update of this os, 10.3.5. yooray! Etienne

2 1

Gem: the nVidia bug with pix_film
by Etienne Desautels 07 Aug '04

07 Aug '04

Hello list, a few weeks ago, I ask you about the bug with pix_film and the nVidia cards. Cgc told me that it was a know bug and suggest me to buy an ati card. It could be an option but I would really prefer if I can use my nvidia card. As I say before, I don't have the bug with pix_movie and I can correct it with pix_film by turning off an on the rendering of the gemwin after the movie is loaded. Also, I don't have the bug with the 0.87 version of gem. In view of this facts I was thinking that it could be surely be possible to find a way to avoid the bug. I did a few test by modifying gem and recompile it but without any success. But I'm far from a C++/openGL/carbon guru. I would really appreciate some help on this subject! Maybe I'm wrong but I feel it's probably just a small difference in the way the video is transfer to a texture between pix_movie and pix_film that avoid the bug in pix_movie and when I think about it I start having problem sleeping! Thanks Etienne

2 2

Re: pix_video
by IOhannes m zmoelnig 30 Jul '04

30 Jul '04

luke allen wrote: > Hi, > soon as i create a pix_video object, pd crashes..... unfortunately this is true for me too. (w2k) i will investigate.... mfg.a.srd IOhannes

1 0

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