Re: [osg-users] Segmentation Fault with std::string
Hi Dan,
Are you running the viewer multi-threaded? By default the OSG will
check your available CPU cores and enable multi-threading if you have
2 more more cores so it may well be multi-threaded.
When the viewer is running the draw thread in a separate graphics
thread the previous frame rendering can run at the same time as the
current frames update, event and cull traversals. If you modify a
drawable or state component in the update phase while the rendering is
still happening then you are likely to get a crash.
The OSG has a built in mechanism for preventing to modification and
rendering happening at the same time - you simply set the DataVariance
on the drawable that you wish to update to DYNAMIC rather than leave
it in it's default of STATIC.
The other alternative is to set the viewer to SingleThreaded.
For more info on this topic have a look through the archives.
Robert.
On 14 November 2011 03:38, dan marshal dash...@gmail.com wrote:
I am trying to update a osgText label object. After about 3000 updates I get
a std::bad_alloc termination.
I am converting a integer value that usually has only 6 or 7 characters in
the string and I thought sprintf would be the fastest and easiest way to
convert from int to std:string.
What is the fastest way to convert from int to str:string?
Any suggestions on how to avoid the segmentation termination?
Thank you for your help.
cc
void quanthud::setLabel(int id, int val)
{
quantLabel-setText(itostr(val));
}
std::string quanthud::itostr(int val)
{
char buff[14];
return std::string(buff, sprintf(buff, %d, val));
}
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=43855#43855
___
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] VDSM Shader problems
Hi
I've recently been testing out the new VDSM shadow implementation in trunk,
it's looking really nice.
I have a problem with the default fragment shader - it stops working as
soon as I attach a vertex shader, even a quite innocuous one like this:
void main(void) {
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex ;
gl_TexCoord[0] = gl_MultiTexCoord0;
gl_TexCoord[1] = gl_MultiTexCoord1;
}
I am working with the osgshadow demo program, modified to attach the above
shader alongside the fragment shader, and before the VDSM is constructed I
edit the settings so that the shaders are constructed and used like this:
settings-setShaderHint(osgShadow::ShadowSettings::PROVIDE_VERTEX_AND_FRAGMENT_SHADER);
The strange result is that both the vertex and fragment shaders appear to
run and there are no warnings about errors compiling or linking the
them.However the call to shadow2DProj() will always return (1,1,1,1) iff a
vertex shader is attached, but work fine without a vertex shader present -
ie every fragment is treated as shadowed.
It feels like there is something vital missing from the vertex shader that
shadow2DProj relies upon, and which is provided by the fixed function
pipeline?
I've also stripped the fragment shader down to simply perform a texture
lookup on the base texture and modulate by the value returned from
shadow2DProj, but this doesn't appear to make any difference.
Has anyone seen anything like this before? Ideas?
TIA
Mike
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VDSM Shader problems
Hi Mike,
You can't just throw in a very simple vertex shader to replace the
built in vertex shader and expect it to work. The vertex shader has
to use texgen to create the texture coordinates for the shadow map.
Robert.
On 14 November 2011 12:06, Mike Connell michael.conn...@gmail.com wrote:
Hi
I've recently been testing out the new VDSM shadow implementation in trunk,
it's looking really nice.
I have a problem with the default fragment shader - it stops working as soon
as I attach a vertex shader, even a quite innocuous one like this:
void main(void) {
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex ;
gl_TexCoord[0] = gl_MultiTexCoord0;
gl_TexCoord[1] = gl_MultiTexCoord1;
}
I am working with the osgshadow demo program, modified to attach the above
shader alongside the fragment shader, and before the VDSM is constructed I
edit the settings so that the shaders are constructed and used like this:
settings-setShaderHint(osgShadow::ShadowSettings::PROVIDE_VERTEX_AND_FRAGMENT_SHADER);
The strange result is that both the vertex and fragment shaders appear to
run and there are no warnings about errors compiling or linking the
them.However the call to shadow2DProj() will always return (1,1,1,1) iff a
vertex shader is attached, but work fine without a vertex shader present -
ie every fragment is treated as shadowed.
It feels like there is something vital missing from the vertex shader that
shadow2DProj relies upon, and which is provided by the fixed function
pipeline?
I've also stripped the fragment shader down to simply perform a texture
lookup on the base texture and modulate by the value returned from
shadow2DProj, but this doesn't appear to make any difference.
Has anyone seen anything like this before? Ideas?
TIA
Mike
___
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] VDSM Shader problems
Doh!
Thanks Robert, I had a niggling feeling it was something terribly
obvious...For the benefit of anyone following in my footsteps, you might
want to start off with a vertex shader looking more like this:
uniform sampler2D baseTexture;
uniform int baseTextureUnit;
uniform sampler2DShadow shadowTexture;
uniform int shadowTextureUnit;
void main(void) {
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex ;
gl_TexCoord[0] = gl_MultiTexCoord0; // base texture
gl_TexCoord[1] = gl_MultiTexCoord1; // shadow tex if it is actually
bound to 1
vec4 ecPosition = gl_ModelViewMatrix*gl_Vertex;
gl_TexCoord[1] =
ecPosition*mat4(gl_EyePlaneS[1],gl_EyePlaneT[1],gl_EyePlaneR[1],gl_EyePlaneQ[1]);
}
best
Mike
On 14 November 2011 14:01, Robert Osfield robert.osfi...@gmail.com wrote:
Hi Mike,
You can't just throw in a very simple vertex shader to replace the
built in vertex shader and expect it to work. The vertex shader has
to use texgen to create the texture coordinates for the shadow map.
Robert.
On 14 November 2011 12:06, Mike Connell michael.conn...@gmail.com wrote:
Hi
I've recently been testing out the new VDSM shadow implementation in
trunk,
it's looking really nice.
I have a problem with the default fragment shader - it stops working as
soon
as I attach a vertex shader, even a quite innocuous one like this:
void main(void) {
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex ;
gl_TexCoord[0] = gl_MultiTexCoord0;
gl_TexCoord[1] = gl_MultiTexCoord1;
}
I am working with the osgshadow demo program, modified to attach the
above
shader alongside the fragment shader, and before the VDSM is constructed
I
edit the settings so that the shaders are constructed and used like this:
settings-setShaderHint(osgShadow::ShadowSettings::PROVIDE_VERTEX_AND_FRAGMENT_SHADER);
The strange result is that both the vertex and fragment shaders appear to
run and there are no warnings about errors compiling or linking the
them.However the call to shadow2DProj() will always return (1,1,1,1) iff
a
vertex shader is attached, but work fine without a vertex shader present
-
ie every fragment is treated as shadowed.
It feels like there is something vital missing from the vertex shader
that
shadow2DProj relies upon, and which is provided by the fixed function
pipeline?
I've also stripped the fragment shader down to simply perform a texture
lookup on the base texture and modulate by the value returned from
shadow2DProj, but this doesn't appear to make any difference.
Has anyone seen anything like this before? Ideas?
TIA
Mike
___
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] osgViewer::GraphicsWindowEmbeded causing OpenGL error
1) Is the CAVElib creating multiple graphics contexts? If so there you'll need a GraphicsWindow on the OSG per context you can't reuse the same window per context. Sorry, forgot to describe CAVElib's behavior there. CAVElib will create a thread for each wall of the cave and thus a new context. Each of these threads will act exactly the same and call the init function once and then call frame followed by display. Using a few built in functions I can use if/else blocks to alter behavior based on the wall but it would have to be in the above three functions; I can just make the master wall update positions and what not. So, to answer your question a bit more specifically, there will be one embedded window for each context. 2) Do you really need to use CAVElib? The OSG itself can render to a cave just by setting up the Viewer slave Camera appropriately. There is also integration with other 3rd party VR libs. Yup, for the present, I have to use CAVElib. I've ready many good things about vrjuggler and would love to use it but the clear time here would be around 6 months if I'm lucky. The project is due in a few weeks so that isn't an option at present. :([/quote] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43861#43861 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer::GraphicsWindowEmbeded causing OpenGL error
Hi Joshua, On 14 November 2011 15:38, Joshua Cook countryartis...@gmail.com wrote: 1) Is the CAVElib creating multiple graphics contexts? If so there you'll need a GraphicsWindow on the OSG per context you can't reuse the same window per context. Sorry, forgot to describe CAVElib's behavior there. CAVElib will create a thread for each wall of the cave and thus a new context. Each of these threads will act exactly the same and call the init function once and then call frame followed by display. Using a few built in functions I can use if/else blocks to alter behavior based on the wall but it would have to be in the above three functions; I can just make the master wall update positions and what not. So, to answer your question a bit more specifically, there will be one embedded window for each context. GraphicsWindowEmbedded is designed to be used with single context, single threaded applications, not multi-threaded multi-context applications like your are describing. osgViewer itself is designed to run multi-threaded multi-context and it's own native windowing support provides CAVElib like functionality out of the box - you simply create slave Camera for each of the faces of the cave. Given that the OSG does what need already I would asks very specifically, what about CAVElib do you need to use that the OSG doesn't already provide. This is key as right now you are wasting time on stuff that to me seems like going the wrong direction. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG website unresponsive
I'm been having the same problem today and all weekend, connecting to www.openscenegraph.org eventually times out. Scott -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43864#43864 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] NVIDIA Driver Problem?
Can somebody do a test for me? I'm using OSG 3.0.0 and this works with NVIDIA
Driver (Linux) 260.19.21 but doesn't seem to work with newer versions of the
driver (e.g. 275.31 beta) with no other changes being made. I've been in
contact with NVIDIA with this problem and they seem to think that it is an OSG
problem.
I'm having trouble when I create an osgViewer, destroy it, restart the X server
and then create the osgViewer. I've boiled my problem down to a small test
case in the attached file which is a slightly modified version of osgviewer.
I know this test case is somewhat convoluted but bare with me. Our application
is required to restart the X server before starting to display an image.
Normally, osgviewer would do the following:
1) osgViewer::Viewer viewer(arguments);
2) viewer.setSceneData( loadedModel.get() );
3) viewer.realize();
4) viewer.run();
5) exit(0);
I have modified it to do the following:
Code:
while (forever)
{
{ // Define a scope of the osgViewer::Viewer
osgViewer::Viewer viewer(arguments);
viewer.setSceneData( loadedModel.get() );
viewer.realize();
viewer.run();
} // osgViewer::Viewer scope has ended and its destructor called.
sleep(2);
system(“/usr/sbin/gdm-restart”);
sleep(20);
}
Compile and run this program. Since this program restarts the X server (with
the gdm-restart command) and attempts to display an image, you will need use
two machines (a remote machine and a target machine). Running this using one
machine will cause the program to be killed when the X server is restarted. To
run this program, do the following:
a. On the console of the target machine, login normally. Open a terminal
window and type “xhost +”
b. From a remote computer login to your target machine and “setenv DISPLAY
:0.0” to keep the display on the remote machine.
c. From this remote computer window, run the attached version of osgviewer as
“osgviewer cow.osg”.
d. Hit the escape key on the target machine to dismiss the cow being
displayed.
e. At this point, the target machine X server will restart. IMMEDIATELY after
the X server has restarted, login to the target machine again from its
console. Open a terminal window and select “xhost +” again. It you don't do
this last part, you will not have permissions to display an image on the
target machine from the remote machine. The program will give you 20 second
before it attempts to display an image on on the target machine.
f. At this point, you should see a cow image on the display but with this new
driver, we’ve been seeing a totally black image.
When I run this program, instead of seeing the cow image the second time, I'm
seeing a black screen. I didn't see this problem with earlier version of the
NVIDIA driver (also using OSG 3.0.0).
Is anybody else having this problem?
Paul P.
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=43865#43865
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2010 Robert Osfield
*
* This application is open source and may be redistributed and/or modified
* freely and without restriction, both in commercial and non commercial
applications,
* as long as this copyright notice is maintained.
*
* This application is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
*/
#include osgDB/ReadFile
#include osgUtil/Optimizer
#include osg/CoordinateSystemNode
#include osg/Switch
#include osgText/Text
#include osgViewer/Viewer
#include osgViewer/ViewerEventHandlers
#include osgGA/TrackballManipulator
#include osgGA/FlightManipulator
#include osgGA/DriveManipulator
#include osgGA/KeySwitchMatrixManipulator
#include osgGA/StateSetManipulator
#include osgGA/AnimationPathManipulator
#include osgGA/TerrainManipulator
#include osgGA/SphericalManipulator
#include iostream
int main(int argc, char** argv)
{
// use an ArgumentParser object to manage the program arguments.
osg::ArgumentParser arguments(argc,argv);
arguments.getApplicationUsage()-setApplicationName(arguments.getApplicationName());
arguments.getApplicationUsage()-setDescription(arguments.getApplicationName()+
is the standard OpenSceneGraph example which loads and visualises 3d models.);
arguments.getApplicationUsage()-setCommandLineUsage(arguments.getApplicationName()+
[options] filename ...);
arguments.getApplicationUsage()-addCommandLineOption(--image
filename,Load an image and render it on a quad);
arguments.getApplicationUsage()-addCommandLineOption(--dem
filename,Load an image/DEM and render it on a HeightField);
arguments.getApplicationUsage()-addCommandLineOption(--login url
username password,Provide authentication information for http file
access.);
unsigned int helpType = 0;
if ((helpType = arguments.readHelpType()))
{
Re: [osg-users] osgViewer::GraphicsWindowEmbeded causing OpenGL error
Robert, Thanks for the replies. Anyhow, the reasoning has to do with risk and periferal support; head tracker, a wand, and other assorted goodies CAVElib already deals with. I probably could write something that did the same but would have a heck of a time convincing them it would be the best approach with the deadline looming like Lancelot at a wedding party. The other thing that CAVElib does is sync the 3D effect over multiple computers. I'm fairly sure that is not too difficult to do but since I've no experience there I wouldn't be able to argue that point very effectively. Yes, they are fairly weak arguments but it is what I have to work with. :) Anyhow, I'll drop the embeded window and look towards another solution. Mayhaps it will be with the osg::Viewer that I'll find the final, correct answer. Thanks again. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43866#43866 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [vpb] osgdem: color terrain isntead of texture mapping it
Hello, Hoping for a bit of help. What I've been doing: I have been using osgdem to merge a dted data geotiff with a geotiff with rgb color values into an ive terrain complex. I am using the -t flag to tell osgdem that my geotiff should be treated as a texture file. However, the rgb values in the geotiff represent scaled physical properties such as temperature. What I think I need to do: I would like to be able to access the color (and thus physical property) of each primitive once I read this ive terrain complex into an osg program. I have an osg node visitor set up that loops over the geometry of my terrain and can loop over all primitives etc, but I do not know how to access the textures and their colors from the primitives. What I think is impossible but would be ideal: What I would really like is if I could tell osgdem to assign each primitive an rgb color value instead of a texture (based on my geotiff file), but I don't think that's possible? I've been turning various osgdem flags on and off and experimenting with it, but thought i would ask the forum to see if anyone has any recommendations for me. Thanks in advance for your help. -Ethan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43867#43867 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG website unresponsive
Hi, The OpenSceneGraph logo loads, but the redirection to the wiki, and the wiki link itself (www.openscenegraph.org/projecst/osg), does not work (from South Africa). Cheers, Chris On Mon, Nov 14, 2011 at 9:42 PM, Scott Wasinger swasin...@comcast.netwrote: Still Not able to connect to the osg homepage. I don't know if this is related but I'm located in Colorado like Chris 'Xenon' Hanson. Is anybody else having this problem? Here is the screen capture from my web browser: http://forum.openscenegraph.org/files/screenshot_mozilla_106.png -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43868#43868 ___ 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 website unresponsive
Ditto from SE USA CD Chris Jaquet wrote: Hi, The OpenSceneGraph logo loads, but the redirection to the wiki, and the wiki link itself (www.openscenegraph.org/projecst/osg (http://www.openscenegraph.org/projecst/osg)), does not work (from South Africa). Cheers, Chris On Mon, Nov 14, 2011 at 9:42 PM, Scott Wasinger () wrote: Still Not able to connect to the osg homepage. I don't know if this is related but I'm located in Colorado like Chris 'Xenon' Hanson. Is anybody else having this problem? Here is the screen capture from my web browser: http://forum.openscenegraph.org/files/screenshot_mozilla_106.png (http://forum.openscenegraph.org/files/screenshot_mozilla_106.png) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43868#43868 (http://forum.openscenegraph.org/viewtopic.php?p=43868#43868) ___ osg-users mailing list () http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org (http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org) -- Post generated by Mail2Forum -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43870#43870 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer::GraphicsWindowEmbeded causing OpenGL error
Hi Joshua, See if you can use the peripheral support from CAVElib and just plugin in the camera view and projection matrix settings into the osgViewer's Camera's and let the OSG do the threading and rendering. Robert. On 14 November 2011 18:25, Joshua Cook countryartis...@gmail.com wrote: Robert, Thanks for the replies. Anyhow, the reasoning has to do with risk and periferal support; head tracker, a wand, and other assorted goodies CAVElib already deals with. I probably could write something that did the same but would have a heck of a time convincing them it would be the best approach with the deadline looming like Lancelot at a wedding party. The other thing that CAVElib does is sync the 3D effect over multiple computers. I'm fairly sure that is not too difficult to do but since I've no experience there I wouldn't be able to argue that point very effectively. Yes, they are fairly weak arguments but it is what I have to work with. :) Anyhow, I'll drop the embeded window and look towards another solution. Mayhaps it will be with the osg::Viewer that I'll find the final, correct answer. Thanks again. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43866#43866 ___ 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] RenderBin-question/problem
Hi Stephan, I'm just about to do a 4 day course so will be out of the loop till next week. Hopefully others will be able to pitch in to look at the problem before then. Robert. On 14 November 2011 16:56, Stephan Maximilian Huber ratzf...@digitalmind.de wrote: Hi I am having problems with renderbins, this is maybe a bug in osg or I have problems to understand the concepts behind renderbins. Here's a simplified test: root + PAT 1 + geode + geo + PAT 2 + geode + geo + PAT 3 + geode + geo the root-group has a stateset with TRANSPARENT_BIN, PAT 1 is positioned at (0/0/0) and has a geode containing a geometry with a red quad (see links) and another PAT 2 holding some linestrip geometry. PAT 3 contains a geode with a green geometry, positioned at 100/100/100. The camera projection matrix is basically a hud. When PAT 2 has a stateset with -setRenderingHint(osg::StateAttribute::TRANSPARENT_BIN) then the depth-sorting is wrong (see bad.osg), if I remove the setRenderingHint-call, everything is correct (good.osg). So what's wrong with my setup? basically all drawables should end in render-bin 10, regardless of additional setRenderingHint-calls by enclosed childs, shouldn't they? AFAIK this worked in previous versions of osg. Attached you'll find two osg-models showing the problem and the corresponding screenshots: good: http://scrups.cefix.org//8k/ikhqjtvumlwco.png bad : http://scrups.cefix.org//8r/nozjb4u5y8owc.png This is with a recent checkout of osg-trunk (3.1.0) cheers, Stephan ___ 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 website unresponsive
Earlier today I emailed Jose Luis Hidalgo about the server, I haven't heard back yet. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] NVIDIA Driver Problem?
paul1492 wrote:
Can somebody do a test for me? I'm using OSG 3.0.0 and this works with NVIDIA
Driver (Linux) 260.19.21 but doesn't seem to work with newer versions of the
driver (e.g. 275.31 beta) with no other changes being made. I've been in
contact with NVIDIA with this problem and they seem to think that it is an
OSG problem.
I'm having trouble when I create an osgViewer, destroy it, restart the X
server and then create the osgViewer. I've boiled my problem down to a small
test case in the attached file which is a slightly modified version of
osgviewer.
I know this test case is somewhat convoluted but bare with me. Our
application is required to restart the X server before starting to display an
image.
Normally, osgviewer would do the following:
1) osgViewer::Viewer viewer(arguments);
2) viewer.setSceneData( loadedModel.get() );
3) viewer.realize();
4) viewer.run();
5) exit(0);
I have modified it to do the following:
Code:
while (forever)
{
{ // Define a scope of the osgViewer::Viewer
osgViewer::Viewer viewer(arguments);
viewer.setSceneData( loadedModel.get() );
viewer.realize();
viewer.run();
} // osgViewer::Viewer scope has ended and its destructor called.
sleep(2);
system(“/usr/sbin/gdm-restart”);
sleep(20);
}
Compile and run this program. Since this program restarts the X server (with
the gdm-restart command) and attempts to display an image, you will need use
two machines (a remote machine and a target machine). Running this using one
machine will cause the program to be killed when the X server is restarted.
To run this program, do the following:
a. On the console of the target machine, login normally. Open a terminal
window and type “xhost +”
b. From a remote computer login to your target machine and “setenv DISPLAY
:0.0” to keep the display on the remote machine.
c. From this remote computer window, run the attached version of osgviewer
as “osgviewer cow.osg”.
d. Hit the escape key on the target machine to dismiss the cow being
displayed.
e. At this point, the target machine X server will restart. IMMEDIATELY
after the X server has restarted, login to the target machine again from
its console. Open a terminal window and select “xhost +” again. It you
don't do this last part, you will not have permissions to display an image
on the target machine from the remote machine. The program will give you 20
second before it attempts to display an image on on the target machine.
f. At this point, you should see a cow image on the display but with this
new driver, we’ve been seeing a totally black image.
When I run this program, instead of seeing the cow image the second time, I'm
seeing a black screen. I didn't see this problem with earlier version of the
NVIDIA driver (also using OSG 3.0.0).
Is anybody else having this problem?
Paul P.
Greetings!
Since your so lucky to try out one of NVidea Beta Drivers, have you ran this
across the NVidia test team first? Also, I didn't get what Graphics Card you
are using!
That is where I would go with this! OSG works on top of OpenGL other than that
it is doing nothing directly with the card.
If your using beta, I would look towards the fact that it may be still buggy!
Also, it has been my experience with NVidia that newer drivers in Linux, don't
necessary mean that it's an improvement. I have had to backtrack on drivers
even on my OpenGL code stuff because Nividia broke something in the process.
They are more concerned over a Windows driver than Linux I think!
David Glenn
---
D Glenn 3D Computer Graphics amp; Media Systems.
www.dglenn.com
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=43874#43874
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG website unresponsive
Same problem in New Jersey, about halfway between Colorodo and South Africa. -Don osg-users-requ...@lists.openscenegraph.org wrote: Send osg-users mailing list submissions to osg-users@lists.openscenegraph.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org or, via email, send a message with subject or body 'help' to osg-users-requ...@lists.openscenegraph.org You can reach the person managing the list at osg-users-ow...@lists.openscenegraph.org When replying, please edit your Subject line so it is more specific than Re: Contents of osg-users digest... Today's Topics: 1. Re: OSG website unresponsive (Chris Jaquet) Subject: Re: [osg-users] OSG website unresponsive From: Chris Jaquet chrisjaq...@gmail.com Date: Mon, 14 Nov 2011 21:53:20 +0200 To: osg-users@lists.openscenegraph.org Hi, The OpenSceneGraph logo loads, but the redirection to the wiki, and the wiki link itself (www.openscenegraph.org/projecst/osg http://www.openscenegraph.org/projecst/osg), does not work (from South Africa). Cheers, Chris On Mon, Nov 14, 2011 at 9:42 PM, Scott Wasinger swasin...@comcast.net mailto:swasin...@comcast.net wrote: Still Not able to connect to the osg homepage. I don't know if this is related but I'm located in Colorado like Chris 'Xenon' Hanson. Is anybody else having this problem? Here is the screen capture from my web browser: http://forum.openscenegraph.org/files/screenshot_mozilla_106.png -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43868#43868 ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] NVIDIA Driver Problem?
dglenn wrote: Greetings! Since your so lucky to try out one of NVidea Beta Drivers, have you ran this across the NVidia test team first? Also, I didn't get what Graphics Card you are using! That is where I would go with this! OSG works on top of OpenGL other than that it is doing nothing directly with the card. If your using beta, I would look towards the fact that it may be still buggy! Also, it has been my experience with NVidia that newer drivers in Linux, don't necessary mean that it's an improvement. I have had to backtrack on drivers even on my OpenGL code stuff because Nividia broke something in the process. They are more concerned over a Windows driver than Linux I think! Sorry that's about all I can help you at this point! I was given this Beta driver by NVIDIA to fix another problem. That other problem seems to have been fixed but then two other problems showed up. One I found a work around for and this is the other. As I said in my earlier post, my Point-Of-Contact at NVIDIA seems to dismiss the new problem as an OSG problem even though the problem showup with only a drive change. I've tried new non-beta drivers and I believe I have the same problem. FYI: I'm using a Quadro 5000. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43876#43876 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] NVIDIA Driver Problem?
Paul, Have you done a search in this mailing list/forum for nvidia 275? Follow some of the threads you find, and see if any help you track down or fix your problem. Due to previous discussions on the topic, I have been careful to generally avoid this specific driver. I hope this helps... D.J. On Mon, Nov 14, 2011 at 5:08 PM, Paul Palumbo paul1...@yahoo.com wrote: dglenn wrote: Greetings! Since your so lucky to try out one of NVidea Beta Drivers, have you ran this across the NVidia test team first? Also, I didn't get what Graphics Card you are using! That is where I would go with this! OSG works on top of OpenGL other than that it is doing nothing directly with the card. If your using beta, I would look towards the fact that it may be still buggy! Also, it has been my experience with NVidia that newer drivers in Linux, don't necessary mean that it's an improvement. I have had to backtrack on drivers even on my OpenGL code stuff because Nividia broke something in the process. They are more concerned over a Windows driver than Linux I think! Sorry that's about all I can help you at this point! I was given this Beta driver by NVIDIA to fix another problem. That other problem seems to have been fixed but then two other problems showed up. One I found a work around for and this is the other. As I said in my earlier post, my Point-Of-Contact at NVIDIA seems to dismiss the new problem as an OSG problem even though the problem showup with only a drive change. I've tried new non-beta drivers and I believe I have the same problem. FYI: I'm using a Quadro 5000. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43876#43876 ___ 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] Terrain Height as Texture
Hi, I used osgdem to create a Terraindatabase from 2 image files (Heightmap and Colormap). Is there any way to access the height information in a texture? I need to do some calculations in the shader for which i need informations abount the surrounding terrain height, at guessed that it would be the easiest to look them up from a texture - but i only have the colormap in the *.ive files. I could replace the colormap by the heightmapt before generation (at least i think so) but i also want to use some finished databases. Thank you! Cheers, Jonathan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43878#43878 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [vpb] Terrain Height as Texture
Hi Jonathan, I used osgdem to create a Terraindatabase from 2 image files (Heightmap and Colormap). Is there any way to access the height information in a texture? I need to do some calculations in the shader for which i need informations abount the surrounding terrain height, at guessed that it would be the easiest to look them up from a texture - but i only have the colormap in the *.ive files. If you can relate scene units to real height in some way (say scene units are meters and Z=0 corresponds to H meters above sea level) then it's pretty trivial to do this without even having the height in a texture. Just transform vertex coordinates to world space in the vertex shader, output those in a varying, and in the fragment shader you'll have the world-space location of your pixel. The Z of this will be the height, relative to H above. You can pass H to the shaders in a uniform that you set at your scene root. If you're in a weird projection then I wouldn't know, but this should work fine for flat-earth models I think. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] NVIDIA Driver Problem?
D.J. Caldwell wrote: Paul, Have you done a search in this mailing list/forum for nvidia 275? Follow some of the threads you find, and see if any help you track down or fix your problem. Due to previous discussions on the topic, I have been careful to generally avoid this specific driver. I hope this helps... D.J. On Mon, Nov 14, 2011 at 5:08 PM, Paul Palumbo () wrote: dglenn wrote: Greetings! Since your so lucky to try out one of NVidea Beta Drivers, have you ran this across the NVidia test team first? Also, I didn't get what Graphics Card you are using! That is where I would go with this! OSG works on top of OpenGL other than that it is doing nothing directly with the card. If your using beta, I would look towards the fact that it may be still buggy! Also, it has been my experience with NVidia that newer drivers in Linux, don't necessary mean that it's an improvement. I have had to backtrack on drivers even on my OpenGL code stuff because Nividia broke something in the process. They are more concerned over a Windows driver than Linux I think! Sorry that's about all I can help you at this point! I was given this Beta driver by NVIDIA to fix another problem. That other problem seems to have been fixed but then two other problems showed up. One I found a work around for and this is the other. As I said in my earlier post, my Point-Of-Contact at NVIDIA seems to dismiss the new problem as an OSG problem even though the problem showup with only a drive change. I've tried new non-beta drivers and I believe I have the same problem. FYI: I'm using a Quadro 5000. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43876#43876 (http://forum.openscenegraph.org/viewtopic.php?p=43876#43876) ___ osg-users mailing list () http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org (http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org) -- Post generated by Mail2Forum Wow I knew that NVidia has been known to make a dud or two, but 275.33.x was a turkey! What can I say about it but I rest my case! I would try to use, maybe a 260.19.44 driver. I using that on a Quatro 4000 in my lab right now and it works very well! I do get rather irritated when a company can't fess-up to their mistakes and use the Not My Problem excuse! David Glenn --- D Glenn 3D Computer Graphics amp; Media Systems. www.dglenn.com -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43880#43880 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [forum] Lightwave 11 Prerelease is now available
Greetings All! For: anyone that wants to know ! Just to let you know that Newtek has announced the prerelease of their Lightwave Product Version 11 that you can get online at their website. This is a prelease only! The full release will be available by the end of the year. If you are a Lightwave 10 or 10.1 user, you have to buy the prerelease version as an upgrade to the full Lightwave 11. Note: One of the new features of Lightwave 11 is the new interoperability between itself and other products including Unity. Anyway, Enjoy All! David Glenn --- D Glenn 3D Computer Graphics amp; Media Systems. www.dglenn.com -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43881#43881 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] NVIDIA Driver Problem?
Hi,
before I go restart X-servers all over the lab, can you give a bit more
info... :)
On 14/11/2011 20:13, Paul Palumbo wrote:
Can somebody do a test for me? I'm using OSG 3.0.0 and this works
with NVIDIA Driver (Linux) 260.19.21 but doesn't seem to work with
newer versions of the driver (e.g. 275.31 beta) with no other changes
being made. I've been in contact with NVIDIA with this problem and
they seem to think that it is an OSG problem.
I'm having trouble when I create an osgViewer, destroy it, restart
the X server and then create the osgViewer. I've boiled my problem
down to a small test case in the attached file which is a slightly
modified version of osgviewer.
I know this test case is somewhat convoluted but bare with me. Our
application is required to restart the X server before starting to
display an image.
Normally, osgviewer would do the following: 1) osgViewer::Viewer
viewer(arguments); 2) viewer.setSceneData( loadedModel.get() ); 3)
viewer.realize(); 4) viewer.run(); 5) exit(0);
I have modified it to do the following:
Code:
while (forever) { { // Define a scope of the osgViewer::Viewer
osgViewer::Viewer viewer(arguments); viewer.setSceneData(
loadedModel.get() ); viewer.realize(); viewer.run(); } //
osgViewer::Viewer scope has ended and its destructor called.
sleep(2); system(“/usr/sbin/gdm-restart”); sleep(20); }
Do you have to do the restart from a C++ app? What happens if you
manually restart gdm and then start another osg process? It might be
some GL resource that is only released when the process exits. Or a
windowing system static that OSG assumes is still valid, but is
obviously not since the gl driver restarted.
I know there was a discussion about static resources when e.g. using OSG
as part of a larger library or as a plugin. How does one get OSG into
its original state without restarting the process... I can go dig it up
if you want.
jp
Compile and run this program. Since this program restarts the X
server (with the gdm-restart command) and attempts to display an
image, you will need use two machines (a remote machine and a target
machine). Running this using one machine will cause the program to be
killed when the X server is restarted. To run this program, do the
following:
a. On the console of the target machine, login normally. Open a
terminal window and type “xhost +” b. From a remote computer login
to your target machine and “setenv DISPLAY :0.0” to keep the
display on the remote machine. c. From this remote computer window,
run the attached version of osgviewer as “osgviewer cow.osg”. d.
Hit the escape key on the target machine to dismiss the cow being
displayed. e. At this point, the target machine X server will
restart. IMMEDIATELY after the X server has restarted, login to the
target machine again from its console. Open a terminal window and
select “xhost +” again. It you don't do this last part, you will
not have permissions to display an image on the target machine from
the remote machine. The program will give you 20 second before it
attempts to display an image on on the target machine. f. At this
point, you should see a cow image on the display but with this new
driver, we’ve been seeing a totally black image.
When I run this program, instead of seeing the cow image the second
time, I'm seeing a black screen. I didn't see this problem with
earlier version of the NVIDIA driver (also using OSG 3.0.0).
Is anybody else having this problem?
Paul P.
-- Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=43865#43865
___ osg-users mailing
list osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [vpb] osgdem: color terrain isntead of texture mapping it
Hi Ethan, the triangle mesh of the terrain will represent the resolution of the DEM, not of the texture. Usualy texture resolution is higher than the DEM ones, therefore you would reduce your image resolution if you don't use textures but try to assign each vertex a color. But nevertheless you can access the color in the texture: Perform an intersection and you will get the vertex indices of the primitive you intersect. Additionally you'll get the ratio of the intersection between the vertices, then you can interpolate the coordinates of the 3 vertices and you have the texture coordiante you need to lookup the color in the texture. Cheers, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43885#43885 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
