[gephex-devel] opengl and gephex

[Philipp Promesberger [c]]

Hi Manuel.

Hope you're still interested in the whole "gephex goes opengl" issue.
I found the time to build a simple crossfade module using the core as 
discussed. I will now try to finalize the core design, if you're 
interested: I'd be glad for some help since I'm not too familiar with 
renderstates. So here's what would be of value to me:
- a list of common extensions
- except glDisable/glEnable states and all texParameters...what states 
would be good to include in the cache?
- I'll publish the current draft of the core library soon, comments on 
that welcome of course
- I haven't really digged into that, but since it is common practice in 
directx...what are your thoughts about handling vertex/index-buffers and 
shaders? (i was thinking of special objects you can feed ascii shaders 
too...this would allow for a great deal of power, but i'm not familiar 
with gl-tools (speaking of vertexshader compilers for instance...how is 
this stuff invoked..in dx you can call this via d3dx from within the 
code...)
- some general outlines...like: (1) i want to have a clear guideline on 
how to implement gl modules, that means: (i) a list of states that is 
"default" (should be compliant to most of the official default states as 
stated in the opengl doc). This can be called over core->setDefaults() 
...just for the sake of "being sure" which states are set and which not. 
I'm just not too familiar with gl yet so i can just go ahead and 
implement it :) (ii) general guidelines, as in: you can NEVER expect 
states to be set...always use the core when appropriate... and such. 
This is really important and should be as detailed as possible to make 
the life for the common module writer as easy as possible. 
I think that's all i can recall atm...but i'm sure there are far more 
issues ahead. My wishlist atm is:
- having a stable core (one that doesn't require changing even with more 
and more extensions pending for instance...i know this is doable...it's 
just an experience issue. I will try and get some more opinions and 
maybe some good, completed state caches for comparisons.)
- having a clear guideline on how to code new modules
- having a vc-wizard (this is win32 only and doesn't concern the 
linux/unix part, and this goes far beyond the gl issue, but i just 
thought of it since i tried to code something during the weekend...but 
it's quite complicated :) ) and/or a nicer way to create modules even 
more quickly...this is mostly a build-system issue and should not affect 
the gl-core-development too much anyway. I just thought i'd throw it in 
here :)
- get new modules fast! I'll not be able to code as much as I do these 
days, so here is a quick list of stuff i'd like to see (i don't know 
what of these i will be able to finish the next weeks):
 (a) gl plasma (easy effect, just jiggle the tex coords)
 (b) radial blur (not the lame version, but recursive..it's much smoother)
 (c) objects! An easy 3d object generator (balls, cubes, 
pyramids....spike-generator..subdivision..supershapes...torusknots) all 
that shit. For "transition" modules it would probably make sense to 
first do environment mapping with those modules.
 (d) texture generator (all sorts. Gephex is fit for this stuff...since 
updates are only issued when inputs change (or if they're not 
deterministic). an easy tex gen chain would only be updated at the 
beginning though).
 (e) i really wanna get a glslang module get going ASAP. this is the 
whole reason i've been working on this...since this would make gephex 
equally powerfull to tools like rendermonkey or the nvidia shader 
framework. Mabye this will rise some core issues also...handling of 
different cards...it should be as comfy as possible as said to just dig 
into gephex and code glslang for tryouts. (the mesh gen is maybe a 
requirement for this though)

(d) this one sticks out...but I've been thinking a lot about this 
lately. The gui is ugly, and i don't really like qt. What about a really 
nice os-independent gl-gui-toolkit? It doesn't need to be too powerful 
(like qt) but most of the stuff one is using is a very small subset of 
the functionality qt provides. This could even be done as a seperate 
project since many people could be interested in something like this. 
It's fairly big though. I'd be in. RFC.

Ok, that's it for now, as usual I was just writing down what was on my 
mind right now....comments and criticism welcome as always.
-coma


--
------------------------ [ SECURITY NOTICE ] ------------------------
To: gephex-devel at lists.gephex.org.
For your security, coma at gephex.org
digitally signed this message on 21 June 2005 at 22:52:44 UTC.
Verify this digital signature at http://www.ciphire.com/verify.
------------------- [ CIPHIRE DIGITAL SIGNATURE ] -------------------
Q2lwaGlyZSBTaWcuAVdnZXBoZXgtZGV2ZWxAbGlzdHMuZ2VwaGV4Lm9yZwBjb21hQGdlc
GhleC5vcmcAZW1haWwgYm9keQAnDgAAfAB8AAAAAQAAADyauEInDgAAggIAAgACAAIAIB
+oZ0QQT9njneW0BJbMBFNhWVl5dPLKbVD4NhL1uvURAQCAY+pi9xDkKQY80xF9IH5q1/2
gCQ+37YHuT7nVIQT0MSg5xpiLncrJJB0zelWT4pBrhe3KhJ2nED/xBoAUPyzgpl/xU2ln
RW5k
--------------------- [ END DIGITAL SIGNATURE ] ---------------------