[gephex-devel] opengl and gephex

[Philipp Promesberger [c]]

Hi Manuel,

> [...]
>
>>- The core can act as a state-manager/state-cache...this is a very
>>common technique upon 3D-engine developers to minimize renderstate
>>changes on the card (performance).
>>    
>>
>
>i just don't think it would be very convenient to wrap everything
>"the_core->glTriangle3f(....)" - style, both for module and core-coders.
>  
>
You're right, I'm not planning on wrapping every sinlge call there is. 
The most important ones are certainly texture swiches, vertexbuffer 
switches and genereal states (texture/sample/render-states). Since I'm 
coming from direct3d I'm not quite sure how this will look in the end 
and which states are convenient to wrap. Especially the render calls 
like triangle or quad or vertex or whatever they're are called make no 
sense probably, since you can't do error checking inbetween 
glBegin()/End() afaik.Wrapping Begin makes a lot of sense though for 
instance, cause this would be the point were you shove all cached states 
to the card.

>maybe a coarse-grained approach would be sufficient, i.e. by just providing
>some state handling in the form of (module to core: "i will mess with register
>combiners, so disable them afterwards if you don't trust me"). default opengl
>  
>
Well, I'd just go for general states...or let's say, every state "group" 
that is cached, has to be completely cached throughout the whole core. 
(Again, in Directx you have a RENDERSTATE setting and a TEXTURESTATE and 
SAMPLERSTATE setting, so this is somewhat easier grouped...as i can see 
for now gl provides a lot of different calls to change settings in the 
same "logical" group). Texture switches can be avoided though since one 
source can have the same texture in multiple inputs...the module would 
never know and just call Texture->set()....the core would realize that 
and not issue any changing.

>attributes like color matrial, shade_model, alpha etc. could be saved and
>restored by default. declare everything else as undefined? i mean, a typical
>renderer will run through several state changes during a single frame
>anyway...
>  
>
A general way of handling IMHO is anyway: If you want something to be 
set: set it. After that, you don't have to care about restoring any 
states. I think that's the most consistent way of doing it.Of course 
this could include some overhead for the module writer (setting all 
those states which are "usually" set), but it's a clear guideline to 
stick to and it's clean.

>just as a use case: what i would like to do is integrate my rendering engine
>into a gephex module - e.g. create signal-driven animations and mix them with
>video streams. the thing is, this is pure opengl and about 20k loc. [and
>preferably resides in a shared library] it would be easy to integrate if gl
>can be called directly from the module, just a matter of a few state-setup
>calls before entering the unaltered render() method. but if everything needs
>to pass through an indirection layer, that's gonna be tough...
>  
>
I see where you're coming from. Well... most stuff WOULD have to go 
through an indirection layer, there's no way around that. Be assured 
though that generally a query/replace from "gl" to "glcore::core->" will 
solve 90% of the work :) (that's ought to be case senstitive though ;) )

>>Well, the core IS the statemanager, and yes, state changes are  probably
>>of no concern ATM...it could be in the future though.
>>This statemanager is the core, and it will be provided to modules
>>through an input (that's the plan right now). The modules can have an
>>arbitrary number of input textures (pointers to Texture* or an id, have
>>a look at the debate :) ) and several output texture which must allow to
>>be rendered to (or glCopySubTexImage or something as a fallback
>>solution). The module can then do what it wants, the scheduler just
>>checks if an update of this module is even necessary or not.
>>    
>>
>
>do multiple outputs have a real advantage versus running single-output modules
>in parallel? because in the first case, the scheduler could just setup the
>rendering context (e.g. as pbuffer, or schedule a post-activation upload)
>before activating the module, even less work for the plugin writer.
>  
>
Well, I don't see any use for multiple outputs anyway, since you can 
connect multiple inputs to one output. So, just forget about that :)

> [...]
>
>the flexible or less intrusive approach. i say relative security because an
>indirection layer could not stop me from linking to opengl directly and
>messing around with the states anyway :-) 
>  
>
Of course...you could still do that...there's no way to prohibit that. 
You can never prevent plugin writers from doing the craziest shit :)

> [...]
>
>i think i'll have to dive into the gephex code to get a grip of what's going
>on in there before i bother you with further discussions ;-) just need to
>pass an examination tomorrow (<panik-mode>arghh, today</panik-mode>)...
>  
>
good luck :)

-coma


--
------------------------ [ SECURITY NOTICE ] ------------------------
To: gephex-devel at lists.gephex.org.
For your security, coma at gephex.org
digitally signed this message on 12 June 2005 at 23:53:47 UTC.
Verify this digital signature at http://www.ciphire.com/verify.
------------------- [ CIPHIRE DIGITAL SIGNATURE ] -------------------
Q2lwaGlyZSBTaWcuAVdnZXBoZXgtZGV2ZWxAbGlzdHMuZ2VwaGV4Lm9yZwBjb21hQGdlc
GhleC5vcmcAZW1haWwgYm9keQD9DwAAfAB8AAAAAQAAAAvLrEL9DwAATQMAAgACAAIAIB
+oZ0QQT9njneW0BJbMBFNhWVl5dPLKbVD4NhL1uvURAQCAY+pi9xDkKQY80xF9IH5q1/2
gCQ+37YHuT7nVIQT0MQF2nWD7bl+ph26aLUX0peJeT3AMqH0jKkbWv8wql0qVahnbU2ln
RW5k
--------------------- [ END DIGITAL SIGNATURE ] ---------------------