Hi Robert,
thanks for the notice. So, I will adjust my plans and I will focus on
completely other work in the mean time
that does not depend on the new GLExtension code.
Good trip,
John
Robert Osfield wrote:
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
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
