[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