Am 19.01.2015 21:40, schrieb Robert Osfield:
Hi Sebastian,
On 19 January 2015 at 12:43, Sebastian Messerschmidt
<[email protected]
<mailto:[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.
That should do the trick as well. Actually it seems to be the cleaner
solution.
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.
Great. I've been doing something like this by modifying the
ShaderComposition (as proposed by you) and injection defines at start of
the composed shader.
It still seems to be a clutch, so I'm looking forward to your ideas. If
you want to, I'm totally happy to share my insights.
I had some request to review it some months ago, but you where into some
other stuff at this time, so it might have ended up below the radar.
(The topic was "[osg-users] ShaderComposer and some missing features")
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.
I disagree. They are still regular at the "tile" level. Currently the
matrix is pushed together with the "local" geometry, so it should stay
in the float precision range (the matrix is not changed, nor are the
local vertices). Maybe I'm overlooking something here, but I don't see
the difference pushing only the vertices for the outer-geometry as the
resulting "inner" is locally flat.
Along with the potential savings in pushing less vertices, it might even
produce some fractal noise to add artificial details (This looks really
really great)
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.
Geometry shaders are great when it comes to minimize drawing. A good
example is rendering millions of billboard trees from instanced point
geometry which is used to create a billboard for each point. I managed
to get a fair amount of trees (~500k) rendered with them, so I wonder
where the bottleneck might be in your case. I guess its all about not
"switching" and batching up similar sized arrays ;-)
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 :-)
See my email concerning the crash and errors I'm experiencing regarding
my terrains. When the issue is solved and you made the GeometryPool
accessible via inheritance I'd be more as happy contributing, as I have
some related work duties to solve in the next months. I've tried some
generic texturing based on height and slope but failed on creating
texture coordinates for the detail textures. So maybe some help might
push things forward on both sides.
Cheers
Sebastian
Robert.
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
