On 14 Jan 2014, at 15:45, Robert Osfield <[email protected]> wrote:
> On 14 January 2014 14:29, James Turner <[email protected]> wrote: > Firstly, am I correct that osg::Geometry::compileGLObjects is required for > VBOs to function? Or is this purely an optional step? > > compileGLObjects() will be called automatically for you, there is rarely need > to call it directly, and then only when you want to explicitly compile > objects prior to rendering such as when paging, but even then if you use the > OSG's built in osgDB::DatabasePager then the pre compile will be do for you > anyway. > I don't know enough about your code to know whether anything is actually > being done wrong or going wrong somewhere. > > In general you don't need to force a GL boejct compile, it'll happen > automatically for you when it comes to rendering the geometry > > There isn't any stats recorded for how many geometries use VBO's but you > could easily put a print statement into osg::Geometry/osg::BufferObject to > check when code paths it's using, or simply use a debugger and set a > breakpoint. > > Normally one just needs to setUseVertexBufferObjects(true) and that's it, so > it's should be that your app is already using VBO's. If there anything that > makes you think it's not? > I added some very crude changes to Geometry.cpp to test this explicitly. This confirmed that in Geometry::drawImplementation, 'usingVertexBufferObjects' is true. However, I also tested whether or not compileGLObjects is called, and as far as I can tell, it really never is. (Which fits my reading of the code). Originally I wondered if the ‘useVertexArrays’ test in that method was failing, but actually the whole function is never run. (That’s the result I got from my debugger before sending the previous email, but I wasn’t 100% sure the debugger wasn’t confused) What is the mechanism by which the compile step happens for a Geometry (or any Drawable) added to the scene after setSceneData and the CompileOnNextDraw mechanism? Because I’m not seeing it from a static reading of the code (but of course I can have missed it), and the runtime result I observe suggests it’s not occurring either. (Of course, if the compile step isn’t necessary for VBOs to work, this is a red-herring anyway) The meta-point is that I don’t see any performance change when enabling VBOs, and the profiler results on Mac suggest that the Geometry in question is still on the traditional (non-VBO) glDrawArrays path. In my specific case VBOs may or may not help a particular performance problem, but most of the ways I can imagine to fix my user-level issue will work much better if VBOs are actually working as expected. Kind regards, James
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
