Re: [osg-users] Slave camera lighting with disabled main camera
OK I figured it out after digging further into SceneView. In case anyone else ever runs into this, here is what's going on and how to fix it. When a new View is created (e.g. osgViewer), it defaults to HEADLIGHT mode and internally creates the master Camera, along with a Renderer and SceneView for that camera. The SceneView initializes the master camera's StateSet with a new Light (diffuse+specular) and Light Model (ambient), enables the GL_LIGHTING mode, and internally sets itself up for HEADLIGHT mode. >From here on, all slave cameras added to the View use the master camera's >StateSet as their global stateset (via their own SceneViews). Under normal >operations, calling View::setLightingMode(NO_LIGHT) results in the master >camera's SceneView removing lighting from the global stateset during the cull >stage. Consequently, all slave cameras also have their lighting disabled >(unless explicitly enabled in their own StateSet). This is all great and works >as expected. However, in my example I was disabling the master camera by removing its graphics context. Because of this, the master camera's SceneView was never being executed during the cull stage, so the default (HEADLIGHT) lighting parameters were never removed from the master camera's stateset. Therefore all slaves were inheriting the HEADLIGHT lighting. The solution to this is pretty simple: manually remove the lighting modes from the master camera's stateset after setting NO_LIGHT. Of course this is only necessary if you plan on disabling the master camera by removing its graphics context. Code: viewer.setLightingMode(View::NO_LIGHT); StateSet* ss = viewer.getCamera()->getStateSet(); if(ss) ss->removeMode(GL_LIGHTING); ... viewer.getCamera()->setGraphicsContext(NULL); If Robert or any of the other experienced folks on here think that I'm mistaken on this, or have other more elegant solutions, please let me know. Otherwise I'll consider the matter closed. Thanks! Ravi -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=72700#72700 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Conan C++ dependency manager
mp3butcher wrote: > Hi all > I made my first step with conan and for that i made a recipe for osg3.4.0 > https://github.com/mp3butcher/osg_conan_recipe > I also upload this bintray but it require approval to be public > > I doubt to understood everything but it could be a great multiplatform tool > to aggregate the scattered osg eco system. > > Just a few look at my script gives you an idea of what can be done and > not...It doesn't solve all problems but can represent an homogenous solution > to adress lib dependencies in user space > > Feel free to give feedback and improvements via github > Cheers > > > robertosfield wrote: > > Hi All, > > > > Below is an "Issue" posted on the openscengraph github page from an > > non OSG developer touting for us to integrate the OSG with the Conan > > C++ depency manager. > > > > Personally, I'm not familiar with Conan, I have no use for itself > > myself, I guess it might be useful to some in the community. I don't > > have time to go chasing it up myself as I have way too much on my > > plate already, so I'll defer to the community as to whether it's worth > > pursuing and doing any legwork required. > > > > As it's really not an "Issue" relating to the OSG but a sales pitch it > > really isn't appropriate place to clog up out Issue list so I'll be > > closing it, but thought it be better at least tell the community about > > it before I do so. > > > > If you are interested than please look into it and report back to us > > about what steps would need to be taken add the OSG into Conan mix. > > > > Cheers, > > Robert. > > > > --- https://github.com/openscenegraph/OpenSceneGraph/issues/395 -- > > > > Hello, > > Do you know about Conan? > > Conan is modern dependency manager for C++. And will be great if your > > library will be available via package manager for other developers. > > > > Here you can find example, how you can create package for the library. > > > > If you have any questions, just ask :-) > > -- > > ___ > > osg-users mailing list > > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > -- > > Post generated by Mail2Forum > -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=72699#72699 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Conan C++ dependency manager
Hi all I made my first step with conan and for that i made a recipe for osg3.4.0 https://github.com/mp3butcher/osg_conan_recipe I also upload this bintray but it require approval to be public I doubt to understood everything but it could be a great multiplatform tool to aggregate the scattered osg eco system Feel free to give feedback and improvements via github Cheers robertosfield wrote: > Hi All, > > Below is an "Issue" posted on the openscengraph github page from an > non OSG developer touting for us to integrate the OSG with the Conan > C++ depency manager. > > Personally, I'm not familiar with Conan, I have no use for itself > myself, I guess it might be useful to some in the community. I don't > have time to go chasing it up myself as I have way too much on my > plate already, so I'll defer to the community as to whether it's worth > pursuing and doing any legwork required. > > As it's really not an "Issue" relating to the OSG but a sales pitch it > really isn't appropriate place to clog up out Issue list so I'll be > closing it, but thought it be better at least tell the community about > it before I do so. > > If you are interested than please look into it and report back to us > about what steps would need to be taken add the OSG into Conan mix. > > Cheers, > Robert. > > --- https://github.com/openscenegraph/OpenSceneGraph/issues/395 -- > > Hello, > Do you know about Conan? > Conan is modern dependency manager for C++. And will be great if your > library will be available via package manager for other developers. > > Here you can find example, how you can create package for the library. > > If you have any questions, just ask :-) > -- > ___ > osg-users mailing list > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > -- > Post generated by Mail2Forum -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=72698#72698 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgUtil::IntersectionVisitor eats all the memory
Hi Nick,
There isn't anyone else other than you can debug this one - you are
the only one with your data and with your application code, you are
the only one seeing this issue, we'd have to be omnipresent to be able
to pinpoint what is wrong.
As I said the best thing you can do is run your application and your
data within a debugger and then break it when it starts to consume
memory/spin the CPUI. You might need to break/restart a few times to
get a clear picture of where things are going amiis.
Robert.
On 9 January 2018 at 12:31, Trajce Nikolov NICK
wrote:
> Thanks Robert,
>
> no circular reference since I am displaying that database in the viewer
> nicely. Here is the struct (a bit odd but it is as is):
>
> Group
> |
> PagedLOD PagedLOD PagedLOD dozen of these
> |
> Quadtree (similar to VPB generated subtiles)
>
> I was thinking the visitor is reading all of these by reading all of these
> PagedLODs without taking the account the range from the eyepoint. So while
> debuging I tried this:
>
> struct MyIntersectionVisitor : public osgUtil::IntersectionVisitor
> {
> MyIntersectionVisitor(float range)
> : IntersectionVisitor()
> , _range(range)
> {
> }
>
> virtual void apply(osg::PagedLOD& plod)
> {
> if (getDistanceFromEyePoint(plod.getCenter(), true) < _range)
> {
> osgUtil::IntersectionVisitor::apply(plod);
> }
> }
>
> protected:
> float _range;
> };
>
> but no luck. Is there a way to flush all the pending and loaded nodes from
> the DatabasePager?
>
> On Tue, Jan 9, 2018 at 1:23 PM, Robert Osfield
> wrote:
>>
>> Hi Nick,
>>
>> This is really something you'd want to use a debug for - just run it
>> and break the app before anything untoward happens.
>>
>> The code itself looks quite benign on a first reading, the only thing
>> I can think of that might cause a memory issue would be if your scene
>> graph had a circular reference in it so the traversal ends up in an
>> infinite loop.
>>
>> Robert
>>
>> On 9 January 2018 at 12:12, Trajce Nikolov NICK
>> wrote:
>> > hi Robert, Community,
>> >
>> > I have the following code in a loop against very large quadtree based
>> > database. And this code is eating all the memory, progressively and then
>> > the
>> > system kills it . Any clue?
>> >
>> > Thanks a lot
>> >
>> > osg::ref_ptr picker;
>> > osg::ref_ptr iv;
>> >
>> > osg::Vec3d getHOT(const osg::Vec3d& position,
>> > osgViewer::CompositeViewer&
>> > viewer, osg::Vec3& normal, bool& valid)
>> > {
>> > osg::Vec3d result;
>> >
>> > osg::EllipsoidModel em;
>> > osg::Vec3d up = em.computeLocalUpVector(position.x(), position.y(),
>> > position.z());
>> > up.normalize();
>> >
>> > osg::Vec3d s = position + up * 100;
>> > osg::Vec3d e = osg::Vec3d(0, 0, 0);
>> >
>> > if (viewer.getView(0)->getSceneData())
>> > {
>> > #if 1
>> > if (!picker.valid())
>> > {
>> > picker = new osgUtil::LineSegmentIntersector(s,e);
>> > iv = new MyIntersectionVisitor(RANGE);
>> > }
>> > picker->setStart(s);
>> > picker->setEnd(e);
>> > picker->getIntersections().clear();
>> > iv->setIntersector(picker);
>> > iv->reset();
>> > iv->setUseKdTreeWhenAvailable(false);
>> >
>> > //iv->setLODSelectionMode(osgUtil::IntersectionVisitor::USE_EYE_POINT_FOR_LOD_LEVEL_SELECTION);
>> > viewer.getView(0)->getSceneData()->accept(*iv);
>> >
>> > if (picker->containsIntersections())
>> > {
>> > osgUtil::LineSegmentIntersector::Intersections hitList =
>> > picker->getIntersections();
>> > osgUtil::LineSegmentIntersector::Intersections::iterator hit =
>> > hitList.begin();
>> >
>> > result = hit->getWorldIntersectPoint();
>> > normal = hit->getWorldIntersectNormal();
>> > valid = true;
>> >
>> > return result;
>> > }
>> > #endif
>> > }
>> > valid = false;
>> >
>> > return result;
>> > }
>> >
>> > --
>> > trajce nikolov nick
>> >
>> > ___
>> > 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
>
>
>
>
> --
> trajce nikolov nick
>
> ___
> 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
Re: [osg-users] Lets slowly update extension gl symbols to latest OpenGL specification with each submission.
Hi Maxim, We just add #define as required rather than attempting to import all features. As new GL features are added we may find temporarily a #define is missed, when this occurs we add it as soon as we know about it. Not all GL headers are up to date so we generally have to backport those missing features, WIndows gl.h is particular problem as it's been deliberately held back my Microsoft. Could you let us know which version of the OSG and what platform you've seen this issue for? Robert. On 9 January 2018 at 19:05, Maxim Stere wrote: > Hi, > > Has this been resolved, or are there any news on keeping GL extensions > updated? > > I just ran into a problem where > > Code: > > #define GL_READ_ONLY 0x88B8 > > > > was missing from GL_VERSION_1_5 section. If GLEW was > included it of course worked. > > So having extensions updated to 4.6 would be very useful... > > ... > > Thank you! > > Cheers, > Maxim > > > Thank you, > --Maxim > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=72694#72694 > > > > > > ___ > 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
Re: [osg-users] Lets slowly update extension gl symbols to latest OpenGL specification with each submission.
Hi, Has this been resolved, or are there any news on keeping GL extensions updated? I just ran into a problem where Code: #define GL_READ_ONLY 0x88B8 was missing from GL_VERSION_1_5 section. If GLEW was included it of course worked. So having extensions updated to 4.6 would be very useful... ... Thank you! Cheers, Maxim Thank you, --Maxim -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=72694#72694 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Scaling visitor not working as expected
I just checked a recent osg::Drawable header file and it seems
dirtyDisplayList() is deprecated
and has been replaced with dirtyGLObjects(). Relevant snippet follows:
#ifdef OSG_USE_DEPRECATED_API
/** Deprecated, use dirtyGLObjects() instead. */
inline void dirtyDisplayList()
{
dirtyGLObjects();
}
#endif
/** Force a recompile on next draw() of any OpenGL objects associated with
this geoset.*/
virtual void dirtyGLObjects();
2018-01-09 17:57 GMT+01:00 Christian Buchner :
>
> Are display lists active in your scene? if so, maybe a dirtyDisplayList()
> call might be required
> on the affected drawables.
>
> drawable->dirtyDisplayList()
>
> As far as I know display lists are still the default in OSG, unless you
> explicitly disable them on
> geometry objects (and possibly enable vertex buffer objects instead, for
> performance reasons)
>
> the corresponding API calls on drawables would be
>
> drawable->setUseDisplayList( false )
> drawable->setUseVertexBufferObjects( true )
>
> you could use a visitor right after loading the scene to switch off
> display lists and enabling
> vertex buffer objects instead.
>
> Christian
>
>
> 2018-01-09 14:58 GMT+01:00 Werner Modenbach :
>
>> Hi all,
>>
>> I'm loading 3ds scenes as subnodes into my scene. The 3ds coordinates are
>> in a different scale than my scene.
>> Usually I would solve this by a transform. But because of internal
>> reasons I need the vertices being
>> in MY coordinate measure.
>> So I wrote a scaling visitor, that multiplies al vertices of geometries
>> by a given factor.
>> That works perfectly fine when loading the 3ds scene:
>> *osg::ref_ptr* *node* *=* *osgDB*
>> *::readRefNodeFile(**path**); *
>> *ScaleVisitor* *sv(**initialObjectScale* ***
>> *correctiveObjectScale**); *
>> *node->**accept**(sv); *
>> *addChild**(node); *
>>
>> Unfortunately when rescaling the object after being added as a child this
>> doesn't work any more:
>> *osg::ref_ptr node* *=* *getChild(0);*
>> *ScaleVisitor* *sv(scaleChange);*
>> *node->accept(sv);*
>>
>> The 3ds scene doesn't change size on my screen.
>> The visitor calls:
>> vertices->dirty();
>> geom.dirtyBound();
>>
>> But nothing happens. What am I missing? Deleting the 3ds scene and
>> recreating it from scratch works OK but is very inefficient.
>>
>> Thanks for any hint.
>>
>> - Werner -
>>
>> ___
>> 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
Re: [osg-users] Scaling visitor not working as expected
Are display lists active in your scene? if so, maybe a dirtyDisplayList() call might be required on the affected drawables. drawable->dirtyDisplayList() As far as I know display lists are still the default in OSG, unless you explicitly disable them on geometry objects (and possibly enable vertex buffer objects instead, for performance reasons) the corresponding API calls on drawables would be drawable->setUseDisplayList( false ) drawable->setUseVertexBufferObjects( true ) you could use a visitor right after loading the scene to switch off display lists and enabling vertex buffer objects instead. Christian 2018-01-09 14:58 GMT+01:00 Werner Modenbach : > Hi all, > > I'm loading 3ds scenes as subnodes into my scene. The 3ds coordinates are > in a different scale than my scene. > Usually I would solve this by a transform. But because of internal reasons > I need the vertices being > in MY coordinate measure. > So I wrote a scaling visitor, that multiplies al vertices of geometries by > a given factor. > That works perfectly fine when loading the 3ds scene: > *osg::ref_ptr* *node* *=* *osgDB**::readRefNodeFile(* > *path**); * > *ScaleVisitor* *sv(**initialObjectScale* *** > *correctiveObjectScale**); * > *node->**accept**(sv); * > *addChild**(node); * > > Unfortunately when rescaling the object after being added as a child this > doesn't work any more: > *osg::ref_ptr node* *=* *getChild(0);* > *ScaleVisitor* *sv(scaleChange);* > *node->accept(sv);* > > The 3ds scene doesn't change size on my screen. > The visitor calls: > vertices->dirty(); > geom.dirtyBound(); > > But nothing happens. What am I missing? Deleting the 3ds scene and > recreating it from scratch works OK but is very inefficient. > > Thanks for any hint. > > - Werner - > > ___ > 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] Scaling visitor not working as expected
Hi all, I'm loading 3ds scenes as subnodes into my scene. The 3ds coordinates are in a different scale than my scene. Usually I would solve this by a transform. But because of internal reasons I need the vertices being in MY coordinate measure. So I wrote a scaling visitor, that multiplies al vertices of geometries by a given factor. That works perfectly fine when loading the 3ds scene: / osg::ref_ptrnode=osgDB//::readRefNodeFile(//path//); // ScaleVisitorsv(//initialObjectScale*correctiveObjectScale//); // // //node->//accept//(sv); // // //addChild//(node); // / Unfortunately when rescaling the object after being added as a child this doesn't work any more: / osg::ref_ptr node=getChild(0); // ScaleVisitorsv(scaleChange);// //node->accept(sv);/ The 3ds scene doesn't change size on my screen. The visitor calls: vertices->dirty(); geom.dirtyBound(); But nothing happens. What am I missing? Deleting the 3ds scene and recreating it from scratch works OK but is very inefficient. Thanks for any hint. - Werner - ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgUtil::IntersectionVisitor eats all the memory
Thanks Robert,
no circular reference since I am displaying that database in the viewer
nicely. Here is the struct (a bit odd but it is as is):
Group
|
PagedLOD PagedLOD PagedLOD dozen of these
|
Quadtree (similar to VPB generated subtiles)
I was thinking the visitor is reading all of these by reading all of these
PagedLODs without taking the account the range from the eyepoint. So while
debuging I tried this:
struct MyIntersectionVisitor : public osgUtil::IntersectionVisitor
{
MyIntersectionVisitor(float range)
: IntersectionVisitor()
, _range(range)
{
}
virtual void apply(osg::PagedLOD& plod)
{
if (getDistanceFromEyePoint(plod.getCenter(), true) < _range)
{
osgUtil::IntersectionVisitor::apply(plod);
}
}
protected:
float _range;
};
but no luck. Is there a way to flush all the pending and loaded nodes from
the DatabasePager?
On Tue, Jan 9, 2018 at 1:23 PM, Robert Osfield
wrote:
> Hi Nick,
>
> This is really something you'd want to use a debug for - just run it
> and break the app before anything untoward happens.
>
> The code itself looks quite benign on a first reading, the only thing
> I can think of that might cause a memory issue would be if your scene
> graph had a circular reference in it so the traversal ends up in an
> infinite loop.
>
> Robert
>
> On 9 January 2018 at 12:12, Trajce Nikolov NICK
> wrote:
> > hi Robert, Community,
> >
> > I have the following code in a loop against very large quadtree based
> > database. And this code is eating all the memory, progressively and then
> the
> > system kills it . Any clue?
> >
> > Thanks a lot
> >
> > osg::ref_ptr picker;
> > osg::ref_ptr iv;
> >
> > osg::Vec3d getHOT(const osg::Vec3d& position, osgViewer::CompositeViewer&
> > viewer, osg::Vec3& normal, bool& valid)
> > {
> > osg::Vec3d result;
> >
> > osg::EllipsoidModel em;
> > osg::Vec3d up = em.computeLocalUpVector(position.x(), position.y(),
> > position.z());
> > up.normalize();
> >
> > osg::Vec3d s = position + up * 100;
> > osg::Vec3d e = osg::Vec3d(0, 0, 0);
> >
> > if (viewer.getView(0)->getSceneData())
> > {
> > #if 1
> > if (!picker.valid())
> > {
> > picker = new osgUtil::LineSegmentIntersector(s,e);
> > iv = new MyIntersectionVisitor(RANGE);
> > }
> > picker->setStart(s);
> > picker->setEnd(e);
> > picker->getIntersections().clear();
> > iv->setIntersector(picker);
> > iv->reset();
> > iv->setUseKdTreeWhenAvailable(false);
> > //iv->setLODSelectionMode(osgUtil::IntersectionVisitor::
> USE_EYE_POINT_FOR_LOD_LEVEL_SELECTION);
> > viewer.getView(0)->getSceneData()->accept(*iv);
> >
> > if (picker->containsIntersections())
> > {
> > osgUtil::LineSegmentIntersector::Intersections hitList =
> > picker->getIntersections();
> > osgUtil::LineSegmentIntersector::Intersections::iterator hit =
> > hitList.begin();
> >
> > result = hit->getWorldIntersectPoint();
> > normal = hit->getWorldIntersectNormal();
> > valid = true;
> >
> > return result;
> > }
> > #endif
> > }
> > valid = false;
> >
> > return result;
> > }
> >
> > --
> > trajce nikolov nick
> >
> > ___
> > 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
>
--
trajce nikolov nick
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgUtil::IntersectionVisitor eats all the memory
Hi Nick,
This is really something you'd want to use a debug for - just run it
and break the app before anything untoward happens.
The code itself looks quite benign on a first reading, the only thing
I can think of that might cause a memory issue would be if your scene
graph had a circular reference in it so the traversal ends up in an
infinite loop.
Robert
On 9 January 2018 at 12:12, Trajce Nikolov NICK
wrote:
> hi Robert, Community,
>
> I have the following code in a loop against very large quadtree based
> database. And this code is eating all the memory, progressively and then the
> system kills it . Any clue?
>
> Thanks a lot
>
> osg::ref_ptr picker;
> osg::ref_ptr iv;
>
> osg::Vec3d getHOT(const osg::Vec3d& position, osgViewer::CompositeViewer&
> viewer, osg::Vec3& normal, bool& valid)
> {
> osg::Vec3d result;
>
> osg::EllipsoidModel em;
> osg::Vec3d up = em.computeLocalUpVector(position.x(), position.y(),
> position.z());
> up.normalize();
>
> osg::Vec3d s = position + up * 100;
> osg::Vec3d e = osg::Vec3d(0, 0, 0);
>
> if (viewer.getView(0)->getSceneData())
> {
> #if 1
> if (!picker.valid())
> {
> picker = new osgUtil::LineSegmentIntersector(s,e);
> iv = new MyIntersectionVisitor(RANGE);
> }
> picker->setStart(s);
> picker->setEnd(e);
> picker->getIntersections().clear();
> iv->setIntersector(picker);
> iv->reset();
> iv->setUseKdTreeWhenAvailable(false);
> //iv->setLODSelectionMode(osgUtil::IntersectionVisitor::USE_EYE_POINT_FOR_LOD_LEVEL_SELECTION);
> viewer.getView(0)->getSceneData()->accept(*iv);
>
> if (picker->containsIntersections())
> {
> osgUtil::LineSegmentIntersector::Intersections hitList =
> picker->getIntersections();
> osgUtil::LineSegmentIntersector::Intersections::iterator hit =
> hitList.begin();
>
> result = hit->getWorldIntersectPoint();
> normal = hit->getWorldIntersectNormal();
> valid = true;
>
> return result;
> }
> #endif
> }
> valid = false;
>
> return result;
> }
>
> --
> trajce nikolov nick
>
> ___
> 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] osgUtil::IntersectionVisitor eats all the memory
hi Robert, Community,
I have the following code in a loop against very large quadtree based
database. And this code is eating all the memory, progressively and then
the system kills it . Any clue?
Thanks a lot
osg::ref_ptr picker;
osg::ref_ptr iv;
osg::Vec3d getHOT(const osg::Vec3d& position, osgViewer::CompositeViewer&
viewer, osg::Vec3& normal, bool& valid)
{
osg::Vec3d result;
osg::EllipsoidModel em;
osg::Vec3d up = em.computeLocalUpVector(position.x(), position.y(),
position.z());
up.normalize();
osg::Vec3d s = position + up * 100;
osg::Vec3d e = osg::Vec3d(0, 0, 0);
if (viewer.getView(0)->getSceneData())
{
#if 1
if (!picker.valid())
{
picker = new osgUtil::LineSegmentIntersector(s,e);
iv = new MyIntersectionVisitor(RANGE);
}
picker->setStart(s);
picker->setEnd(e);
picker->getIntersections().clear();
iv->setIntersector(picker);
iv->reset();
iv->setUseKdTreeWhenAvailable(false);
//iv->setLODSelectionMode(osgUtil::IntersectionVisitor::USE_EYE_POINT_FOR_LOD_LEVEL_SELECTION);
viewer.getView(0)->getSceneData()->accept(*iv);
if (picker->containsIntersections())
{
osgUtil::LineSegmentIntersector::Intersections hitList =
picker->getIntersections();
osgUtil::LineSegmentIntersector::Intersections::iterator hit =
hitList.begin();
result = hit->getWorldIntersectPoint();
normal = hit->getWorldIntersectNormal();
valid = true;
return result;
}
#endif
}
valid = false;
return result;
}
--
trajce nikolov nick
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Free camera manipulator
"Kazim Kamilov" writes: > Hi, OSG community! > > In OSG is not have free camera manipulator. Need to fix it! > Robert, can you add this in the osgGA? > Sources in attachment. > > Thank you! > Dear Kazim, by just attaching your files in a post in the general channel you risk that your submission goes unnoticed. Please submit a "pull request" from github, which is one of the official ways. Thanks! -- Alberto ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] Building OpenSceneGraph Windows
Hi. Here's a step-by-step guide to get you started with OSG & MinGW: https://github.com/OGStudio/openscenegraph-cross-platform-guide/tree/master/1.3.InstallUnderWindows On 8 January 2018 at 12:43, Christian Schulte wrote: > Hi Stephan, > > in my honest opinion it looks more like a compiler configuration issue than > an OSG problem. Try to check the environment variables PATH (in a command > window "echo %PATH%") and look for the path to your mingw/bin. As far as I > know the mingw_get does not configure the environment variables of the > Windows system. CMake is, during configuration, testing if the compiler > works correctly before configuring OSG itself. > > Regards, > > Christian > > > Le 24/12/2017 05:13, Stefan Waldegger a écrit : >> >> Hi, >> >> this is my first post here and I have already searched in this Forum and >> on google but I did not get the answer which is handling my problem. >> >> So I have read a lot about OSG in the internet and no I want to give it a >> try. >> I have downloaded OSG 3.4.1 from the official homepage. >> >> Then I unzipped it and put it to a convinient place and had a look into >> it. I found the sourcecode and some makefiles in the folder. >> >> >From my experiences using Ubuntu and other Unix distibutions I know how >> easy this normally is, just call make and a big batch is being executed and >> voila, all the .so and .a files are here and everybody is happy. >> >> But now I am on windows. Windows 10 to be honest. >> >> I am using Code::Blocks as IDE and MinGW compiler. Downloaded with >> MinGW_get. So it is not that comes with Code::Blocks. >> >> Also I downloaded CMake for windows with the Gui. >> Then I started the CMake gui and on the first glance it all looked very >> easy. >> >> I entered the path of OSG as source and the same path as destnation, >> clicked on configure, chose MinGW as compiler, clicked ok. >> >> Aaaand then. Like 20 messageboxes are popping up in seria telling me that >> dll files are missing libisl-15.dll, libmingwex-0.dll, libiconv-2.dll, >> libgmp-10.dll, and much more. And naturally CMake finishes wihtout >> having done anything in the end. >> >> It is this messagebox wich comes when you want to try to sart a program >> the the dll is missing. But the funny thing is, when I look in the MinGW\bin >> folder, all the dlls are there. It is also the first time I am using CMake >> in windows, so I dont have any experience here. >> >> Do you know this issue, is there a solution? >> >> Thank you all for your support in advance. >> >> Merry Christmas >> >> Cheers, >> Stefan >> >> -- >> Read this topic online here: >> http://forum.openscenegraph.org/viewtopic.php?p=72635#72635 >> >> >> >> >> >> ___ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> > > > -- > SCHULTE Christian > Ingénieur Recherche > Responsable du Laboratoire de Simulation > ONERA - DTIS/PSEV > Département Traitement de l'information et systèmes > ONERA - Centre de Salon de Provence > BA 701 > 13661 SALON AIR Cedex - France > Tel :04.90.17.01.45 > > ___ > 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
