Hi Sebastian, On 19 January 2015 at 12:43, Sebastian Messerschmidt < [email protected]> wrote:
> after inspecting the new DisplacementMappingTechnique I have some ideas. > First of all, the shader source code should be configurable from the > outside via interface in order to integrate it into own pipelines (in my > case I have a CustomShaderProgram based pipeline. > Making the methods of the osgTerrain::GeometryPool virtual might a means of achieving this. Allow you to overload the osg::Program creation. > Another option might be to create an interface to let one set the program > from the outside, alongside with an option to retrieve the "defines" that > would have been injected. > I am actually working on adding support to osg::State, osg::Program and osg::Shader for passing on #define's to the Shaders, and have these #define's match up to osg::StateSet::setMode(GLenum,..) management of glEnable/glDisable. This would eventually be user customizable, but in the first instance my intention is to have the normally toggling of GL_LIGHTING, or GL_TEXTURE_* map to #define GL_LIGHTING etc. that gets included infront of a Shader when it's compiled. This approach would allow use to blend fixed function style OSG usage with Shaders. Potentially this approach could be a new take on doing shader composition. Second suggestion: The use of tesselation shaders. > Currently you are pushing a lot vertex buffers around for tiles with a > regular grid. The idea of the GeometryPool is that most of the osg::Geometry are now shared so the number of VBO's being managed is now far lower than it used to be with the brute force GeometryTechnique. With Geocentric databases the grids aren't actually regular, it takes double maths to make sure the curvature it correct when you set up the osg::Geometry to share. It might be more efficient only pushing 4 vertices and letting the > tesselation do the rest. It might be even more efficient to move the > displacement there, since each vertex would be touched exactly once in > terms of transform. > My work I checked in last on using geometry shaders to toggle the edge of the triangles to fit with terrain has worked as I intended but performance hit is far greater than I expected - it's around 3 times slower on the GPU when using the geometry shader than when just using the vertex and fragment shaders to displacement mapping. For the small visual quality improvement the use of geometry shaders provide I'm incline to think for most users they aren't a good tradeoff. It's could be that tessellation shaders will be good solution, it's something I've only briefly looked at so can't comment on it more deeply. The issue of using double maths to compute the base mesh that is displaced is something that will require us to still do stuff on the CPU unless we start pushing double data down to the GPU, but here dragons lie... I'm open to suggestions, especially if you pony up some code to illustrate what you have in mind :-) Robert.
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
