Hello Johannes, On 03/06/2014 03:56 AM, Johannes wrote: > Ok, here are the first questions I have: > - With respect to the extension mechanism > > i) Could you give me some overall explanation of the route OpenSG is taking?
Window is the interface to obtain extensions (a Window basically represents an OpenGL context within OpenSG). For each extension and each function of an extension that a type wants to use create a static UInt32 member that can hold the extension/function Id - these Ids are independent of the context/window and you only need to obtain their values once, typically in Foo::initMethod(InitPhase ePhase) by calling Window::registerExtension/registerFunction. In Foo::handleGL you can then use Window::hasExtension(UInt32) or Window::hasExtOrVersion() to query if at runtime the extension/OpenGL version meets your requirements. To get an extension function pointer you'd use Window::getFunction(UInt32). > ii) What is the correct way to address symbols? With 'ARB' or 'EXT' or > directly? Depends on whether you want the symbol from the ARB extension the EXT extension or one that is part of the OpenGL spec itself. In general if there is an ARB extension I would suggest using it, the EXT extensions sometimes have subtly different behaviour and the functionality sometimes moves into the spec proper in much later versions that also increase the hardware requirements - so in order to support a feature on as wide a set of hardware as possible I'd suggest using the ARB extension. > iii) The OpenGL symbols like GL_UNIFORM_BUFFER etc. are not known by > OpenSG. At least not in the naive approach starting with > > #include "OSGGL.h" > #include "OSGGLU.h" > #include "OSGGLEXT.h" > #include "OSGGLFuncProtos.h" > > However, I found them in glextarb.h, glcorearb.h and gl3.h. > > I expect that I have to expand "OSGGLEXT.h" for getting proper symbols. > Is that correct? Yes, IIRC that's what has been done so far in order to avoid difficulties with the availability of headers on the various platforms. > From what place do I have to take the symbols declaration then? I'd suggest either the spec or the official headers on the opengl.org website (http://www.opengl.org/registry/). > iv) The function names like glMapBuffer are also unknown with the simple > setup. After looking at the code I suspect that I have to write > something like the following; > > _extVertexBufferObject= > Window::registerExtension("GL_ARB_vertex_buffer_object"); > > _funcUnmapBuffer = Window::registerFunction( > OSG_DLSYM_UNDERSCORE"glMapBufferARB", > _extVertexBufferObject); > > OSGGETGLFUNCBYID_GL3_ES( glMapBuffer, > osgGlMapBuffer, > _funcMapBuffer, > pWin); > > Is that correct? Looks correct to me, see also above. > Is there a simpler way of doing things? I don't think so. The functions that make use of extensions have to be able to work when called from different GL contexts and at least on Windows the extension function pointers from one context are not guaranteed to work on another context (from what I've heard they only have the same value if the contexts have the same pixel format). > Do I have also to expand "OSGGLFuncProtos.h"? Those are used in calls of the OSGGETGLFUNC* macros, so it's probably more convenient to extent that header then duplicate the information elsewhere. > v) Could you briefly outline the steps you perform when introducing new > extensions? Is there any tool support or do you modify the "OSGGLEXT.h" > and "OSGGLFuncProtos.h" by hand? It's a manual process. > vi) Why does OpenSG not use glew? OpenSG has existed for quite a long time at this point and the extension function mechanism has existed for nearly as long. It may not pre-date glew, but I don't think glew had support for multiple contexts when the functionality was added to OpenSG. > - with respect to the handleGL calls: > > Am I correct with the following order of things? > > The Chunk::changed() evaluates the bitmask and any other relevant > information, and signals the task to be happen to the delayed > Chunk::handleGL() execution by calls to the > Window::reinitializeGLObject(), ... functions and that these correspond > to the mode enumerations > > notused = 0x0001, /**< Object is not used at all right now. */ > initialize = 0x0002, /**< Object is being initialized for the first > time. */ > reinitialize = 0x0003, /**< Object is being re-initialized (ie. > significant change) */ > initialized = 0x0004, /**< Object is initialized and valid. */ > needrefresh = 0x0005, /**< Object is initialized but needs a refresh. */ > destroy = 0x0006, /**< Object is to be destroyed (removed from > context) */ > finaldestroy = 0x0007 /**< Object has been removed from contexts, now > release resources. */ > > taken by the Chunk::handleGL() method. Yes, that's a good summary. The motivation is that the application thread (on which Foo::changed() executes) may not have an active GL context, so it can not make GL calls directly. When Foo::handleGL() is called you can be sure to have an active GL context. > That are the current questions at hand. Ok, hope this helps. Cheers, Carsten ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk _______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
