[gephex-devel] opengl and gephex

Philipp Promesberger [c] coma at gephex.org
Sat Jun 11 02:04:14 CEST 2005


Hi,

after a long time of arguing (2 years+ ? :) )  me and martin finally 
came to a conclusion on how to integrate opengl into the gephex project.
Here are the thoughts:

- 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). This core is handed over to every module that is a "GLModule". 
Hence, the module can use gl with no effort soever by just calling the 
corresponding functions from the core. A lib is under development which 
will ease the use of (specifically opengl in this case) the rendersytem 
( for a current state of the lib have a look at 
http://people.gephex.org/~coma/glutil/ ..it's still heavily under 
construction though )
- Every class that is dependend of the core will need to have the core 
to be passed into its constructor so it can handle the rendering system
- GL modules will have an arbitrary number of inputs/ouputs, each of the 
type Texture, which will be RenderTexture for outputs and generic 
Texture for inputs (RenderTexture subclasses Texture). Thus easy 
rendering via Input_texture->Set(); and Output_texture->SetActive(); 
will be possible (this would in the case of opengl bind a texture to a 
certain stage and set Output_texture as an active rendertarget). (this 
is still just a draft, so thoughts are welcome). Every Module can expect 
their inputs/outputs to be initalized (Texture(Core*)). (Note: this has 
to go into 0.5 since this is heavily concerning  the implementation of 
links).
- Core will handle state management, meaning, states are only updated 
when a "draw" call is issued (thus enhancing performance). This is just 
to illustrate that a Core class is indeed required.
- The engine will handle the auto-connection of core to every mdule that 
requires it...or the module writer has to take care of that theirself 
(this discussion vaporized somehow, but since 0.5 doesn't hold any 
states...should be not too hard to work this out though)
- OS-specific things go into IRenderWindow. This class takes care about 
things like rendering contextes, pixelformats, devices and whatsoever. 
This will be passed to the Core class mandatory (initialized) and will 
take care of system specific implementations of how to set up a window 
which opengl can render to. An output module will merely be a wrapper 
around an IRenderWindow able to query/modify all essential parameters 
and issue a blit call.
- If this isn't clear by now: All rendering input will be rendered into 
a rendertarget output (texture). The core will query extensions and 
determine the fastest way to do this.
- Wrapper classes should exist to copy data into textures...this won't 
be very fast though, but it could still be reasonable enough to implement.

That's all I can think of now, Martin will probably complete the missing 
parts tomorrow in one way or the other, it's late and I'm tired and it 
was hell of a long discussion :)

RFC!
-coma




--
------------------------ [ SECURITY NOTICE ] ------------------------
To: gephex-devel at lists.gephex.org.
For your security, coma at gephex.org
digitally signed this message on 11 June 2005 at 00:00:07 UTC.
Verify this digital signature at http://www.ciphire.com/verify.
------------------- [ CIPHIRE DIGITAL SIGNATURE ] -------------------
Q2lwaGlyZSBTaWcuAVdnZXBoZXgtZGV2ZWxAbGlzdHMuZ2VwaGV4Lm9yZwBjb21hQGdlc
GhleC5vcmcAZW1haWwgYm9keQCFCQAAfAB8AAAAAQAAAIcpqkKFCQAApwIAAgACAAIAIB
+oZ0QQT9njneW0BJbMBFNhWVl5dPLKbVD4NhL1uvURAQCAY+pi9xDkKQY80xF9IH5q1/2
gCQ+37YHuT7nVIQT0MUuQkCSxjkc3Mik2T2Tdz+6+eIIWhLT01ZBI5L1ak2LI0TROU2ln
RW5k
--------------------- [ END DIGITAL SIGNATURE ] ---------------------



More information about the gephex-devel mailing list