Hi,
you could also try setting the LODscale:
view->getCamera()->setLODScale(scale);
I'm doing this when creating an ortho camera for osgEarth scenes and
placing the camera far from the earth.
jp
On 10/08/2011 16:14, Emmanuel Roche wrote:
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 <mailto: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
<mailto: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
<mailto:osg-users@lists.openscenegraph.org>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
<mailto: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
--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean.
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
