Hi John, As part of my work shader composition I'll be introducing GL mode remapping listing that will automatically ignore modes that are no longer appropriate. Perhaps this scheme could be co-opted to eat the GL_STENCIL_TEST_TWO_SIDE mode when the NVidia extension isn't used.
This would mean we'd need to revisit this issue once I've done more work on shader composition. Hopefully will be getting back to it next week. Robert. On Wed, Sep 15, 2010 at 4:34 PM, PCJohn <[email protected]> wrote: > 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 > > _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
