timon botez wrote:
Scuse my ignorance. Im using the tex-object to build models and as far as I understand, the text object draws polygons right? How about Gem objects to OBJ's? The rest I can handle in Alias wavefront...
probably i have sent this mail to tim already; but i have lost it and just for the archives:
the problem is a bit subtle. openGL is (to a wide extent) vector-based. Gem is openGL-based.
however, Gem does not handle the vectors (vertices, polygons,...) itself (in very special cases it does so). instead, this is done by the openGL-server (which is done by the GPU on modern gfx-cards) e.g, Gem only tells the openGL-server to rotate an "object"; it does not do the calculations itself.
openGL is optimized for a one-way connection (meaning: it is fast to send something to the openGL-server; but slow to get information back from the server); furthermore i don't even know, whether it is possible, to get the vector-information before it is passed to the rasterizer (the last stage of rendering: make pixels out of abstract polygons)
of course it would be possible to do all the vector-transformations within Gem: this would be slow (as it had to be done on the CPU instead of the optimized GPU); AND this would mean a *lot* of re-programming of things that are already there.
the forthcoming vertex-stuff (a starter is already in the CVS) will handle verteces directly in Gem most of the time an object-exporter will most probably make sense here.
fmg.as.dr IOhannes
On Wed, 25 Aug 2004, IOhannes m zmoelnig wrote:
timon botez wrote:
Scuse my ignorance. Im using the tex-object to build models and as far as I understand, the text object draws polygons right? How about Gem objects to OBJ's? The rest I can handle in Alias wavefront...
probably i have sent this mail to tim already; but i have lost it and just for the archives:
the problem is a bit subtle. openGL is (to a wide extent) vector-based. Gem is openGL-based.
however, Gem does not handle the vectors (vertices, polygons,...) itself (in very special cases it does so). instead, this is done by the openGL-server (which is done by the GPU on modern gfx-cards) e.g, Gem only tells the openGL-server to rotate an "object"; it does not do the calculations itself.
openGL is optimized for a one-way connection (meaning: it is fast to send something to the openGL-server; but slow to get information back from the server); furthermore i don't even know, whether it is possible, to get the vector-information before it is passed to the rasterizer (the last stage of rendering: make pixels out of abstract polygons)
of course it would be possible to do all the vector-transformations within Gem: this would be slow (as it had to be done on the CPU instead of the optimized GPU); AND this would mean a *lot* of re-programming of things that are already there.
the forthcoming vertex-stuff (a starter is already in the CVS) will handle verteces directly in Gem most of the time an object-exporter will most probably make sense here.
just a small remark.
it think it is possible to directly map opengl to postscript, by just mapping the initial data (coordinates, model, ...) and the operations (rotate, translate) to postscript code.
i think there's no 'native' support in postscript for 3d objects (just 2d). anyway, wether anyone would want to invest time in this is another question. postscript is very flexible, but really a pain to use directly. and doing a full mapping is quite a lot of work i think, but definitely possible.
actually, i would be surprized if there isn't any code for this floating around on the internet, maybe using some intermediate format.. so many crazy people out there :)
On Wed, 25 Aug 2004 18:35:14 +0200 (CEST), Tom Schouten doelie@zzz.kotnet.org wrote:
actually, i would be surprized if there isn't any code for this floating around on the internet, maybe using some intermediate format.. so many crazy people out there :)
Now, processing [http://processing.org] (a java api designed for easily creating visual stuff by non-programmers) has postscript and illustrator export libraries so you *could* connect to a processing java applet via a socket and send it the GEM commands too (i've never really played with GEM so don't know the commands) which it'd interpret and create its own 3d objects and could then generate the eps (it handling all the 3d to 2d stuff)
Just a crazy idea
On Wed, 25 Aug 2004, Edward George wrote:
On Wed, 25 Aug 2004 18:35:14 +0200 (CEST), Tom Schouten doelie@zzz.kotnet.org wrote:
actually, i would be surprized if there isn't any code for this floating around on the internet, maybe using some intermediate format.. so many crazy people out there :)
Now, processing [http://processing.org] (a java api designed for easily creating visual stuff by non-programmers) has postscript and illustrator export libraries so you *could* connect to a processing java applet via a socket and send it the GEM commands too (i've never really played with GEM so don't know the commands) which it'd interpret and create its own 3d objects and could then generate the eps (it handling all the 3d to 2d stuff)
Just a crazy idea
there you have it :)
another thing that might be interesting is this python pdf engine. i forgot the name but i saw a presentation about it on a dorkbot meeting in gent. basicly, as far as i understand, it's a wrapper around OSX's pdf engine and it enables you to do generative page design.
there was this nice hack where they generated the python code to generate a pdf from some syntax description. looks like a powerful framework. only OSX though..