[gephex-devel] opengl and gephex

[Manuel Massing]

Hi Philipp,

> You're right, I'm not planning on wrapping every sinlge call there is.
> The most important ones are certainly texture swiches, vertexbuffer
> switches and genereal states (texture/sample/render-states). Since I'm
> coming from direct3d I'm not quite sure how this will look in the end
> and which states are convenient to wrap. Especially the render calls
> like triangle or quad or vertex or whatever they're are called make no
> sense probably, since you can't do error checking inbetween
> glBegin()/End() afaik.Wrapping Begin makes a lot of sense though for
> instance, cause this would be the point were you shove all cached states
> to the card.

hm, maybe i misunderstood you there. do you want to offer the state
handling via a higher-level c++ interface, or via a (necessarily complete)
emulation of the gl layer?

> Well, I'd just go for general states...or let's say, every state "group"
> that is cached, has to be completely cached throughout the whole core.
> (Again, in Directx you have a RENDERSTATE setting and a TEXTURESTATE and
> SAMPLERSTATE setting, so this is somewhat easier grouped...as i can see
> for now gl provides a lot of different calls to change settings in the
> same "logical" group). Texture switches can be avoided though since one
> source can have the same texture in multiple inputs...the module would
> never know and just call Texture->set()....the core would realize that
> and not issue any changing.

yepp, i guess gl has a somewhat more chaotic state handling mechanism.
Nice poster to print out and impress your friends: 

	http://www.opengl.org/documentation/specs/version1.1/state.pdf 

might also be of use for the implementation, though :-)

> A general way of handling IMHO is anyway: If you want something to be
> set: set it. After that, you don't have to care about restoring any
> states. I think that's the most consistent way of doing it.Of course
> this could include some overhead for the module writer (setting all
> those states which are "usually" set), but it's a clear guideline to
> stick to and it's clean.

yes, one can certainly live with that. if it doesn't mean you have
to disable everything you don't use (so that e.g. a
"render-everything-in-a-shade-of-glibberish" pixelshader from
the previous module won't affect you downstream). i think its
majorly this (keeping a "barebone" or defined state on entry) which makes 
the state manager a necessity. 

i am not sure if the glPush{Client}Attrib(GL_{CLIENT_}ALL_ATTRIB_BITS) /
glPop{Client}Attrib() encompass all (extension) state variables,
but if so, they could yield the easiest solution to the barebone state
restoration.

(the following applies only if you do plan to emulate the gl layer:)

> > 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
> I see where you're coming from. Well... most stuff WOULD have to go
> through an indirection layer, there's no way around that. Be assured
> though that generally a query/replace from "gl" to "glcore::core->" will
> solve 90% of the work :) (that's ought to be case senstitive though ;) )

i agree that this shouldn't be a big problem for most applications, though
it could be a bit inconvenient in some cases: if its a externaly maintained
piece of gl software, you'll have to keep the (query/replace) module version
in sync with the gl code base. okay, i know, there's sed :-)

but could one possibly set things up so that the modules just links to a
glcore c-interface instead of "the real" gl lib? in the sense that glcore
would provide the indirection transparently via c-bindings? sorry if i'm a bit
clueless about linking issues - probably calls for "multiply defined symbol"
hell.

void glWhatever(GLint foobar)
{
	glcore::core->glWhatever(foobar);
}

apart from that, the gl-emulation surely also has its advantages, i like the
possibility to handle gl extension management transparently in the core 
(glew - http://glew.sourceforge.net/ - is a nice library for such things,
btw). on the other hand, creating all these bindings is probably a nightmare
if there's no automated way. especially if you want to support different
verions, e.g. opengl2.0, in the future... 

> >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.
>
> Well, I don't see any use for multiple outputs anyway, since you can
> connect multiple inputs to one output. So, just forget about that :)

of course, i meant to write "in the latter case", so absolutely no
disagreement here :-)

oh, and i hope my comments don't come over as nitpicking, i just thought i'd
add my "lazy gl programmer" perspective.

> >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>)...
>
> good luck :)

thanks! surprisingly, i survived :-)

btw, are there any documents regarding the gephex 0.5 architecture?

bye,

	Manuel