Hi Paul, On Thu, Oct 29, 2009 at 9:22 PM, Paul Martz <[email protected]> wrote: > Hi Robert -- I'm building against the GL3 header now, and many symbols are > used in OSG that are deprecated in GL3, such as some of the TexGen symbols. > So I checked to see what you do for the GLES2 case, and I found the > following in the TexGen header: > > #if defined(OSG_GLES1_AVAILABLE) || defined(OSG_GLES2_AVAILABLE) > #define GL_OBJECT_LINEAR 0x2401 > #define GL_EYE_LINEAR 0x2400 > #define GL_SPHERE_MAP 0x2402 > #define GL_TEXTURE_GEN_S 0x0C60 > #define GL_TEXTURE_GEN_T 0x0C61 > #define GL_TEXTURE_GEN_R 0x0C62 > #define GL_TEXTURE_GEN_Q 0x0C63 > #endif > > If I understand correctly, these are currently non-functional. You've just > added the definitions so that you can compile and link, and you'll add > TexGen later (presumably with the ShaderGen utility). Is that correct?
Yes you've read my intention correctly. My approach with the OpenGL ES port has been to try and keen the public API of the OSG the same across all OpenGL targets - so the libs will be as close to binary compatible as we can get it. One consequence of this approach is that while the public interface is the same the implementation behind the scenes can be different, often an non op, but while this will screw up the runtime behavior so potentially cause bugs in your app if you just assume you can use everything as before, it will at least mean that you can load the full range of scene graphs and then search and replace elements that you know aren't supported on your target of interest. In effect I've pushed the issue of support for non op elements on to application developer to handle, but as the same time given them a basic tool for going about fixing it. > Should I do the same for GL3? I believe that is the right thing to do. Even though texgen for now will be a non op under GL3, at least the osg::TexGen class will be loaded and we can they detect this and use tools like ShaderGen to convert to shader equivalents. Further down the line I am thinking about whether we can do some runtime work to map elements like TexGen to uniforms or runtime modification of texture coordinates (for GLES1.x), this possibility extends to the rest of the osg::StateAttribute that are non ops as well. All these StateAttribute are useful ways to control elements of the rendering so not having them available in some way in GL3 and GLES2 would be a handicap to OSG users. However, solving these problems is something I'm more than happy to leave until after the basic GLES and GL3 ports. Cheers, Robert. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
