Thanks for those inputs Sergey, but actually I tried to follow the way
described in another OSG post: to create a custom CullVisitor and override
the getDistanceFromViewPoint() method:
And this seems to work great !!
Just in case someone would need some hints on this:
1. To override the CullVisitor, I do soemthing like:
camera->getRenderer()->getSceneView(id)->setCullVisitor(new
MyOwnCullVisitor) (do this for id=0 and 1)
2. In my own cull visitor I then have something like:
virtual float getDistanceToViewPoint(const osg::Vec3& pos, bool
withLODScale) const
{
if(_lastTraversalNumber!=_traversalNumber) {
// Retrieve the beamTarget position X and use it as -Z position
in the view frame:
osg::PositionAttitudeTransform* beamTarget =
_data->getRef<osg::PositionAttitudeTransform>("beamTarget");
CHECK_POINTER(beamTarget,"Invalid beamTarget PAT in callback.");
double offset = beamTarget->getPosition().x();
referencePoint = osg::Vec3(0.0,0.0,-offset);
_lastTraversalNumber = _traversalNumber;
}
osg::Matrixd mat;
if(!_modelviewStack.empty()) {
const osg::RefMatrix* mview = _modelviewStack.back().get();
mat.invert(*mview);
}
osg::Vec3f localViewPoint = referencePoint*mat;
//wxLogMessage("I'm in my special getDistanceToViewPoint!");
if (withLODScale) return
(pos-localViewPoint).length()*getLODScale();
else return (pos-localViewPoint).length();
}
And with this I get the expected results without significant performance
lost.
So all good for me.
Cheers,
Manu.
2011/8/10 Sergey Polischuk <pol...@yandex.ru>
> Hi,
>
> osg::LOD have option to use object's size on screen (in pixels?) instead of
> distance to camera to determine which lod to use, you can try these setting.
>
> Cheers,
> Sergey.
> 10.08.2011, 16:03, "Emmanuel Roche" <roche.emman...@gmail.com>:
>
> Hi everyone,
>
> I've have a specific question for which I could use some help/advises:
>
> - I'm quite up-to-date with OSG 3.0.0 and osgEarth current git version
> - I'm build an app where I use the osgEarth library to display the earth
> model.
> - When I setup a camera on that model, I use a camera with a very very
> small field of view (about 0.5 degrees in both horizontal and vertical
> directions), and my camera is actually far away from the earth model I'm
> looking at.
>
> - as a result of this, only low resolution tiles are loaded (because the
> camera distance to the tiles is used to diced what to load or not).
>
> - What I want to do is : to get high resolution tiles displayed around the
> ground location the camera is pointing at even if it is "physically" far
> away. then, because (or thanks to?) the small field of view, I would still
> see the local details on the high res tile textures.
>
> So, any advise how to achieve this ?
>
> - so far I have tried the following:
> 1. Setup this famous camera just as described before,
> 2. Add a slave camera, using the earth as child too, but this time,
> positioned very close to the first camera target point on earth (and looking
> "down" that point from the local zenith).
>
> Both cameras share the same databasepager (I think) and high res tiles are
> indeed properly loaded because of the second camera cull traversal. The
> problem is: I was expecting the loaded tiles to be "shared" by both cameras,
> yet that is not the case: I still only get the low res tiles displayed by
> the "far away camera". Is there a way to "share the tiles" as I was
> expecting ?
>
>
> - The other main idea I have then would be to find a way to "trick" the
> cull traversal of the far away camera so that, when traversing pagedLODs the
> reported distance to the tile would be as if the camera was actually much
> closer to its target point on the ground. Would that be a good idea ? Any
> hint on how to proceed then ??
>
>
> - of course, option 3 would be to actually move the camera to that close
> location and change the field of view to a bigger value to try to
> approximate the previous small field of view coverage. But the point is,
> this camera is meant for a simulator system, and the generated view should
> not "approximate the actual view", it should really be the same, so
> computing a new field of view would actually be impossible (or too complex
> to be worth at least).
>
>
> cheers,
> Manu.
>
> _______________________________________________
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
> _______________________________________________
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
