[osg-users] [build] how do i generate project.exe file and .pdb file in specified folder
Hi, i am building my project in VS2005. right now the .exe file and .pdb file go in debug folder but i want the to go in the bin folder instead and run from there. plz suggest the CMakeList.txt code for it ... Thank you. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10694#10694 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] how do i generate project.exe file and .pdb file in specified folder
Hi, You don't need Cmake for that, just run into VS project properties - Linker - General - output file (or similar, my VS is in French) Same thing for the .pdb file in properties - Linker- debug Regards, Vincent. 2009/4/23 Abhinav Dubey dubey.abhin...@gmail.com Hi, i am building my project in VS2005. right now the .exe file and .pdb file go in debug folder but i want the to go in the bin folder instead and run from there. plz suggest the CMakeList.txt code for it ... Thank you. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10694#10694 ___ 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] Picking Problem PolytopeIntersector
Hi Jean-Sébastien,
Jean-Sébastien Guay schrieb:
Hello Matthias,
[...]
Another difference, the line segment intersector orders objects by their
distance (closest intersection first), but the polytope intersector
doesn't (it would be pretty hard to implement even an approximation, and
even that would be slow - the polytope intersector is slow enough as it
is).
I'd like to correct you on that one. Let me quote PolytopeIntesector:
/** set the plane used to sort the intersections.
* The intersections are sorted by the distance of the
* localIntersectionPoint and the reference plane.
* The default for the reference plane is the
* last plane of the polytope.
*/
inline void setReferencePlane(const osg::Plane plane) {...}
We use this for point and line picking and only have to check
the first (few) intersections.
So you see, the two types of intersectors lend themselves naturally to
different applications. Hope this helps,
J-S
Regards
Peter
--
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Roland Niemeier,
Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Michel Lepert
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RecordCameraPathHandler where is the saved_animation.path file?
HI Rodrigo, On Wed, Apr 22, 2009 at 8:39 PM, Rodrigo Salvador osgfo...@tevs.eu wrote: Felix, did you achieve to replay the animation? I recorded a animation in a saved_animation.path file, but what I want is to play it in a external player. Does OSG save the animation with another kind of file, like .wmv? The recoding of the animation *path* is supported, but this is just log of position+orientation of the camera. You can run osgviewer with this path to replay it, but it's not something other non OSG tools will support. If you want a movie then you'll need an entirely seperate image capture support. I do plan to add support for this in the 2.9.x dev series using the ffmpeg plugin to do the video encoding, but I don't have any dates for the work. In the meantime you'll need to use a 3rd party tool to capture the desktop and encode it. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DBPager continuously reloading tiles
Hi Evan, On Wed, Apr 22, 2009 at 10:05 PM, Evan Andersen andersen.e...@gmail.com wrote: Ryan, Thank you for the suggestion. When I call setTargetMaximumNumberOfPagedLOD(0) on the database pager, as you suggested and then set the expiry delay to DBL_MAX and the expiry frames to 10, as Jason Suggested the problem seems to go away. I'm not really sure why this works. It seems like the default behavior should work in my usage case, but at least it is working now. Could you modify one of the OSG examples to reproduce your application usage style and use this to recreate the problem. I could then have a look at why the new (and now default) expiry scheme is not working correctly. As you say it should work, at present I don't know why the old scheme is able to work. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Jerky display?
On Thu, Apr 23, 2009 at 6:20 AM, Akilan akilan.thangam...@gmail.com wrote: Hi I bit know about the concept of quad tree. But I want to know applying the concept on OSG construction. Can I get any reference for organizing the scenegraph in quad tree form? I have help with API, but it's not my role to teach your about basics of computer graphics. Try google. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to make a thread running into the graph safely ?
Hi Robert,
I am using the 2.6.1 that's why I didn't found stats code.
For the moment, I just copy the code from 2.8 concerning camera stats
(visible vertices, ...) but it does not work correctly :
In the StatsHandler, in the case of camera stats, there is :
for(osgViewer::ViewerBase::Cameras::iterator itr = cameras.begin();
itr != cameras.end();
++itr)
{
osg::Stats* stats = _camera-getStats();
if (stats)
{
stats-collectStats(scene,true);
}
}
But when I do _camera-getStats(), I get NULL ... so the stats do not
contain anything so I have no stats on the screen.
I didn't found if there is an other initialization or something to do on
camera to get/compute the stats ... my Handler is very close to the
StatsHandler of the 2.8...
What do I miss ?
Thanks a lot.
Regards,
Vincent
2009/4/22 Robert Osfield robert.osfi...@gmail.com
Hi Vincent,
The osgviewer stats has scene info collection and works pretty fast so
I'm surprised similar code of yours has problems. Is you scene
particular big? How many nodes/geometries etc?
As for running in a separate thread when not run the thread in a
parallel to the viewer.renderingTraversals(); just put a barrier
before and after the call to renderingTraversals().
Robert.
On Wed, Apr 22, 2009 at 3:53 PM, Vincent Bourdier
vincent.bourd...@gmail.com wrote:
Hi,
I have a problem of how-to :
I have a function, which need to run into the graph to count the visible
and total number of face. This is a code which is not so quick... so I
would
like to put it in a separate thread to avoid my application lags.
But, my thread isn't synchronized yet, so in case of the graph
modification
... it crashes.
How can I set my thread to be synchronized with osg threads, keeping the
thread advantage or parallel process to avoid the user seeing a lag when
the
algorithm traverse the graph ?
This algorithm is based on NodeVisistors, does it change anything ?
Thanks for help.
Regards,
Vincent.
___
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
Re: [osg-users] How to make a thread running into the graph safely ?
Hi Vincent,
Camera's don't have a Stats object assigned to them by default, you
have to assign it. osgViewer does assign Stats for the viewer camera,
or at least in 2.8. Go check the differences between the viewer libs.
Robert.
On Thu, Apr 23, 2009 at 9:34 AM, Vincent Bourdier
vincent.bourd...@gmail.com wrote:
Hi Robert,
I am using the 2.6.1 that's why I didn't found stats code.
For the moment, I just copy the code from 2.8 concerning camera stats
(visible vertices, ...) but it does not work correctly :
In the StatsHandler, in the case of camera stats, there is :
for(osgViewer::ViewerBase::Cameras::iterator itr = cameras.begin();
itr != cameras.end();
++itr)
{
osg::Stats* stats = _camera-getStats();
if (stats)
{
stats-collectStats(scene,true);
}
}
But when I do _camera-getStats(), I get NULL ... so the stats do not
contain anything so I have no stats on the screen.
I didn't found if there is an other initialization or something to do on
camera to get/compute the stats ... my Handler is very close to the
StatsHandler of the 2.8...
What do I miss ?
Thanks a lot.
Regards,
Vincent
2009/4/22 Robert Osfield robert.osfi...@gmail.com
Hi Vincent,
The osgviewer stats has scene info collection and works pretty fast so
I'm surprised similar code of yours has problems. Is you scene
particular big? How many nodes/geometries etc?
As for running in a separate thread when not run the thread in a
parallel to the viewer.renderingTraversals(); just put a barrier
before and after the call to renderingTraversals().
Robert.
On Wed, Apr 22, 2009 at 3:53 PM, Vincent Bourdier
vincent.bourd...@gmail.com wrote:
Hi,
I have a problem of how-to :
I have a function, which need to run into the graph to count the
visible
and total number of face. This is a code which is not so quick... so I
would
like to put it in a separate thread to avoid my application lags.
But, my thread isn't synchronized yet, so in case of the graph
modification
... it crashes.
How can I set my thread to be synchronized with osg threads, keeping the
thread advantage or parallel process to avoid the user seeing a lag when
the
algorithm traverse the graph ?
This algorithm is based on NodeVisistors, does it change anything ?
Thanks for help.
Regards,
Vincent.
___
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
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to make a thread running into the graph safely ?
Hi Robert,
First, thanks for the answers.
Next, I get my camera stats, it contains a lot of things :
In _collectMap there are (gpu, true) and (rendering, true), and in
_attributeMapList there are 25 item, which are empty or containing some
things like cull traversal begin time or Draw traversal begin time.
After the call of stats-collectStats(scene,true); there are no more
information in the _attributeMapList ... In the code I see that it just add
one flag in the _collectMap so how can I get the scene informations ?
How, I just found that in the stats I wait for are set in the Renderer.cpp,
but in the osg 2.6.1 I didn't found them ... If i'm right ... I cannot get
these stats with the 2.6.1, isn't ?
Thanks.
Regards,
Vincent.
2009/4/23 Robert Osfield robert.osfi...@gmail.com
Hi Vincent,
Camera's don't have a Stats object assigned to them by default, you
have to assign it. osgViewer does assign Stats for the viewer camera,
or at least in 2.8. Go check the differences between the viewer libs.
Robert.
On Thu, Apr 23, 2009 at 9:34 AM, Vincent Bourdier
vincent.bourd...@gmail.com wrote:
Hi Robert,
I am using the 2.6.1 that's why I didn't found stats code.
For the moment, I just copy the code from 2.8 concerning camera stats
(visible vertices, ...) but it does not work correctly :
In the StatsHandler, in the case of camera stats, there is :
for(osgViewer::ViewerBase::Cameras::iterator itr = cameras.begin();
itr != cameras.end();
++itr)
{
osg::Stats* stats = _camera-getStats();
if (stats)
{
stats-collectStats(scene,true);
}
}
But when I do _camera-getStats(), I get NULL ... so the stats do not
contain anything so I have no stats on the screen.
I didn't found if there is an other initialization or something to do on
camera to get/compute the stats ... my Handler is very close to the
StatsHandler of the 2.8...
What do I miss ?
Thanks a lot.
Regards,
Vincent
2009/4/22 Robert Osfield robert.osfi...@gmail.com
Hi Vincent,
The osgviewer stats has scene info collection and works pretty fast so
I'm surprised similar code of yours has problems. Is you scene
particular big? How many nodes/geometries etc?
As for running in a separate thread when not run the thread in a
parallel to the viewer.renderingTraversals(); just put a barrier
before and after the call to renderingTraversals().
Robert.
On Wed, Apr 22, 2009 at 3:53 PM, Vincent Bourdier
vincent.bourd...@gmail.com wrote:
Hi,
I have a problem of how-to :
I have a function, which need to run into the graph to count the
visible
and total number of face. This is a code which is not so quick... so I
would
like to put it in a separate thread to avoid my application lags.
But, my thread isn't synchronized yet, so in case of the graph
modification
... it crashes.
How can I set my thread to be synchronized with osg threads, keeping
the
thread advantage or parallel process to avoid the user seeing a lag
when
the
algorithm traverse the graph ?
This algorithm is based on NodeVisistors, does it change anything ?
Thanks for help.
Regards,
Vincent.
___
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
___
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] How to make a thread running into the graph safely ?
Hi Vincent,
I can't keep track of every little bit of code in every previous OSG
release. The code works in 2.8.0 as far as I'm aware so why not just
upgrade, all it should require is a download and recompile of the OSG
and your app.
Robert.
On Thu, Apr 23, 2009 at 10:13 AM, Vincent Bourdier
vincent.bourd...@gmail.com wrote:
Hi Robert,
First, thanks for the answers.
Next, I get my camera stats, it contains a lot of things :
In _collectMap there are (gpu, true) and (rendering, true), and in
_attributeMapList there are 25 item, which are empty or containing some
things like cull traversal begin time or Draw traversal begin time.
After the call of stats-collectStats(scene,true); there are no more
information in the _attributeMapList ... In the code I see that it just add
one flag in the _collectMap so how can I get the scene informations ?
How, I just found that in the stats I wait for are set in the Renderer.cpp,
but in the osg 2.6.1 I didn't found them ... If i'm right ... I cannot get
these stats with the 2.6.1, isn't ?
Thanks.
Regards,
Vincent.
2009/4/23 Robert Osfield robert.osfi...@gmail.com
Hi Vincent,
Camera's don't have a Stats object assigned to them by default, you
have to assign it. osgViewer does assign Stats for the viewer camera,
or at least in 2.8. Go check the differences between the viewer libs.
Robert.
On Thu, Apr 23, 2009 at 9:34 AM, Vincent Bourdier
vincent.bourd...@gmail.com wrote:
Hi Robert,
I am using the 2.6.1 that's why I didn't found stats code.
For the moment, I just copy the code from 2.8 concerning camera stats
(visible vertices, ...) but it does not work correctly :
In the StatsHandler, in the case of camera stats, there is :
for(osgViewer::ViewerBase::Cameras::iterator itr = cameras.begin();
itr != cameras.end();
++itr)
{
osg::Stats* stats =
_camera-getStats();
if (stats)
{
stats-collectStats(scene,true);
}
}
But when I do _camera-getStats(), I get NULL ... so the stats do not
contain anything so I have no stats on the screen.
I didn't found if there is an other initialization or something to do on
camera to get/compute the stats ... my Handler is very close to the
StatsHandler of the 2.8...
What do I miss ?
Thanks a lot.
Regards,
Vincent
2009/4/22 Robert Osfield robert.osfi...@gmail.com
Hi Vincent,
The osgviewer stats has scene info collection and works pretty fast so
I'm surprised similar code of yours has problems. Is you scene
particular big? How many nodes/geometries etc?
As for running in a separate thread when not run the thread in a
parallel to the viewer.renderingTraversals(); just put a barrier
before and after the call to renderingTraversals().
Robert.
On Wed, Apr 22, 2009 at 3:53 PM, Vincent Bourdier
vincent.bourd...@gmail.com wrote:
Hi,
I have a problem of how-to :
I have a function, which need to run into the graph to count the
visible
and total number of face. This is a code which is not so quick... so
I
would
like to put it in a separate thread to avoid my application lags.
But, my thread isn't synchronized yet, so in case of the graph
modification
... it crashes.
How can I set my thread to be synchronized with osg threads, keeping
the
thread advantage or parallel process to avoid the user seeing a lag
when
the
algorithm traverse the graph ?
This algorithm is based on NodeVisistors, does it change anything ?
Thanks for help.
Regards,
Vincent.
___
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
___
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
Re: [osg-users] Is polygon on screen
Hello there, are you the famous manguliok from the vegaprime forum?? I hope so... to the business, I'm new to the OSG, as I understood from your question I'm in the same need, but I just can't understand Robert tips. I set up my entire camera as the frustrum, but where do I select the triangle I wish to know if it's on screen now. For my case, the triangle I look after is a part of a big mesh that is always on screen (it's a huge mesh used as a terrain). -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10707#10707 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Copying top half of image using osg::copyImage
Hi Robert,
I have indeed gone through the debugger and the values are what I would
expect. I've attached an example so you could see the issue. If I am
interpreting the osg::copyImage parameters correctly, then the if
((src_t+height) (dest_t + destImage-t())) check seems should rather be
if ((src_t+height) (srcImage-t())) if testing if the height parameter
is valid. The attached example fails the if ((src_t+height) (dest_t +
destImage-t())) check. If I remove this check from osg::copyImage, then
the output image is what I would expect.
Thanks,
Donny
On Wed, Apr 22, 2009 at 1:10 PM, Robert Osfield robert.osfi...@gmail.comwrote:
Hi Donald,
Have you gone through your code with a debugger at all? Check what
value of nHalfSrcHeight you are getting.
One fix to your code you could do would be to use /2 rather *0.5 as /2
can use integer maths, while *0.5 requires pImageSrc-t() to be
automatically promoted to a float for it work.
Robert.
On Wed, Apr 22, 2009 at 5:57 PM, Donald Cipperly osgc...@gmail.com
wrote:
Hi Robert,
I'm trying to copy the top half of an existing image using
osg::copyImage.
I do this as such:
// Read in source image
osg::ref_ptr osg::Image pImageSrc = osgDB::readImageFile(
test.jpg
);
int nHalfSrcHeight = (int)(pImageSrc-t() * 0.5);
// Allocate destination image
osg::Image *pImageDest = new osg::Image();
pImageDest-allocateImage(pImageSrc-s(), nHalfSrcHeight,
pImageSrc-r(), pImageSrc-getPixelFormat(), pImageSrc-getDataType());
// Copy top half of source image to destination
myCopyImage( pImageSrc.get(), 0, (nHalfSrcHeight-1), 0,
pImageSrc-s(),
nHalfSrcHeight, pImageSrc-r(),
pImageDest, 0, 0, 0, false );
This appears to be the correct way to perform this operation. Is this
correct? If so, then line 210 of osg/ImageUtils.cpp appears to be
incorrect
as it notifies that my input height is too large. And indeed when I
commend
out the block below in ImageUtils.cpp, then it outputs the top half of my
image as I expect.
if ((src_t+height) (dest_t + destImage-t()))
{
osg::notify(osg::NOTICE)copyImage(srcImage, src_s,
src_t, src_r, width, height,
depthstd::endl;
osg::notify(osg::NOTICE) destImage,
dest_s,
dest_t, dest_r, doRescale)std::endl;
osg::notify(osg::NOTICE) input height too
large.std::endl;
return false;
}
Thanks for any help you can provide,
Donny
___
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
#include osgDB/ReadFile
#include osgDB/WriteFile
#include osg/ImageUtils
int main( int, char **)
{
// Read in source image...clockface.JPG from the base
OpenSceneGraph-Data
osg::ref_ptr osg::Image pImageSrc = osgDB::readImageFile(
Images/clockface.JPG );
int nHalfSrcHeight = pImageSrc-t() / 2;
// Allocate destination image
osg::Image *pImageDest = new osg::Image();
pImageDest-allocateImage(pImageSrc-s(), nHalfSrcHeight,
pImageSrc-r(), pImageSrc-getPixelFormat(), pImageSrc-getDataType());
// Copy top half of source image to destination
osg::copyImage( pImageSrc.get(), 0, (nHalfSrcHeight-1), 0,
pImageSrc-s(), nHalfSrcHeight, pImageSrc-r(),
pImageDest, 0, 0, 0, false );
// Write the destination image to file
osgDB::writeImageFile( *pImageDest,
std::string(C:/OpenSceneGraph-Data/Images/clockfaceTop.jpg) );
return 0;
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to make a thread running into the graph safely ?
Hi Robert,
You're right of course, I was just asking if you remember something about
that, but the code seems to always tell the truth, and so I need to upgrade
... I'll notice that for the day when we upgrade.
Thanks for your time and your explanations.
Regards,
Vincent.
2009/4/23 Robert Osfield robert.osfi...@gmail.com
Hi Vincent,
I can't keep track of every little bit of code in every previous OSG
release. The code works in 2.8.0 as far as I'm aware so why not just
upgrade, all it should require is a download and recompile of the OSG
and your app.
Robert.
On Thu, Apr 23, 2009 at 10:13 AM, Vincent Bourdier
vincent.bourd...@gmail.com wrote:
Hi Robert,
First, thanks for the answers.
Next, I get my camera stats, it contains a lot of things :
In _collectMap there are (gpu, true) and (rendering, true), and in
_attributeMapList there are 25 item, which are empty or containing some
things like cull traversal begin time or Draw traversal begin time.
After the call of stats-collectStats(scene,true); there are no more
information in the _attributeMapList ... In the code I see that it just
add
one flag in the _collectMap so how can I get the scene informations ?
How, I just found that in the stats I wait for are set in the
Renderer.cpp,
but in the osg 2.6.1 I didn't found them ... If i'm right ... I cannot
get
these stats with the 2.6.1, isn't ?
Thanks.
Regards,
Vincent.
2009/4/23 Robert Osfield robert.osfi...@gmail.com
Hi Vincent,
Camera's don't have a Stats object assigned to them by default, you
have to assign it. osgViewer does assign Stats for the viewer camera,
or at least in 2.8. Go check the differences between the viewer libs.
Robert.
On Thu, Apr 23, 2009 at 9:34 AM, Vincent Bourdier
vincent.bourd...@gmail.com wrote:
Hi Robert,
I am using the 2.6.1 that's why I didn't found stats code.
For the moment, I just copy the code from 2.8 concerning camera stats
(visible vertices, ...) but it does not work correctly :
In the StatsHandler, in the case of camera stats, there is :
for(osgViewer::ViewerBase::Cameras::iterator itr = cameras.begin();
itr != cameras.end();
++itr)
{
osg::Stats* stats =
_camera-getStats();
if (stats)
{
stats-collectStats(scene,true);
}
}
But when I do _camera-getStats(), I get NULL ... so the stats do not
contain anything so I have no stats on the screen.
I didn't found if there is an other initialization or something to do
on
camera to get/compute the stats ... my Handler is very close to the
StatsHandler of the 2.8...
What do I miss ?
Thanks a lot.
Regards,
Vincent
2009/4/22 Robert Osfield robert.osfi...@gmail.com
Hi Vincent,
The osgviewer stats has scene info collection and works pretty fast
so
I'm surprised similar code of yours has problems. Is you scene
particular big? How many nodes/geometries etc?
As for running in a separate thread when not run the thread in a
parallel to the viewer.renderingTraversals(); just put a barrier
before and after the call to renderingTraversals().
Robert.
On Wed, Apr 22, 2009 at 3:53 PM, Vincent Bourdier
vincent.bourd...@gmail.com wrote:
Hi,
I have a problem of how-to :
I have a function, which need to run into the graph to count the
visible
and total number of face. This is a code which is not so quick...
so
I
would
like to put it in a separate thread to avoid my application lags.
But, my thread isn't synchronized yet, so in case of the graph
modification
... it crashes.
How can I set my thread to be synchronized with osg threads,
keeping
the
thread advantage or parallel process to avoid the user seeing a lag
when
the
algorithm traverse the graph ?
This algorithm is based on NodeVisistors, does it change anything ?
Thanks for help.
Regards,
Vincent.
___
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
___
osg-users mailing list
Re: [osg-users] [build] how do i generate project.exe file and .pdb file in specified folder
Try this
SET_TARGET_PROPERTIES(${PROJECT_NAME} PROPERTIES
RUNTIME_OUTPUT_DIRECTORY ${your_exe_dir} )
SET_TARGET_PROPERTIES(${PROJECT_NAME} PROPERTIES
LIBRARY_OUTPUT_DIRECTORY ${your_lib_dir} )
IF(MSVC_IDE)
SET_TARGET_PROPERTIES(${PROJECT_NAME} PROPERTIES PREFIX ../)
or
SET_TARGET_PROPERTIES(${PROJECT_NAME} PROPERTIES
RELEASE_OUTPUT_NAME ../${TARGET_NAME})
SET_TARGET_PROPERTIES(${PROJECT_NAME} PROPERTIES
DEBUG_OUTPUT_NAME ../${TARGET_NAME}D)
ENDIF(MSVC_IDE)
Not sure where the pdb will be put though I' m using the latest (
2.6.3) cmake
Hope it helps
Luigi
Abhinav Dubey ha scritto:
i know that way it can be done..but i am using Qt+VS+Cmake and need to do this
cia CMakeLists.txt. right now what i am doing is that i copy these file from
the repective folders as a post build even. the code i am using is:
if(WIN32)
add_custom_command(TARGET ${PROJECT_NAME} POST_BUILD
COMMAND md ARGS
$ENV{N3DBINARY_PATH}\\bin
COMMAND copy ARGS
$ENV{N3DBINARY_PATH}\\${CMAKE_CFG_INTDIR}\\${PROJECT_NAME}*.exe
$ENV{N3DBINARY_PATH}\\bin
COMMAND if $(ConfigurationName) == Debug copy ARGS
$ENV{N3DBINARY_PATH}\\${CMAKE_CFG_INTDIR}\\${PROJECT_NAME}*.pdb
$ENV{N3DBINARY_PATH}\\bin
)
endif(WIN32)
but i want to directly get these files in bin instead of copying them. can yoyu
uggest the code for it!!
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=10697#10697
___
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] 300 forum members
Just wanted to inform you that we have reached 300 forum members. Small overview over forum and ML members (non-digest/digest) 25 februari 2009 Forum 100 ML 1842 (1410/432) 24 march 2009 Forum 200 ML? 23 april 2009 Forum 300 ML 1852 (1413/439) 22 may 2009 Forum 400??? kind regards, Roland -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10710#10710 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [osgPlugins] collada: use of bind_vertex_input
Hi, I export from Max using the feeling exporter 3.05b (c gives the same results). I have a diffuse map and an ambient map in my model. When importing the collada file into osg, the maps are not shown. It seems that I have to modify [code]instance_material symbol=r8.3.007_1 target=#r8.3.007-material/[/code] to [code] instance_material symbol=r8.3.007_1 target=#r8.3.007-material bind_vertex_input semantic=CHANNEL2 input_semantic=TEXCOORD input_set=2/ bind_vertex_input semantic=CHANNEL1 input_semantic=TEXCOORD input_set=1/ /instance_material [/code] Then everything works as expected. Is this faulty behavior of the exporter? The collada 1.4 spec says: [quote] The bind_vertex_input element binds geometry vertex streams (identified as input elements within geometry elements) to material effect vertex stream semantics. Although applications commonly perform automatic binding of vertex streams with identical semantic identifiers, there are frequently mismatches in a semantic identifier’s meaning. Use bind_vertex_input to remove these ambiguities [/quote] So maybe the exporter could detect texture coordinate sets automatically? Thanks, Martin[/quote] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10711#10711 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Public ffmpeg plugin testing streams
Hi J-S,
FFmpegDecoder.cpp :
- bool FFmpegDecoder::readNextPacketNormal() [Line 246 to 308]
- bool FFmpegDecoder::readNextPacketEndOfStream() [Line 312 to 320]
More precisely, I wonder about the API validity of the following code in the
case of a streaming video. FFmpeg documentation is quite poor in this regard.
// Read the next frame packet
if (av_read_frame(m_format_context.get(), packet) 0)
{
if (url_ferror(m_format_context-pb) == 0)
end_of_stream = true;
else
throw std::runtime_error(av_read_frame() failed);
}
Also note that there might be a difference between a finite video streamed from
an HTTP source and an endless video stream from an HTTP source.
Cheers,
Tanguy
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien
Guay
Sent: Wednesday 22 April 2009 18:06
To: OpenSceneGraph Users
Subject: Re: [osg-users] Public ffmpeg plugin testing streams
Hello Tanguy,
The osgFFmpeg plugin was written with a file source in mind. By default when
it encounters an EOF, it will either loop the video or stop playing
(depending on the ImageStream settings).
This behaviour may probably be incorrect with streaming sources.
Yes, seems so, it would need to wait and try again later... Interesting
you didn't mention this earlier, I've been saying that it stopped after
15-20 seconds of streaming and asking if someone knew why... Oh wait,
are you not on osg-submissions? That discussion was there.
Where is that code located? I looked around but didn't find it, perhaps
I was looking wrong :-)
As you said, one needs to dive further into FFmpeg API to really understand
what is really happening.
Yeah, that's what's killing me. I really want this to work, but without
knowing ffmpeg more I'm really grasping at straws...
Thanks,
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.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
Re: [osg-users] [build] how do i generate project.exe file and .pdb file in specified folder
will dis put the .exe file directly in bin folder without creating a copy in debug folder?? because what i actually want is when i debug my project the .exe file gets created in bin folder and run from there!! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10712#10712 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DoomLike manipulator
Hi Richard, I wouldn't want to fool you with this collision stuff. The goal is simply to prevent the player (the camera) to cross through the walls of the scene, and in the meantime to stick to the ground in case of grounded mode. Something alike is already done in the DriveManipulator, using a LineSegmentIntersector. I wanted to improve it by modeling the player as a rectangle box, and use a PolytopeIntersector, but then I ran into a lot of trouble. So I think I will release a version with the LineSegmentIntersector first and when/if I find some time I will try again with the polytope one. -- Loïc Simon On Thu, Apr 23, 2009 at 12:33 AM, Richard Baron Penman richardbp+...@gmail.com richardbp%2b...@gmail.com wrote: 'collision handling' - oh wow! I eagerly await. Richard On Wed, Apr 22, 2009 at 7:59 AM, Simon Loic simon1l...@gmail.com wrote: Hi, In fact I've struggled quite a while to handle collision in a way that apparently doesn't work, and finally I had to postpone coding on it for work reason. I'll try to post a version of this manipulator with simple collision tests soon , let's say by the week end. On Tue, Apr 21, 2009 at 3:51 AM, Richard Baron Penman richardbp+...@gmail.com richardbp%2b...@gmail.com wrote: hi, I'm interested in using this manipulator. Have any updates been posted or should I use the originally posted one? Richard 2009/3/24 Simon Loic simon1l...@gmail.com In fact I didn't have enough time to finish this week-end. So It will be postponed to next week. On Fri, Mar 20, 2009 at 9:10 AM, Simon Loic simon1l...@gmail.comwrote: All right, I'll certainly finish during the week-end and post it on osg-users for testing. 2009/3/20 Robert Osfield robert.osfi...@gmail.com Hi Loic, Great little discussion :-) 2009/3/19 Simon Loic simon1l...@gmail.com Maybe when I will have finished to implement the GROUNDED/HORIZONTAL mode you can give it a try and decide which name best fits. In my concern I clearly incline towars grounded as the implementation I was about to propose allows step over small obstacles like stairs. If you have remarks on the implementation so far, go ahead... to sukender : I didn't exacly get your remarks while I'm sure they are founded. Anyway I think that when I wil have finished to code both mode, things will become clearer for me and for you. Get you informed as soon as the manipulator is ready. When you ready just post the changes to either osg-submissions if it's ready to merge, or to osg-users if you feel it still needs more discussion. Cheers, Robert, ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Loïc Simon -- Loïc Simon ___ 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 -- Loïc Simon ___ 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
Re: [osg-users] OpenFlight, subsurfaces and PolygonOffset settings
Hi, On Thursday 23 April 2009 14:16, Robert Osfield wrote: As an another little aside, in testing on my ATI card I found that the original hack that was introduced into osg::PolygonOffset, to try and cope with implementations differences of glPolygonOffset between ATI and NVidia, now is doing more harm than good. Commenting out this hack so that glPolygonOffset values are passed identically produces the best results for me. I never got to try out the hack first hand before I got this ATI card, and I never got really definitive feedback on how the previous settings were working. It does seem appropriate to now revert this old hack though, looks like ATI cards/drivers are behaving much more similar to NVidia now which is a good thing. Hmm, I remember that thing. There were some subtle problems with a ATI card where this scaling factors were introduced. My personal feeling at that point in time was that this was a singular bug in the fglrx driver at that time. Solving that a temporary driver problem with a persistent scaling factor is IMO something we should rethink. I personally have resetted *all* these factors explicitly to 1 in *every* application I have some revision control access for - including flightgear. Also note that I do work on ATI gpu's on a regular basis without any problems with these factors equal to one and with huge z buffer problems with the defaults. Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 300 forum members
Hi, yeah this are interesting news. To hook up to the thread about 200 forum users from the last month, it would be interesting to know how much is the overlap between forum and mailing list users. Robert, could you still provide me with the list of the names (or emails) of all mailing list users (of course discreet)? I could then compare them to the forum database. This way we could find out how much of the users registered on the ML are using forum now. Cheers, art -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10720#10720 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 300 forum members
Art, if you are subscribed to the mailing list you can retrieve a list of subscribers. That's how I know the ML numbers. See osg-users Subscribers at http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Roland -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10721#10721 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Picking Problem PolytopeIntersector
Hi J-S -- You can dismiss tradition in this area, but I prefer to learn lessons instead. Generally speaking, polytope is what you want. It generally runs faster than a cull traversal, so performance is rarely an issue. Most users can tolerate a small delay anyway, but are very unforgiving of accuracy issues when it comes to picking. Polytope gives you more accuracy at greater distances, and also intersects with point and line primitives. If you choose to use line segment intersections for picking, don't come crying to me when you encounter inherent accuracy issues. :-) The bottom line is that the developer must know their app's requirements and must know how line segment and polytope intersection work, then make an appropriate choice. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] how to use the function of getParent(0)
Hi, Can you tell me the meaning of the node-getParent(0)?Why is it not node-getParent(1) or node-getParent(2)? Thank you. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10723#10723 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 300 forum members
Oh, in deed, hmm, I didn't knew that there exists such a capability. OK, I will then write a script which will check how much of the overlap there is between mailing list and forum users. As soon as I have the info, I let you all know. Roland, thank you again for pointing me into the right direction! cheers, art -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10725#10725 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] how to use the function of getParent(0)
Hi, In the most case, you node only get one parent, so getParent(0) is safe... You can also consider that if you node is in the scene graph, the parent(0) is valid. I you do getParent(i) with i0, you have to check the parent you get, if null or not ... Hope this help. Regards, Vincent 2009/4/23 Wangjian dmt198...@163.com Hi, Can you tell me the meaning of the node-getParent(0)?Why is it not node-getParent(1) or node-getParent(2)? Thank you. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10723#10723 ___ 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] [build] how do i generate project.exe file and .pdb file in specified folder
Hello Abhinav, but i want to directly get these files in bin instead of copying them. can yoyu uggest the code for it!! You don't need to change anything in CMake to get binaries in bin, just set CMAKE_INSTALL_PREFIX = (your OSG directory) and build the INSTALL project in the VS solution. That will put the binaries and DLLs in CMAKE_INSTALL_PREFIX\bin, libs in CMAKE_INSTALL_PREFIX\lib, and examples in CMAKE_INSTALL_PREFIX\share\OpenSceneGraph\bin We might have make some modifications to get the pdb files to follow though, currently they don't (they stay in the build subdirectories). J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenFlight, subsurfaces and PolygonOffset settings
-1,-1 has always worked for me in the typical case, and the OpenFlight setting is excessive for the typical case. In the typical case, your geometry is near the origin. In an atypical case, imagine two coplanar polygons with an arbitrary (non-axis aligned) orientation and a heterogeneous set of vertices, and located so far from the origin that single-precision IEEE float becomes an issue (xyz coords are in the 5-digit range, for example). In this case, you'd need a much larger scale,bias pair to resolve the coplanarity. If the magnitude of the xyz vertices is even larger, PolygonOffset becomes pretty much unusable. I saw the excessive values in the OpenFlight loader a long time ago, and I remember some discussion regarding this atypical case, which is actually quite common in OpenFlight terrain databases modeled in UTM coordinates. As a solution, I'd suggest adding an Option to control whether the importer handles subfaces using PolygonOffset (with -1,-1) or stencil. Maybe another Option to toggle use of the backwards-compatible -10,-40 setting? Or, more forward-looking, is there an elegant way to draw coplanar polys using a shader? Regarding the exporter, it currently writes subfaces if it detects use of PolygonOffset, so it would require some work to also look for stencil. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Thursday, April 23, 2009 6:17 AM To: OpenSceneGraph Users Subject: [osg-users] OpenFlight, subsurfaces and PolygonOffset settings Hi OpenFlight users, I had a support email this morning that led me to investigate problems with the way the OSG's present OpenFlight plugin handles subsurfaces. The particular problem observed was that a road that had been modelled in creator was clipping out vehicles on top of the road. I investigated and found out that the OpenFlight loaded was created used code from src/osgPlugins/OpenFlight/GeometryRecords.cpp: 386 static osg::ref_ptrosg::PolygonOffset polygonOffset = new osg::PolygonOffset(-10.0f, -40.0f); 387 stateset-setAttributeAndModes(polygonOffset.get(), osg::StateAttribute::ON); 388 389 static osg::ref_ptrosg::Depth depth = new osg::Depth(osg::Depth::LESS, 0.0, 1.0,false); 390 stateset-setAttribute(depth.get()); The use of static vars was a bit dodgy so I replaced these with variables stored in Document, but this is really just an side show to the real problem - the excessive PolygonOffset settings, a factor of -10, and units -40 is very aggressive a setting pushing out the subsurfaces way further than is either necessary or safe. Scaling these values back to -1, -1 resulted in my better results on the models I have without causing problems with the subsurfaces having z fighting. -1, -1 may be too conservative though. I'd like to get feedback from the community on what works for your OpenFlight models. I've checked in my changes into svn/trunk and the OSG-2.8 branch. It'd be useful to import OpenFlight models and convert to .osg or .ive and then update the OSG version + compile it, then redo the conversion, then compare the before and after results. As an another little aside, in testing on my ATI card I found that the original hack that was introduced into osg::PolygonOffset, to try and cope with implementations differences of glPolygonOffset between ATI and NVidia, now is doing more harm than good. Commenting out this hack so that glPolygonOffset values are passed identically produces the best results for me. I never got to try out the hack first hand before I got this ATI card, and I never got really definitive feedback on how the previous settings were working. It does seem appropriate to now revert this old hack though, looks like ATI cards/drivers are behaving much more similar to NVidia now which is a good thing. On all these counts I really like feedback. Was sub surfaces working OK for you prior to my changes today, or do todays changes improve things? 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] OpenFlight, subsurfaces and PolygonOffset settings
Hi Paul, I do wonder if the right way to solve subsurfaces is modify the underlying geometry so it shares the same vertices as the subsurface, and then insert any vertices of the underlying geometry into the subsurface geometry, then render with the depth test to pass when fragments are less than or equal to the existing fragment. Or perhaps even better just automatically cut out the underlying geometry. This obviously requires more work from the loader, but it would be far more robust in terms of handling large/small models. Robert. On Thu, Apr 23, 2009 at 2:55 PM, Paul Martz pma...@skew-matrix.com wrote: -1,-1 has always worked for me in the typical case, and the OpenFlight setting is excessive for the typical case. In the typical case, your geometry is near the origin. In an atypical case, imagine two coplanar polygons with an arbitrary (non-axis aligned) orientation and a heterogeneous set of vertices, and located so far from the origin that single-precision IEEE float becomes an issue (xyz coords are in the 5-digit range, for example). In this case, you'd need a much larger scale,bias pair to resolve the coplanarity. If the magnitude of the xyz vertices is even larger, PolygonOffset becomes pretty much unusable. I saw the excessive values in the OpenFlight loader a long time ago, and I remember some discussion regarding this atypical case, which is actually quite common in OpenFlight terrain databases modeled in UTM coordinates. As a solution, I'd suggest adding an Option to control whether the importer handles subfaces using PolygonOffset (with -1,-1) or stencil. Maybe another Option to toggle use of the backwards-compatible -10,-40 setting? Or, more forward-looking, is there an elegant way to draw coplanar polys using a shader? Regarding the exporter, it currently writes subfaces if it detects use of PolygonOffset, so it would require some work to also look for stencil. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Thursday, April 23, 2009 6:17 AM To: OpenSceneGraph Users Subject: [osg-users] OpenFlight, subsurfaces and PolygonOffset settings Hi OpenFlight users, I had a support email this morning that led me to investigate problems with the way the OSG's present OpenFlight plugin handles subsurfaces. The particular problem observed was that a road that had been modelled in creator was clipping out vehicles on top of the road. I investigated and found out that the OpenFlight loaded was created used code from src/osgPlugins/OpenFlight/GeometryRecords.cpp: 386 static osg::ref_ptrosg::PolygonOffset polygonOffset = new osg::PolygonOffset(-10.0f, -40.0f); 387 stateset-setAttributeAndModes(polygonOffset.get(), osg::StateAttribute::ON); 388 389 static osg::ref_ptrosg::Depth depth = new osg::Depth(osg::Depth::LESS, 0.0, 1.0,false); 390 stateset-setAttribute(depth.get()); The use of static vars was a bit dodgy so I replaced these with variables stored in Document, but this is really just an side show to the real problem - the excessive PolygonOffset settings, a factor of -10, and units -40 is very aggressive a setting pushing out the subsurfaces way further than is either necessary or safe. Scaling these values back to -1, -1 resulted in my better results on the models I have without causing problems with the subsurfaces having z fighting. -1, -1 may be too conservative though. I'd like to get feedback from the community on what works for your OpenFlight models. I've checked in my changes into svn/trunk and the OSG-2.8 branch. It'd be useful to import OpenFlight models and convert to .osg or .ive and then update the OSG version + compile it, then redo the conversion, then compare the before and after results. As an another little aside, in testing on my ATI card I found that the original hack that was introduced into osg::PolygonOffset, to try and cope with implementations differences of glPolygonOffset between ATI and NVidia, now is doing more harm than good. Commenting out this hack so that glPolygonOffset values are passed identically produces the best results for me. I never got to try out the hack first hand before I got this ATI card, and I never got really definitive feedback on how the previous settings were working. It does seem appropriate to now revert this old hack though, looks like ATI cards/drivers are behaving much more similar to NVidia now which is a good thing. On all these counts I really like feedback. Was sub surfaces working OK for you prior to my changes today, or do todays changes improve things? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org
Re: [osg-users] Picking Problem PolytopeIntersector
Hi Paul, Hi J-S -- You can dismiss tradition in this area, but I prefer to learn lessons instead. I was just joking :-) I've used GL_SELECTION too in the past, it was a good tool, but there are better ways now. Generally speaking, polytope is what you want. It generally runs faster than a cull traversal, so performance is rarely an issue. Most users can tolerate a small delay anyway, but are very unforgiving of accuracy issues when it comes to picking. Try using the polytope intersector with a polytope more than a few pixels wide (say 100x100 pixels, encompassing a large model with tens of thousands of polygons), and you'll see that it causes a severe frame drop. When all I want is to select the model, I don't need to know that the polytope encompassed all the model's polygons, so this part of PolytopeIntersector is useless and takes time for nothing. If the object occupies more than a few pixels, a line segment will pass through it without problems, and will only return a few intersections (for a manifold object) so it will work great. Of course, if you want a box intersection you don't have a choice. Polytope gives you more accuracy at greater distances, and also intersects with point and line primitives. If you choose to use line segment intersections for picking, don't come crying to me when you encounter inherent accuracy issues. :-) I have used it extensively, without any problems. Of course, again, if you want to pick points and lines, you can't, period. But for the rest, line segment is faster and is generally good enough. The bottom line is that the developer must know their app's requirements and must know how line segment and polytope intersection work, then make an appropriate choice. I totally agree. And hey, if you want a single code path for picking everything and doing both box and click selection, then sure, polytope is your man (err, class). But we have multiple paths for both cases, and it works great. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] how do i generate project.exe file and .pdb file in specified folder
Skylark wrote: Hello Abhinav, but i want to directly get these files in bin instead of copying them. can yoyu uggest the code for it!! You don't need to change anything in CMake to get binaries in bin, just set CMAKE_INSTALL_PREFIX = (your OSG directory) and build the INSTALL project in the VS solution. That will put the binaries and DLLs in CMAKE_INSTALL_PREFIX\bin, libs in CMAKE_INSTALL_PREFIX\lib, and examples in CMAKE_INSTALL_PREFIX\share\OpenSceneGraph\bin We might have make some modifications to get the pdb files to follow though, currently they don't (they stay in the build subdirectories). J-S -- __ Jean-Sebastien Guay http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum ok..will try this out..i tried the other way i.s setting the RUNTIME_OUTPUT_DIRECTORY but what its doing is that it creates a debug folder containing the executable files in the bin bolder. I want the files directly to come under the bin folder..hope yor solution works. will let you know tomorrow when i try it out at my office. Thx a lot.. :) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10731#10731 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Stereo with my own model
Dear all, I have a little problem with stereo display. When I run osgviewer with --stereo HORIZONTAL_SPLIT and the cow.osg, it looks great. But when I try to run osgviewer with my own model, it looks weird. It seems that the eye separation is too far (although I'm not sure). I try to change to eye position but it doesn't help. Could any of you know how to fix that problem? Here is the link for the model: http://cs.uiowa.edu/~tinguyen/stereoproblemwithmyownmodel.zip Thanks a bunch, Dat ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OpenSceneGraph-2.8.1 release candidate three tagged
Hi All, (from my blog at blog.openscenegraph.org) I’ve just tagged the 2.8.1 release candidate 3. The are a couple of fixes since rc2: * Fix to the subsurface handling in OpenFlight files * Removal of an old hack to PolygonOffset’s unit multiplier for ATI cards that is no longer required. * A couple of typo/spelling fixes. * Build fix for collada under OSX. * Addition of GL_RGB8 support to osg::image::computeNumComponts() * Fix to DatabasePager to prevent a crash that occurred when apps that did’t set the active contexts (note, osgViewer automatically sets the active contexts so was unaffected by this bug.) You can grab the source code from: source package : OpenSceneGraph-2.8.1-rc3.zip svn tag: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.1-rc3 OpenSceneGraph Please test with your apps and various build environments, and send in feedback of success or failures to osg-users mailing lists/forum so we can track convergence to the final 2.8.1 stable release. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Modifying SG based on viewpoint location
Hi all -- I'd like to see how members of the community are handling this fairly common OSG problem. Imagine that your app needs to modify the scene graph based on the viewpoint location, view frustum, distance to the viewpoint, etc. This information is not guaranteed to be available, accurate, or up-to-date until the _end_ of the update phase, right? Typically this info is only available from the CullVisitor. But it's too late to modify the scene graph during cull -- it's not thread safe. So, how does your app handle this situation? OSG itself needs to handle this situation in a few places. AutoTransform, Billboard, LOD, and screen-oriented text, just to name a few. I believe OSG handles this with a 1-frame latency with these classes (obtains the values during cull but updates the scene graph during update of the next frame), but haven't looked at the code in a long time. Another way to do this would be to query the viewpoint location / view frustum during update and modify the scene graph based on those values, even though those values could still change before the start of cull-draw. But I'm interested in hearing other ideas on how to handle this issue. Thanks in advance for any feedback. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.1 release candidate three tagged
Robert -- Typo. I think when you say subsurface in regards to OpenFlight, you actually mean subface. We're talking about coplanar polygons, not translucent light scattering, right? I'll switch over to the rc3 tag and try it out. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Thursday, April 23, 2009 8:41 AM To: OpenSceneGraph Users Subject: [osg-users] OpenSceneGraph-2.8.1 release candidate three tagged Hi All, (from my blog at blog.openscenegraph.org) I've just tagged the 2.8.1 release candidate 3. The are a couple of fixes since rc2: * Fix to the subsurface handling in OpenFlight files * Removal of an old hack to PolygonOffset's unit multiplier for ATI cards that is no longer required. * A couple of typo/spelling fixes. * Build fix for collada under OSX. * Addition of GL_RGB8 support to osg::image::computeNumComponts() * Fix to DatabasePager to prevent a crash that occurred when apps that did't set the active contexts (note, osgViewer automatically sets the active contexts so was unaffected by this bug.) You can grab the source code from: source package : OpenSceneGraph-2.8.1-rc3.zip svn tag: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8 .1-rc3 OpenSceneGraph Please test with your apps and various build environments, and send in feedback of success or failures to osg-users mailing lists/forum so we can track convergence to the final 2.8.1 stable release. Cheers, 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] Modifying SG based on viewpoint location
Hi Paul, On Thu, Apr 23, 2009 at 3:59 PM, Paul Martz pma...@skew-matrix.com wrote: Hi all -- I'd like to see how members of the community are handling this OSG itself needs to handle this situation in a few places. AutoTransform, Billboard, LOD, and screen-oriented text, just to name a few. I believe OSG handles this with a 1-frame latency with these classes (obtains the values during cull but updates the scene graph during update of the next frame), but haven't looked at the code in a long time. For clarity: Billboard creates matrices on the fly in the cull traversal, so the billboard itself never changes with viewpoint. AutoTransform does update it's parameters based in the viewpoint. While the changes are not ones that will break a multi-threaded viewer, the state of the AutoTransform is only valid for one view so while not crashes will occur visual artefact's will. LOD/PagedLOD don't have any state that varies with viewpoint, their settings get read and this effects the cull traversal but the cull traversal don't affect these nodes in any way. (Note PagedLOD's requests get made in by the CullVisitor, but the eventual changes are made by during the update phase. With the screen aligned text, the internal vertices get updated in the cull traversal, but the this data is multi-buffered to avoid threading issues. Another way to do this would be to query the viewpoint location / view frustum during update and modify the scene graph based on those values, even though those values could still change before the start of cull-draw. But I'm interested in hearing other ideas on how to handle this issue. Thanks in advance for any feedback. One can do custom update traversals that use the view frustum. Or multi-buffer data in the scene graph and do the updates in the cull traversal. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DBPager continuously reloading tiles
Robert,
Here's a simple viewer I wrote that does non-continuous render and exhibits
the problem. You can just run it like the osgviewer application, passing in
the path to a database on the command line. I have also included a stats
handler that will cause the app to switch to continuous render while it is
onscreen. I have only tested this with osgEarth, so I don't know if the
problem manifests itself with VPB databases. The reloading problem wouldn't
manifest itself when I ran an animation path because playing back the
animation essentially caused continuous rendering, but if you load an earth
database and move around a bit in the scene you should see the behavior. I
can get it to happen pretty reliably when I load the yahoo satellite images
using osgEarth, then quickly zoom in on an area that I have cached. When I
stop zooming and zoom back out or pan around, the tiles start reloading. I
had a co-worker try this out and he was able to duplicate the problem pretty
quickly, so hopefully it will happen easily for you too.
Evan
On Thu, Apr 23, 2009 at 2:14 AM, Robert Osfield robert.osfi...@gmail.comwrote:
Hi Evan,
On Wed, Apr 22, 2009 at 10:05 PM, Evan Andersen andersen.e...@gmail.com
wrote:
Ryan,
Thank you for the suggestion. When I call
setTargetMaximumNumberOfPagedLOD(0) on the database pager, as you
suggested
and then set the expiry delay to DBL_MAX and the expiry frames to 10, as
Jason Suggested the problem seems to go away. I'm not really sure why
this
works. It seems like the default behavior should work in my usage case,
but
at least it is working now.
Could you modify one of the OSG examples to reproduce your application
usage style and use this to recreate the problem. I could then have a
look at why the new (and now default) expiry scheme is not working
correctly. As you say it should work, at present I don't know why the
old scheme is able to work.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
#include osgViewer/viewer
#include osgDB/ReadFile
#include osgViewer/ViewerEventHandlers
#include osgGA/TrackballManipulator
#include osgGA/FlightManipulator
#include osgGA/DriveManipulator
#include osgGA/KeySwitchMatrixManipulator
#include osgGA/StateSetManipulator
#include osgGA/TerrainManipulator
#include OpenThreads/Thread
#include cfloat
// The stats handler has to be modified to request continuous updates
// when stats are being displayed
class MyStats : public osgViewer::StatsHandler
{
protected:
~MyStats() {}
int keyPresses;
public:
MyStats() : osgViewer::StatsHandler(), keyPresses(0) {}
virtual bool handle(const osgGA::GUIEventAdapter ea,
osgGA::GUIActionAdapter aa)
{
if( ea.getEventType() != osgGA::GUIEventAdapter::KEYDOWN )
return false;
int key = ea.getKey();
if(key == -1)
return false;
if(key == 's') {
if(keyPresses 4)
{
aa.requestContinuousUpdate(true);
keyPresses++;
}
else
{
keyPresses = 0;
aa.requestContinuousUpdate(false);
aa.requestRedraw();
}
return osgViewer::StatsHandler::handle(ea, aa);
}
return false;
}
};
class MyViewer : public osgViewer::Viewer
{
public:
MyViewer() : osgViewer::Viewer(), needsRender(true),
continuousUpdate(false) {}
MyViewer(osg::ArgumentParser arguments) : osgViewer::Viewer(arguments),
needsRender(true), continuousUpdate(false) {}
virtual void requestRedraw()
{
needsRender = true;
}
virtual void requestContinuousUpdate(bool needed=true)
{
continuousUpdate = needed;
}
virtual int run()
{
// From osgViewer::Viewer
if (!getCameraManipulator() getCamera()-getAllowEventFocus())
{
setCameraManipulator(new osgGA::TrackballManipulator);
}
setReleaseContextAtEndOfFrameHint(false);
// From osgViewer::ViewerBase
if (!isRealized())
{
realize();
}
/***/
// This block of code seems to fix the reloading problems
//getDatabasePager()-setTargetMaximumNumberOfPageLOD(0);
//getDatabasePager()-setExpiryDelay(DBL_MAX);
//getDatabasePager()-setExpiryFrames(10);
/**/
while (!done())
{
frame();
// Sleep for 10 miliseconds. This is just an arbitrary value, but
we'd
// do something intelligent to make the loop run at a desired rate.
OpenThreads::Thread::microSleep(1);
}
return 0;
}
virtual void frame(double
Re: [osg-users] [osgPlugins] collada: use of bind_vertex_input
Martin Scheffler wrote: Hi, I export from Max using the feeling exporter 3.05b (c gives the same results). I have a diffuse map and an ambient map in my model. When importing the collada file into osg, the maps are not shown. It seems that I have to modify [code]instance_material symbol="r8.3.007_1" target="#r8.3.007-material"/[/code] to [code] instance_material symbol="r8.3.007_1" target="#r8.3.007-material" bind_vertex_input semantic="CHANNEL2" input_semantic="TEXCOORD" input_set="2"/ bind_vertex_input semantic="CHANNEL1" input_semantic="TEXCOORD" input_set="1"/ /instance_material [/code] Then everything works as expected. Is this faulty behavior of the exporter? The collada 1.4 spec says: [quote] The bind_vertex_input element binds geometry vertex streams (identified as input elements within geometry elements) to material effect vertex stream semantics. Although applications commonly perform automatic binding of vertex streams with identical semantic identifiers, there are frequently mismatches in a semantic identifier’s meaning. Use bind_vertex_input to remove these ambiguities [/quote] So maybe the exporter could detect texture coordinate sets automatically? Thanks, Martin[/quote] Martin, When I added the support for bind_vertex_input I am afraid I was quite strict in requiring it to be present. I admit if there if there was only one vertex stream with a CHANNEL1 or a CHANNEL2 semantic available then probably the binding should be automatic. However, in this case it looks like the exporter is still at fault as the the streams appear to have been given a TEXCOORD semantic, and because there are two of them then a bind_vertex_input is definitely needed to differentiate between the input sets. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.1 release candidate three tagged
On Thu, Apr 23, 2009 at 4:04 PM, Paul Martz pma...@skew-matrix.com wrote: Robert -- Typo. I think when you say subsurface in regards to OpenFlight, you actually mean subface. We're talking about coplanar polygons, not translucent light scattering, right? Thanks for the note, I've ammened the blog and NEWS items to read subface. I'll switch over to the rc3 tag and try it out. Thanks. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DBPager continuously reloading tiles
Though I do not believe this problem to be limited to a particular application, we are seeing this problem with our terrapage databases produced through Terra Vista. I'll try and see if our database group can produce a dataset that exhibits this problem and can be released to the community with no problems. Ryan H. Kawicki The Boeing Company Training Systems Services Software Engineer Phone: (314) 777-1654 From: Evan Andersen [mailto:andersen.e...@gmail.com] Sent: Thursday, April 23, 2009 10:09 AM To: OpenSceneGraph Users Subject: Re: [osg-users] DBPager continuously reloading tiles Robert, Here's a simple viewer I wrote that does non-continuous render and exhibits the problem. You can just run it like the osgviewer application, passing in the path to a database on the command line. I have also included a stats handler that will cause the app to switch to continuous render while it is onscreen. I have only tested this with osgEarth, so I don't know if the problem manifests itself with VPB databases. The reloading problem wouldn't manifest itself when I ran an animation path because playing back the animation essentially caused continuous rendering, but if you load an earth database and move around a bit in the scene you should see the behavior. I can get it to happen pretty reliably when I load the yahoo satellite images using osgEarth, then quickly zoom in on an area that I have cached. When I stop zooming and zoom back out or pan around, the tiles start reloading. I had a co-worker try this out and he was able to duplicate the problem pretty quickly, so hopefully it will happen easily for you too. Evan On Thu, Apr 23, 2009 at 2:14 AM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Evan, On Wed, Apr 22, 2009 at 10:05 PM, Evan Andersen andersen.e...@gmail.com wrote: Ryan, Thank you for the suggestion. When I call setTargetMaximumNumberOfPagedLOD(0) on the database pager, as you suggested and then set the expiry delay to DBL_MAX and the expiry frames to 10, as Jason Suggested the problem seems to go away. I'm not really sure why this works. It seems like the default behavior should work in my usage case, but at least it is working now. Could you modify one of the OSG examples to reproduce your application usage style and use this to recreate the problem. I could then have a look at why the new (and now default) expiry scheme is not working correctly. As you say it should work, at present I don't know why the old scheme is able to work. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DBPager continuously reloading tiles
Thanks Evan, with your example I'm able to see the problem when browsing http://www.openscenegraph.org/data/earth_bayarea/earth.ive. I'll now dig into the DatabasePager to see what is up. On Thu, Apr 23, 2009 at 4:08 PM, Evan Andersen andersen.e...@gmail.com wrote: Robert, Here's a simple viewer I wrote that does non-continuous render and exhibits the problem. You can just run it like the osgviewer application, passing in the path to a database on the command line. I have also included a stats handler that will cause the app to switch to continuous render while it is onscreen. I have only tested this with osgEarth, so I don't know if the problem manifests itself with VPB databases. The reloading problem wouldn't manifest itself when I ran an animation path because playing back the animation essentially caused continuous rendering, but if you load an earth database and move around a bit in the scene you should see the behavior. I can get it to happen pretty reliably when I load the yahoo satellite images using osgEarth, then quickly zoom in on an area that I have cached. When I stop zooming and zoom back out or pan around, the tiles start reloading. I had a co-worker try this out and he was able to duplicate the problem pretty quickly, so hopefully it will happen easily for you too. Evan On Thu, Apr 23, 2009 at 2:14 AM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Evan, On Wed, Apr 22, 2009 at 10:05 PM, Evan Andersen andersen.e...@gmail.com wrote: Ryan, Thank you for the suggestion. When I call setTargetMaximumNumberOfPagedLOD(0) on the database pager, as you suggested and then set the expiry delay to DBL_MAX and the expiry frames to 10, as Jason Suggested the problem seems to go away. I'm not really sure why this works. It seems like the default behavior should work in my usage case, but at least it is working now. Could you modify one of the OSG examples to reproduce your application usage style and use this to recreate the problem. I could then have a look at why the new (and now default) expiry scheme is not working correctly. As you say it should work, at present I don't know why the old scheme is able to work. 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.1 release candidate three tagged
Thanks. Sorry I'm slow--I have built rc2 on Intel Mac, win32, and Linux 64. I have tried it in my app on win32. I guess instead of trying what I have on the other platforms, I should get the new one. I've had a lot going on, so haven't been able to give quick responses. andy -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Thursday, April 23, 2009 10:41 AM To: OpenSceneGraph Users Subject: [osg-users] OpenSceneGraph-2.8.1 release candidate three tagged Hi All, (from my blog at blog.openscenegraph.org) I've just tagged the 2.8.1 release candidate 3. The are a couple of fixes since rc2: * Fix to the subsurface handling in OpenFlight files * Removal of an old hack to PolygonOffset's unit multiplier for ATI cards that is no longer required. * A couple of typo/spelling fixes. * Build fix for collada under OSX. * Addition of GL_RGB8 support to osg::image::computeNumComponts() * Fix to DatabasePager to prevent a crash that occurred when apps that did't set the active contexts (note, osgViewer automatically sets the active contexts so was unaffected by this bug.) You can grab the source code from: source package : OpenSceneGraph-2.8.1-rc3.zip svn tag: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.1-rc3 OpenSceneGraph Please test with your apps and various build environments, and send in feedback of success or failures to osg-users mailing lists/forum so we can track convergence to the final 2.8.1 stable release. Cheers, 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] Modifying SG based on viewpoint location
Paul Martz wrote on Thursday, April 23, 2009 9:59 AM: Hi all -- I'd like to see how members of the community are handling this fairly common OSG problem. Imagine that your app needs to modify the scene graph based on the viewpoint location, view frustum, distance to the viewpoint, etc. This information is not guaranteed to be available, accurate, or up-to-date until the _end_ of the update phase, right? Typically this info is only available from the CullVisitor. But it's too late to modify the scene graph during cull -- it's not thread safe. So, how does your app handle this situation? OSG itself needs to handle this situation in a few places. AutoTransform, Billboard, LOD, and screen-oriented text, just to name a few. I believe OSG handles this with a 1-frame latency with these classes (obtains the values during cull but updates the scene graph during update of the next frame), but haven't looked at the code in a long time. Another way to do this would be to query the viewpoint location / view frustum during update and modify the scene graph based on those values, even though those values could still change before the start of cull-draw. But I'm interested in hearing other ideas on how to handle this issue. Thanks in advance for any feedback. I used a custom cull visitor (which I needed for other reasons, too) to capture the viewpoint data and do the necessary scenegraph modifications. At the time, I also needed more than the float precision given by getEyepoint(), and I was trying to minimize the effects on code that used my library; otherwise, I think I would have gone with a modified update visitor that tracked the current eyepoint(s). -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] how do i generate project.exe file and .pdb file in specified folder
It depends if you want them put there at INSTALL time or at BUILD time. CMAKE_INSTALL_PREFIX set the installation path If you want the dll and ex in bin at BUILD time, as I' ve already suggested, set RUNTIME_OUTPUT_DIRECTORY in bin AND put ../ in front of your name or prefix property as I' ve already suggested. the ../ hack is also used in osg CMake files, look at OsgMacroUtils.cmake, in particular line 263 of macro SETUP_EXE This is the way the target are currently put into bin subfolder of the build dir. Regards Luigi Abhinav Dubey ha scritto: Skylark wrote: Hello Abhinav, but i want to directly get these files in bin instead of copying them. can yoyu uggest the code for it!! You don't need to change anything in CMake to get binaries in bin, just set CMAKE_INSTALL_PREFIX = (your OSG directory) and build the INSTALL project in the VS solution. That will put the binaries and DLLs in CMAKE_INSTALL_PREFIX\bin, libs in CMAKE_INSTALL_PREFIX\lib, and examples in CMAKE_INSTALL_PREFIX\share\OpenSceneGraph\bin We might have make some modifications to get the pdb files to follow though, currently they don't (they stay in the build subdirectories). J-S -- __ Jean-Sebastien Guay http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum ok..will try this out..i tried the other way i.s setting the RUNTIME_OUTPUT_DIRECTORY but what its doing is that it creates a debug folder containing the executable files in the bin bolder. I want the files directly to come under the bin folder..hope yor solution works. will let you know tomorrow when i try it out at my office. Thx a lot.. :) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10731#10731 ___ 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] Modifying SG based on viewpoint location
Hi, On Thursday 23 April 2009 16:59, Paul Martz wrote: But I'm interested in hearing other ideas on how to handle this issue. Thanks in advance for any feedback. That depends on what you need to do 'modify' in the scenegraph. In certain situations, like dynamic model view transform updates for a subraph (like in your autotransform/bilborad example), the Node::_cullCallback can apply some dynamic changes to the CullVisitor that is used to call the Cull callback. Also applying state attributes or modes as part of a dynamic created StateSet can be pushed/poped on the fly to the CullVisitor without disturbing the scenegraph as a whole. But keep in mind that you need seperate StateSets/StateAttributes for each CullVisitor. Either cache them per CullVisitor pointer or just allocate them on each frame if you do not need too much of them per frame. Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Modifying SG based on viewpoint location
Paul Martz wrote: Hi all -- I'd like to see how members of the community are handling this fairly common OSG problem. Imagine that your app needs to modify the scene graph I guess the important question is, what kind of modifications exactly? -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DBPager continuously reloading tiles
On Thu, Apr 23, 2009 at 4:32 PM, Robert Osfield
robert.osfi...@gmail.com wrote:
Thanks Evan, with your example I'm able to see the problem when
browsing http://www.openscenegraph.org/data/earth_bayarea/earth.ive.
I'll now dig into the DatabasePager to see what is up.
The culprit looks to be the following (normally valid) code in
DatabasePager::capped_removeExpiredSubgraphs(const osg::FrameStamp
frameStamp):
int delta = frameStamp.getFrameNumber() -
plod-getFrameNumberOfLastTraversal();
if (delta1)
{
if (_releaseDelay!=DBL_MAX)
{
plod-releaseGLObjects();
osg::notify(osg::NOTICE)DatabasePager::removeExpiredSubgraphs(),
releasing gl objectsstd::endl;
}
_inactivePagedLODList.push_back(plod);
itr = _activePagedLODList.erase(itr);
}
The only reason why this is a problem in this particular usage case is
that you have a viewer that is continue to increment the frame count
so the frameStamp.getFrameNumber() keeps getting incremented, but
since the scene isn't being rendering the
plod-getFrameNumberOfLastTraversal() is not updating so the frame
delta becomes 1 and the PagedLOD gets assigned as expired.
The code in DatabasePager is correct for how the pager + PagedLOD were
designed to be used. The problem is that code is now being used in
way that is wasn't originally intended. Updating the frame count and
not rendering is the problem. Not updating the frame count and not
rendering would work, as does updating the frame count and rendering.
The next question is how to either get the viewer or DatabasePager to
do what is desired here - i.e. lazy updating of the graphics. It
might be possible to tell the DatabasePager that rendering of frame is
switched off for that frame and for it handle this case. Tweaking the
application code so that it doesn't do an viewer.advance() until a new
frame is actually required.
It's also worth noting that there is a potential bug in the supplied
viewer that does lazy update - it only will ever work if the pager
isn't doing precompile, if it does do precompile then you have to
render frames to enable the pager to get it's GL objects compiled,
otherwise the pager will just go to sleep waiting for the objects to
be compiled by the rendering thread(s), then you'd have stale mate.
A possible way to solve this would be to check the DatabasePager to
see if it has any database requests that are still active, and keeping
rendering while it does.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DBPager continuously reloading tiles
Robert,
Things seem to work fine if I only call advance() when a render is done.
Off the top of your head, can you think of any problems that might be caused
by not doing an advance for every iteration of the event and update
traversals? Would it be better to advance the reference time at each
iteration and only advance the frame number when a render is performed?
Also in regards to the potential problems with pre-compiling objects, I
assume that I can just call requiresCompileGLObjects on the pager in each
iteration of the main loop and then do a render if it returns true. My main
concern is doing unnecessary renders while the pager is downloading tiles
from an internet source.
Thanks for all your help.
Evan
On Thu, Apr 23, 2009 at 10:16 AM, Robert Osfield
robert.osfi...@gmail.comwrote:
On Thu, Apr 23, 2009 at 4:32 PM, Robert Osfield
robert.osfi...@gmail.com wrote:
Thanks Evan, with your example I'm able to see the problem when
browsing http://www.openscenegraph.org/data/earth_bayarea/earth.ive.
I'll now dig into the DatabasePager to see what is up.
The culprit looks to be the following (normally valid) code in
DatabasePager::capped_removeExpiredSubgraphs(const osg::FrameStamp
frameStamp):
int delta = frameStamp.getFrameNumber() -
plod-getFrameNumberOfLastTraversal();
if (delta1)
{
if (_releaseDelay!=DBL_MAX)
{
plod-releaseGLObjects();
osg::notify(osg::NOTICE)DatabasePager::removeExpiredSubgraphs(),
releasing gl objectsstd::endl;
}
_inactivePagedLODList.push_back(plod);
itr = _activePagedLODList.erase(itr);
}
The only reason why this is a problem in this particular usage case is
that you have a viewer that is continue to increment the frame count
so the frameStamp.getFrameNumber() keeps getting incremented, but
since the scene isn't being rendering the
plod-getFrameNumberOfLastTraversal() is not updating so the frame
delta becomes 1 and the PagedLOD gets assigned as expired.
The code in DatabasePager is correct for how the pager + PagedLOD were
designed to be used. The problem is that code is now being used in
way that is wasn't originally intended. Updating the frame count and
not rendering is the problem. Not updating the frame count and not
rendering would work, as does updating the frame count and rendering.
The next question is how to either get the viewer or DatabasePager to
do what is desired here - i.e. lazy updating of the graphics. It
might be possible to tell the DatabasePager that rendering of frame is
switched off for that frame and for it handle this case. Tweaking the
application code so that it doesn't do an viewer.advance() until a new
frame is actually required.
It's also worth noting that there is a potential bug in the supplied
viewer that does lazy update - it only will ever work if the pager
isn't doing precompile, if it does do precompile then you have to
render frames to enable the pager to get it's GL objects compiled,
otherwise the pager will just go to sleep waiting for the objects to
be compiled by the rendering thread(s), then you'd have stale mate.
A possible way to solve this would be to check the DatabasePager to
see if it has any database requests that are still active, and keeping
rendering while it does.
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] DBPager continuously reloading tiles
HI Evan et. al,
On Thu, Apr 23, 2009 at 5:16 PM, Robert Osfield
robert.osfi...@gmail.com wrote:
Tweaking the
application code so that it doesn't do an viewer.advance() until a new
frame is actually required.
I've now tried this and got the viewer supplied by Evan to do lazy
updating of the graphics to work without the paging out problem. I
simply refactored the custom frame() a little so that it just does the
eventTraversal() when no rendering so the frame count never goes up,
it only does a full frame when there is need to. The code is below:
It's also worth noting that there is a potential bug in the supplied
viewer that does lazy update - it only will ever work if the pager
isn't doing precompile, if it does do precompile then you have to
render frames to enable the pager to get it's GL objects compiled,
otherwise the pager will just go to sleep waiting for the objects to
be compiled by the rendering thread(s), then you'd have stale mate.
A possible way to solve this would be to check the DatabasePager to
see if it has any database requests that are still active, and keeping
rendering while it does.
This was simple to solve, I simply added an additional check of
getDatabasePager()-getRequestsInProgress() in the test whether to
render the frame or not. I've added this into my version of Evan's
test viewer, code is part of the code fragment at the bottom of this
email.
Now I have a viewer level solution for this problem, is a
DatabasePager level solution required? Added such supported to
DatabasePager is possible by it'd complicate it, and it would change
it's ABI so isn't something we can role into the 2.8.x series without
breaking binary compatibility. Given this issue isn't actual a bug in
the DatabasePager, but an issue with it being used out of it's
designed usage I thinking it's probably appropriate to view any
expansion of the usage models it's support as an added feature and
therefore something would go into svn/trunk + 2.9.x.
I have some other thoughts too on this issue that I'll leave for a
follow up email.
Robert.
-- Custom frame that works with lazy updating of the frame.
virtual void frame(double simulationTime=USE_REFERENCE_TIME)
{
if (_done) return;
if (_firstFrame)
{
viewerInit();
if (!isRealized())
{
realize();
}
_firstFrame = false;
}
if (!needsRender !continuousUpdate)
{
eventTraversal();
// If the database pager is going to update the scene the
render flag is
// set so that the updates show up
if(getDatabasePager()-requiresUpdateSceneGraph() ||
getDatabasePager()-getRequestsInProgress())
needsRender = true;
}
if(needsRender || continuousUpdate)
{
advance(simulationTime);
eventTraversal();
// If the database pager is going to update the scene the
render flag is
// set so that the updates show up
if(getDatabasePager()-requiresUpdateSceneGraph() ||
getDatabasePager()-getRequestsInProgress())
needsRender = true;
updateTraversal();
renderingTraversals();
needsRender = false;
}
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DBPager continuously reloading tiles
On Thu, Apr 23, 2009 at 5:51 PM, Evan Andersen andersen.e...@gmail.com wrote: Things seem to work fine if I only call advance() when a render is done. Off the top of your head, can you think of any problems that might be caused by not doing an advance for every iteration of the event and update traversals? Would it be better to advance the reference time at each iteration and only advance the frame number when a render is performed? Not calling advance should be fine. See the email I just sent. Also in regards to the potential problems with pre-compiling objects, I assume that I can just call requiresCompileGLObjects on the pager in each iteration of the main loop and then do a render if it returns true. My main concern is doing unnecessary renders while the pager is downloading tiles from an internet source. Problem solved, see the email just sent. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DBPager continuously reloading tiles
Hi All, Out of curiosity I did some power tests viewing a paged database with different viewer frame updating configs. Power is measure at the wall using so it's the complete machine. T 103W Compute at idle 103W Lazy frame rendering (based on modified version of Evan's viewer) 125W Continuous framer rate (standard osgviewer) with vsync on (60fps) 156W Continuous framer rate (standard osgviewer) with vsync off (300 - 2000fps) The Lazy frame rendering does bump up it's power consumption when the scene is updating or the view is moving so it's only the time when the view is still that the power consumption goes down, so actual power usage will vary with user interaction. So... lazy frame updates/rendering is good for the power consumption (~20% better) , good for keeping lower computer temperatures and noise, and should be better component life to boot. Makes me wonder if it's not time to add support directly into osgViewer for lazy frame updates/rendering. On the same track, perhaps we should also consider artificially restricting frame rate to prevent running apps running at full pelt due to vsync being off. The later is possible more important under Linux as I've found ATI, Nvidia and Intel drivers neglect to enable vysnc by default. Getting this fixed is another battle though... Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DBPager continuously reloading tiles
Hi Robert, On the same track, perhaps we should also consider artificially restricting frame rate to prevent running apps running at full pelt due to vsync being off. The later is possible more important under Linux as I've found ATI, Nvidia and Intel drivers neglect to enable vysnc by default. Getting this fixed is another battle though... As an additional data point, on Windows, the NVidia drivers ship with vsync enabled by default, but ATI ships with it disabled. This always bugs me when setting up a new machine. If you want to add a feature for capping the frame rate, then I'd like to suggest having a key, a command-line arg and an environment variable to enable/disable this, and perhaps a way of setting the target frame rate. Personally I prefer letting users have the choice, through the vsync setting in their driver, whether they want to cap the frame rate or not. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.1 release candidate three tagged
Just tested the following with my current software project and encountered no issues: 2.8.1 rc3 on WinXP using VS8 with Quadro 1500M svn head on WinXP using VS8 with Quadro 1500M svn head on Mac OS X using makefiles/gcc with GeForce 8800 Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Andy Skinner Sent: Thursday, April 23, 2009 9:55 AM To: OpenSceneGraph Users Subject: Re: [osg-users] OpenSceneGraph-2.8.1 release candidate three tagged Thanks. Sorry I'm slow--I have built rc2 on Intel Mac, win32, and Linux 64. I have tried it in my app on win32. I guess instead of trying what I have on the other platforms, I should get the new one. I've had a lot going on, so haven't been able to give quick responses. andy -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Thursday, April 23, 2009 10:41 AM To: OpenSceneGraph Users Subject: [osg-users] OpenSceneGraph-2.8.1 release candidate three tagged Hi All, (from my blog at blog.openscenegraph.org) I've just tagged the 2.8.1 release candidate 3. The are a couple of fixes since rc2: * Fix to the subsurface handling in OpenFlight files * Removal of an old hack to PolygonOffset's unit multiplier for ATI cards that is no longer required. * A couple of typo/spelling fixes. * Build fix for collada under OSX. * Addition of GL_RGB8 support to osg::image::computeNumComponts() * Fix to DatabasePager to prevent a crash that occurred when apps that did't set the active contexts (note, osgViewer automatically sets the active contexts so was unaffected by this bug.) You can grab the source code from: source package : OpenSceneGraph-2.8.1-rc3.zip svn tag: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8 .1-rc3 OpenSceneGraph Please test with your apps and various build environments, and send in feedback of success or failures to osg-users mailing lists/forum so we can track convergence to the final 2.8.1 stable release. Cheers, 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Modifying SG based on viewpoint location
Yeah, what does modify mean, that's the question. I have a client who is modifying the scene graph in a number of ways during the cull traversal and is therefore only able to run SingleThreaded. I'm still digging in to find out exactly what it is they are doing that isn't thread safe (even the client isn't exactly sure, or isn't able to spell it out precisely for some reason), but it seems to be some type of viewpoint-dependent LOD-like modification. In the meantime, I wanted to poll the community for thread-safe alternatives. So I want to thank all that have replied, especially Robert for telling me how those OSG classes handle this requirement. At some point, I'll summarize all this into some kind of document or posting, so that people don't go down the non-thread safe path in the future. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Chris 'Xenon' Hanson Sent: Thursday, April 23, 2009 10:15 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Modifying SG based on viewpoint location Paul Martz wrote: Hi all -- I'd like to see how members of the community are handling this fairly common OSG problem. Imagine that your app needs to modify the scene graph I guess the important question is, what kind of modifications exactly? -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ 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] osgEarth 1.1 Released
Hi all, Cross posting from the osgEarth forums. We've just tagged the osgEarth 1.1 release. Changes in this release include: *Enhanced WCS driver with support for ArcGIS Server *Added GDAL dependency to osgEarth to support new SpatialReference classes *Added new GeoExtent class *Added a memory cache to TileSources to increase performance when performing compositing *Added ability to use Mercator data in a geodetic globe. *All geocentric globes now use a global-geodetic profile now that osgEarth can mix Mercator and Geodetic imagery. *Added ElevationManager class to provide support for multiple heightfield sources *Bug fixes and performance enhancements You can find the tag here: http://wush.net/svn/osgearth/tags/osgearth_1.1_T2009-04-23/ Enjoy! Jason ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Modifying SG based on viewpoint location
Related to this question I have two cases where I want to do something similar. 1. HUD across multiple slave views I have a view that uses multiple slave camera's with a projection offset (or viewmatrix offset). Simply adding a HUD camera like in the osghud example will result in two similar HUDs on both views. I want to offset the projection matrix in the osg::Camera based on the offset of top level camera in the view. 2. Projected grid with multiple views For rendering of sea we use the projected grid method, where a regular screenspace grid is projected onto a plane based on the camera projection matrix. When using multiple views each view should update the grid projection based on the current camera projection and view matrix. Any suggestions? kind regards Roland Smeenk -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10760#10760 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Modifying SG based on viewpoint location
The HUD issue shouldn't require modifying the scene graph at all. Create one HUD scene graph with the entire HUD in it. Parent it to two HUD cameras with two different views. One Camera has its view matrix set to view the left half of the HUD, and the other is similarly configured to view the right half. (I guess if you are not lighting, you could do this in the projection matrix and get the same results. But conceptually this is a view matrix issue, and the projections are the same.) Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Roland Smeenk Sent: Thursday, April 23, 2009 3:09 PM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Modifying SG based on viewpoint location Related to this question I have two cases where I want to do something similar. 1. HUD across multiple slave views I have a view that uses multiple slave camera's with a projection offset (or viewmatrix offset). Simply adding a HUD camera like in the osghud example will result in two similar HUDs on both views. I want to offset the projection matrix in the osg::Camera based on the offset of top level camera in the view. 2. Projected grid with multiple views For rendering of sea we use the projected grid method, where a regular screenspace grid is projected onto a plane based on the camera projection matrix. When using multiple views each view should update the grid projection based on the current camera projection and view matrix. Any suggestions? kind regards Roland Smeenk -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10760#10760 ___ 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] osgEarth 1.1 Released
Will one of you be at SIGGRAPH this year? The OSG BOF is Wednesday afternoon, and it'd be great to get a demo of osgEarth (if you can get to the internet). I'll post a call for participation as SIGGRAPH approaches. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ +1 303 859 9466 _ From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jason Beverage Sent: Thursday, April 23, 2009 2:46 PM To: osg users Subject: [osg-users] osgEarth 1.1 Released Hi all, Cross posting from the osgEarth forums. We've just tagged the osgEarth 1.1 release. Changes in this release include: *Enhanced WCS driver with support for ArcGIS Server *Added GDAL dependency to osgEarth to support new SpatialReference classes *Added new GeoExtent class *Added a memory cache to TileSources to increase performance when performing compositing *Added ability to use Mercator data in a geodetic globe. *All geocentric globes now use a global-geodetic profile now that osgEarth can mix Mercator and Geodetic imagery. *Added ElevationManager class to provide support for multiple heightfield sources *Bug fixes and performance enhancements You can find the tag here: http://wush.net/svn/osgearth/tags/osgearth_1.1_T2009-04-23/ Enjoy! Jason ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Modifying SG based on viewpoint location
Paul Martz wrote:
The HUD issue shouldn't require modifying the scene graph at all. Create one
HUD scene graph with the entire HUD in it. Parent it to two HUD cameras with
two different views. One Camera has its view matrix set to view the left
half of the HUD, and the other is similarly configured to view the right
half.
Ok, that's a possible solution, but this creates a specific scenegraph for a
specific number of slave cameras.
A more flexible and dirty solution I came up with a couple of minutes ago was
this:
-Add an empty group node above the HUD camera
-Add a CullCallback with a reference to the HUD camera
In the CullCallback do this
Code:
class CullCallback : public osg::NodeCallback
{
osg::ref_ptrosg::Camera _camera;
public:
CullCallback(osg::Camera* camera) :
_camera(camera)
{
}
virtual void operator()(osg::Node* node, osg::NodeVisitor* nv)
{
osgUtil::CullVisitor* cv =
dynamic_castosgUtil::CullVisitor*(nv);
if (cv)
{
osg::Camera* cam = cv-getCurrentCamera();
osg::View::Slave* slave =
cam-getView()-findSlaveForCamera(cam);
mat.makeOrtho2D(-1,1,-1,1);
if (slave)
{
mat *= slave-_projectionOffset;
}
_camera-setProjectionMatrix(mat);
}
traverse(node,nv);
}
};
--
Roland
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=10763#10763
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Picking Problem PolytopeIntersector
Paul Martz wrote: You _can_ use a line segment for mouse click picking, but in a perspective view, polytope is really better suited for this task. Also, polytope will pick point and line primitives, while line segment intersection will miss them. Unless you're dealing with points/lines, I'm failing to see why a polytope is really better suited for this task. I also fail to see why accuracy would be a problem when using line segments (unless you're trying to pick something one or two pixels wide, which doesn't happen often in my experience). Can you elaborate a bit (or point me at something that explains it)? --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSG .NET demo using C++/CLI
Hi, I've downloaded OSG2.8 and any trying heiscong osgNetDemo, mainly because I found an issue with C# as it does not expose the 'inheritedWindowData' so C# can't have the rendering window embedded in the program as osgNetDemo does. All that beside. In running osgNetDemo it throws an exception, but I don't know why. I have a lot of development in C#, so would like to use C# or C++.Net/cli which ever works and allows me to embed a graphics render windows in my program as heiscong's demo should do. I'm happy about learning C++/CLi but don't want to learn C++ for 1 or 2 programs in this project. regards Ernest Abbott ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] how do i generate project.exe file and .pdb file in specified folder
Skylark wrote: Hello Abhinav, but i want to directly get these files in bin instead of copying them. can yoyu uggest the code for it!! You don't need to change anything in CMake to get binaries in bin, just set CMAKE_INSTALL_PREFIX = (your OSG directory) and build the INSTALL project in the VS solution. That will put the binaries and DLLs in CMAKE_INSTALL_PREFIX\bin, libs in CMAKE_INSTALL_PREFIX\lib, and examples in CMAKE_INSTALL_PREFIX\share\OpenSceneGraph\bin We might have make some modifications to get the pdb files to follow though, currently they don't (they stay in the build subdirectories). J-S -- __ Jean-Sebastien Guay http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum hey dear it works but the only problem is that it creates a subfolder DEBUG under BIN which i dont want ..i want the files to directly come under BIN. Any solution for this??? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10770#10770 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
