Hi John, I have GLU changes to bed down before I can dive into an new topics, and also have a business trip next Monday and Tuesday, so it won't be well into next week before I'll be able to get chance to review.
Thanks you patience, Robert. On Fri, Oct 8, 2010 at 11:03 AM, PCJohn <[email protected]> wrote: > Hi Robert, > > please, find attached new OpenGL extension architecture. > > > What it provides: > - Each GraphicsContext derived class may query supported extensions any time > - highly improved flexibility when using OpenGL extensions > - performance + little bit more flexibility to disable extensions/features + > backward-compatibility (unless/until we drop old code) > > > Reasons for the improvement (you may skip if you like the submission): > > Current architecture uses class::Extensions approach while Extensions can be > determined in draw phase only when context is current. This makes the design > of higher-level OSG classes difficult and more complicated. Examples: > - StencilTwoSided - it does not know in cull phase, which of underlying > three implementations will be > used in draw phase > - ShadowMaps - let's expect, there are three implementations, one using the > latest OpenGL 4.1 > with various features and the second using GLSL 1.5 and the third legacy > shader code. > ShadowMap class does not know in cull phase which one should be used. > Thus, it chooses legacy for the first frame. > During the draw phase, it can detect capabilities from graphics context > and use this information > to switch to better path. > - ShadowVolumes - My current implementation uses two sets of attributes. > One is for one sided stencil > and the second for two sided stenciling. Unless I provide explicitly, > which stenciling should be used, > ShadowVolume class have to use slow one sided stenciling until it has a > chance to get capabilities from graphics > context in draw phase. In short, there is at least one frame using slowest > path. > > The usual workaround is to query available extensions in realize operation. > Just initializing class::Extensions is usually sufficient approach. However, > it means we need to know which classes we are going to use in our app. This > is usually true, but we have serialization support for all (or nearly all) > classes in OSG. Thus, we expect that the whole scene can be also loaded from > file whose content is not known beforehand. Thus, we should initialize > Extensions for all the classes. However, it means that our approach will be > broken with each new class added to OSG, forcing us to update the > initialization of classes, .... > > In my opinion, it is a good idea to put list of supported OpenGL extensions > and supported OpenGL version to GraphicsContext, so this information can be > queried at cull time (using cv.getState()->getGraphicsContext()->isGL...). > This smoothly resolves all above mentioned problems. I intend to keep all > class::Extensions classes as they contain function pointers and encapsulate > the extension details. GraphicsContext should be aware just about > support/not-support of particular graphics extension. > > > Attaching one demo-usage on StencilTwoSided class (just for the case, do not > commit it yet). The code was tested on my ShadowVolumes on Windows and works > like a charm. > > Sorry for a long email, but I feel it as the important submission that may > need considerations. > John > > > _______________________________________________ > osg-submissions mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
