opengl and gephex
"Philipp Promesberger [c]" <[email protected]> Sat, 11 Jun 2005 02:04:14 +0200
| Newsgroups | gmane.comp.video.gephex.devel |
|---|---|
| Message-ID | <[email protected]> |
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: [email protected]. For your security, [email protected] 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 ] ---------------------