[gephex-devel] opengl and gephex

[Philipp Promesberger [c]]

Manuel Massing wrote:

>Hey,
>
>great to see someone envisaging an OpenGL integration :-) I've just been
>waiting (yeah, lurking :-)) for an easy way to get some 3d running with
>gephex...
>  
>
Very well :)

>  
>
>>>- There is one Core class. This class wraps every call there is (or
>>>every call that is used) of opengl (Note: this could be any rendering
>>>system).
>>>      
>>>
>
>is it really necessary to wrap a whole 3d api? this seems a bit ambitious.
>besides, it's not in the interest of someone who writes OpenGL apps and
>would like to port them to a gephex module... I am assuming here that
>you don't want to build something along the lines of a scene graph manager,
>but just a technical framework to do some hardware-accelerated 3d or
>2d image processing.
>  
>
A Core has several advantages:
- In the ideal case modules wouldn't have to worry about intializing GL 
or OS-dependent things like window-"management". They can just assume GL 
to be initialized (we're still arguing no that though :) )
- 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).
- The core can act as a kind of a Fallback-Manager...for example,  a 
render to texture operation could be done in four or five different ways 
each one gaining speed but losing compatibility. By wrapping operations 
like this through convenience classes the plugin writer would be assured 
to have the optimal way selected automatically.
- Enforce error checking (this and the fact that access to GL is wrapped 
can be of an advantages when debugging)

>I confess I don't know much about the gephex architecture, but wouldn't it be
>sufficient for the graph scheduler to provide an adequate opengl context, i.e.
>uploading input textures and setting an output context before GL-module
>activation? or at the limit, provide a state manager. But I doubt state
>changes will be of any concern (performance wise) compared to texture-upload /
>download ops or framebuffer clears.
>  
>
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.

>so, i guess i'll just add some random notes to the discussion. excuse me if
>i miss the point :-)
>
>	- transitioning image data out of a GL chain is expensive (i.e.
>	  GPU-to-memory transfer!) ideally, a GL chain should therefore mark
>	  the endpoint of the graph, i.e. use OpenGL for device output.
>	  does the architecture allow for typed data streams? if so, make
>	  opengl "images/textures" an own type and define portal modules (convert
>	  image to glimage type) for transition into (texture upload) and out of
>	  gl/gpu-space. 
>  
>
That's the plan.

>	- I think a single (image) output sink is sufficient for any GL processing
>	  module. i am assuming here that only image (RGB) output is propagated, and
>	  only in the form of textures (no shared framebuffers), i.e. depth
>     information is discarded between GL modules (which makes sense, the
>	  depth values being a function of the projection matrix, so that wouldn't be
>	  really consistent anyway...)
>  
>
Exactly. Passing on the depth- or stencilbuffer would not really make sense.

>	- so, for glmodules, the minimal GLscheduler would need to [apart from the 	
>	  texture resource management/propagation, but I this can be handled the same
>	  way as "other" graph resources]: 
>
>		- set the current context to either a framebuffer object(render-to-texture),
>		  or a visible buffer (if the GL module marks the end point of an effect
>		  chain). this way, it will be transparent to the gl module where the output
>		  goes. if FBOs are too state-of-the-artish (don't know if NVIDIA has
>		  implemented them on linux yet?), bite the bullet and use pbuffers. 
>  
>
That's what RenderTexture::MakeCurrent(...) or SetActive or something 
like that should handle...select fbo if available or else use something 
slower.

>		- maybe clear the framebuffer?
>  
>
Modules are given full control on what to render to their output. The 
output module itselfs just renders a fullscreen quad with the last 
texture connected to it bound.

>		- on first activation of the gl module, restore default opengl state, or
>		  call a special GL setup routine. load previously saved state* otherwise. 
>		- call glModule->activate(),->update(),->render(),whatever()
>		- save opengl state*
>		- manage/share the freshly rendered texture id.
>  
>
Our approach is similar. We are still arguing on the setup (default 
state restoring).

>	*caveat: don't know if there is an easy way to store state information for
>	         all those gl extensions. that's where a state manager might make
>	         sense
>  
>
Yepp.

>	- GLModules would only need a method to retrieve the input texture IDs, and
>	  could handle rendering/processing like a normal opengl app. 
>  
>
Of course. This would still be possible, the only wrapping would lie in 
a Texture class...one does not have to use it's convenience functions 
though and can still query the texture id and do everything 
GL-ish/C-ish. The only "limitation" is that you have to use the core as 
interface to gl.


-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 13:06:03 UTC.
Verify this digital signature at http://www.ciphire.com/verify.
------------------- [ CIPHIRE DIGITAL SIGNATURE ] -------------------
Q2lwaGlyZSBTaWcuAVdnZXBoZXgtZGV2ZWxAbGlzdHMuZ2VwaGV4Lm9yZwBjb21hQGdlc
GhleC5vcmcAZW1haWwgYm9keQACEgAAfAB8AAAAAQAAADszrEICEgAA7QEAAgACAAIAIB
+oZ0QQT9njneW0BJbMBFNhWVl5dPLKbVD4NhL1uvURAQCAY+pi9xDkKQY80xF9IH5q1/2
gCQ+37YHuT7nVIQT0MVqhfGpTGWHKKCNV+GRbTMHttrRjgnEqeiliKIyjGGB2zV/6U2ln
RW5k
--------------------- [ END DIGITAL SIGNATURE ] ---------------------