Hi Sebastian, On 19 January 2015 at 21:09, Sebastian Messerschmidt < [email protected]> wrote:
> That should do the trick as well. Actually it seems to be the cleaner > solution. > I'll check this in today. 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") > Once we've got crash sorted, it'd be a good time to dive into this topic. I'll have a search later. > 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. > When doing a Geocentric database the base tiles are all fitted to the curvature of the earth and the shape of the mapping of a regular grid to the sphere, they very much aren't flat or regular anywhere, one has to compute the position of each vertex on the base grid in ECEF coords in doubles then take away the local tile transform to get local coordinates in floats. The GeometryPool creates a single osg::Geometry for each LOD level and latitude, this way the scheme can share geometry as much as possible. For a non Geocentric database you could share osg::Geometry for all same dimensioned tiles and compute vertices on the GPU without problem. > 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 should be possible to add such effects to the present scheme.. > 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 ;-) > Switching doesn't seem to be a big cost - the new GeometryPoll/DisplacementMapping approach is significantly faster than the old GeometryTechnique scheme, but when you enable geometry shaders it's slower :-| Not sure why it's quite as slow as it is since the geometry shader is very similar, reading up on geometry shaders it's a known issue with their speed not being great. When pushing a lot of geometry - well over a million vertices the geometry shader is clear bottleneck for the tests I've done. I'm still comfortably getting a solid 60hz, but the GPU draw times was 7+ms vs 2.6ms between geometry shader and non geometry shader paths. > > 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. > I looked at this thread and spotted the test file but didn't spot instructions on what app to test with, when the crash occurs, what platform etc. Robert.
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
