Re: [osg-users] [ANN] View-dependent progressive meshes on OpenSceneGraph
Good job! No, I usually use vs2013 to compile. Jim webmaster wrote: > Hi Jim, Now i compiled and tested all the vdpm for osg projects successfully > with vs2010 and vs2013 in debug and release mode,and made some fixed and > improvement of your cmake files,and find the compiler you always using to > compile this pack is visual studio 2012? > Good work! > zhuwan > 08,06,2015 > > > > -原始邮件- > > > > > 发件人: "Jim Tan" <> > > > 发送时间: 2015-8-3 17:52:37 > > > 收件人: > > > 抄送: > > > 主题: Re: [ANN] View-dependent progressive meshes on OpenSceneGraph > > > > > > Sorry, lost one file CMakeLists.txt on the root directory. > > > Please update and try again. > > > > > > Jim > > > > > > > > > > > > webmaster wrote: > > > > > > > Hi Jim, Infact i used to try this method,because i already found the > > > > E:/vdpm-master20150728/project/* can be used > > > > for refrence,and also tried the name > > > > E:/vdpm-master20150728/build/vdpmslim and > > > > > > > > > > > > > E:/vdpm-master20150728/build/test etc,before get your hints,but still > > > > > get the same errors,and even open some cmakelist.txt to check the > > > > > things related. and even tried in several computers,the error is > > > > > still. --- CMake > > > > > Error: The source directory "E:/vdpm-master20150728" does not appear > > > > > to contain CMakeLists.txt. > > > > > > > > > Specify --help for usage, or press the help button on the CMake GUI. > > > > > > > > > --- very > > > > > confused. thanks zhuwan 08,03,2015some cmakelist.txt to check the > > > > > things related. > > > > > > > > > 0 > > > > > > > > -- > > > > Post generated by Mail2Forum > > > > > > > > > > > > > -- > > > Read this topic online here: > > > http://forum.openscenegraph.org/viewtopic.php?p=64576#64576 > > > > > > > > > > > > > > > > > > ___ > > > 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=64646#64646 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [ANN] View-dependent progressive meshes on OpenSceneGraph
Hi Jim, Now i compiled and tested all the vdpm for osg projects successfully with vs2010 and vs2013 in debug and release mode,and made some fixed and improvement of your cmake files,and find the compiler you always using to compile this pack is visual studio 2012? Good work! zhuwan 08,06,2015 > -原始邮件- > 发件人: "Jim Tan" > 发送时间: 2015-8-3 17:52:37 > 收件人: osg-users@lists.openscenegraph.org > 抄送: > 主题: Re: [osg-users] [ANN] View-dependent progressive meshes on OpenSceneGraph > > Sorry, lost one file CMakeLists.txt on the root directory. > Please update and try again. > > Jim > > > > webmaster wrote: > > Hi Jim, Infact i used to try this method,because i already found the > > E:/vdpm-master20150728/project/* can be used > > for refrence,and also tried the name E:/vdpm-master20150728/build/vdpmslim > > and > > > > > E:/vdpm-master20150728/build/test etc,before get your hints,but still get > > > the same errors,and even open some cmakelist.txt to check the things > > > related. and even tried in several computers,the error is still. > > > --- CMake Error: The > > > source directory "E:/vdpm-master20150728" does not appear to contain > > > CMakeLists.txt. > > Specify --help for usage, or press the help button on the CMake GUI. > > > --- very confused. > > > thanks zhuwan 08,03,2015some cmakelist.txt to check the things related. > > 0 > > > > -- > > Post generated by Mail2Forum > > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=64576#64576 > > > > > > ___ > 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] OpenSceneGraph-3.4.0-rc9 tagged
Works fine until now on Visual Studio 2013 + Qt 5.4.2 + Windows 10 Thank you! Cheers, Mohammed -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=64643#64643 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Segfault occuring in -- void Text::drawImplementation(osg::State& state, const osg::Vec4& colorMultiplier) const -- after updating from osg 3.3.1 to the current trunk
Robert, Just tested the trunk from a svn co from about 1 hour ago, with my test osgviewerQT.cpp source. Still getting a segv when running it. I was running in release mode for this test so cannot verify if its exactly the same fault or notbut it would seem that there is still some sort of issue with this. I will rebuild in debug mode as soon as I have some more free time and check to see if its the same bug or something different as I saw before. ... Thank you! Cheers, Curtis -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=64642#64642 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] update slave camera with frame scheme ON_DEMAND
OK Robert, no problem, I thought there could be a way to improve the existing OSG code so that other users would not struggle like me because slave cameras are updated before the master camera. From my point of view the default behavior should comply with the common concept that the master gives the rules, then slaves depend on the master. So slave cameras may depend on the master camera and not vice versa. On this bases the master camera should be updated first, then the slaves. I also had in mind another scenario (think of a rearview mirror of a car) in which, in addition to my scenario, the slave camera shares the scene with the master camera. I would say the slave camera depends on the master camera and I expect the master is updated first so that the slave can use correct master camera values. Anyway, thank you for your time and answers. Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=64641#64641 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Volume image crash on the latest version of Nvidia driver
Hi Clement, I have tried Julian's suggested approach of assign the num_iterations to an int and it works, simplify his original suggestion I get: Original shader line that results in hang: float num_iterations = ceil(length((te-t0).xyz)/SampleDensityValue); Revised shader line that works fine: int num_iterations = ceil(length((te-t0).xyz)/SampleDensityValue); Now, these both should result in the same value, as ceil rounds to an integer value, abeit within the scope of floating point math. Curiously the modern MultiPassTechnique shaders work fine too and they use an int. Originally I didn't use an int for the num_iterations as early GLSL implementations didn't fully support int's. I think the best solution would be to modify the shaders to all use int's for the num_iterations as a general coding approach using int's is sound. It shouldn't however be need a float should work in this context just as well as a int. What I suspect is that at certain values there is some kind of numerical bug on the GPU or perhaps driver that is resulting in an invalid float point value. Casting from float to int seems to nip this error in the bud so it doesn't propagate. It's end of day here so I'll have to make the changes and test them tomorrow and will update OpenSceneGraph-Data and OSG-3.2, OSG-3.4 an OSG-svn/trunk branches. Robert. Robert. On 5 August 2015 at 17:46, Robert Osfield wrote: > Hi Clement, > > > On 5 August 2015 at 17:06, wrote: > >> Thanks for your help to test the problem. Please find the attachment >> of my test data. I tested with my laptop (Nvidia NVS 5200M with driver >> 353.62) and used osg 3.2.1 x64 windows version. The command is: >> >> osgviewer t1.osg >> > > Thanks for the model. > > I've run it on my Kubuntu system with Geforce GTX 760 + 346.59 drives and > get a hang on my system when I rotate the view. This happens with OSG > svn/trunk (equivalent to OSG-3.4). When I run osgvolume t1.dds I get the > hang as well. Given the nature of the hang and how it locks out the whole > desktop it all points to GPU/driver issue of some kind. > > If I run: > > osgvolume t1.dds --multi-pass > > I don't get any hang. The osgVolume::MultiPassTechnique is only part of > OSG-3.4 so you won't have this option when using OSG3.2.1. By default > osgvolume still defaults to the old RayTracedTechnique that you'll be > familiar with, so I would suspect an issue with how the GPU is managing the > RayTracedTechnique GLSL shaders. > > > The thread that Julian Valentin linked discusses potentially the same > issue, although the GLSL code Julian suggesting could be changed looks > valid and the fix a workaround to otherwise valid code. I will do a review > of the shaders to see I can spot a problem. > > Robert. > > > > > > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Segfault occuring in -- void Text::drawImplementation(osg::State& state, const osg::Vec4& colorMultiplier) const -- after updating from osg 3.3.1 to the current trunk
Hi Robert, I noticed some references to this reported issue in the latest Changelog for the trunk checking for the proper setup of the number of contexts in the osgText area. Do you think this entire issue is now resolved or is the possible issue with QtOSG and it not reporting the number of proper contexts possibly still present? ... Thank you! Cheers, Curtis -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=64637#64637 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Segfault occuring in -- void Text::drawImplementation(osg::State& state, const osg::Vec4& colorMultiplier) const -- after updating from osg 3.3.1 to the current trunk
HI Curtis, On 5 August 2015 at 17:42, Curtis Rubel wrote: > I noticed some references to this reported issue in the latest Changelog > for the trunk > checking for the proper setup of the number of contexts in the osgText > area. > > Do you think this entire issue is now resolved or is the possible issue > with > QtOSG and it not reporting the number of proper contexts possibly still > present? > Possibly, but I haven't tested the Qt combination. It would certainly be worth updating to OSG svn/trunk, OSG-3.4 branch or the OSG-3.4.0-rc9. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Volume image crash on the latest version of Nvidia driver
Hi Clement, On 5 August 2015 at 17:06, wrote: > Thanks for your help to test the problem. Please find the attachment of > my test data. I tested with my laptop (Nvidia NVS 5200M with driver > 353.62) and used osg 3.2.1 x64 windows version. The command is: > > osgviewer t1.osg > Thanks for the model. I've run it on my Kubuntu system with Geforce GTX 760 + 346.59 drives and get a hang on my system when I rotate the view. This happens with OSG svn/trunk (equivalent to OSG-3.4). When I run osgvolume t1.dds I get the hang as well. Given the nature of the hang and how it locks out the whole desktop it all points to GPU/driver issue of some kind. If I run: osgvolume t1.dds --multi-pass I don't get any hang. The osgVolume::MultiPassTechnique is only part of OSG-3.4 so you won't have this option when using OSG3.2.1. By default osgvolume still defaults to the old RayTracedTechnique that you'll be familiar with, so I would suspect an issue with how the GPU is managing the RayTracedTechnique GLSL shaders. The thread that Julian Valentin linked discusses potentially the same issue, although the GLSL code Julian suggesting could be changed looks valid and the fix a workaround to otherwise valid code. I will do a review of the shaders to see I can spot a problem. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] update slave camera with frame scheme ON_DEMAND
HI Gianni,
There is no need to modify the OSG code, all you need to do is move the
update of your transform to after the call to updateTraversals(). You
could do this lots of different ways - all under your application control.
Personally I'd do it by expanding the call to viewer->frame() to it's
component parts as I suggested earlier. Alternatively you could subclass
from the Viewer/CompositeViewer and override the updateTraversal() method -
it's a virtual method to allow you to customize things.
Robert.
On 5 August 2015 at 16:58, Gianni Ambrosio wrote:
> Hi Robert, I didn't understand your answer.
>
> I use OSG 3.0.1 but I tried with 3.4.0.-rc8 and the behavior is the same.
> Moreover updateTraversal() of CompositeViewer is basically the same for
> these versions.
> Anyway we are probably talking of a slightly different scenario: I have a
> slave camera which update callback needs an up to date viewer master
> camera's view matrix. In this case, as you told me, since the master camera
> matrix is updated (with the inverse matrix of the manipulator) after the
> slave camera update callback, then the value is that of the previous frame.
> I can understand and the reason is in CompositeViewer::updateTraversal()
> because the for loop "// Do UpdateTraversal for slaves with their own
> subgraph" is done before
> "view->getCameraManipulator()->updateCamera(*(view->getCamera()));".
> So, to make scenarios like mine working, my suggestion is to move:
>
>
> Code:
>
> // Do UpdateTraversal for slaves with their own subgraph
> for(unsigned int i=0; igetNumSlaves(); ++i)
> {
> osg::View::Slave& slave = view->getSlave(i);
> osg::Camera* camera = slave._camera.get();
> if(camera && !slave._useMastersSceneData)
> {
> camera->accept(*_updateVisitor);
> }
> }
>
>
>
>
> after
>
>
> Code:
>
> if (view->getCameraManipulator())
> {
> view->setFusionDistance(
> view->getCameraManipulator()->getFusionDistanceMode(),
>
> view->getCameraManipulator()->getFusionDistanceValue() );
>
>
> view->getCameraManipulator()->updateCamera(*(view->getCamera()));
>
> }
>
>
>
>
> I tried this solution and it works fine.
> With this modification the scene remains updated before the main camera,
> so nothing you already told me should be broken.
> Moreover the for loop to move down is related to slave cameras with thier
> own subgraph.
>
> Regards,
> Gianni[/code]
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=64634#64634
>
>
>
>
>
> ___
> 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] update slave camera with frame scheme ON_DEMAND
Hi Robert, I didn't understand your answer.
I use OSG 3.0.1 but I tried with 3.4.0.-rc8 and the behavior is the same.
Moreover updateTraversal() of CompositeViewer is basically the same for these
versions.
Anyway we are probably talking of a slightly different scenario: I have a slave
camera which update callback needs an up to date viewer master camera's view
matrix. In this case, as you told me, since the master camera matrix is updated
(with the inverse matrix of the manipulator) after the slave camera update
callback, then the value is that of the previous frame. I can understand and
the reason is in CompositeViewer::updateTraversal() because the for loop "// Do
UpdateTraversal for slaves with their own subgraph" is done before
"view->getCameraManipulator()->updateCamera(*(view->getCamera()));".
So, to make scenarios like mine working, my suggestion is to move:
Code:
// Do UpdateTraversal for slaves with their own subgraph
for(unsigned int i=0; igetNumSlaves(); ++i)
{
osg::View::Slave& slave = view->getSlave(i);
osg::Camera* camera = slave._camera.get();
if(camera && !slave._useMastersSceneData)
{
camera->accept(*_updateVisitor);
}
}
after
Code:
if (view->getCameraManipulator())
{
view->setFusionDistance(
view->getCameraManipulator()->getFusionDistanceMode(),
view->getCameraManipulator()->getFusionDistanceValue() );
view->getCameraManipulator()->updateCamera(*(view->getCamera()));
}
I tried this solution and it works fine.
With this modification the scene remains updated before the main camera, so
nothing you already told me should be broken.
Moreover the for loop to move down is related to slave cameras with thier own
subgraph.
Regards,
Gianni[/code]
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=64634#64634
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] update slave camera with frame scheme ON_DEMAND
Hi Gianni,
I'm looking at OSG-3.4 and the setting of the master Camera from the
CameraManipulator that happens after running the update traversals of the
scene and slave Camera's, so I presume you are looking at an older rev of
the OSG.
This doesn't change my suggestion though.
Robert.
On 5 August 2015 at 15:25, Gianni Ambrosio wrote:
> Thank you Robert for the explanation.
>
> Please don't blame me if I have a couple of questions.
>
> First of all, debugging the updateTraversal() implementation it seems the
> AxesCameraUpdateCallback is called twice: one in
>
> scene->updateSceneGraph(*_updateVisitor);
>
> and the second time in
>
> camera->accept(*_updateVisitor);
>
> I guess this is an expected behavior.
>
> Second, you say "The master Camera's value can depend upon values in the
> scene graph". But isn't the scene updated in updateSceneGraph call? While
> the slave cameras are updated in a couple of following for loops? I mean,
> couldn't the main camera view matrix be updated, I agree after the
> updateSceneGraph() call, but before the slave cameras? Or at least move the
> slave cameras with "_useMastersSceneData=false" after the main camera?
> Something like:
>
> Code:
>
> if (view->getCameraManipulator())
> {
> view->setFusionDistance(
> view->getCameraManipulator()->getFusionDistanceMode(),
>
> view->getCameraManipulator()->getFusionDistanceValue() );
>
> view->getCamera()->setViewMatrix(
> view->getCameraManipulator()->getInverseMatrix());
> }
>
> // Do UpdateTraversal for slaves with their own subgraph
> for(unsigned int i=0; igetNumSlaves(); ++i)
> {
>osg::View::Slave& slave = view->getSlave(i);
>osg::Camera* camera = slave._camera.get();
>if(camera && !slave._useMastersSceneData)
>{
> camera->accept(*_updateVisitor);
>}
> }
>
> view->updateSlaves();
>
>
>
>
> Regards,
> Gianni
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=64631#64631
>
>
>
>
>
> ___
> 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] Volume image crash on the latest version of Nvidia driver
Hi Clement, Could you post the data and command line options with osgvolume that illustrate the problem so I can test here. Cheers, Robert. On 5 August 2015 at 13:36, wrote: > Hi Robert, > > The problem may be related to Nvidia driver. I tested on my laptop > (Nvidia NVS 5200M) with driver 353.62 and deskop (Nvidia Quadro 2000) with > driver 353.62. Both machines have the crash problem. I also tested the > crash problem starting from the driver version 343. > > My application is using window MFC. There is no crash when the volume > data is loaded. Once I started to rotate the image, it will crash the > whole application. I also exported my volume data into dds format using > (osg write image method). When I used osgviewer.exe to load the dds image, > the crash problem also occurred if I rotated the image. I cannot run the > osg volume data sample, but there is no crash problem with using others osg > example data. I will try OSG-3.4.0-rc later. > > > *Regards,* > *Clement* > > -- > *From:* osg-users [osg-users-boun...@lists.openscenegraph.org] on behalf > of Robert Osfield [robert.osfi...@gmail.com] > *Sent:* Wednesday, 5 August 2015 16:52 > *To:* OpenSceneGraph Users > *Subject:* Re: [osg-users] Volume image crash on the latest version of > Nvidia driver > > Hi Clement and Julien, > > On 5 August 2015 at 02:12, wrote: > >> Hi Julien, >> >>I am using osg stable release 3.2.1 64 bit windows version. Did you >> solve the problem so far? >> > > Can you create the problem with any of the standard OSG examples? > > If not could you create a small example that illustrates the problem. > > Trying out one of the OSG-3.4.0-rc as well as the OpenSceneGraph-Data in > svn/trunk. I'll make a new OpenSceneGraph-Data for OSG-3.4.0. > > Robert. > > > ___ > 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] update slave camera with frame scheme ON_DEMAND
Thank you Robert for the explanation.
Please don't blame me if I have a couple of questions.
First of all, debugging the updateTraversal() implementation it seems the
AxesCameraUpdateCallback is called twice: one in
scene->updateSceneGraph(*_updateVisitor);
and the second time in
camera->accept(*_updateVisitor);
I guess this is an expected behavior.
Second, you say "The master Camera's value can depend upon values in the scene
graph". But isn't the scene updated in updateSceneGraph call? While the slave
cameras are updated in a couple of following for loops? I mean, couldn't the
main camera view matrix be updated, I agree after the updateSceneGraph() call,
but before the slave cameras? Or at least move the slave cameras with
"_useMastersSceneData=false" after the main camera? Something like:
Code:
if (view->getCameraManipulator())
{
view->setFusionDistance(
view->getCameraManipulator()->getFusionDistanceMode(),
view->getCameraManipulator()->getFusionDistanceValue() );
view->getCamera()->setViewMatrix(
view->getCameraManipulator()->getInverseMatrix());
}
// Do UpdateTraversal for slaves with their own subgraph
for(unsigned int i=0; igetNumSlaves(); ++i)
{
osg::View::Slave& slave = view->getSlave(i);
osg::Camera* camera = slave._camera.get();
if(camera && !slave._useMastersSceneData)
{
camera->accept(*_updateVisitor);
}
}
view->updateSlaves();
Regards,
Gianni
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=64631#64631
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Find out if a node is "dirty"
Hi Robert, robertosfield wrote: > > What do you need it for? > I'm now working to switch my applocation from a continuous frame to an ON_DEMAND frame to reduce CPU consumption. Unfotunately even with vsync enabled my application takes one cpu core even if nothing changes in the scene. So, for the time being I implemented a "dirty falg" in my scene manager so that the viewer can check it and call frame() as needed. Then, looking at that _boundingSphereComputed flag I was thinking if it may be useful instead of implementing my own dirty flag. I found some "setters" (i.e. in PositionAttitudeTransform) calls dirtyBounds() which is propagated to parents. For sure in my specific case (i.e. one viewer and one scene) a "dirty flag" like that would be enough but may be in a more general case (i.e. scene shared to more than one Viewer) there must be something stored in each viewer also. I thought of a time stamp for example: time of modification to be compared to the time stamp of the frame() computed from each viewer. But I don't know if that would make sense. Regards, Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=64630#64630 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Find out if a node is "dirty"
Hi Gianni, On 5 August 2015 at 13:12, Gianni Ambrosio wrote: > it there a reason why _boundingSphereComputed is not accessible through a > public getter? > Simply no one has asked for it so far :-) What do you need it for? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Volume image crash on the latest version of Nvidia driver
Hi Robert, The problem may be related to Nvidia driver. I tested on my laptop (Nvidia NVS 5200M) with driver 353.62 and deskop (Nvidia Quadro 2000) with driver 353.62. Both machines have the crash problem. I also tested the crash problem starting from the driver version 343. My application is using window MFC. There is no crash when the volume data is loaded. Once I started to rotate the image, it will crash the whole application. I also exported my volume data into dds format using (osg write image method). When I used osgviewer.exe to load the dds image, the crash problem also occurred if I rotated the image. I cannot run the osg volume data sample, but there is no crash problem with using others osg example data. I will try OSG-3.4.0-rc later. Regards, Clement From: osg-users [osg-users-boun...@lists.openscenegraph.org] on behalf of Robert Osfield [robert.osfi...@gmail.com] Sent: Wednesday, 5 August 2015 16:52 To: OpenSceneGraph Users Subject: Re: [osg-users] Volume image crash on the latest version of Nvidia driver Hi Clement and Julien, On 5 August 2015 at 02:12, mailto:clement@csiro.au>> wrote: Hi Julien, I am using osg stable release 3.2.1 64 bit windows version. Did you solve the problem so far? Can you create the problem with any of the standard OSG examples? If not could you create a small example that illustrates the problem. Trying out one of the OSG-3.4.0-rc as well as the OpenSceneGraph-Data in svn/trunk. I'll make a new OpenSceneGraph-Data for OSG-3.4.0. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Find out if a node is "dirty"
Hi Robert, it there a reason why _boundingSphereComputed is not accessible through a public getter? Regards, Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=64627#64627 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] update slave camera with frame scheme ON_DEMAND
Hi Gianni,
The ordering of update of the view's master Camera is done after the update
traversal, so checking the Camera's value in update traversal will result
in using the previous frames value. The master Camera's value can depend
upon values in the scene graph so this ordering make sense for most
application, and since you are using the NodeTrackerManipulator it's
essential.
So for your application I'd suggest shift the slave Camera (CrossAxes) so
that is' done after the call to viewer::updateTraversal(). This could be
done by simply calling the frame components manually in your application
and then inserting the appropriate update code.
i..e.
while(!viewer.done())
{
viewer.advance();
viewer.eventTraversal();
viewer.updateTraversal();
// do your CrossAxes updating here.
viewer.renderingTraversals();
}
On 5 August 2015 at 10:41, Gianni Ambrosio wrote:
> Hi All,
> it seems I found the problem but not a solution jet.
>
> In my CrossAxes object (that is an osg::Camera) I do:
>
> setUpdateCallback(new AxesCameraUpdateCallback);
>
> and in AxesCameraUpdateCallback::operator() implementation I have:
>
>transform->setAttitude(view->getCamera()->getViewMatrix().getRotate());
>
> where "transform" is child of the CrossAxes camera node and parent of the
> real axes graphics (please see previous message for details).
> In AxesCameraUpdateCallback I get the rotation from the camera of the view
> to show the global axes correctly oriented wrt the current camera
> orientation.
> Unfortunately, in this case, it seems that the first time frame() is
> called I get an "old" value from
>
> view->getCamera()->getViewMatrix().getRotate()
>
> It seems that the camera view matrix is updated after my
> AxesCameraUpdateCalback is called. That's wht a second call to frame()
> fixes axes orientation.
>
> Since to set the desired point of view I call
>
> NodeTrackerManipulator::setTransformation(const osg::Vec3d& iEye, const
> osg::Vec3d& iCenter, const osg::Vec3d& iUp)
>
> Which is the proper modification to do on my code to have a correct
> behaviour? Is there a way to get the correct view matrix in
> AxesCameraUpdateCallback::operator() implementation?
>
> Best regards,
> Gianni
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=64623#64623
>
>
>
>
>
> ___
> 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] OpenGL OSG Rendering 19 tessellation + LOD + tiles
Really nice ! It's seems to get all that I need. Thank a lot ! valerian -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=64624#64624 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] update slave camera with frame scheme ON_DEMAND
Hi All, it seems I found the problem but not a solution jet. In my CrossAxes object (that is an osg::Camera) I do: setUpdateCallback(new AxesCameraUpdateCallback); and in AxesCameraUpdateCallback::operator() implementation I have: transform->setAttitude(view->getCamera()->getViewMatrix().getRotate()); where "transform" is child of the CrossAxes camera node and parent of the real axes graphics (please see previous message for details). In AxesCameraUpdateCallback I get the rotation from the camera of the view to show the global axes correctly oriented wrt the current camera orientation. Unfortunately, in this case, it seems that the first time frame() is called I get an "old" value from view->getCamera()->getViewMatrix().getRotate() It seems that the camera view matrix is updated after my AxesCameraUpdateCalback is called. That's wht a second call to frame() fixes axes orientation. Since to set the desired point of view I call NodeTrackerManipulator::setTransformation(const osg::Vec3d& iEye, const osg::Vec3d& iCenter, const osg::Vec3d& iUp) Which is the proper modification to do on my code to have a correct behaviour? Is there a way to get the correct view matrix in AxesCameraUpdateCallback::operator() implementation? Best regards, Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=64623#64623 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
