[osg-users] osgGA::GUIEventHandler deprecated method
Hi All, I'm trying to implement picking and I found some examples where a deprecated method of osgGA::GUIEventHandler is used: bool handle(const osgGA::GUIEventAdapter, osgGA::GUIActionAdapter); This method seems deprecated at least from 3.0.1 to 3.2.1. So, which method should be used instead? Maybe the following one? boolhandle (const GUIEventAdapter ea, GUIActionAdapter aa, osg::Object *, osg::NodeVisitor *) Cheers, Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61384#61384 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] load example iphoneviewer error !!!
Hi, CullSettings::readEnvironmentalVariables() DatabasePager::addDatabaseThread() HANDLE_NON_HTTP DatabasePager::addDatabaseThread() HANDLE_ONLY_HTTP CullSettings::readEnvironmentalVariables() CullSettings::readEnvironmentalVariables() CullSettings::readEnvironmentalVariables() CullSettings::readEnvironmentalVariables() ShaderComposer::ShaderComposer() 0x8abc5e0 CullSettings::readEnvironmentalVariables() ShaderComposer::ShaderComposer() 0x8abd4d0 GraphicsContext::registerGraphicsContext 0xa8a6a60 ShaderComposer::ShaderComposer() 0xa8a6cd0 GraphicsContext::createNewContextID() creating contextID=0 Updating the MaxNumberOfGraphicsContexts to 1 uncompressed ive stream CullSettings::readEnvironmentalVariables() Font 0xa8a8870, numberOfTexturesAllocated 1 Warning: dynamic library 'osgPlugins-3.3.1/osgdb_freetype.so' does not exist (or isn't readable): dlopen(osgPlugins-3.3.1/osgdb_freetype.so, 9): image not found DynamicLibrary::failed loading osgPlugins-3.3.1/osgdb_freetype.so No valid object found for /Library/Fonts/Arial.ttf View::setSceneData() Reusing exisitng scene0x8ababf0 CameraManipulator::computeHomePosition(0, 0) boundingSphere.center() = (26634 37420 3733.74) boundingSphere.radius() = 37260.7 CameraManipulator::computeHomePosition(0x9221200, 0) boundingSphere.center() = (26634 37420 3733.74) boundingSphere.radius() = 37260.7 Warning: dynamic library 'osgPlugins-3.3.1/osgdb_freetype.so' does not exist (or isn't readable): dlopen(osgPlugins-3.3.1/osgdb_freetype.so, 9): image not found DynamicLibrary::failed loading osgPlugins-3.3.1/osgdb_freetype.so No valid object found for /Library/Fonts/Arial.ttf Warning: dynamic library 'osgPlugins-3.3.1/osgdb_freetype.so' does not exist (or isn't readable): dlopen(osgPlugins-3.3.1/osgdb_freetype.so, 9): image not found DynamicLibrary::failed loading osgPlugins-3.3.1/osgdb_freetype.so No valid object found for /Library/Fonts/Arial.ttf Warning: dynamic library 'osgPlugins-3.3.1/osgdb_freetype.so' does not exist (or isn't readable): dlopen(osgPlugins-3.3.1/osgdb_freetype.so, 9): image not found DynamicLibrary::failed loading osgPlugins-3.3.1/osgdb_freetype.so No valid object found for /Library/Fonts/Arial.ttf Warning: dynamic library 'osgPlugins-3.3.1/osgdb_freetype.so' does not exist (or isn't readable): dlopen(osgPlugins-3.3.1/osgdb_freetype.so, 9): image not found DynamicLibrary::failed loading osgPlugins-3.3.1/osgdb_freetype.so No valid object found for /Library/Fonts/Arial.ttf Warning: dynamic library 'osgPlugins-3.3.1/osgdb_freetype.so' does not exist (or isn't readable): dlopen(osgPlugins-3.3.1/osgdb_freetype.so, 9): image not found DynamicLibrary::failed loading osgPlugins-3.3.1/osgdb_freetype.so No valid object found for /Library/Fonts/Arial.ttf Warning: dynamic library 'osgPlugins-3.3.1/osgdb_freetype.so' does not exist (or isn't readable): dlopen(osgPlugins-3.3.1/osgdb_freetype.so, 9): image not found DynamicLibrary::failed loading osgPlugins-3.3.1/osgdb_freetype.so No valid object found for /Library/Fonts/Arial.ttf Warning: dynamic library 'osgPlugins-3.3.1/osgdb_freetype.so' does not exist (or isn't readable): dlopen(osgPlugins-3.3.1/osgdb_freetype.so, 9): image not found DynamicLibrary::failed loading osgPlugins-3.3.1/osgdb_freetype.so No valid object found for /Library/Fonts/Arial.ttf Warning: dynamic library 'osgPlugins-3.3.1/osgdb_freetype.so' does not exist (or isn't readable): dlopen(osgPlugins-3.3.1/osgdb_freetype.so, 9): image not found DynamicLibrary::failed loading osgPlugins-3.3.1/osgdb_freetype.so No valid object found for /Library/Fonts/Arial.ttf Warning: dynamic library 'osgPlugins-3.3.1/osgdb_freetype.so' does not exist (or isn't readable): dlopen(osgPlugins-3.3.1/osgdb_freetype.so, 9): image not found DynamicLibrary::failed loading osgPlugins-3.3.1/osgdb_freetype.so No valid object found for /Library/Fonts/Arial.ttf Warning: dynamic library 'osgPlugins-3.3.1/osgdb_freetype.so' does not exist (or isn't readable): dlopen(osgPlugins-3.3.1/osgdb_freetype.so, 9): image not found DynamicLibrary::failed loading osgPlugins-3.3.1/osgdb_freetype.so No valid object found for /Library/Fonts/Arial.ttf GraphicsContext::getWindowingSystemInterface() 0x8a970c00x719bd4 osg::State::_maxTexturePoolSize=0 osg::State::_maxBufferObjectPoolSize=0 GraphicsContext::getWindowingSystemInterface() 0x8a970c00x719bd4 updateDimensions, resize to 0 0 220 380 GraphicsWindowIOS :: grabFocusIfPointerInWindow not implemented yet View::init() OpenGL extensions supported by installed OpenGL drivers are: GL_APPLE_copy_texture_levels GL_APPLE_framebuffer_multisample GL_APPLE_texture_2D_limited_npot GL_APPLE_texture_format_BGRA GL_APPLE_texture_max_level GL_EXT_blend_minmax GL_EXT_debug_label GL_EXT_debug_marker GL_EXT_discard_framebuffer GL_EXT_map_buffer_range GL_EXT_read_format_bgra GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod_bias GL_EXT_texture_storage
[osg-users] Quad Buffer Stereo in osgViewer::CompositeViewer
Hi, I've been struggling with this for over a week now, its really blocking progress on my project. Basically, I can't seem to get quad buffer stereo working in any sort of compositeviewer. For what its worth, both the osgcompositeviewer example and my own application show the same error : Warning: detected OpenGL error 'invalid operation' at after RenderBin::draw(..) ..and refuse to show anything other than a mono view. I get the same issue on both my builds: a MinGW Windows 7 build and a gcc build on Arch Linux. My OpenSceneGraph is built from source in both cases using the latest revision in trunk (14459) Finally all other stereo modes seem to work in all cases, on both builds. I've been trying to track the problem down using a debugger without any luck. I'm going to try and debug the GL calls next, but was wondering if anyone else had experienced anything similar. ... Thank you! Cheers, Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61366#61366 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How do I adapt the osgViewer::Viewer in order to have my model in fullscreen mode?
HI Filipe,
On 23 October 2014 00:03, Filipe P filipe.edu.pimen...@gmail.com wrote:
The image is now on the left-bottom side of the screen.
Somehow, the image is scalling from 1600x900px to 2048x1024px. (reported
on the OSG console)
Someone can explain me what is missing?!
This message is probably osg::Texture2D rescaling the image to a power of
two when the osg::Image assigned to it is applied to OpenGL. Setting the
the non power of two hint in osg::Texture can prevent this. It used to be
that OpenGL only support power of two textures so has remained the default
for the OSG. From the include/osg/Texture header:
/** Sets whether to force the texture to resize images that have
dimensions
* that are not a power of two. If enabled, NPOT images will be
resized,
* whether or not NPOT textures are supported by the hardware. If
disabled,
* NPOT images will not be resized if supported by hardware. */
inline void setResizeNonPowerOfTwoHint(bool flag) {
_resizeNonPowerOfTwoHint = flag; }
Robert
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GeometryTechnique race condition crash
Hi David,
Could you post the whole modified files. What version of the OSG are you
working on?
FYI, I'm actually working on a osgTerrain related task right now,
developing a new TerrainTechnique that use shader based displacement
mapping. This new implementation is still underdevelopment so not ready
for prime time, and by co-incidence has contains a race condition that I
started investigated yesterday afternoon! The race condition that this new
technique looks to be related to the osgUtil::StateToCompile visitor, which
might be just a co-incidence. Once I have tracked down the problem with
code I'm working I'll know if it parallels the problem you've uncovered.
Obviously understanding the issue you've found will be part of this.
Robert.
On 23 October 2014 04:51, David Fries da...@fries.net wrote:
We're getting a crash with some ive paged terrains, it was being ht
when the system was under load with 7 OSG application instances all
thrashing their pagers. I've tracked it down to a race condition and
included two patches, the first adds a sleep to greatly increase the
chance of the crash to reproduce it, the second is a potential fix.
I've verified trunk crashes. The first one obviously is not to be
committed. I don't know enough about GeometryTechnique to know if
there is a better way to fix it, so I didn't include the full file as
I didn't think it was ready to submit.
I would have thought a subtree would either be being processed by the
DatabasePager or in the main scene graph for draw, but not both at the
same time, and something is happening to cause one to be deleting
nodes while the other is trying to compile the state sets. Any ideas?
---
cause GeometryTechnique::traverse crash
Add a sleep to widen the race condition to demonstrate a crash in
GeometryTechnique::traverse
partial stack trace of the crashing thread,
osg::NodeVisitor::traverse
osgUtil::StateToCompile::apply
osg::NodeVisitor::apply
osg::NodeVisitor::apply
osg::NodeVisitor::apply
osg::MatrixTransform::accept
osgTerrain::GeometryTechnique::traverse
osgTerrain::TerrainTile::traverse
osg::NodeVisitor::traverse
osgUtil::StateToCompile::apply
...
osg::Group::accept
osgDB::DatabasePager::DatabaseThread::run
The additional sleep allows another thread to call
GeometryTechnique::init which leaves a dangling pointer for this code.
main thread,
osg::MatrixTransform::~MatrixTransform()
osg::Referenced::signalObserversAndDelete
osg::Referenced::unref
osg::ref_ptrosg::MatrixTransform::~ref_ptr()
osgTerrain::GeometryTechnique::BufferData::~BufferData()
osgTerrain::GeometryTechnique::BufferData::~BufferData()
osg::Referenced::signalObserversAndDelete
assignosgTerrain::GeometryTechnique::BufferData
operator=
osgTerrain::GeometryTechnique::init(int, bool)
(GeometryTechnique.cpp:145)
---
src/osgUtil/IncrementalCompileOperation.cpp |3 +++
1 file changed, 3 insertions(+)
diff --git a/src/osgUtil/IncrementalCompileOperation.cpp
b/src/osgUtil/IncrementalCompileOperation.cpp
index 520f4db..dff6354 100644
--- a/src/osgUtil/IncrementalCompileOperation.cpp
+++ b/src/osgUtil/IncrementalCompileOperation.cpp
@@ -67,6 +67,9 @@ void StateToCompile::apply(osg::Node node)
apply(*(node.getStateSet()));
}
+// widen the race condition to demonstrate
GeometryTechnique::traverse causing a crash
+OpenThreads::Thread::microSleep(10);
+
traverse(node);
}
--
1.7.10.4
---
add a lock to GeometryTechnique::traverse
One thread can be in init while another in traverse and the end result
is a crash.
---
include/osgTerrain/GeometryTechnique |3 ++-
src/osgTerrain/GeometryTechnique.cpp |1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/osgTerrain/GeometryTechnique
b/include/osgTerrain/GeometryTechnique
index fdb0df4..071e0c6 100644
--- a/include/osgTerrain/GeometryTechnique
+++ b/include/osgTerrain/GeometryTechnique
@@ -20,6 +20,7 @@
#include osgTerrain/TerrainTechnique
#include osgTerrain/Locator
+#include OpenThreads/ReentrantMutex
namespace osgTerrain {
@@ -99,7 +100,7 @@ class OSGTERRAIN_EXPORT GeometryTechnique : public
TerrainTechnique
virtual void applyTransparency(BufferData buffer);
-OpenThreads::Mutex _writeBufferMutex;
+OpenThreads::ReentrantMutex _writeBufferMutex;
osg::ref_ptrBufferData_currentBufferData;
osg::ref_ptrBufferData_newBufferData;
diff --git a/src/osgTerrain/GeometryTechnique.cpp
b/src/osgTerrain/GeometryTechnique.cpp
index e1c461b..9b161e0 100644
--- a/src/osgTerrain/GeometryTechnique.cpp
+++ b/src/osgTerrain/GeometryTechnique.cpp
@@ -1451,6 +1451,7 @@ void GeometryTechnique::cull(osgUtil::CullVisitor*
cv)
void GeometryTechnique::traverse(osg::NodeVisitor nv)
{
if (!_terrainTile) return;
+
Re: [osg-users] model rendering glitch on osg versions 3.0.1
Hi, I'm running into an issue that I think is related, but not exactly the same. Prior to the 3.2 release, I could load an .stl file using the osgDB::readNodeFile(~) function, and it would come out looking like a diffuse white material. Presumably this was just a default setting somewhere in OSG or OpenGL, because the .stl file doesn't encode color or material properties. In the latest release, the file gets loaded as a shiny golden color (attachment A). I tried applying setGlobalDefaults() to the Viewer's Camera, but this had no effect. I also tried applying setGlobalDefaults() to the node which gets generated from osgDB::readNodeFile(~), and this changed the golden color to a blackish color (attachment B). I found that I could crawl through the auto-generated node and parse out its geodes and geometries, then change their color array to whatever I want. I imagine I could do something similar with their materials to get rid of the shininess. However, this is a problem for two reasons: (1) It's annoying, and more importantly (2) If some color/material properties are loaded from the file, I don't want to overwrite them. I'd really just like a way to get back the behavior prior to 3.2 where a loaded node would have some reasonable default rendering properties if the properties aren't provided by the file that's being loaded. If anyone has suggestions for how I might be able to accomplish this in a robust way, I would greatly appreciate it! I suspect there's probably some stupidly simple thing I could do that I'm just not aware of because of my inexperience with OSG. Thanks! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61381#61381 Attachments: http://forum.openscenegraph.org//files/dark_robot_376.png http://forum.openscenegraph.org//files/gold_robot_174.png ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgGA::GUIEventHandler deprecated method
Hi Gianni, On 23 October 2014 08:18, Gianni Ambrosio g.ambrosio+...@gmail.com wrote: Hi All, I'm trying to implement picking and I found some examples where a deprecated method of osgGA::GUIEventHandler is used: bool handle(const osgGA::GUIEventAdapter, osgGA::GUIActionAdapter); This method seems deprecated at least from 3.0.1 to 3.2.1. So, which method should be used instead? Maybe the following one? boolhandle (const GUIEventAdapter ea, GUIActionAdapter aa, osg::Object *, osg::NodeVisitor *) Yes the later is more general purpose replacement that you should use. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Quad Buffer Stereo in osgViewer::CompositeViewer
HI Guy, Does you hardware and OpenGL drivers support quad buffer stereo? In their attempts to carve up the market the graphics hardware manufactures restrict quad buffer support to professional range of cards such as the NVidia Quadro's. Robert. On 22 October 2014 12:11, Guy Barlow guy.bar...@gaia-tech.com wrote: Hi, I've been struggling with this for over a week now, its really blocking progress on my project. Basically, I can't seem to get quad buffer stereo working in any sort of compositeviewer. For what its worth, both the osgcompositeviewer example and my own application show the same error : Warning: detected OpenGL error 'invalid operation' at after RenderBin::draw(..) ..and refuse to show anything other than a mono view. I get the same issue on both my builds: a MinGW Windows 7 build and a gcc build on Arch Linux. My OpenSceneGraph is built from source in both cases using the latest revision in trunk (14459) Finally all other stereo modes seem to work in all cases, on both builds. I've been trying to track the problem down using a debugger without any luck. I'm going to try and debug the GL calls next, but was wondering if anyone else had experienced anything similar. ... Thank you! Cheers, Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61366#61366 ___ 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] model rendering glitch on osg versions 3.0.1
HI Michael, This issue you have doesn't look to be related to the parent thread so fixes suggested on that thread are unlikely to be relevant. As to what might be wrong in your case it's not possible to say without having the model in front of me to look at and reproduce the problem. The best I can suggest would to look at the differences in the .stl plugin between OSG-3.0.x and OSG-3.2.x to see if there are any differences there. Also try running the model in osgviewer, is this possible to reproduce the issue? Another thing you could try is to run osgconv on the original .stl to generate a .osgt or .osg file using osgconv from 3.0.x and then 3.2.x to see if the differences are apparent. If it does turn out to be the case that the .stl plugin isn't setting state it should be setting so is inheriting random state from elsewhere in the scene graph then it'd be appropriate to add that missing state to the plugin. However, this is just speculation, I don't know enough information to know the actual cause. Robert. On 23 October 2014 03:33, Michael Grey chaotic.actua...@gmail.com wrote: Hi, I'm running into an issue that I think is related, but not exactly the same. Prior to the 3.2 release, I could load an .stl file using the osgDB::readNodeFile(~) function, and it would come out looking like a diffuse white material. Presumably this was just a default setting somewhere in OSG or OpenGL, because the .stl file doesn't encode color or material properties. In the latest release, the file gets loaded as a shiny golden color (attachment A). I tried applying setGlobalDefaults() to the Viewer's Camera, but this had no effect. I also tried applying setGlobalDefaults() to the node which gets generated from osgDB::readNodeFile(~), and this changed the golden color to a blackish color (attachment B). I found that I could crawl through the auto-generated node and parse out its geodes and geometries, then change their color array to whatever I want. I imagine I could do something similar with their materials to get rid of the shininess. However, this is a problem for two reasons: (1) It's annoying, and more importantly (2) If some color/material properties are loaded from the file, I don't want to overwrite them. I'd really just like a way to get back the behavior prior to 3.2 where a loaded node would have some reasonable default rendering properties if the properties aren't provided by the file that's being loaded. If anyone has suggestions for how I might be able to accomplish this in a robust way, I would greatly appreciate it! I suspect there's probably some stupidly simple thing I could do that I'm just not aware of because of my inexperience with OSG. Thanks! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61381#61381 Attachments: http://forum.openscenegraph.org//files/dark_robot_376.png http://forum.openscenegraph.org//files/gold_robot_174.png ___ 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] Flickering in PSSM shadows.
Hi, I am using OSG 3.1 and I am facing a issue of flickering in PSSM shadows. I am using single threaded mode. I think the problem is related to the the split distances. These are calculated per frame as soon as camera position changes , If I use static split distances,I am not getting those flickers,but shadow quality highly decreases in the split edges. Please help me resolve this. Thank you! Cheers, dheeraj -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61365#61365 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Quad Buffer Stereo in osgViewer::CompositeViewer
Hi Robert, Many thanks for the quick response. I'm currently testing on an Nvidia Quadro 600 on windows with drivers I've just updated. I've enabled stereo on the control panel and I have seen other applications (and the demo) working fine. The linux build is on a virtual machine.. so I would not expect stereo to actually 'work' with that.. but I'd at least expect to see the usual flickery ghosting of frame sequential output. Just an added additional note: the osgviewer application 'looks' like its rendering frame sequential - but does't seem to trigger my nView stereo monitor. Again, osgcompositeviewer shows no signs of quad buffer output at all. Hope this helps. Guy ... Thank you! Cheers, Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61390#61390 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Quad Buffer Stereo in osgViewer::CompositeViewer
Hi, OK, I've made some progress. osgcompositeviewer seems to be producing frame sequential output as expected when I use the -2 flag to full screen it. The problem with the default settings was that the WSI graphics context wasn't getting initialised with stereo enabled. Still not playing nice will nView.. but its definitely progress. ... Thank you! Cheers, Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61391#61391 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] invalid enumerant error
Hi community, This is question for those who has debug OpenGL apps. I am getting the following message: Warning: detected OpenGL error 'invalid enumerant' after applying GLMode 0x40b3 Any hints how to resolve it or at least get some more info? Thanks a lot, Nick -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] invalid enumerant error
Robert had a suggestion in the past that helped me track down a similar issue in the past. From an earlier post from him: One way of pinpointing the error better is to enable fine grained error checking in the osg::State by setting the env OSG_GL_ERROR_CHECKING to ON, on my Linux system this is: export OSG_GL_ERROR_CHECKING=ON In my case this pointed me to a Texture2DRectangle that I was improperly declaring a min filter on. Hope this helps. -Original Message- From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Trajce Nikolov NICK Sent: Thursday, October 23, 2014 6:57 AM To: OpenSceneGraph Users Subject: [osg-users] invalid enumerant error Hi community, This is question for those who has debug OpenGL apps. I am getting the following message: Warning: detected OpenGL error 'invalid enumerant' after applying GLMode 0x40b3 Any hints how to resolve it or at least get some more info? Thanks a lot, Nick -- trajce nikolov nick smime.p7s Description: S/MIME cryptographic signature ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] invalid enumerant error
Thanks Karl, I set this in my code: std::ostringstream oss; oss OSG_GL_ERROR_CHECKING=ON; _putenv(oss.str().c_str()); still getting the same output, nothing extra. I am using TextureRectangle as well so might be the same issue. Any further hints? Thanks a bunch! Nick On Thu, Oct 23, 2014 at 1:08 PM, Cary, Karl A. karl.a.c...@leidos.com wrote: Robert had a suggestion in the past that helped me track down a similar issue in the past. From an earlier post from him: One way of pinpointing the error better is to enable fine grained error checking in the osg::State by setting the env OSG_GL_ERROR_CHECKING to ON, on my Linux system this is: export OSG_GL_ERROR_CHECKING=ON In my case this pointed me to a Texture2DRectangle that I was improperly declaring a min filter on. Hope this helps. -Original Message- From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Trajce Nikolov NICK Sent: Thursday, October 23, 2014 6:57 AM To: OpenSceneGraph Users Subject: [osg-users] invalid enumerant error Hi community, This is question for those who has debug OpenGL apps. I am getting the following message: Warning: detected OpenGL error 'invalid enumerant' after applying GLMode 0x40b3 Any hints how to resolve it or at least get some more info? Thanks a lot, Nick -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] invalid enumerant error
Just checked my changelog, I thought it was a min filter, but actually it was I was enabling wrap, which isn't allowed for a texture rectangle. Not sure if this is it or not. From it saying GLMode, I would suspect you are doing a stateset setAttribute or setMode that isn't viable. Personally I would suggest commenting out large groups of stateset code until the error goes away and use that to track down what section of your code is doing it. -Original Message- From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Trajce Nikolov NICK Sent: Thursday, October 23, 2014 7:36 AM To: OpenSceneGraph Users Subject: Re: [osg-users] invalid enumerant error Thanks Karl, I set this in my code: std::ostringstream oss; oss OSG_GL_ERROR_CHECKING=ON; _putenv(oss.str().c_str()); still getting the same output, nothing extra. I am using TextureRectangle as well so might be the same issue. Any further hints? Thanks a bunch! Nick On Thu, Oct 23, 2014 at 1:08 PM, Cary, Karl A. karl.a.c...@leidos.com wrote: Robert had a suggestion in the past that helped me track down a similar issue in the past. From an earlier post from him: One way of pinpointing the error better is to enable fine grained error checking in the osg::State by setting the env OSG_GL_ERROR_CHECKING to ON, on my Linux system this is: export OSG_GL_ERROR_CHECKING=ON In my case this pointed me to a Texture2DRectangle that I was improperly declaring a min filter on. Hope this helps. -Original Message- From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Trajce Nikolov NICK Sent: Thursday, October 23, 2014 6:57 AM To: OpenSceneGraph Users Subject: [osg-users] invalid enumerant error Hi community, This is question for those who has debug OpenGL apps. I am getting the following message: Warning: detected OpenGL error 'invalid enumerant' after applying GLMode 0x40b3 Any hints how to resolve it or at least get some more info? Thanks a lot, Nick -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- trajce nikolov nick smime.p7s Description: S/MIME cryptographic signature ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] invalid enumerant error
thats the ugly approach ... but needed indeed. Thanks again Nick On Thu, Oct 23, 2014 at 1:44 PM, Cary, Karl A. karl.a.c...@leidos.com wrote: Just checked my changelog, I thought it was a min filter, but actually it was I was enabling wrap, which isn't allowed for a texture rectangle. Not sure if this is it or not. From it saying GLMode, I would suspect you are doing a stateset setAttribute or setMode that isn't viable. Personally I would suggest commenting out large groups of stateset code until the error goes away and use that to track down what section of your code is doing it. -Original Message- From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Trajce Nikolov NICK Sent: Thursday, October 23, 2014 7:36 AM To: OpenSceneGraph Users Subject: Re: [osg-users] invalid enumerant error Thanks Karl, I set this in my code: std::ostringstream oss; oss OSG_GL_ERROR_CHECKING=ON; _putenv(oss.str().c_str()); still getting the same output, nothing extra. I am using TextureRectangle as well so might be the same issue. Any further hints? Thanks a bunch! Nick On Thu, Oct 23, 2014 at 1:08 PM, Cary, Karl A. karl.a.c...@leidos.com wrote: Robert had a suggestion in the past that helped me track down a similar issue in the past. From an earlier post from him: One way of pinpointing the error better is to enable fine grained error checking in the osg::State by setting the env OSG_GL_ERROR_CHECKING to ON, on my Linux system this is: export OSG_GL_ERROR_CHECKING=ON In my case this pointed me to a Texture2DRectangle that I was improperly declaring a min filter on. Hope this helps. -Original Message- From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Trajce Nikolov NICK Sent: Thursday, October 23, 2014 6:57 AM To: OpenSceneGraph Users Subject: [osg-users] invalid enumerant error Hi community, This is question for those who has debug OpenGL apps. I am getting the following message: Warning: detected OpenGL error 'invalid enumerant' after applying GLMode 0x40b3 Any hints how to resolve it or at least get some more info? Thanks a lot, Nick -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] invalid enumerant error
Hi Nick, I usually use GDebugger or similar tools which can hook into the OpenGLDriver. There you can get the stack-trace telling you the provoking OpenGL call. Good tools might like GDebugger will also allow you to see the actual code (e.g. the OSG call) where the error stems from Thanks Karl, I set this in my code: std::ostringstream oss; oss OSG_GL_ERROR_CHECKING=ON; _putenv(oss.str().c_str()); still getting the same output, nothing extra. I am using TextureRectangle as well so might be the same issue. Any further hints? Thanks a bunch! Nick On Thu, Oct 23, 2014 at 1:08 PM, Cary, Karl A. karl.a.c...@leidos.com mailto:karl.a.c...@leidos.com wrote: Robert had a suggestion in the past that helped me track down a similar issue in the past. From an earlier post from him: One way of pinpointing the error better is to enable fine grained error checking in the osg::State by setting the env OSG_GL_ERROR_CHECKING to ON, on my Linux system this is: export OSG_GL_ERROR_CHECKING=ON In my case this pointed me to a Texture2DRectangle that I was improperly declaring a min filter on. Hope this helps. -Original Message- From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Trajce Nikolov NICK Sent: Thursday, October 23, 2014 6:57 AM To: OpenSceneGraph Users Subject: [osg-users] invalid enumerant error Hi community, This is question for those who has debug OpenGL apps. I am getting the following message: Warning: detected OpenGL error 'invalid enumerant' after applying GLMode 0x40b3 Any hints how to resolve it or at least get some more info? Thanks a lot, Nick -- trajce nikolov nick ___ 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 -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] invalid enumerant error
Thanks Sebasitian . I have heard of it but never tried. Now seam the time comes. Thanks again! Nick On Thu, Oct 23, 2014 at 1:50 PM, Sebastian Messerschmidt sebastian.messerschm...@gmx.de wrote: Hi Nick, I usually use GDebugger or similar tools which can hook into the OpenGLDriver. There you can get the stack-trace telling you the provoking OpenGL call. Good tools might like GDebugger will also allow you to see the actual code (e.g. the OSG call) where the error stems from Thanks Karl, I set this in my code: std::ostringstream oss; oss OSG_GL_ERROR_CHECKING=ON; _putenv(oss.str().c_str()); still getting the same output, nothing extra. I am using TextureRectangle as well so might be the same issue. Any further hints? Thanks a bunch! Nick On Thu, Oct 23, 2014 at 1:08 PM, Cary, Karl A. karl.a.c...@leidos.com wrote: Robert had a suggestion in the past that helped me track down a similar issue in the past. From an earlier post from him: One way of pinpointing the error better is to enable fine grained error checking in the osg::State by setting the env OSG_GL_ERROR_CHECKING to ON, on my Linux system this is: export OSG_GL_ERROR_CHECKING=ON In my case this pointed me to a Texture2DRectangle that I was improperly declaring a min filter on. Hope this helps. -Original Message- From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Trajce Nikolov NICK Sent: Thursday, October 23, 2014 6:57 AM To: OpenSceneGraph Users Subject: [osg-users] invalid enumerant error Hi community, This is question for those who has debug OpenGL apps. I am getting the following message: Warning: detected OpenGL error 'invalid enumerant' after applying GLMode 0x40b3 Any hints how to resolve it or at least get some more info? Thanks a lot, Nick -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- trajce nikolov nick ___ osg-users mailing listosg-users@lists.openscenegraph.orghttp://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] invalid enumerant error
+1 on gDEBbugger.. very useful tool... also look into AMD CodeXL, which I believe, is an updated version of gDEBugger. Trajce Nikolov NICK wrote: Thanks Sebasitian . I have heard of it but never tried. Now seam the time comes. Thanks again! Nick On Thu, Oct 23, 2014 at 1:50 PM, Sebastian Messerschmidt () wrote: Hi Nick, I usually use GDebugger or similar tools which can hook into the OpenGLDriver. There you can get the stack-trace telling you the provoking OpenGL call. Good tools might like GDebugger will also allow you to see the actual code (e.g. the OSG call) where the error stems from Thanks Karl, I set this in my code: std::ostringstream oss; oss OSG_GL_ERROR_CHECKING=ON; _putenv(oss.str().c_str()); still getting the same output, nothing extra. I am using TextureRectangle as well so might be the same issue. Any further hints? Thanks a bunch! Nick On Thu, Oct 23, 2014 at 1:08 PM, Cary, Karl A. () wrote: Robert had a suggestion in the past that helped me track down a similar issue in the past. From an earlier post from him: One way of pinpointing the error better is to enable fine grained error checking in the osg::State by setting the env OSG_GL_ERROR_CHECKING to ON, on my Linux system this is: export OSG_GL_ERROR_CHECKING=ON In my case this pointed me to a Texture2DRectangle that I was improperly declaring a min filter on. Hope this helps. -Original Message- From: osg-users [mailto: ()] On Behalf Of Trajce Nikolov NICK Sent: Thursday, October 23, 2014 6:57 AM To: OpenSceneGraph Users Subject: invalid enumerant error Hi community, This is question for those who has debug OpenGL apps. I am getting the following message: Warning: detected OpenGL error 'invalid enumerant' after applying GLMode 0x40b3 Any hints how to resolve it or at least get some more info? Thanks a lot, Nick -- trajce nikolov nick ___ osg-users mailing list () http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org (http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org) -- trajce nikolov nick ___ osg-users mailing list () http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org (http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org) ___ osg-users mailing list () http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org (http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org) -- trajce nikolov nick -- Post generated by Mail2Forum -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61399#61399 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] invalid enumerant error
Thanks Conan! Nick On Thu, Oct 23, 2014 at 3:08 PM, Conan Doyle o...@celticblues.com wrote: +1 on gDEBbugger.. very useful tool... also look into AMD CodeXL, which I believe, is an updated version of gDEBugger. Trajce Nikolov NICK wrote: Thanks Sebasitian . I have heard of it but never tried. Now seam the time comes. Thanks again! Nick On Thu, Oct 23, 2014 at 1:50 PM, Sebastian Messerschmidt () wrote: Hi Nick, I usually use GDebugger or similar tools which can hook into the OpenGLDriver. There you can get the stack-trace telling you the provoking OpenGL call. Good tools might like GDebugger will also allow you to see the actual code (e.g. the OSG call) where the error stems from Thanks Karl, I set this in my code: std::ostringstream oss; oss OSG_GL_ERROR_CHECKING=ON; _putenv(oss.str().c_str()); still getting the same output, nothing extra. I am using TextureRectangle as well so might be the same issue. Any further hints? Thanks a bunch! Nick On Thu, Oct 23, 2014 at 1:08 PM, Cary, Karl A. () wrote: Robert had a suggestion in the past that helped me track down a similar issue in the past. From an earlier post from him: One way of pinpointing the error better is to enable fine grained error checking in the osg::State by setting the env OSG_GL_ERROR_CHECKING to ON, on my Linux system this is: export OSG_GL_ERROR_CHECKING=ON In my case this pointed me to a Texture2DRectangle that I was improperly declaring a min filter on. Hope this helps. -Original Message- From: osg-users [mailto: ()] On Behalf Of Trajce Nikolov NICK Sent: Thursday, October 23, 2014 6:57 AM To: OpenSceneGraph Users Subject: invalid enumerant error Hi community, This is question for those who has debug OpenGL apps. I am getting the following message: Warning: detected OpenGL error 'invalid enumerant' after applying GLMode 0x40b3 Any hints how to resolve it or at least get some more info? Thanks a lot, Nick -- trajce nikolov nick ___ osg-users mailing list () http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org (http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ) -- trajce nikolov nick ___ osg-users mailing list () http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org (http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ) ___ osg-users mailing list () http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org (http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ) -- trajce nikolov nick -- Post generated by Mail2Forum -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61399#61399 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Slave camera question
Hello users! I'm currently trying to re-implement the example osgdistortion in another test application to see how it works. I'm facing this issue. If I run the osgdistortion example with the --dome parameter, and that I comment all the viewer.addSlave calls, I get the expected result of seeing only my model with no distortion. However, if I add only the first call to the viewer.addSlave (in setDomeCorrection; front face part), which in theory renders to a cube texture, I no longer see my model and the screen is all black. I'm having trouble figuring out what's going on in there, I would expect to still see my model not distorted. Any pointers would be appreciated! I've been using the 'scene graph' part of osg for a couple of years now, but the OpenGL aspect of it is still unclear. Thanks! -- Alexandre Vaillancourt ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GeometryTechnique race condition crash
Interesting chance. Are these nodes supposed to be called from the
DatabasePager for StateToCompile and main draw thread at the same
time? I would have thought it would only be reachable by one or the
other, but not both.
These are modified from svn trunk 14451, we were using 3.2.0 when it
was found. IncrementalCompileOperation.cpp change is to make it more
reproducible. The valgrind --tool=helgrind also helped in pointing
out where the problem was with this bug.
On Thu, Oct 23, 2014 at 09:08:15AM +0100, Robert Osfield wrote:
Hi David,
Could you post the whole modified files. What version of the OSG are you
working on?
FYI, I'm actually working on a osgTerrain related task right now,
developing a new TerrainTechnique that use shader based displacement
mapping. This new implementation is still underdevelopment so not ready
for prime time, and by co-incidence has contains a race condition that I
started investigated yesterday afternoon! The race condition that this new
technique looks to be related to the osgUtil::StateToCompile visitor, which
might be just a co-incidence. Once I have tracked down the problem with
code I'm working I'll know if it parallels the problem you've uncovered.
Obviously understanding the issue you've found will be part of this.
Robert.
On 23 October 2014 04:51, David Fries da...@fries.net wrote:
We're getting a crash with some ive paged terrains, it was being ht
when the system was under load with 7 OSG application instances all
thrashing their pagers. I've tracked it down to a race condition and
included two patches, the first adds a sleep to greatly increase the
chance of the crash to reproduce it, the second is a potential fix.
I've verified trunk crashes. The first one obviously is not to be
committed. I don't know enough about GeometryTechnique to know if
there is a better way to fix it, so I didn't include the full file as
I didn't think it was ready to submit.
I would have thought a subtree would either be being processed by the
DatabasePager or in the main scene graph for draw, but not both at the
same time, and something is happening to cause one to be deleting
nodes while the other is trying to compile the state sets. Any ideas?
---
cause GeometryTechnique::traverse crash
Add a sleep to widen the race condition to demonstrate a crash in
GeometryTechnique::traverse
partial stack trace of the crashing thread,
osg::NodeVisitor::traverse
osgUtil::StateToCompile::apply
osg::NodeVisitor::apply
osg::NodeVisitor::apply
osg::NodeVisitor::apply
osg::MatrixTransform::accept
osgTerrain::GeometryTechnique::traverse
osgTerrain::TerrainTile::traverse
osg::NodeVisitor::traverse
osgUtil::StateToCompile::apply
...
osg::Group::accept
osgDB::DatabasePager::DatabaseThread::run
The additional sleep allows another thread to call
GeometryTechnique::init which leaves a dangling pointer for this code.
main thread,
osg::MatrixTransform::~MatrixTransform()
osg::Referenced::signalObserversAndDelete
osg::Referenced::unref
osg::ref_ptrosg::MatrixTransform::~ref_ptr()
osgTerrain::GeometryTechnique::BufferData::~BufferData()
osgTerrain::GeometryTechnique::BufferData::~BufferData()
osg::Referenced::signalObserversAndDelete
assignosgTerrain::GeometryTechnique::BufferData
operator=
osgTerrain::GeometryTechnique::init(int, bool)
(GeometryTechnique.cpp:145)
---
src/osgUtil/IncrementalCompileOperation.cpp |3 +++
1 file changed, 3 insertions(+)
diff --git a/src/osgUtil/IncrementalCompileOperation.cpp
b/src/osgUtil/IncrementalCompileOperation.cpp
index 520f4db..dff6354 100644
--- a/src/osgUtil/IncrementalCompileOperation.cpp
+++ b/src/osgUtil/IncrementalCompileOperation.cpp
@@ -67,6 +67,9 @@ void StateToCompile::apply(osg::Node node)
apply(*(node.getStateSet()));
}
+// widen the race condition to demonstrate
GeometryTechnique::traverse causing a crash
+OpenThreads::Thread::microSleep(10);
+
traverse(node);
}
--
1.7.10.4
---
add a lock to GeometryTechnique::traverse
One thread can be in init while another in traverse and the end result
is a crash.
---
include/osgTerrain/GeometryTechnique |3 ++-
src/osgTerrain/GeometryTechnique.cpp |1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/osgTerrain/GeometryTechnique
b/include/osgTerrain/GeometryTechnique
index fdb0df4..071e0c6 100644
--- a/include/osgTerrain/GeometryTechnique
+++ b/include/osgTerrain/GeometryTechnique
@@ -20,6 +20,7 @@
#include osgTerrain/TerrainTechnique
#include osgTerrain/Locator
+#include OpenThreads/ReentrantMutex
namespace osgTerrain {
@@ -99,7 +100,7 @@ class OSGTERRAIN_EXPORT GeometryTechnique : public
TerrainTechnique
virtual void applyTransparency(BufferData buffer);
Re: [osg-users] GeometryTechnique race condition crash
Hi David, On 23 October 2014 17:08, David Fries da...@fries.net wrote: Interesting chance. Are these nodes supposed to be called from the DatabasePager for StateToCompile and main draw thread at the same time? I would have thought it would only be reachable by one or the other, but not both. In theory the design of the DatabasePager should ensure that subgraphs that are being pre-compiled are kept separate from the main scene graph till compilation is complete. This should mean that the traversal during construction and search for the compilable objects is done single threaded. I don't know why there seems to be a way around this yet, outwardly it looks like there are multiple traversals happening causing the race condition. These are modified from svn trunk 14451, we were using 3.2.0 when it was found. IncrementalCompileOperation.cpp change is to make it more reproducible. The valgrind --tool=helgrind also helped in pointing out where the problem was with this bug. I have been using valgrind through this afternoon, but so far haven't come up with any smoking gun. Thanks for the files. It's end of day here so I'll look at them tomorrow. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
