Re: [osg-users] osgstereomatch not working on Windows, NVIDIA 8800
Hi, I will try later with the latest svn. I have an older version (8504) and your posted command line for stereomatch works on Linux here: The top right is white, but the top left shows the disparity image. osgmultiplerendertargets without params should display a light yellow square. I also post my warnings, they are similar to yours, you do not need a specific enable for sampler2DRect, OSG does this. It seems something is up with FBO and multiple targets. Can you check if osgprerender works properly? jp Thrall, Bryan wrote: I've compiled OSG from svn HEAD (revision 8952)on Windows XP, but osgstereomatch isn't working. I have an NVIDIA 8800 card; I tried driver version 169 and 175 with the same results. I'm using OpenSceneGraph-Data from svn HEAD (revision 8952) as well. When I run osgstereomatch --left Images/dog_left_eye.jpg --right Images/dog_right_eye.jpg --min 0 --max 31 --window 9 --single I see the two dog images with a flat red rectangle above them on the left and a flat white rectangle above on the right. Isn't this example supposed to show the pixel difference between these images? I tried without '--single' as well, and the only difference is the red rectangle is blue. The only sign of something going wrong are warnings are printed from compiling the shaders with OSG_NOTIFY_LEVEL=DEBUG_FP (see attached log). Also, there was an additional warning that said sampler2DRect couldn't be used without adding the following to the shaders: #extension GL_ARB_texture_rectangle : enable But adding that didn't resolve the problem. On a possibly related note, osgstereoimage doesn't display anything, and osgmultiplerendertargets only displays a blue rectangle (which I'm not sure is correct). Is anyone else having similar problems? Any suggestions? -- Bryan Thrall FlightSafety International [EMAIL PROTECTED] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. RegisterWindowingSystemInterfaceProxy() X11WindowingSystemInterface() GraphicsContext::setWindowingSystemInterface() 0x806cd70 0xb7d1f300 itr='/usr/lib/' FindFileInPath() : trying /usr/lib/osgPlugins-2.5.3/osgdb_jpeg.so ... itr='/usr/local/lib/' FindFileInPath() : trying /usr/local/lib/osgPlugins-2.5.3/osgdb_jpeg.so ... FindFileInPath() : USING /usr/local/lib/osgPlugins-2.5.3/osgdb_jpeg.so Opened DynamicLibrary osgPlugins-2.5.3/osgdb_jpeg.so itr='/home/jpd/OSG_files' FindFileInPath() : trying /home/jpd/OSG_files/Images/dog_left_eye.jpg ... itr='/usr/local/share/OpenSceneGraph-Data' FindFileInPath() : trying /usr/local/share/OpenSceneGraph-Data/Images/dog_left_eye.jpg ... FindFileInPath() : USING /usr/local/share/OpenSceneGraph-Data/Images/dog_left_eye.jpg itr='/home/jpd/OSG_files' FindFileInPath() : trying /home/jpd/OSG_files/Images/dog_right_eye.jpg ... itr='/usr/local/share/OpenSceneGraph-Data' FindFileInPath() : trying /usr/local/share/OpenSceneGraph-Data/Images/dog_right_eye.jpg ... FindFileInPath() : USING /usr/local/share/OpenSceneGraph-Data/Images/dog_right_eye.jpg CullSettings::readEnvironmentalVariables() Uniform Adding parent Uniform Adding parent Uniform Adding parent Uniform Adding parent Uniform Adding parent itr='/home/jpd/OSG_files' FindFileInPath() : trying /home/jpd/OSG_files/shaders/stereomatch_stereopass.frag ... itr='/usr/local/share/OpenSceneGraph-Data' FindFileInPath() : trying /usr/local/share/OpenSceneGraph-Data/shaders/stereomatch_stereopass.frag ... FindFileInPath() : USING /usr/local/share/OpenSceneGraph-Data/shaders/stereomatch_stereopass.frag Loading shader source file /usr/local/share/OpenSceneGraph-Data/shaders/stereomatch_stereopass.frag CullSettings::readEnvironmentalVariables() Render::Render() 0x8073578 CullSettings::readEnvironmentalVariables() CullSettings::readEnvironmentalVariables() CullSettings::readEnvironmentalVariables() CullSettings::readEnvironmentalVariables() CullSettings::readEnvironmentalVariables() _availableQueue.size()=2 CullSettings::readEnvironmentalVariables() Render::Render() 0x8075990 CullSettings::readEnvironmentalVariables() CullSettings::readEnvironmentalVariables() CullSettings::readEnvironmentalVariables() CullSettings::readEnvironmentalVariables() _availableQueue.size()=2 View::setSceneData() Reusing exisitng scene0x80721a8 Viewer::realize() - No valid contexts found, setting up view across all screens. GraphicsContext::getWindowingSystemInterface() 0x806cd70
[osg-users] Web and svn server down?
They seem unreachable a.t.m Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Web and svn server down?
Hi, I can also confirm svn via https seems down. jp Paul Melis wrote: They seem unreachable a.t.m Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Textures not displaying properly when you open the OSG window the second t ime arround in a Win32 application
Hi Robert, I managed to solve the problem, thanks a lot for pointing me in the right direction! I am using OSG version 2.6, and did see that in the destructor of the CompositeViewer, there is a call to GraphicsContext::close() which flushes the objects... But, as you said, I was removing some parts of the scene graph before closing the context. Thanks again for your help. Juan -Mensaje original- Date: Fri, 26 Sep 2008 09:44:15 +0100 From: Robert Osfield [EMAIL PROTECTED] Subject: Re: [osg-users] Textures not displaying properly when you open theOSG window the second t ime arround in a Win32 application To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 Hi Juan, This problem has arisen before and is related to the scene graph reusing the contextID from the previous context in the new context with the scene graph being flushed of OpenGL objects related to the original graphics context so the OSG then tries to use these OpenGL objects in the new context, but of course these objects have really been deleted so things don't work. The solution is to flush the GL objects for the context scene graph on closing of the first context, and the OSG will now do this, so should just work automatically, but if you detach parts of the scene graph before closing the context you'll need to flush these parts manually as the context itself won't know about them unless that are nested below a Camera that the context has. This leads to next question, which OSG version are you using? If it isn't 2.6 then upgrade to 2.6 as there is good chance you problem will disappear as it does a better job at cleaning up on context closure. Robert. On Fri, Sep 26, 2008 at 9:13 AM, Juan Sebastian Casanueva [EMAIL PROTECTED] wrote: Hi, We are implementing a Windows application that opens an OSG viewer on a Windows window (lets call it 3d window) and displays some 3d graphics. The way we are implementing the application is similar to the MFC example (although I am not using MFC, but Win32 API instead), the only difference is that I use a CompositeViewer instead of a Viewer. Everything works fine when you open the 3d window for the first time, but if you close the 3d window and open it again (note that you don't close the main application, only the 3d window), the textures do not display properly anymore. Sometimes some textures are dark, sometimes some are white, sometimes they do not show at all, and sometimes some textures are swapped between objects. If you close and open again and again, you get a combination of those problems. If you exit the main application, start it again and open the 3d window, everything is displayed perfectly. I don't really know were the problem might be, so if somebody can guide me in the right direction as to where the problem might be, I will appreciate it . Thanks very much Juan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Web and svn server down?
and seems up now... J.P. Delport wrote: Hi, I can also confirm svn via https seems down. jp Paul Melis wrote: They seem unreachable a.t.m Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How can I render to two textures by turns?
HI J.P, Would you be willing for this example to be merged with the OSG as a standard example? Cheers, Robert. On Mon, Sep 29, 2008 at 7:56 AM, J.P. Delport [EMAIL PROTECTED] wrote: Hi, the attached example shows a simple way to do this. Also search the list for osgPPU. jp Lilinx wrote: hi, how can I do this ? 1; render to texture A; 2: textureA render to textureB; 3. textureB render back to textureA ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ 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 can I render to two textures by turns?
Hi Robert, yes, that was the intention when I first made it. I have just not taken time to clean it up and name it properly. It is basically the game of life implemented in GPU with ping-pong textures. It also illustrates only one possible ping-pong method (with multiple cameras below switches). It is quite cool with the land_shallow_topo_2048.jpg as input :) jp Robert Osfield wrote: HI J.P, Would you be willing for this example to be merged with the OSG as a standard example? Cheers, Robert. On Mon, Sep 29, 2008 at 7:56 AM, J.P. Delport [EMAIL PROTECTED] wrote: Hi, the attached example shows a simple way to do this. Also search the list for osgPPU. jp Lilinx wrote: hi, how can I do this ? 1; render to texture A; 2: textureA render to textureB; 3. textureB render back to textureA ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ 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 -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgstereomatch not working on Windows, NVIDIA 8800
Hi, just recompiled latest svn (8953) and stereomatch and multiplerendertargets work OK. Linux NVidia 7400 Go (177.67). sorry I can't help on Windows. Anyone else? jp J.P. Delport wrote: Hi, I will try later with the latest svn. I have an older version (8504) and your posted command line for stereomatch works on Linux here: The top right is white, but the top left shows the disparity image. osgmultiplerendertargets without params should display a light yellow square. I also post my warnings, they are similar to yours, you do not need a specific enable for sampler2DRect, OSG does this. It seems something is up with FBO and multiple targets. Can you check if osgprerender works properly? jp Thrall, Bryan wrote: I've compiled OSG from svn HEAD (revision 8952)on Windows XP, but osgstereomatch isn't working. I have an NVIDIA 8800 card; I tried driver version 169 and 175 with the same results. I'm using OpenSceneGraph-Data from svn HEAD (revision 8952) as well. When I run osgstereomatch --left Images/dog_left_eye.jpg --right Images/dog_right_eye.jpg --min 0 --max 31 --window 9 --single I see the two dog images with a flat red rectangle above them on the left and a flat white rectangle above on the right. Isn't this example supposed to show the pixel difference between these images? I tried without '--single' as well, and the only difference is the red rectangle is blue. The only sign of something going wrong are warnings are printed from compiling the shaders with OSG_NOTIFY_LEVEL=DEBUG_FP (see attached log). Also, there was an additional warning that said sampler2DRect couldn't be used without adding the following to the shaders: #extension GL_ARB_texture_rectangle : enable But adding that didn't resolve the problem. On a possibly related note, osgstereoimage doesn't display anything, and osgmultiplerendertargets only displays a blue rectangle (which I'm not sure is correct). Is anyone else having similar problems? Any suggestions? -- Bryan Thrall FlightSafety International [EMAIL PROTECTED] ___ 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 -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Pager problem
Hi all, I am currently facing a strange problem with the database pager : - On an Intel QuadCore CPU with 2 NVidia GPUs (8800 GT), after some time (several hours), the pager stops to load new nodes. The file request list size continues to grow but no new nodes are added to the graph. And finally (after for example one hour not processing new requests), my application crash. - On an Intel DualCore CPU with 1 GPU (my dev machine), everyting works fine, even if it runs several days. My app uses a CompositeViewer with 2 views (sharing the same scene), under WinXP and in DrawThreadPerContext mode. That's why I would like to know if internally OSG setup things differently for these two setups ? Or anyone has already seen this problem on its machine ? Thanks in advance ! -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] useCursor
I'm attempting to turn off the cursor using osgViewer::Viewer::Windows windows; _viewer-getWindows(windows); for (osgViewer::Viewer::Windows::iterator itr = windows.begin(); itr != windows.end(); ++itr) (*itr)-useCursor(false); and I seem to be getting this: Got an X11ErrorHandling call disGpot laany =X11Err0oxr8H270a9n2d8lin g ceavlentl=0 dxispbl7a1y3=00200x8270 928 event=0xbfffcc60 Xlib: sequence lost (0x10034 0x35) in reply type 0x0! Xlib: charsets ISO8859-1:GL and ISO8859-1:GL have the same CT sequence Xlib: charsets ISO8859-10:GR and ISO8859-10:GR have the same CT sequence Xlib: charsets ISO8859-15:GR and ISO8859-15:GR have the same CT sequence Xlib: charsets GB2312.1980-0:GL and GB2312.1980-0:GL have the same CT sequence Xlib: charsets JISX0212.1990-0:GL and JISX0212.1990-0:GL have the same CT sequence Xlib: charsets KSC5601.1987-0:GR and KSC5601.1987-0:GR have the same CT sequence Xlib: charsets CNS11643.1986-2:GL and CNS11643.1986-2:GL have the same CT sequence Xlib: charsets CNS11643.1992-3:GR and CNS11643.1992-3:GR have the same CT sequence Xlib: charsets CNS11643.1992-5:GL and CNS11643.1992-5:GL have the same CT sequence Xlib: charsets CNS11643.1992-7:GL and CNS11643.1992-7:GL have the same CT sequence Xlib: charsets BIG5-0:GLGR and BIG5-0:GLGR have the same CT sequence Xlib: charsets BIG5-E1:GL and BIG5-E1:GL have the same CT sequence Segmentation fault I don't seem to have any problems with osgcatch which seems to do the same thing, but I am newing an osgViewer. Any ideas what might be causing this? I'm using OSG 2.6. I do play with processor affinity/shielding, but turning this off doesn't seem to help. Paul P. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] cullcallback and visitor ?
Hi
I make a little UP because I go now a strange problem :
My Cullcallback seem to engender some other problems in my application. When
I put it, the application can crash or freeze, pretending sometimes not
enough memory (false, I've checked) or some other error messages with no
relation with that. I suppose my cull callback is not good and randomly
engender unstable states in the application...
This is what I do, to check visible elements or not :
Callback :
tileVisibleCallback::tileVisibleCallback(Tile* tile)
: osg::NodeCallback(){
_tile = tile;
};
void tileVisibleCallback::operator()(osg::Node* node, osg::NodeVisitor*
nv){
if(!_tile.valid()){
osg::notify(osg::WARN)Tile callback error : tile not
recognized!\n;
return;
}
//This method is called so the tile is visible
//Its name is added to the visible Tile list.
_tile-_stack-_cullList.push_back(_tile-getName());
traverse(node, nv);
};
and the Set :
osg::ref_ptrtileVisibleCallback tvc = new tileVisibleCallback(this);
if(_mainChild-getCullCallback())
_mainChild-getCullCallback()-setNestedCallback(tvc.get());
else
_mainChild-setCullCallback(tvc.get());
Do you see something not clear ? unstable ? what can engender problems ?
Thanks a lot.
Regards,
Vincent
2008/9/26 Vincent Bourdier [EMAIL PROTECTED]
Hi,
I found an other solution using a vector to store the visible elements and
clearing this list each render loop. I is the more simple solution I think.
thanks for your help.
Regards,
Vincent.
2008/9/26 Ulrich Hertlein [EMAIL PROTECTED]
Hi Vincent,
Vincent Bourdier wrote:
Vincent Bourdier wrote:
If if do a nodevisitior, I've the problem that the operator() takes a
nodevisitor in parameter and so I can't obtain the cull state with
that.
(method isCulled() not aviable from a node visitor)
The way I understood Robert, the fact that your operator() is called
means
the node in
question is *not* culled so you could simple set your _isCulled=true.
And
don't forget to call traverse().
Ok, this is a simple and good way to have the result, but not sufficient
:
cull = true when operator() is called, but if the operator is not
called,
cull still = true and will never be false...
Yes it will never be reset by the cull traversal so you have to do that
yourself e.g. just
before cull or maybe after you've read the cull state from your class.
Cheers,
/ulrich
___
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] vpb: Spherical terrains?
Hello: As recommended in this forum, I installed both osg and vpb from svn and I was able to reproduce the example with the Punget terrain. Now I want to try it with planets, starting with the moon. I started trying with these parameters --geocentric --spherical --radius-equator 1735000 but I get this error: ERROR 1: Unable to compute a transformation between pixel/line and georeferenced coordinates for moon_heigth.tif. There is no affine transformation and no GCPs. I assume I could add that transformation in a world file or creating a geotiff file, but I am not sure how to do that. I also assume that the bluemarble options only works at Earth scale, as in this example: http://www.andesengineering.com/BlueMarbleViewer/ Sorry if these are faqs, I am a newvbie and there is not much documentation about this subject. I will appreciate any advice. Regards, -- Alejandro Sierra ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] cullcallback and visitor ?
Hi Vincent,
There isn't really any much of clue about what might be wrong from
your email, so you are probably going to have rely on your own skills
to track down what you've done wrong. The only hint I got from you
email was mention of a out of memory, which could suggest many things
including perhaps that the stack has been filled by a never ending
loop. This is all your code we are talking about here so you the only
person in a position to debug it.
Robert.
On Mon, Sep 29, 2008 at 2:52 PM, Vincent Bourdier
[EMAIL PROTECTED] wrote:
Hi
I make a little UP because I go now a strange problem :
My Cullcallback seem to engender some other problems in my application. When
I put it, the application can crash or freeze, pretending sometimes not
enough memory (false, I've checked) or some other error messages with no
relation with that. I suppose my cull callback is not good and randomly
engender unstable states in the application...
This is what I do, to check visible elements or not :
Callback :
tileVisibleCallback::tileVisibleCallback(Tile* tile)
: osg::NodeCallback(){
_tile = tile;
};
void tileVisibleCallback::operator()(osg::Node* node, osg::NodeVisitor*
nv){
if(!_tile.valid()){
osg::notify(osg::WARN)Tile callback error : tile not
recognized!\n;
return;
}
//This method is called so the tile is visible
//Its name is added to the visible Tile list.
_tile-_stack-_cullList.push_back(_tile-getName());
traverse(node, nv);
};
and the Set :
osg::ref_ptrtileVisibleCallback tvc = new tileVisibleCallback(this);
if(_mainChild-getCullCallback())
_mainChild-getCullCallback()-setNestedCallback(tvc.get());
else
_mainChild-setCullCallback(tvc.get());
Do you see something not clear ? unstable ? what can engender problems ?
Thanks a lot.
Regards,
Vincent
2008/9/26 Vincent Bourdier [EMAIL PROTECTED]
Hi,
I found an other solution using a vector to store the visible elements and
clearing this list each render loop. I is the more simple solution I think.
thanks for your help.
Regards,
Vincent.
2008/9/26 Ulrich Hertlein [EMAIL PROTECTED]
Hi Vincent,
Vincent Bourdier wrote:
Vincent Bourdier wrote:
If if do a nodevisitior, I've the problem that the operator() takes a
nodevisitor in parameter and so I can't obtain the cull state with
that.
(method isCulled() not aviable from a node visitor)
The way I understood Robert, the fact that your operator() is called
means
the node in
question is *not* culled so you could simple set your _isCulled=true.
And
don't forget to call traverse().
Ok, this is a simple and good way to have the result, but not
sufficient :
cull = true when operator() is called, but if the operator is not
called,
cull still = true and will never be false...
Yes it will never be reset by the cull traversal so you have to do that
yourself e.g. just
before cull or maybe after you've read the cull state from your class.
Cheers,
/ulrich
___
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] vpb: Spherical terrains?
Hi Alejandro, The GDAL error that is produced suggests that you are trying to apply a transform to the data when the data doesn't have an geocentric infomation associated with it - which boils down to it can't transform data when it doesn't know what coordinate system it's starting off in. You need to use imagery/dems with coordinates system or apply them manually. Robert. On Mon, Sep 29, 2008 at 3:00 PM, Alejandro Aguilar Sierra [EMAIL PROTECTED] wrote: Hello: As recommended in this forum, I installed both osg and vpb from svn and I was able to reproduce the example with the Punget terrain. Now I want to try it with planets, starting with the moon. I started trying with these parameters --geocentric --spherical --radius-equator 1735000 but I get this error: ERROR 1: Unable to compute a transformation between pixel/line and georeferenced coordinates for moon_heigth.tif. There is no affine transformation and no GCPs. I assume I could add that transformation in a world file or creating a geotiff file, but I am not sure how to do that. I also assume that the bluemarble options only works at Earth scale, as in this example: http://www.andesengineering.com/BlueMarbleViewer/ Sorry if these are faqs, I am a newvbie and there is not much documentation about this subject. I will appreciate any advice. Regards, -- Alejandro Sierra ___ 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] osgdem --terrain vs polygon count?
Hi all, I admit I don't know what causes osgdem --terrain to take so little time to generate the same terrain that would take hours without that option. I suspect that's part of the answer to my question. But I'd like to know a few of the details if possible. I was wondering why, when I generate a database with the --terrain option, the geometry is a uniform grid (not simplified)? I would suspect this would affect the run time speed on large terrain and where the rest of the scene (other than the terrain) is complex? So are we trading a (very large) increase in build speed for a slowdown in run time speed on slower video cards? What is the magnitude of that slowdown in practice (assuming it actually exists)? Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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] osgdem --terrain vs polygon count?
Hi J-S, The main speed up with using --terrain in the osgdem/vpbmaster build is that the tile geometry doesn't need to simplified - it can just be aquired from the source DEM's as grids and then output as grids. At runtime there will typically many more triangles being rendered with an --terrain (osgTerrain) scene than one with standard paged database with osg::Geometry, the delta between the two depends upon how flat the region is, and the error metric used in the simplification, and the SampleRatio used in osgTerrain at runtime. The key thing to remember with --terrain databases is that since the triangulation is done dynamically on load you do load balancing - you can set the Terrain::setSampleRatio() according to the hardware that you have, so low level hardware you can set a very low ratio to cull lots of geometry, while high end hardware may even be able to handle a ratio of 1.0. You can't do this type of geometry complexity load balancing with a polygonal paged database, the best you can do is change the Camera's LODScale which affects LOD selection and hence which Nodes, Textures and Geometry that will be selected. Robert. On Mon, Sep 29, 2008 at 3:50 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: Hi all, I admit I don't know what causes osgdem --terrain to take so little time to generate the same terrain that would take hours without that option. I suspect that's part of the answer to my question. But I'd like to know a few of the details if possible. I was wondering why, when I generate a database with the --terrain option, the geometry is a uniform grid (not simplified)? I would suspect this would affect the run time speed on large terrain and where the rest of the scene (other than the terrain) is complex? So are we trading a (very large) increase in build speed for a slowdown in run time speed on slower video cards? What is the magnitude of that slowdown in practice (assuming it actually exists)? Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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] cullcallback and visitor ?
Ok,
So I've some question for you :
It is usefull to put a traverse() call in a cullcallback ? are there some
actions we can not put in a cullcallback ?
thanks,
Regards
Vincent
2008/9/29 Robert Osfield [EMAIL PROTECTED]
Hi Vincent,
There isn't really any much of clue about what might be wrong from
your email, so you are probably going to have rely on your own skills
to track down what you've done wrong. The only hint I got from you
email was mention of a out of memory, which could suggest many things
including perhaps that the stack has been filled by a never ending
loop. This is all your code we are talking about here so you the only
person in a position to debug it.
Robert.
On Mon, Sep 29, 2008 at 2:52 PM, Vincent Bourdier
[EMAIL PROTECTED] wrote:
Hi
I make a little UP because I go now a strange problem :
My Cullcallback seem to engender some other problems in my application.
When
I put it, the application can crash or freeze, pretending sometimes not
enough memory (false, I've checked) or some other error messages with no
relation with that. I suppose my cull callback is not good and randomly
engender unstable states in the application...
This is what I do, to check visible elements or not :
Callback :
tileVisibleCallback::tileVisibleCallback(Tile* tile)
: osg::NodeCallback(){
_tile = tile;
};
void tileVisibleCallback::operator()(osg::Node* node, osg::NodeVisitor*
nv){
if(!_tile.valid()){
osg::notify(osg::WARN)Tile callback error : tile not
recognized!\n;
return;
}
//This method is called so the tile is visible
//Its name is added to the visible Tile list.
_tile-_stack-_cullList.push_back(_tile-getName());
traverse(node, nv);
};
and the Set :
osg::ref_ptrtileVisibleCallback tvc = new tileVisibleCallback(this);
if(_mainChild-getCullCallback())
_mainChild-getCullCallback()-setNestedCallback(tvc.get());
else
_mainChild-setCullCallback(tvc.get());
Do you see something not clear ? unstable ? what can engender problems ?
Thanks a lot.
Regards,
Vincent
2008/9/26 Vincent Bourdier [EMAIL PROTECTED]
Hi,
I found an other solution using a vector to store the visible elements
and
clearing this list each render loop. I is the more simple solution I
think.
thanks for your help.
Regards,
Vincent.
2008/9/26 Ulrich Hertlein [EMAIL PROTECTED]
Hi Vincent,
Vincent Bourdier wrote:
Vincent Bourdier wrote:
If if do a nodevisitior, I've the problem that the operator() takes
a
nodevisitor in parameter and so I can't obtain the cull state with
that.
(method isCulled() not aviable from a node visitor)
The way I understood Robert, the fact that your operator() is called
means
the node in
question is *not* culled so you could simple set your
_isCulled=true.
And
don't forget to call traverse().
Ok, this is a simple and good way to have the result, but not
sufficient :
cull = true when operator() is called, but if the operator is not
called,
cull still = true and will never be false...
Yes it will never be reset by the cull traversal so you have to do that
yourself e.g. just
before cull or maybe after you've read the cull state from your class.
Cheers,
/ulrich
___
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] osgstereomatch not working on Windows, NVIDIA 8800
J.P. Delport wrote on Monday, September 29, 2008 4:17 AM: Hi, just recompiled latest svn (8953) and stereomatch and multiplerendertargets work OK. Linux NVidia 7400 Go (177.67). sorry I can't help on Windows. Anyone else? Thanks for checking. I'll try the latest NVidia driver release. osgprerender does work just fine. J.P. Delport wrote: Hi, I will try later with the latest svn. I have an older version (8504) and your posted command line for stereomatch works on Linux here: The top right is white, but the top left shows the disparity image. osgmultiplerendertargets without params should display a light yellow square. I also post my warnings, they are similar to yours, you do not need a specific enable for sampler2DRect, OSG does this. It seems something is up with FBO and multiple targets. Can you check if osgprerender works properly? jp Thrall, Bryan wrote: I've compiled OSG from svn HEAD (revision 8952)on Windows XP, but osgstereomatch isn't working. I have an NVIDIA 8800 card; I tried driver version 169 and 175 with the same results. I'm using OpenSceneGraph-Data from svn HEAD (revision 8952) as well. When I run osgstereomatch --left Images/dog_left_eye.jpg --right Images/dog_right_eye.jpg --min 0 --max 31 --window 9 --single I see the two dog images with a flat red rectangle above them on the left and a flat white rectangle above on the right. Isn't this example supposed to show the pixel difference between these images? I tried without '--single' as well, and the only difference is the red rectangle is blue. The only sign of something going wrong are warnings are printed from compiling the shaders with OSG_NOTIFY_LEVEL=DEBUG_FP (see attached log). Also, there was an additional warning that said sampler2DRect couldn't be used without adding the following to the shaders: #extension GL_ARB_texture_rectangle : enable But adding that didn't resolve the problem. On a possibly related note, osgstereoimage doesn't display anything, and osgmultiplerendertargets only displays a blue rectangle (which I'm not sure is correct). Is anyone else having similar problems? Any suggestions? -- Bryan Thrall FlightSafety International [EMAIL PROTECTED] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Example osgtexture1d
Hi, While playing with the example osgtexture1d, I wasn't able to see the changes from object linear to eye linear mode. I've run the example both on linux and windows with latest svn version. I would have expected to see bands of colours linked to the object in OBJECT_LINEAR and eye linked bands of colours in EYE_LINEAR mode. But it seems to me that only the OBJECT_LINEAR mode is working... Could someone please test it and see if the dumptruck changes it's texture every other second to eliminate a possible driver issue ? Thanks in advance -- Mathieu ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgdem --terrain vs polygon count?
Hi Robert, The main speed up with using --terrain in the osgdem/vpbmaster build is that the tile geometry doesn't need to simplified - it can just be aquired from the source DEM's as grids and then output as grids. [...] The key thing to remember with --terrain databases is that since the triangulation is done dynamically on load you do load balancing - you can set the Terrain::setSampleRatio() according to the hardware that you have Ok, so in order to get --terrain databases to work optimally on all machines I would have to expose this setting in my software's config files (for example) so that it can be tweaked according to each machine's hardware, is that right? I would suspect that on relatively flat terrain, the terrain database using simplified geometry might run fast enough on all machines (or all reasonably fast machines) without losing any relevant detail, whereas the --terrain database would be too slow on older machines, which would require that we lower the sampleRatio, and thus lose some detail? Is that possible? In that case, if we need to support a large number of different hardware configurations, we might be willing to accept the longer build times of not using --terrain in exchange for not needing to tweak sampleRatio and not losing any detail. Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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] Converting GeoTiff to UTM - unable to compute output bounds
Hi all, This is probably just a sign of my inexperience in using gdal and GeoTiffs... I'm getting this error message when trying to convert a GeoTiff to UTM (in meters): gdalwarp -t_srs +proj=utm +zone=32 +datum=WGS84 +units=m file.wgs84.tif file.utm.tif ERROR 1: Too many points (441 out of 441) failed to transform, unable to compute output bounds. This is the info of the file: gdalinfo file.wgs84.tif Driver: GTiff/GeoTIFF Files: Gjoa-fledermaus.wgs84.tif Size is 6190, 7250 Coordinate System is: GEOGCS[WGS 84, DATUM[WGS_1984, SPHEROID[WGS 84,6378137,298.2572235630016, AUTHORITY[EPSG,7030]], AUTHORITY[EPSG,6326]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433], AUTHORITY[EPSG,4326]] Origin = (548676.250,6807000.000) Pixel Size = (0.955613893376414,-0.956137931034483) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=PIXEL Corner Coordinates: Upper Left ( 548676.250, 6807000.000) (548676d15'0.00E,6807000d 0'25769803776.00N) Lower Left ( 548676.250, 6800068.000) (548676d15'0.00E,6800068d 0'25769803776.00N) Upper Right ( 554591.500, 6807000.000) (554591d30'0.00E,6807000d 0'25769803776.00N) Lower Right ( 554591.500, 6800068.000) (554591d30'0.00E,6800068d 0'25769803776.00N) Center ( 551633.875, 6803534.000) (551633d52'30.00E,6803534d 0'25769803776.00N) Band 1 Block=6190x1 Type=Byte, ColorInterp=Red Mask Flags: PER_DATASET ALPHA Band 2 Block=6190x1 Type=Byte, ColorInterp=Green Mask Flags: PER_DATASET ALPHA Band 3 Block=6190x1 Type=Byte, ColorInterp=Blue Mask Flags: PER_DATASET ALPHA Band 4 Block=6190x1 Type=Byte, ColorInterp=Alpha The first thing I noticed is that what is in the SPHEROID section doesn't seem to match the other coordinates in the file, but I'm not sure that's the problem, and even if my hunch is correct, I don't know how to fix it. For reference, the original file (which I got from importing point data into some third party software and then exporting a GeoTiff from it) had this info: gdalinfo file.tif Driver: GTiff/GeoTIFF Files: Gjoa-fledermaus.tif Size is 6190, 7250 Coordinate System is: PROJCS[unnamed, GEOGCS[unnamed, DATUM[unknown, SPHEROID[unretrievable - using WGS84,6378137,298.257223563]], PRIMEM[Greenwich,0], UNIT[,0.0174532925199433]], UNIT[unknown,1]] Origin = (548676.250,6807000.000) Pixel Size = (0.955613893376414,-0.956137931034483) Image Structure Metadata: COMPRESSION=LZW INTERLEAVE=PIXEL Corner Coordinates: Upper Left ( 548676.250, 6807000.000) Lower Left ( 548676.250, 6800068.000) Upper Right ( 554591.500, 6807000.000) Lower Right ( 554591.500, 6800068.000) Center ( 551633.875, 6803534.000) Band 1 Block=6190x1 Type=Byte, ColorInterp=Red Mask Flags: PER_DATASET ALPHA Band 2 Block=6190x1 Type=Byte, ColorInterp=Green Mask Flags: PER_DATASET ALPHA Band 3 Block=6190x1 Type=Byte, ColorInterp=Blue Mask Flags: PER_DATASET ALPHA Band 4 Block=6190x1 Type=Byte, ColorInterp=Alpha and I got file.wgs84.tif by running gdal_translate -a_srs WGS84 file.tif file.wgs84.tif on it. Any hints would be appreciated. Thanks in advance, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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] Example osgtexture1d
oups .. forgotten OSG svn rev 8956 David Callu 2008/9/29 David Callu [EMAIL PROTECTED] Hi Mathieu Same thing for me. Fedora 8, kernel 2.6.26 gcc 4.1.3 driver NVidia 173.14.12 David Callu 2008/9/29 Mathieu MARACHE [EMAIL PROTECTED] Hi, While playing with the example osgtexture1d, I wasn't able to see the changes from object linear to eye linear mode. I've run the example both on linux and windows with latest svn version. I would have expected to see bands of colours linked to the object in OBJECT_LINEAR and eye linked bands of colours in EYE_LINEAR mode. But it seems to me that only the OBJECT_LINEAR mode is working... Could someone please test it and see if the dumptruck changes it's texture every other second to eliminate a possible driver issue ? Thanks in advance -- Mathieu ___ 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] Converting GeoTiff to UTM - unable to compute output bounds
J-S, from the looks of the coords, your original file may have already been in UTM to begin with. When you ran gdal_translate -a_srs WGS84 file.tif file.wgs84.tif you assigned a WGS84 projection to what appears to be a UTM tif file. Can you double-check this? Glenn On Mon, Sep 29, 2008 at 11:34 AM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: Hi all, This is probably just a sign of my inexperience in using gdal and GeoTiffs... I'm getting this error message when trying to convert a GeoTiff to UTM (in meters): gdalwarp -t_srs +proj=utm +zone=32 +datum=WGS84 +units=m file.wgs84.tif file.utm.tif ERROR 1: Too many points (441 out of 441) failed to transform, unable to compute output bounds. This is the info of the file: gdalinfo file.wgs84.tif Driver: GTiff/GeoTIFF Files: Gjoa-fledermaus.wgs84.tif Size is 6190, 7250 Coordinate System is: GEOGCS[WGS 84, DATUM[WGS_1984, SPHEROID[WGS 84,6378137,298.2572235630016, AUTHORITY[EPSG,7030]], AUTHORITY[EPSG,6326]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433], AUTHORITY[EPSG,4326]] Origin = (548676.250,6807000.000) Pixel Size = (0.955613893376414,-0.956137931034483) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=PIXEL Corner Coordinates: Upper Left ( 548676.250, 6807000.000) (548676d15'0.00E,6807000d 0'25769803776.00N) Lower Left ( 548676.250, 6800068.000) (548676d15'0.00E,6800068d 0'25769803776.00N) Upper Right ( 554591.500, 6807000.000) (554591d30'0.00E,6807000d 0'25769803776.00N) Lower Right ( 554591.500, 6800068.000) (554591d30'0.00E,6800068d 0'25769803776.00N) Center ( 551633.875, 6803534.000) (551633d52'30.00E,6803534d 0'25769803776.00N) Band 1 Block=6190x1 Type=Byte, ColorInterp=Red Mask Flags: PER_DATASET ALPHA Band 2 Block=6190x1 Type=Byte, ColorInterp=Green Mask Flags: PER_DATASET ALPHA Band 3 Block=6190x1 Type=Byte, ColorInterp=Blue Mask Flags: PER_DATASET ALPHA Band 4 Block=6190x1 Type=Byte, ColorInterp=Alpha The first thing I noticed is that what is in the SPHEROID section doesn't seem to match the other coordinates in the file, but I'm not sure that's the problem, and even if my hunch is correct, I don't know how to fix it. For reference, the original file (which I got from importing point data into some third party software and then exporting a GeoTiff from it) had this info: gdalinfo file.tif Driver: GTiff/GeoTIFF Files: Gjoa-fledermaus.tif Size is 6190, 7250 Coordinate System is: PROJCS[unnamed, GEOGCS[unnamed, DATUM[unknown, SPHEROID[unretrievable - using WGS84,6378137,298.257223563]], PRIMEM[Greenwich,0], UNIT[,0.0174532925199433]], UNIT[unknown,1]] Origin = (548676.250,6807000.000) Pixel Size = (0.955613893376414,-0.956137931034483) Image Structure Metadata: COMPRESSION=LZW INTERLEAVE=PIXEL Corner Coordinates: Upper Left ( 548676.250, 6807000.000) Lower Left ( 548676.250, 6800068.000) Upper Right ( 554591.500, 6807000.000) Lower Right ( 554591.500, 6800068.000) Center ( 551633.875, 6803534.000) Band 1 Block=6190x1 Type=Byte, ColorInterp=Red Mask Flags: PER_DATASET ALPHA Band 2 Block=6190x1 Type=Byte, ColorInterp=Green Mask Flags: PER_DATASET ALPHA Band 3 Block=6190x1 Type=Byte, ColorInterp=Blue Mask Flags: PER_DATASET ALPHA Band 4 Block=6190x1 Type=Byte, ColorInterp=Alpha and I got file.wgs84.tif by running gdal_translate -a_srs WGS84 file.tif file.wgs84.tif on it. Any hints would be appreciated. Thanks in advance, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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 -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : +1.703.652.4791 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Converting GeoTiff to UTM - unable to compute output bounds
Hi Glenn, J-S, from the looks of the coords, your original file may have already been in UTM to begin with. When you ran gdal_translate -a_srs WGS84 file.tif file.wgs84.tif you assigned a WGS84 projection to what appears to be a UTM tif file. Can you double-check this? Hm, interesting, all those unknown, unnamed and unretrievable values looked to me like I needed to assign a projection to the file... You're right, VPB can use the original file no problem. But won't the units be lat/long degrees then? I need meters. I'm waiting for the results... Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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] osgstereomatch not working on Windows, NVIDIA 8800
Thrall, Bryan wrote on Monday, September 29, 2008 10:06 AM: J.P. Delport wrote on Monday, September 29, 2008 4:17 AM: Hi, just recompiled latest svn (8953) and stereomatch and multiplerendertargets work OK. Linux NVidia 7400 Go (177.67). sorry I can't help on Windows. Anyone else? Thanks for checking. I'll try the latest NVidia driver release. The 178.13 release breaks everything; can't even run 'osgviewer cow.osg'. Back to 175... osgprerender does work just fine. J.P. Delport wrote: Hi, I will try later with the latest svn. I have an older version (8504) and your posted command line for stereomatch works on Linux here: The top right is white, but the top left shows the disparity image. osgmultiplerendertargets without params should display a light yellow square. I also post my warnings, they are similar to yours, you do not need a specific enable for sampler2DRect, OSG does this. It seems something is up with FBO and multiple targets. Can you check if osgprerender works properly? jp Thrall, Bryan wrote: I've compiled OSG from svn HEAD (revision 8952)on Windows XP, but osgstereomatch isn't working. I have an NVIDIA 8800 card; I tried driver version 169 and 175 with the same results. I'm using OpenSceneGraph-Data from svn HEAD (revision 8952) as well. When I run osgstereomatch --left Images/dog_left_eye.jpg --right Images/dog_right_eye.jpg --min 0 --max 31 --window 9 --single I see the two dog images with a flat red rectangle above them on the left and a flat white rectangle above on the right. Isn't this example supposed to show the pixel difference between these images? I tried without '--single' as well, and the only difference is the red rectangle is blue. The only sign of something going wrong are warnings are printed from compiling the shaders with OSG_NOTIFY_LEVEL=DEBUG_FP (see attached log). Also, there was an additional warning that said sampler2DRect couldn't be used without adding the following to the shaders: #extension GL_ARB_texture_rectangle : enable But adding that didn't resolve the problem. On a possibly related note, osgstereoimage doesn't display anything, and osgmultiplerendertargets only displays a blue rectangle (which I'm not sure is correct). Is anyone else having similar problems? Any suggestions? -- Bryan Thrall FlightSafety International [EMAIL PROTECTED] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Getting started with OSG and GLSL
also see http://mew.cx/osg_glsl_july2005.pdf cheers -- mew On Fri, Sep 19, 2008 at 3:22 AM, Filip R. Andersson [EMAIL PROTECTED] wrote: Hi all, I would like to add shading effects to my application, which uses OSG, but have never programmed GLSL or Cg before. Can anyone please guide me to tutorials or a good source of information about using GLSL with OSG? I noticed that OSG comes with one or two shading examples but I would like to see how .osg/.ive files can be loaded to the scenegraph and what kind of shading information I can embed in the files. Any direction to where I can do some reading is appreciated. Cheers, Filip -- Mike Weiblen -- Austin Texas USA -- http://mew.cx/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] cullcallback and visitor ?
Hi Vincent,
You have to call traverse() in your callback, as node callbacks are in
effect traversal callbacks, if you don't include the traversal of the
subgraph nothing will happen, just make sure you don't traverse the
parent otherwise you'll end up with an infinite loop.
Robert.
On Mon, Sep 29, 2008 at 4:05 PM, Vincent Bourdier
[EMAIL PROTECTED] wrote:
Ok,
So I've some question for you :
It is usefull to put a traverse() call in a cullcallback ? are there some
actions we can not put in a cullcallback ?
thanks,
Regards
Vincent
2008/9/29 Robert Osfield [EMAIL PROTECTED]
Hi Vincent,
There isn't really any much of clue about what might be wrong from
your email, so you are probably going to have rely on your own skills
to track down what you've done wrong. The only hint I got from you
email was mention of a out of memory, which could suggest many things
including perhaps that the stack has been filled by a never ending
loop. This is all your code we are talking about here so you the only
person in a position to debug it.
Robert.
On Mon, Sep 29, 2008 at 2:52 PM, Vincent Bourdier
[EMAIL PROTECTED] wrote:
Hi
I make a little UP because I go now a strange problem :
My Cullcallback seem to engender some other problems in my application.
When
I put it, the application can crash or freeze, pretending sometimes not
enough memory (false, I've checked) or some other error messages with
no
relation with that. I suppose my cull callback is not good and randomly
engender unstable states in the application...
This is what I do, to check visible elements or not :
Callback :
tileVisibleCallback::tileVisibleCallback(Tile* tile)
: osg::NodeCallback(){
_tile = tile;
};
void tileVisibleCallback::operator()(osg::Node* node, osg::NodeVisitor*
nv){
if(!_tile.valid()){
osg::notify(osg::WARN)Tile callback error : tile not
recognized!\n;
return;
}
//This method is called so the tile is visible
//Its name is added to the visible Tile list.
_tile-_stack-_cullList.push_back(_tile-getName());
traverse(node, nv);
};
and the Set :
osg::ref_ptrtileVisibleCallback tvc = new tileVisibleCallback(this);
if(_mainChild-getCullCallback())
_mainChild-getCullCallback()-setNestedCallback(tvc.get());
else
_mainChild-setCullCallback(tvc.get());
Do you see something not clear ? unstable ? what can engender problems ?
Thanks a lot.
Regards,
Vincent
2008/9/26 Vincent Bourdier [EMAIL PROTECTED]
Hi,
I found an other solution using a vector to store the visible elements
and
clearing this list each render loop. I is the more simple solution I
think.
thanks for your help.
Regards,
Vincent.
2008/9/26 Ulrich Hertlein [EMAIL PROTECTED]
Hi Vincent,
Vincent Bourdier wrote:
Vincent Bourdier wrote:
If if do a nodevisitior, I've the problem that the operator()
takes a
nodevisitor in parameter and so I can't obtain the cull state with
that.
(method isCulled() not aviable from a node visitor)
The way I understood Robert, the fact that your operator() is
called
means
the node in
question is *not* culled so you could simple set your
_isCulled=true.
And
don't forget to call traverse().
Ok, this is a simple and good way to have the result, but not
sufficient :
cull = true when operator() is called, but if the operator is not
called,
cull still = true and will never be false...
Yes it will never be reset by the cull traversal so you have to do
that
yourself e.g. just
before cull or maybe after you've read the cull state from your class.
Cheers,
/ulrich
___
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] osgdem --terrain vs polygon count?
Hi J-S, You need to decide what you want to do, but personally I'd recommend using --terrain and then in your app decide how much detail you want, you can make this user definable, provide reasonable defaults for different classes of hardware 0 they key is it's under your control and even after the app is deployed you can still tweak things to better fit the hardware. --terrain also provide much greater opportunities for compressing the tiles on disk. More work will go into this in the future, so tiles with --terrain will end up being more compact despite have more geometry detail available when you need it. Robert. On Mon, Sep 29, 2008 at 4:20 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: Hi Robert, The main speed up with using --terrain in the osgdem/vpbmaster build is that the tile geometry doesn't need to simplified - it can just be aquired from the source DEM's as grids and then output as grids. [...] The key thing to remember with --terrain databases is that since the triangulation is done dynamically on load you do load balancing - you can set the Terrain::setSampleRatio() according to the hardware that you have Ok, so in order to get --terrain databases to work optimally on all machines I would have to expose this setting in my software's config files (for example) so that it can be tweaked according to each machine's hardware, is that right? I would suspect that on relatively flat terrain, the terrain database using simplified geometry might run fast enough on all machines (or all reasonably fast machines) without losing any relevant detail, whereas the --terrain database would be too slow on older machines, which would require that we lower the sampleRatio, and thus lose some detail? Is that possible? In that case, if we need to support a large number of different hardware configurations, we might be willing to accept the longer build times of not using --terrain in exchange for not needing to tweak sampleRatio and not losing any detail. Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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] Example osgtexture1d
Hi Mathieu, EYE_LINEAR is only relative to the eye when you use a identiy modelview matrix. Robert. On Mon, Sep 29, 2008 at 4:06 PM, Mathieu MARACHE [EMAIL PROTECTED] wrote: Hi, While playing with the example osgtexture1d, I wasn't able to see the changes from object linear to eye linear mode. I've run the example both on linux and windows with latest svn version. I would have expected to see bands of colours linked to the object in OBJECT_LINEAR and eye linked bands of colours in EYE_LINEAR mode. But it seems to me that only the OBJECT_LINEAR mode is working... Could someone please test it and see if the dumptruck changes it's texture every other second to eliminate a possible driver issue ? Thanks in advance -- Mathieu ___ 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] 2.6.1 RC1 tag created
Paul, Will this release include the FLT Export fix for PositionAttitudeTransforms AND the FLT ExportOptions texture path stripping option initialization in the constructor with ReaderWriterOptions passed in? Thanks, John Argentieri -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Friday, September 26, 2008 1:53 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] 2.6.1 RC1 tag created Kubuntu 7.10, 64bit, 8800GTS, Quad core Intel. gcc --version gcc (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2) Compiles cleanly and examples run fine ;-) Excellent, thanks. I've tested in WinXP w/ VS8, and OSX w/ gcc 4.0.1, so the major platforms are covered. I'll aim for an Oct 1 official release. -Paul ___ 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] Converting GeoTiff to UTM - unable to compute output bounds
J-S, if you know it is UTM 32N, you can assign that CS with something like gdal_translate -a_srs +proj=utm +zone=32 +datum=WGS84 +units=m file.tif file.utm32.tif HTH. Glenn On Mon, Sep 29, 2008 at 12:06 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: Hi Glenn, J-S, from the looks of the coords, your original file may have already been in UTM to begin with. When you ran gdal_translate -a_srs WGS84 file.tif file.wgs84.tif you assigned a WGS84 projection to what appears to be a UTM tif file. Can you double-check this? Hm, interesting, all those unknown, unnamed and unretrievable values looked to me like I needed to assign a projection to the file... You're right, VPB can use the original file no problem. But won't the units be lat/long degrees then? I need meters. I'm waiting for the results... Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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 -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : +1.703.652.4791 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.6.1 RC1 tag created
Paul, Will this release include the FLT Export fix for PositionAttitudeTransforms AND the FLT ExportOptions texture path stripping option initialization in the constructor with ReaderWriterOptions passed in? Yes, both of those are included. The other FLT fix we discussed (the BIND_PER_PRIMITIVE fix) will have to wait for a future release, such as 2.8. I hope to get around to fixing that sometime in the next couple months. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Converting GeoTiff to UTM - unable to compute output bounds
Hi Glenn, J-S, if you know it is UTM 32N, you can assign that CS with something like gdal_translate -a_srs +proj=utm +zone=32 +datum=WGS84 +units=m file.tif file.utm32.tif OK, thanks for the tip. Slowly learning these tools and file formats... J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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] 2.6.1 RC1 tag created
Thanks! to Paul and the rest of the OSG devs for maintaining OSG as a great package. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Monday, September 29, 2008 1:49 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] 2.6.1 RC1 tag created Paul, Will this release include the FLT Export fix for PositionAttitudeTransforms AND the FLT ExportOptions texture path stripping option initialization in the constructor with ReaderWriterOptions passed in? Yes, both of those are included. The other FLT fix we discussed (the BIND_PER_PRIMITIVE fix) will have to wait for a future release, such as 2.8. I hope to get around to fixing that sometime in the next couple months. -Paul ___ 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
[osg-users] LiSPSM and main camera nearFarRatio?
Hi all, Hi Wojtek, I've been working on deploying the new LiSPSM in our simulators. While fixing a totally unrelated problem today (when viewing from inside the cockpit, the cockpit geometry was being clipped), I added some parameters to control the nearFarRatio on a camera. I have no idea why, but this seems to have an effect on shadows. More specifically, the shadows are being clipped. The default nearFarRatio is 0.0005, and when I set it just a bit lower, 0.00049, the shadow of the boom (arm) of our crane (when viewed from the cockpit) is clipped. The more I decrease the nearFarRatio, the more the shadows are clipped. I have looked a bit into the code, but since it's not my code, I may have a hard time finding out what is causing this. Off the top of your head, what might cause this? And what would you suggest to fix it (meaning, be able to control the nearFarRatio of my main camera and maintain correct shadows)? For reference, I have set minLightMargin to 100, and maxFarPlane to 5000. Thanks in advance, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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] LiSPSM and main camera nearFarRatio?
Hi J-S, I guess its related to my computation of clamped projection matrix. I need to compute this matrix myself as its not yet computed when I cull shadows. It is computed at the end of whole traversal. I copied clamping code from osgSim::OverlayNode. I guess that for this computation I may somehow use default clamp callback nearFarRatio. Put a breakpoint in line 255 in MinimalShadowMap.cpp. This is the line where clampProjectionMatrix is called and check what is the nearFarRation inside this call. Let me know what you find. I think I did it right, so there is chance the error may be somewhere else. Cheers,Wojtek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jean-Sebastien Guay Sent: Monday, September 29, 2008 9:28 PM To: OpenSceneGraph Users Subject: [osg-users] LiSPSM and main camera nearFarRatio? Hi all, Hi Wojtek, I've been working on deploying the new LiSPSM in our simulators. While fixing a totally unrelated problem today (when viewing from inside the cockpit, the cockpit geometry was being clipped), I added some parameters to control the nearFarRatio on a camera. I have no idea why, but this seems to have an effect on shadows. More specifically, the shadows are being clipped. The default nearFarRatio is 0.0005, and when I set it just a bit lower, 0.00049, the shadow of the boom (arm) of our crane (when viewed from the cockpit) is clipped. The more I decrease the nearFarRatio, the more the shadows are clipped. I have looked a bit into the code, but since it's not my code, I may have a hard time finding out what is causing this. Off the top of your head, what might cause this? And what would you suggest to fix it (meaning, be able to control the nearFarRatio of my main camera and maintain correct shadows)? For reference, I have set minLightMargin to 100, and maxFarPlane to 5000. Thanks in advance, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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] [osg-submissions] View Dependent Shadow maps(LispSM)
Hi Adrian, I will check it. Hopefully tomorrow (tuesday) Maybe I will be able to find what is wrong. Cheers, Wojtek [Wojciech Lewandowski] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Adrian Egli OpenSceneGraph (3D) Sent: Saturday, September 27, 2008 6:52 PM To: OpenSceneGraph Users Subject: Re: [osg-users] [osg-submissions] View Dependent Shadow maps(LispSM) I don't have any shadow, my scene look similar to the osgshadow one. but i have a strange behaviour. pseudo code: osg::Group g osg::Lightsource s; shadowed-addchild(s) shadowed-addchild(g) viewer.setData(shadowed) i don't have light on, need state set to switch on light () s-getOrCreateStateSet()-setAttributeAndModes(m_lightSource_Sun-getL ight(),osg::StateAttribute::ON); and pssm does work, but lispsm not (event with setlight(s-getLight()) adrian 2008/9/24 Wojciech Lewandowski [EMAIL PROTECTED] Hi, What is wrong ? It does not work ? Method accepts Light ptr. If you have LightNode simply use getLight() to pass right argument. Wojtek - Original Message - From: Adrian Egli OpenSceneGraph (3D) To: [EMAIL PROTECTED] ; OpenSceneGraph Users Sent: Wednesday, September 24, 2008 10:17 AM Subject: Re: [osg-users] [osg-submissions] View Dependent Shadow maps (LispSM) Thanks, it doesn't solve my problem. i will have a look into the code as soon as i have some time left adrian 2008/9/24 Wojciech Lewandowski [EMAIL PROTECTED] Thank You, Adrian Lispsm classes derive all methods from StandardShadowMap MinimalShadowMap. StandardShadowMap has setLight method. I believe this is what you want. Cheers, Wojtek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Adrian Egli OpenSceneGraph (3D) Sent: Tuesday, September 23, 2008 10:46 PM To: OpenSceneGraph Users Subject: Re: [osg-users] [osg-submissions] View Dependent Shadow maps (LispSM) Sorry, answered to wrong list but here i am right :-) Hi all, great algorithm. i have just one question. my scene has a lof of lighs, but only one should cast shadows. so would it be possible to add a method like in parallel splitted shadow map to tell the algorithm witch light it should be used for shadow casting. please have a short look at : _ParallelSplitShadowMap- setUserLight(m_sun.get()); this method allow to tell the sun light. :-) for example adrian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegrap h.org -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgPPU and multiple processor
Hi Art, It works fine to switch between multiple processor, with or without osg::Switch. It was my error too many threads in my application :D Thanks Alex Hi Alexandre, I have never tried to alternate osgppu's processors dynamicly while rendering. I am not sure if it is a good idea at all (even also for other kind of osg nodes), since osg provides a mechanism called osg::SwitchNode which do the trick. Could you try to use the SwitchNode as a parent node for the processors. This will force to render only the active processor hence changing effects on the fly. I think this wouldn't make troubles, however I am not sure ;) If this doesn't help, could you then provide me with a small example code reproducing the error. This would be helpful to eliminate the issue. Cheers, art ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] When to use AdapterWidget vs QOSGWidget?
I'm a little confused about the difference between AdapterWidget and QOSGWidget. As far as I can see AdapterWidget derives from QGLwidget and so should be a drop in replacement in any opengl sample. But QOSGWidget is a QWidget and so can be used directly in a mainwindow. Are there any other performance/capability differences between them? Which should be the starting point for a new application on QT4 Thanks Martin ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] When to use AdapterWidget vs QOSGWidget?
Hi Martin, AdapterWidget using GraphicsWindowEmbedded to enable osgViewer to reuse an already create OpenGL context, this route is easy to implement, but and it's a big but, it doesn't integrate any of the high level context management that multi-threading or switching between contexts requires - this means you can only use it in places where you have a single viewer per window. For a fully capably viewer you need to use QOSGWidget which uses osgViewer itself to create and manage the graphics context, but using QT to create the window. This route allows the Viewer/CompositeViewer to handle multiple contexts and multi-threading. Robert. On Mon, Sep 29, 2008 at 11:48 PM, [EMAIL PROTECTED] wrote: I'm a little confused about the difference between AdapterWidget and QOSGWidget. As far as I can see AdapterWidget derives from QGLwidget and so should be a drop in replacement in any opengl sample. But QOSGWidget is a QWidget and so can be used directly in a mainwindow. Are there any other performance/capability differences between them? Which should be the starting point for a new application on QT4 Thanks Martin ___ 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
