[gephex-devel] opengl and gephex

[Manuel Massing]

Hi,

> - 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 :) )

yeah, I really second that "won't have to worry" part :-) besides, how
would you share resources (textures) if every plugin initialises its own
context?

> - 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.

performance-wise, the most costly operations are probably switching
textures (cache invalidation), so i'd say pretty unavoidable between modules.

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
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...

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...

> 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.

> Our approach is similar. We are still arguing on the setup (default
> state restoring).

yes, i don't see an easy&clean solution to the problem either, but if it's
only a tradeoff between (relative) security and flexibility, i'd vote for 
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 :-) the performance issue might
merit some discussion, though. probalby depends on the typical gl-module
complexity, i.e. if "module-switch" overhead will be amortized by
rendering tasks.

> 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.

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>)...

cheers,

	Manuel