GEM-dev August 2004

gem-dev@lists.iem.at

6 participants
7 discussions

off to new shores...
by IOhannes m zmoelnig 17 Sep '04

17 Sep '04

hi all. now that the gem-0.90 release is out for some weeks, i think it is time to start some traffic on this list again. (but of course: what to talk about now ? we used to discuss the release for years...) some points: ------- stable: i have branched v0_90 for bug-fixes on the latest stable release -------------------- further development: wini has done some research on opensource-development and has found out that os-dev can be organized effectively in (surprise:) several ways to achieve an optimum development/stability-ratio: (the following is a translation from german and it is already some weeks ago, so i might use the wrong termini) a) pope: one person revises all code and decides which parts of the development should go into the next release b) committee: a small team off people does like the pope. c) branching: each new feature is branched off the main CVS-trunk. as soon as it has become stable the branch is merged with the main trunk. i don't think that a) would be a very good idea (as it has proven to lead to major quarrels and misunderstanding) as for b) it seems like a bit of an overhead, as the core-development team is so small, that all of us would be in the committee. so i favour c) (with some b)): each development should be forked into a separate branch in the CVS; the core-developpers of this branch work on the code until they consider it stable and then make a call for testing via the list. after it has proven to run stable on all platforms this tree is merged back in. i would suggest that the releasing should be done on each merge of a development-branch to the main-trunk that adds new functionality. (this can be discussed; it is just fundamentally different from the last release) the main-trunk can be used for bug-fixing... ------------- new features: i'm looking forward to vertex-manipulation, pixel-shaders, multiple gemwins, MMX/SSE2, new pixel-effects, pixel-analysis and tons of other things. cheers, comments ? and happy coding mfg.as.dr IOhannes

7 14

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

GEM-dev August 2004