Robert,
actually, the only motivation is the support of older hardware which, for
instance, include my old netbook with Intel 945GM graphics chip (in Core2
chipset).
Core2 isn't old at all, just a couple of years, so yes this is
something desirable to support. I'm a bit surprised that GL2 isn't
fully supported.
Surprise even on my side. OpenGL renderer: Intel 945GM, Version: 1.4.0 -
Build 7.14.10.4926
I verified that it is the latest available driver from Intel for WinXP.
It is 945GSE Core/Core2 style chipset, released Q2.2008 for Atom
processors. Manual speaks about Intel 945GSE graphics card that belongs
to Intel's GMA 950 architecture. And GMA 950 is limited to OpenGL 1.4 by
design.
Sure, we can drop it, but in my humble opinion, it would be better to leave
it as it is, e.g. keeping glEnable(GL_STENCIL_TEST_TWO_SIDE) and no support
for mixing one and two sided stenciling, than to remove the extension
support completely. But others may have different opinion.
Well we have code that is checked in, and with careful usage would be
safe, but... portability is an issue that anyone uses the NVidia route
would need to take care of.
Yes. Careful usage is ok, but I understand - it is basically not
finished. :-(
Do you think it will be too difficult to develop "proper" solution? I am
able to put a little bit time to it, if you provide few hints about the
proper solution.
Perhaps "proper" solution might be something like eating the
GL_STENCIL_TEST_TWO_SIDE when under GL2/ATI.
That would definitely work. I cracked my head, and let me suggest two
more solutions, although I am not sure if they are possible:
- to make osg::Stencil disable GL_STENCIL_TEST_TWO_SIDE
If osg::StencilTwoSided enabled GL_STENCIL_TEST_TWO_SIDE, osg::Stencil
will disable it. osg::Stencil::apply can easily query
osg::StencilTwoSided::Extensions and see which rendering way is used. If
it is NVIDIA's EXT_stencil_two_side, osg::Stencil would
disable(GL_STENCIL_TEST_TWO_SIDE), eliminating the effect of
osg::StencilTwoSided and restoring one side stenciling once again.
- during StencilTwoSided::apply to inject GL_STENCIL_TEST_TWO_SIDE mode
into osg::State::_modeMap to fool osg::State and give it impression that
the current StateSet enabled GL_STENCIL_TEST_TWO_SIDE in a regular way.
Thus, this mode should be disabled once the rendering of the subgraph
bellow completes and the rendering moves to other parts of the scene
graph that should not be affected by "our" StateSet. Or, am I wrong in
this approach?
One more idea that you may not welcome - Is rendering graph produced by
cull visitor expected to be reused for more windows/screens or rendering
contexts? If no, then cull is done for particular graphics context. In
that case, it would be beneficial to know extension string and OpenGL
version of graphics context for which the cull is performed. In that
case, it would be straightforward solution to query these at context
creation/realization and storing them at the GraphicsContext object. If
this would be possible, it would, among others, resolve the
GL_STENCIL_TEST_TWO_SIDE issue.
Thanks,
John
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
