Re: [osg-users] context IDs
I tried your suggestion of clearing the s_gl* lists in ~GLException. I think it works, but have not been as thorough as I'd like yet. Do I need to consider threading issues? Could someone be calling isGLExtensionOrVersionSupported at the same time ~GLExceptions is being called? I am using an older version of OSG, and when I send a version for review, I should probably make the change to current files. While I think the smaller fix would be appropriate for us, I like the alternate approach better. It would be: * put the things stored on the s_gl* lists into GLExtensions * pull out the code that gets the renderer string and extensions and have them called from GLExtensions constructor. * have isGLExtensionOrVersionSupported do GLExtensions::Get to get or create the GLExtensions for the given context ID and check that. * remove the s_gl* lists I can't update the version of OpenSceneGraph in this part of our cycle, but I may be able to make a change. I think I feel better with the change to clear the existing list element in ~GLException. But I think the other approach would be better for current OSG. andy -Original Message- From: Andy Skinner Sent: Wednesday, September 19, 2018 3:32 PM To: OpenSceneGraph Users Subject: RE: [osg-users] context IDs Thanks, I'll take a look. I am hoping this will be more remove than replace, not needing multiple levels of caching. thanks andy -Original Message- From: osg-users On Behalf Of Robert Osfield Sent: Wednesday, September 19, 2018 2:28 PM To: OpenSceneGraph Users Subject: Re: [osg-users] context IDs Hi Andy, I have just had a quick look at the various s_* containers in GLExtensions.cpp and I think these are an old hang over that should be removed and replaced by code that is embedded into the GLExtensions object so that it can be constructed and destructed. Short of this refactor perhaps these data structures could be reset within the GLExtensions destructor. I don't have time to look into a fix right now, so either dive into the code yourself or avoid creating and destructor lots of contexts. Robert. Robert. On Wed, 19 Sep 2018 at 15:52, Andy Skinner wrote: > > OK, I've digested some more. I see what you mean (I think) about ~State > clearing the GLExtensions object from the static map (s_extensions) defined > in GLExtensions.cpp. > > However, if the next GLExceptions::Get will make a new one, the GLExtensions > constructor will use other static maps: s_glExtensionSetList, > s_glRendererList, and s_glInitializedList. So if we make a new GLExtensions > object, we will get the answers from last time, because they were cached. > > It seems to me that if we need to store these per context ID, and if we can > re-use context IDs, then we need a way to clear out what is stored, possibly > when the context ID usage count goes to 0, or maybe explicitly. > > thanks > > andy > > -Original Message- > From: osg-users On Behalf > Of Robert Osfield > Sent: Wednesday, September 19, 2018 4:20 AM > To: OpenSceneGraph Users > Subject: Re: [osg-users] context IDs > > Hi Andy, > > It's quite a while since I worked specifically on the osg::State, > ContextID, osg::GLExtensions management. In principle it should be > possible to reuse ContextID's, the sticky issue of whether the > GLExtensions object is recreated for each new graphics context is > something I haven't personally tested. Looking at osg::State is does > look to clean up the GLExtensions object in 3.4 onwards (I haven't > checked further back) > > For graphics performance I would recommend that applications don't go > creating and destroying GraphicsWindows, if possible just hide the window and > reuse it will provide better performance. > > Cheers, > Robert. > On Mon, 17 Sep 2018 at 19:08, Andy Skinner wrote: > > > > If we get our contextIDs from GraphicsContext::createNewContextID(), it > > could give us a new number or return a previous one, if we are returning > > them with GraphicsContext::decrementContextIDUsageCount. Right? > > > > > > > > Is there an intended connection between a contextID that has been used and > > a new one? It looks to me that extensions are stored per context ID and > > never reset. > > > > > > > > So if we change something about what we are looking for in the context > > (sometimes we fall back to software OpenGL for testing or helping a > > customer through an issue), we might reuse a context ID, but still have > > extensions associated with the ID that are not appropriate for it. > > > > > > > > Am I missing an assumption here? Should I be able to reuse a contextID for > > an unrelated context? If not, I'll just remove call to > >
Re: [osg-users] context IDs
Thanks, I'll take a look. I am hoping this will be more remove than replace, not needing multiple levels of caching. thanks andy -Original Message- From: osg-users On Behalf Of Robert Osfield Sent: Wednesday, September 19, 2018 2:28 PM To: OpenSceneGraph Users Subject: Re: [osg-users] context IDs Hi Andy, I have just had a quick look at the various s_* containers in GLExtensions.cpp and I think these are an old hang over that should be removed and replaced by code that is embedded into the GLExtensions object so that it can be constructed and destructed. Short of this refactor perhaps these data structures could be reset within the GLExtensions destructor. I don't have time to look into a fix right now, so either dive into the code yourself or avoid creating and destructor lots of contexts. Robert. Robert. On Wed, 19 Sep 2018 at 15:52, Andy Skinner wrote: > > OK, I've digested some more. I see what you mean (I think) about ~State > clearing the GLExtensions object from the static map (s_extensions) defined > in GLExtensions.cpp. > > However, if the next GLExceptions::Get will make a new one, the GLExtensions > constructor will use other static maps: s_glExtensionSetList, > s_glRendererList, and s_glInitializedList. So if we make a new GLExtensions > object, we will get the answers from last time, because they were cached. > > It seems to me that if we need to store these per context ID, and if we can > re-use context IDs, then we need a way to clear out what is stored, possibly > when the context ID usage count goes to 0, or maybe explicitly. > > thanks > > andy > > -Original Message- > From: osg-users On Behalf > Of Robert Osfield > Sent: Wednesday, September 19, 2018 4:20 AM > To: OpenSceneGraph Users > Subject: Re: [osg-users] context IDs > > Hi Andy, > > It's quite a while since I worked specifically on the osg::State, > ContextID, osg::GLExtensions management. In principle it should be > possible to reuse ContextID's, the sticky issue of whether the > GLExtensions object is recreated for each new graphics context is > something I haven't personally tested. Looking at osg::State is does > look to clean up the GLExtensions object in 3.4 onwards (I haven't > checked further back) > > For graphics performance I would recommend that applications don't go > creating and destroying GraphicsWindows, if possible just hide the window and > reuse it will provide better performance. > > Cheers, > Robert. > On Mon, 17 Sep 2018 at 19:08, Andy Skinner wrote: > > > > If we get our contextIDs from GraphicsContext::createNewContextID(), it > > could give us a new number or return a previous one, if we are returning > > them with GraphicsContext::decrementContextIDUsageCount. Right? > > > > > > > > Is there an intended connection between a contextID that has been used and > > a new one? It looks to me that extensions are stored per context ID and > > never reset. > > > > > > > > So if we change something about what we are looking for in the context > > (sometimes we fall back to software OpenGL for testing or helping a > > customer through an issue), we might reuse a context ID, but still have > > extensions associated with the ID that are not appropriate for it. > > > > > > > > Am I missing an assumption here? Should I be able to reuse a contextID for > > an unrelated context? If not, I'll just remove call to > > decrementContextIDUsageCount. That means the number and various maps will > > continue to grow. > > > > > > > > thanks > > > > andy > > > > > > > > ___ > > osg-users mailing list > > osg-users@lists.openscenegraph.org > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org. > > openscenegraph.org > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org. > openscenegraph.org > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org. > 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] context IDs
OK, I've digested some more. I see what you mean (I think) about ~State clearing the GLExtensions object from the static map (s_extensions) defined in GLExtensions.cpp. However, if the next GLExceptions::Get will make a new one, the GLExtensions constructor will use other static maps: s_glExtensionSetList, s_glRendererList, and s_glInitializedList. So if we make a new GLExtensions object, we will get the answers from last time, because they were cached. It seems to me that if we need to store these per context ID, and if we can re-use context IDs, then we need a way to clear out what is stored, possibly when the context ID usage count goes to 0, or maybe explicitly. thanks andy -Original Message- From: osg-users On Behalf Of Robert Osfield Sent: Wednesday, September 19, 2018 4:20 AM To: OpenSceneGraph Users Subject: Re: [osg-users] context IDs Hi Andy, It's quite a while since I worked specifically on the osg::State, ContextID, osg::GLExtensions management. In principle it should be possible to reuse ContextID's, the sticky issue of whether the GLExtensions object is recreated for each new graphics context is something I haven't personally tested. Looking at osg::State is does look to clean up the GLExtensions object in 3.4 onwards (I haven't checked further back) For graphics performance I would recommend that applications don't go creating and destroying GraphicsWindows, if possible just hide the window and reuse it will provide better performance. Cheers, Robert. On Mon, 17 Sep 2018 at 19:08, Andy Skinner wrote: > > If we get our contextIDs from GraphicsContext::createNewContextID(), it could > give us a new number or return a previous one, if we are returning them with > GraphicsContext::decrementContextIDUsageCount. Right? > > > > Is there an intended connection between a contextID that has been used and a > new one? It looks to me that extensions are stored per context ID and never > reset. > > > > So if we change something about what we are looking for in the context > (sometimes we fall back to software OpenGL for testing or helping a customer > through an issue), we might reuse a context ID, but still have extensions > associated with the ID that are not appropriate for it. > > > > Am I missing an assumption here? Should I be able to reuse a contextID for > an unrelated context? If not, I'll just remove call to > decrementContextIDUsageCount. That means the number and various maps will > continue to grow. > > > > thanks > > andy > > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org. > 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] context IDs
Thanks. The problem is in GLExtensions.cpp. It has some maps that it keeps, and it adds contexts and does not take them off. But GraphicsContext will provide an old, no-long-used context ID, and that ID can look up the wrong thing in GLExtensions.cpp if we have changed from hardware to software OpenGL. Oh, wait. I see, you're talking about when the GLExtensions object gets created. Let me look into that. We make lots of windows over time, and don't really know in advance how many we'll have, either at one time or across a session. We are drawing into buffers that then get drawn into Java windows. andy -Original Message- From: osg-users On Behalf Of Robert Osfield Sent: Wednesday, September 19, 2018 4:20 AM To: OpenSceneGraph Users Subject: Re: [osg-users] context IDs Hi Andy, It's quite a while since I worked specifically on the osg::State, ContextID, osg::GLExtensions management. In principle it should be possible to reuse ContextID's, the sticky issue of whether the GLExtensions object is recreated for each new graphics context is something I haven't personally tested. Looking at osg::State is does look to clean up the GLExtensions object in 3.4 onwards (I haven't checked further back) For graphics performance I would recommend that applications don't go creating and destroying GraphicsWindows, if possible just hide the window and reuse it will provide better performance. Cheers, Robert. On Mon, 17 Sep 2018 at 19:08, Andy Skinner wrote: > > If we get our contextIDs from GraphicsContext::createNewContextID(), it could > give us a new number or return a previous one, if we are returning them with > GraphicsContext::decrementContextIDUsageCount. Right? > > > > Is there an intended connection between a contextID that has been used and a > new one? It looks to me that extensions are stored per context ID and never > reset. > > > > So if we change something about what we are looking for in the context > (sometimes we fall back to software OpenGL for testing or helping a customer > through an issue), we might reuse a context ID, but still have extensions > associated with the ID that are not appropriate for it. > > > > Am I missing an assumption here? Should I be able to reuse a contextID for > an unrelated context? If not, I'll just remove call to > decrementContextIDUsageCount. That means the number and various maps will > continue to grow. > > > > thanks > > andy > > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org. > openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] context IDs
If we get our contextIDs from GraphicsContext::createNewContextID(), it could give us a new number or return a previous one, if we are returning them with GraphicsContext::decrementContextIDUsageCount. Right? Is there an intended connection between a contextID that has been used and a new one? It looks to me that extensions are stored per context ID and never reset. So if we change something about what we are looking for in the context (sometimes we fall back to software OpenGL for testing or helping a customer through an issue), we might reuse a context ID, but still have extensions associated with the ID that are not appropriate for it. Am I missing an assumption here? Should I be able to reuse a contextID for an unrelated context? If not, I'll just remove call to decrementContextIDUsageCount. That means the number and various maps will continue to grow. thanks andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShaderComposer::releaseGLObjects warning
So, to be clear, we'll leave it as is? thanks andy Needing to put a using in lots of places across the OSG to just quieten inappropriate warnings is pretty crappy. The more superfluous code you have in your code base the less easy it is to read, the easier it to break. This makes me very wary of jumping through hoops to quieten dodgy warnings from the compilers. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShaderComposer::releaseGLObjects warning
Yes, the "using" statement does quiet the warning.
Does that mean this is the solution, or that this just shows that there isn't a
problem? The reason I ask is that we've discussed the "using" statement for
things like this before, and I don't believe you were in favor of it. But
using it would let us remove a bunch of warning handling in our use of OSG.
thanks
andy
From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf
Of Robert Osfield
Sent: Wednesday, April 27, 2016 5:55 AM
To: OpenSceneGraph Users <osg-users@lists.openscenegraph.org>
Subject: Re: [osg-users] ShaderComposer::releaseGLObjects warning
Hi Andy,
On 26 April 2016 at 20:31, Andy Skinner
<andy.skin...@mathworks.com<mailto:andy.skin...@mathworks.com>> wrote:
Thanks for that fix. There is a remaining issue, and I'm not sure if you would
see it as a bug or a dodgy compiler warning. :)
We get a similar message about osgUtil::CullVisitor::clone().
NodeVisitor uses META_Object, which brings in:
virtual osg::Object* clone(const osg::CopyOp& copyop) const { return new name
(*this,copyop); }
But CullVisitor defines clone as:
virtual CullVisitor* clone() const { return new CullVisitor(*this); }
They differ in whether they take an argument. I believe we've discussed this
kind of thing before when considering using "using", and it was, if I remember
correctly, a dodgy compiler warning then.
The osg::ShaderComposer warning did highlight a bug, but this warning isn't
highlighting an actual error. If one calls clone(osg::CopyOp) then you'll
still git the correct clone() method. It does highlight what is not ideal
coding style, and in this case it's a historical reason why there is this
clone() convenience method. These days a osg::clone(object) would do just as
well without requiring the extra method, but this is a relatively modern
addition.
Could you try doing adding:
using NodeVisitor::clone;
To the include/osgUtil/CullVisitor and see if that quietens the warning.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShaderComposer::releaseGLObjects warning
Thanks for that fix. There is a remaining issue, and I'm not sure if you would
see it as a bug or a dodgy compiler warning. :)
We get a similar message about osgUtil::CullVisitor::clone().
NodeVisitor uses META_Object, which brings in:
virtual osg::Object* clone(const osg::CopyOp& copyop) const { return new name
(*this,copyop); }
But CullVisitor defines clone as:
virtual CullVisitor* clone() const { return new CullVisitor(*this); }
They differ in whether they take an argument. I believe we've discussed this
kind of thing before when considering using "using", and it was, if I remember
correctly, a dodgy compiler warning then.
thanks
andy
From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf
Of Robert Osfield
Sent: Monday, April 18, 2016 4:05 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] ShaderComposer::releaseGLObjects warning
On 18 April 2016 at 20:30, Robert Osfield
> wrote:
Hi Jannik and Ulrich,
You are right it's a bug, the missing const is an error, rather than the
missing virtual. I've fixed this and rewritten the implementation of
ShaderCompose::releaseGLObjects() const.
I need to do a build and test before checking it in.
Now checked into OpenSceneGraph-3.4 and master.
I am bit concerned that this fix breaks the ABI of 3.4 though... Would
changing const affect the ABI? I'm thinking yes, but it's too late in the
evening for me to go and search for an answer...
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] ShaderComposer::releaseGLObjects warning
We are getting a warning for ShaderComposer::releaseGLObjects: 'void osg::ShaderComposer::releaseGLObjects(osg::State *)' : member function does not override any base class virtual member function osg::Object::releaseGLObjects is virtual, but osg::ShaderComposer::releaseGLObjects is not. Is there a reason why? thanks andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] building OSG 3.0.1
I set OPENGL_INCLUDE_DIR to /System/Library/Frameworks/OpenGL.framework, even though I don't see any headers in it. That satisfied CMake, and the build found the headers somewhere. I don't know where to look for those headers, but it does seem CMake's FindOpenGL modules might need to be updated. I think, from reading, that if I installed compiler command tools I'd get the headers folder in the framework, and maybe then CMake would find it again. andy From: Andy Skinner Sent: Tuesday, January 28, 2014 5:16 PM To: OpenSceneGraph Users (osg-users@lists.openscenegraph.org) Subject: building OSG 3.0.1 We're using 3.0.1. I'd like to update, but at the moment don't have time and have something else going on. I'm able to build on a Mac OS X 10.7.5 machine. With a few changes to our makefile (which calls cmake and then gmake), I'm trying to build on Mac OS X 10.8. (The changes involve specifying SDK so we can get past the test for a C compiler.) But after that, it says that OPENGL_INCLUDE_DIR is set to NOTFOUND. When I search for help on this, all I see are references to OpenGL ES, iphones, etc. I'm just building on a mac, and am not after ES. Is there something else I need to do to build 3.0.1 on 10.8.5, when I can build on 10.7.5? Why is it looking for OPENGL_INCLUDE_DIR on 10.8 and not 10.7? (The CMake cache file seems to show it as NOTFOUND as well.) If that's the answer, what would I set it to? I'm open to the possibility that I need to upgrade, but at this point only if that's what I need to do to move forward. I'd like to update OSG to more recent at a time when I'm not trying to fix something else at the same time. thanks andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] building OSG 3.0.1
We're using 3.0.1. I'd like to update, but at the moment don't have time and have something else going on. I'm able to build on a Mac OS X 10.7.5 machine. With a few changes to our makefile (which calls cmake and then gmake), I'm trying to build on Mac OS X 10.8. (The changes involve specifying SDK so we can get past the test for a C compiler.) But after that, it says that OPENGL_INCLUDE_DIR is set to NOTFOUND. When I search for help on this, all I see are references to OpenGL ES, iphones, etc. I'm just building on a mac, and am not after ES. Is there something else I need to do to build 3.0.1 on 10.8.5, when I can build on 10.7.5? Why is it looking for OPENGL_INCLUDE_DIR on 10.8 and not 10.7? (The CMake cache file seems to show it as NOTFOUND as well.) If that's the answer, what would I set it to? I'm open to the possibility that I need to upgrade, but at this point only if that's what I need to do to move forward. I'd like to update OSG to more recent at a time when I'm not trying to fix something else at the same time. thanks andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] RenderStage setting Viewport as it knows it, then as default
We've seen that we have calls to glViewport(800, 600), mixed in with calls to the actual size of our viewport. Is the final state.apply() call at the end of RenderStage::drawImplementation() intended to set things back to a default state after rendering everything? I've seen that RenderStage has a Viewport and applies it at the beginning of drawImplementation(). When I saw state.apply() putting in a different value, I thought it was a bug. But if it returning things to a default value, I get it. Is that what's happening? thanks, andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] intersection of lines: line widths?
Thanks for comments, Peter. By easier to pick, I didn't mean relative to other lines in the scene, but that I wouldn't have to be as close to the actual line geometry. It is a question of whether the line will be in the list of intersections, rather than which intersection I choose. I suspect the same thing about whether it is worth the effort. As for your other kinds of thinks in the scene you should be aware that the performance of PolytopeIntersector for 2d-geometries is rather bad. It is much faster to use LineSegementIntersector for those and combine the results afterwards. By 2d-geometries, do you mean triangles and quads (and not 2D scenes)? And that it would be better to run the polytope intersector for points and lines, and a separate line intersector for triangles and quads, and combine intersections? I know all of that is pretty much what you said, but I wanted to be sure. That's using two intersection traversals. Sounds interesting if it is really faster. thanks, andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] intersection of lines: line widths?
I know that intersections are about 3d world coordinates, and line widths are about pixels. But is there a way to use line widths in calculating intersections with the polytope intersector? In other words, I want a wider line to be easier to pick. I could just expand the polytope a bit, except that the lines are just one kind of thing in the scene, and they could have different line widths. thanks, andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] clipping the Intersectors
Should we expect the picking Intersectors to look at the clipping planes set up by ClipNodes and Scissors? We can clip the results, but it seems like the sort of thing the Intersectors would be good at. Basically, we've been getting points picked that should have been clipped by a clip box. They're clipped when drawing-is there a way to clip when finding intersections? thanks, andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Point attribute affecting display of triangle on OS X
Thanks, Ulrich. Sorry, I missed your reply before. Yes, your results do sound different. I'd expect no argument to have green dots instead of green discs, because the point size won't be set. They're small and right on the edge of the triangle. And in our case, the red triangle and the line aren't visible when the point attribute is set, so when the PointAttribute is set. My co-worker is trying to get a straight OpenGL program to show this problem. If we can get it to happen, we'll see about talking to Apple. thanks, andy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=46063#46063 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Point attribute affecting display of triangle on OS X
Attached is a simple OSG example that, on Mac with nVidia card, seems to show
point geometry with the Point StateAttribute set causing other geometry to be
clipped. We did not see this on a Mac with an ATI card. This has been
reproduced on the OSG trunk, but has been seen on older versions as well.
The example has a ClipNode, and a Geode with a Point, Line, and Triangle. When
we set the Point attribute on the StateSet, the Triangle and Line don't appear.
When we skip setting the Point attribute, all three Geometry drawables appear.
If you build the example and run it with no arguments, the Point attribute is
not set. If you run with an argument (doesn't matter what it is), the Point
attribute is set.
Leaving out the ClipNode causes all the Geometry objects to show, whether or
not the Point is set.
We suspect the part of Point::apply() which handles some of the extensions.
Could there be a problem in the nVidia driver?
If someone with an nVidia card on a Mac could try this out and give us some
input, we would appreciate it.
Also, if it turns out to be an issue we would report to nVidia, could we report
it with an OSG example? In other words, does nVidia have the ability to build
OSG examples, and have you reported problems to them with OSG to demonstrate?
In our real app, we saw triangle geometry move when we set the point attribute.
That pushed it out of the clipping planes, sometimes partially. This example
only shows the triangle disappearing, but it may be moving. Any idea for why
these things (settings on point attribute and transform of triangle) might be
connected?
thanks,
andy
#include osg/Geometry
#include osg/ClipNode
#include osg/Point
#include osg/Geode
#include osgViewer/Viewer
int main(int argc, char *){
// GL_LINES
osg::ref_ptrosg::Vec3Array xAxis = new osg::Vec3Array;
xAxis-push_back( osg::Vec3( -10.f, 0.f, 0.0f) );
xAxis-push_back( osg::Vec3( 10.f, 0.f, 0.0f) );
osg::ref_ptr osg::Vec4Array xColor = new osg::Vec4Array;
xColor-push_back( osg::Vec4(0.0f, 1.0f, 0.0f, 1.0f));
osg::ref_ptrosg::Geometry X = new osg::Geometry;
X-setVertexArray( xAxis.get() );
X-setColorArray( xColor.get() );
X-setColorBinding( osg::Geometry::BIND_OVERALL );
X-addPrimitiveSet( new osg::DrawArrays( GL_LINES,0 , 2 ) );
// GL_Triangles
osg::ref_ptrosg::Vec3Array tVertices = new osg::Vec3Array;
tVertices-push_back( osg::Vec3(0.0f, 0.0f, 0.0f) );
tVertices-push_back( osg::Vec3(10.0f, 0.0f, 0.0f) );
tVertices-push_back( osg::Vec3(10.0f, 10.0f,10.0f) );
osg::ref_ptrosg::Vec4Array tColor = new osg::Vec4Array;
tColor-push_back( osg::Vec4( 1.0f, 0.0f, 0.0f, 1.0f) );
osg::ref_ptr osg::Geometry tri = new osg::Geometry;
tri-setVertexArray( tVertices.get() );
tri-setColorArray( tColor.get() );
tri-setColorBinding( osg::Geometry::BIND_OVERALL );
tri-addPrimitiveSet( new osg::DrawArrays( GL_TRIANGLES, 0, 3 ) );
// GL_POINTS
osg::ref_ptrosg::Geometry geom(new osg::Geometry());
osg::ref_ptrosg::StateSet stateSet(geom-getOrCreateStateSet());
osg::ref_ptrosg::Vec4Array pColor = new osg::Vec4Array;
pColor-push_back( osg::Vec4( 0.0f, 1.0f, 0.0f, 1.0f) );
osg::ref_ptrosg::Point p(new osg::Point());
osg::ref_ptrosg::Vec3Array pVertices = new osg::Vec3Array;
for( float idx = 0.; idx 10; idx = idx + 1.){
pVertices-push_back( osg::Vec3( idx, idx, idx ) );
}
geom-setColorArray( pColor.get() );
geom-setColorBinding( osg::Geometry::BIND_OVERALL );
geom-setVertexArray(pVertices.get());
int numVerts = pVertices-size();
geom-addPrimitiveSet(new osg::DrawArrays(osg::PrimitiveSet::POINTS, 0, 7));
float ptSize = 20.f; // some large size
p-setSize(ptSize);
if (argc 1){
// This seems to cause the triangle and line to disappear
stateSet-setAttributeAndModes(p.get(), osg::StateAttribute::ON);
}
osg::ref_ptrosg::Geoderoot = new osg::Geode;
root-addDrawable ( X.get() );
root-addDrawable( tri.get() );
root-addDrawable( geom.get() );
// This is needed
osg::ref_ptrosg::ClipNodeclipper = new osg::ClipNode;
osg::BoundingBox bb(-5., -10., -10., 5., 5., 5.);
clipper-createClipBox(bb);
clipper-addChild(root);
osgViewer::Viewer viewer;
viewer.setLightingMode(osg::View::NO_LIGHT);
viewer.setSceneData( clipper.get() );
viewer.setUpViewInWindow(20, 20, 640, 480);
viewer.realize();
return viewer.run();
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osg plugins
We're just moving from 2.8.something to 3.0.1. Looks like I should update from using .osg to .osgx. While I was looking at that, I was wondering about this line from DogOSGWrapper.cpp: if (osgDB::Registry::instance()-loadLibrary(*itr)==osgDB::Registry::LOADED) return writeObject(obj,fw); It looked to me that loadLibrary() was returning PREVIOUSLY_LOADED. Should the condition be != osgDB::Registry::NOT_LOADED? I'm not familiar with this code, but that seemed odd to me. thanks andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OsgParticle variables causing objects to disappear
Maybe far off, but something I've seen: Do you happen to be working on a mac? We've seen something on one particular graphics card on the mac, where drawing with points sometimes seems to affect clipping on other objects. It seems really weird. I think that when we didn't set the osg::Point state attribute, it didn't happen. And when we turned off clipping, it didn't happen. And it only happened on one particular graphics card on a mac. I didn't look at the near and far settings at the time, but I don't see why that would be affected by the card/driver. andy -Original Message- Not to worry, I redesigned the min and max values to give a better looking fire, and now the problem has gone. Still don't know what caused it though, gonna worry about that in the future D: Simon. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Mac NVidia Point / clipping issue?
This will sound like a reach, and I can't easily make a simple case to show it. But I'd like to know if this rings a bell with anyone. We've seen geometry disappear when in the same scene as a point, on NVidia 7300 on a Mac. If I comment out the part of our code where we set the Point StateAttribute onto the StateSet, the geometry does not disappear. If I remove the ClipNode from the scene, the geometry does not disappear. Is there a way, either in OpenSceneGraph or in the NVidia driver, that specifying some of the things that the Point does (point size, attenutation, fade threshold) might affect clipping for other geometry? Might point attenuation occupy some slot on the card for points that is used for a clip plane for other geometry? (That's a wild guess.) I don't know that it is the attenuation--just something specified by Point. I've tried turning off the extensions related to points, but it didn't have an effect. This seems like a long shot, but changing either of those situations does make the geometry appear again. We are using OSG 2.8.3. I've not yet been able to run one of the examples, or we'd try to show it in osgpoints. thanks andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] using points and lines for compute near and far
Sometimes our scene only consists of lines. When we use COMPUTE_NEAR_FAR_USING_PRIMITIVES, the near and far aren't computed correctly, because the TriangleFunctor used with ComputeNearestPointFunctor doesn't look at points or lines. In order to get this to work, if I want to consider lines the way the current code considers triangles, I'd need to write a functor that uses lines or points. I think I'd want to use the lines if possible, and consider individual points only if that is what the geometry is. I'm not sure it would be useful to write general LineFunctor and PointFunctor classes and make them available. So maybe I could put something intended just for this purpose into the CullVisitor. Maybe extend TriangleFunctor to do what it currently does, but handle lines and points differently? I don't want to clutter up CullVisitor.cpp with a large object if I can help it. I could just use TemplatePrimitiveFunctor and implement all the operators. Maybe that would be simpler, because some could forward to others. Is there a better approach here? It does seem a bit of a lack to me that computing near and far doesn't handle scene without faces. It also makes me wonder about the various cases that use TriangleFunctor. Are they all only relevant for faces? thanks andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] plugin source code
I was looking at submitting a fix for the osg plugin. We use shared arrays (see osgsharedarray example) in the last stable release of OSG. We had a problem writing osg files of our scene because of a static cast in the osg plugin. It assumed it knew what the array was (FloatArray, for example) and cast to it. Our arrays weren't implemented with that, and we crashed. We had a fix where we get the actual array memory out and use that, so it worked with either kind of array. I was going to submit that, but I don't see the problem in the trunk. (I added writing a file to the osgsharedarray example.) So I went to check out Geometry.cpp in the osg plugin, and it isn't there. Seems the plugins have been refactored. Could someone point me to the code equivalent to the Array_writeLocalData function that was in Geometry.cpp in src/osgPlugins/osg before? Is the new code set up to handle shared arrays without assuming what they are? I want to make sure I didn't get lucky with the shared array example. Seems unlikely that the memory would just happen to work, but I figure someone will be familiar with the plugins and can reassure me. thanks andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] plugin source code
Thank you. That also shows me where the new code is--the serializers directory next to the deprecated-dotosg, right? Looks like the equivalent writing code uses a operator on the data. Following that code around to OutputStream.cpp, it looks like the writeArray() method does a static cast of the arrays to ByteArray, FloatArray, etc. I think that's the same problem we had before. But writeArrayImplementation() takes a pointer to the array of actual data. That would work for us. So I _think_ it depends on the particular cast between things like FloatArray and float*. While I look into this, could you tell me if I'm in the correct code? thanks, andy -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users- boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Monday, December 06, 2010 9:46 AM To: OpenSceneGraph Users Subject: Re: [osg-users] plugin source code Hi Andy, The deprecated DotOsgWrappers can now be found in src/osgWrappers/deprecated-dotosg/*/*. Robert. On Mon, Dec 6, 2010 at 2:34 PM, Andy Skinner andy.skin...@mathworks.com wrote: I was looking at submitting a fix for the osg plugin. We use shared arrays (see osgsharedarray example) in the last stable release of OSG. We had a problem writing osg files of our scene because of a static cast in the osg plugin. It assumed it knew what the array was (FloatArray, for example) and cast to it. Our arrays weren't implemented with that, and we crashed. We had a fix where we get the actual array memory out and use that, so it worked with either kind of array. I was going to submit that, but I don't see the problem in the trunk. (I added writing a file to the osgsharedarray example.) So I went to check out Geometry.cpp in the osg plugin, and it isn't there. Seems the plugins have been refactored. Could someone point me to the code equivalent to the Array_writeLocalData function that was in Geometry.cpp in src/osgPlugins/osg before? Is the new code set up to handle shared arrays without assuming what they are? I want to make sure I didn't get lucky with the shared array example. Seems unlikely that the memory would just happen to work, but I figure someone will be familiar with the plugins and can reassure me. thanks andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users- openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users- openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] AutoTransform and traversals
I'm not sure why the calculations done in AutoTransform are done in the cull traversal, rather than in update. I'd have thought that update was for objects setting things in themselves, and the cull was read only. Does the update not accumulate transform matrices? Something else? thanks andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] destructing Viewer after context is gone
GraphicsWindowEmbbedded usage assume that context is always current for the life of the viewer. With a bit of hacking you could probably disable the clean up the view and graphics window are attempting to do, but it would probably be far easier to remove the destroy the graphics window/viewer prior to the context being deleted. Thanks. JOGL has an interface with init(), display(), displayChanged(), and reshape(). It doesn't have a method for when the context is being destroyed. You can do something on the removeNotify() for the component, but we've seen some cases where the context is remade without prior notice (it had to do with resizing GLJPanel, which has a PBuffer inside it). That just makes me concerned that I can't guarantee to catch a context going away before it does. thanks, andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] destructing Viewer after context is gone
I'm using OSG 2.8.3, the last stable release. I'm using a Viewer with GraphicsWindowEmbedded. On closing the window, the Viewer is destroyed, and the destructor tries to close the GraphicsContext. Inside flushAllDeletedGLObjects, flushDeletedGlPrograms is called. Inside that, there is a call to GL2Extensions::Get(). And in that, if s_extensions[contextID] is 0, it is trying to construct a new GL2Extensions object. Finally, that's calling glGetString(GL_VERSION). But by now, the graphics context is no longer valid. Should I be able to set up a Viewer or CompositeViewer such that it can be destroyed when the graphics context is not current? What about if it does not exist anymore? thanks andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] cull callbacks
What is the difference between the cull callback set on a Drawable and a NodeCallback set as a cull callback on a Node? I saw one thread on the list where someone was confusing them, and the difference was mentioned, but not spelled out. It appears the Drawable::CullCallback is used to decide whether to cull the drawable. What does the cull callback on the Node do? thanks andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.8.3 testing
I was able to build from the updated 2.8 branch last night. This morning I was able to telnet to a mac and run osgconv without complaints about not being able to get to the display. That was the case we were testing before. thanks andy -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users- boun...@lists.openscenegraph.org] On Behalf Of Paul Martz Sent: Monday, March 22, 2010 6:27 PM To: OpenSceneGraph Users Subject: Re: [osg-users] 2.8.3 testing Chuck Seberino wrote: Andy and Paul - I submitted a fix for this (r10927) which reorders some of the ifdef checking so that it works properly under OSX. Thanks, r10927 is now merged onto the 2.8 branch. Andy, let me know how that works for you. (I wasn't seeing this problem on 32bit OS X 10.5; I do a ccmake to generate makefiles and build with gcc on the command line, apparently a different configuration from you?) And, sorry I wasn't able to get to this sooner. We had a temporary internet outage in the area. Back online now (obviously). -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users- openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.8.3 release likely, need community assistance
Rats. I think some more changes were made after I tested this off of the trunk. I don't mind taking a look at it, but haven't been paying attention to how much time I'd have to get this fixed. How long? Of course, if it is breaking the trunk's build, I assume it will be fixed soon. Thanks for trying to get it, andy -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users- boun...@lists.openscenegraph.org] On Behalf Of Paul Martz Sent: Sunday, March 21, 2010 5:12 PM To: OpenSceneGraph Users Subject: Re: [osg-users] 2.8.3 release likely, need community assistance Paul Martz wrote: Hi Andy -- This is now in the 2.8 branch (r11207, and also yesterday's r11263). It would be great if you could do some testing and verify this resolves the issue. Thanks in advance. Well, not so fast... It turns out that r11207 breaks the build on OS X 10.5. I get the same build errors on trunk as I do on the 2.8 branch with this change. Errors below. I'll back this out in 2.8. -Paul /Users/pmartz/Projects/OSG/trunk/src/osgViewer/GraphicsWindowCarbon.cpp : In member function Ôvirtual void osgViewer::CarbonWindowingSystemInterface::_init()Õ: /Users/pmartz/Projects/OSG/trunk/src/osgViewer/DarwinUtils.h:123: error: Ôbool osgDarwin::DarwinWindowingSystemInterface::_initializedÕ is private /Users/pmartz/Projects/OSG/trunk/src/osgViewer/GraphicsWindowCarbon.cpp :1069: error: within this context /Users/pmartz/Projects/OSG/trunk/src/osgViewer/GraphicsWindowCarbon.cpp :1071: error: ÔinitÕ is not a member of ÔosgDarwin::DarwinWindowingSystemInterfaceÕ make[2]: *** [src/osgViewer/CMakeFiles/osgViewer.dir/GraphicsWindowCarbon.cpp.o] Error 1 make[1]: *** [src/osgViewer/CMakeFiles/osgViewer.dir/all] Error 2 make: *** [all] Error 2 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users- openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.8.3 release likely, need community assistance
I'm building the trunk again now on OS X, to see if Robert has fixed the problem you mention. If he has, maybe you could bring this change back in. andy Rats. I think some more changes were made after I tested this off of the trunk. I don't mind taking a look at it, but haven't been paying attention to how much time I'd have to get this fixed. How long? Of course, if it is breaking the trunk's build, I assume it will be fixed soon. Thanks for trying to get it, andy Paul Martz wrote: Hi Andy -- This is now in the 2.8 branch (r11207, and also yesterday's r11263). It would be great if you could do some testing and verify this resolves the issue. Thanks in advance. Well, not so fast... It turns out that r11207 breaks the build on OS X 10.5. I get the same build errors on trunk as I do on the 2.8 branch with this change. Errors below. I'll back this out in 2.8. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.8.3 release likely, need community assistance
OK, I'll do that. I was building the trunk, but now that you've got that back, I'm getting 2.8. I'll let you know. andy -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users- boun...@lists.openscenegraph.org] On Behalf Of Paul Martz Sent: Monday, March 22, 2010 11:35 AM To: OpenSceneGraph Users Subject: Re: [osg-users] 2.8.3 release likely, need community assistance Andy Skinner wrote: I'm building the trunk again now on OS X, to see if Robert has fixed the problem you mention. If he has, maybe you could bring this change back in. Yes, it does look like trunk has a fix, plus I was missing another change. I have put your fix back in the 2.8 branch, plus also merged in r9904 and r11273, and this is building for me without errors on OS X 10.5 (and trunk is also building fine). Please test the latest 2.8 branch to make sure this resolves your static initializer issue. Thanks. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users- openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.8.3 testing
I just got OpenSceneGraph-2.8, and tried to build on OS X. I'm getting an error in OpenThreads/Atomic, complaining that int32_t does not name a type. I'm following the unix instructions, doing configure and then make. I had just build the trunk (at least the first part) and got past this. Have I got it set up incorrectly, or is there a problem on 2.8? thanks andy -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users- boun...@lists.openscenegraph.org] On Behalf Of Paul Martz Sent: Monday, March 22, 2010 12:31 PM To: OpenSceneGraph Users Subject: [osg-users] 2.8.3 testing Hi all -- Here's an update on the 2.8.3 release, and a plea for testing. The 2.8.3 release is slightly behind my original schedule, but nonetheless getting close to a release candidate. ISSUES: There are two open issues at this point: 1. XCode project files need to be updated. (Stephan, will you have any time to contribute this in the near future, or do we need another volunteer?) 2. Updates to the DAE plugin and osgManipulators nodekit. These are late feature requests. I'm concerned about updating these two modules. The changes for both these modules are not limited to the modules themselves, and require changes to core OSG and elsewhere. Many changes on trunk often depend on previous changes, and chasing all of them down with a high level of confidence is difficult. It would certainly introduce issues if I missed any required changes. Let me make this suggestion: Let's leave DAE and osgManipulators out of the 2.8.3 release. If someone really wants them, and can't wait for v2.10 (or v3.0), then we could do a 2.8.4 release. The benefit of this approach is that it doesn't prevent 2.8.3 from getting out the door in a timely fashion, should merging these changes produce instability that would otherwise delay the release. Does this make sense? TESTING: Please test the 2.8 branch if you have time. For convenience, here's the 2.8 branch URL: http://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/OpenScene Graph-2.8 I'd appreciate build/run testing for the following platforms and features: Platforms: Mac 10.5/10.6 32/64bit Windows XP/Vista/7, 32/64bit *nix, 32/64bit Features (latest stuff from trunk): osgAnimation nodekit FBX plugin 3ds plugin (esp writer capability) ImageIO plugin QuickTime plugin Inventor plugin ply plugin ffmpeg plugin There were also minor bug fixes to the 3dc, ac, dds, and flt plugins. When you send a test report, please mention which plugins you are building, as not all plugins build by default of course. Once we get the XCode project files updated, I'll tag a release candidate, and further candidates will follow as needed. I'm still hoping for a 31 March release date. If we start testing now, this should give us plenty of time for testing and resolving issues. Thanks! -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users- openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.8.3 testing
Does that mean I need to wait for it to get onto 2.8? Or that it is there? thanks andy -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users- boun...@lists.openscenegraph.org] On Behalf Of Chuck Seberino Sent: Monday, March 22, 2010 1:00 PM To: OpenSceneGraph Users Subject: Re: [osg-users] 2.8.3 testing Andy and Paul - I submitted a fix for this (r10927) which reorders some of the ifdef checking so that it works properly under OSX. Chuck On Mar 22, 2010, at 9:47 AM, Andy Skinner wrote: I just got OpenSceneGraph-2.8, and tried to build on OS X. I'm getting an error in OpenThreads/Atomic, complaining that int32_t does not name a type. I'm following the unix instructions, doing configure and then make. I had just build the trunk (at least the first part) and got past this. Have I got it set up incorrectly, or is there a problem on 2.8? thanks andy -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users- boun...@lists.openscenegraph.org] On Behalf Of Paul Martz Sent: Monday, March 22, 2010 12:31 PM To: OpenSceneGraph Users Subject: [osg-users] 2.8.3 testing Hi all -- Here's an update on the 2.8.3 release, and a plea for testing. The 2.8.3 release is slightly behind my original schedule, but nonetheless getting close to a release candidate. ISSUES: There are two open issues at this point: 1. XCode project files need to be updated. (Stephan, will you have any time to contribute this in the near future, or do we need another volunteer?) 2. Updates to the DAE plugin and osgManipulators nodekit. These are late feature requests. I'm concerned about updating these two modules. The changes for both these modules are not limited to the modules themselves, and require changes to core OSG and elsewhere. Many changes on trunk often depend on previous changes, and chasing all of them down with a high level of confidence is difficult. It would certainly introduce issues if I missed any required changes. Let me make this suggestion: Let's leave DAE and osgManipulators out of the 2.8.3 release. If someone really wants them, and can't wait for v2.10 (or v3.0), then we could do a 2.8.4 release. The benefit of this approach is that it doesn't prevent 2.8.3 from getting out the door in a timely fashion, should merging these changes produce instability that would otherwise delay the release. Does this make sense? TESTING: Please test the 2.8 branch if you have time. For convenience, here's the 2.8 branch URL: http://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/OpenScene Graph-2.8 I'd appreciate build/run testing for the following platforms and features: Platforms: Mac 10.5/10.6 32/64bit Windows XP/Vista/7, 32/64bit *nix, 32/64bit Features (latest stuff from trunk): osgAnimation nodekit FBX plugin 3ds plugin (esp writer capability) ImageIO plugin QuickTime plugin Inventor plugin ply plugin ffmpeg plugin There were also minor bug fixes to the 3dc, ac, dds, and flt plugins. When you send a test report, please mention which plugins you are building, as not all plugins build by default of course. Once we get the XCode project files updated, I'll tag a release candidate, and further candidates will follow as needed. I'm still hoping for a 31 March release date. If we start testing now, this should give us plenty of time for testing and resolving issues. Thanks! -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users- openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users- openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users- openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.8.3 release likely, need community assistance
Paul, Robert was at one time (Novemeber, December) working with removing some more static initializers. We really need to get up to date on OSG, and we need to get rid of the initializers. If Robert was able to complete that (he hadn't had time as of December), it would be a big help. (We want to use the osgViewer library, but the initializers caused problems for us.) Even if he was able to do it, I don't know whether the changes were small enough for your purposes. But for us to take another step on 2.8.x (as stable instead of developer) would be comforting. thanks andy -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users- boun...@lists.openscenegraph.org] On Behalf Of Paul Martz Sent: Tuesday, March 09, 2010 9:25 PM To: OpenSceneGraph Users Subject: [osg-users] 2.8.3 release likely, need community assistance Hi folks -- I am 99% certain that I'll be doing a 2.8.3 release in the next few weeks. The release will not be API compatible with 2.8.2. I wanted to let you all know my plans, and also solicit input and assistance if there are any changes you'd like to get into this release. With some community input, I'm sure this release could be valuable to others besides myself. I'm not inclined to incorporate any major changes such as the Notify changes, new text/binary file format, or the weak_ptr-related changes. Large changes increase the complexity of the merge and the odds of me introducing errors as I apply the changes. I'm really just interested in bug fixes and feature changes that affect only a limited portion of OSG as a whole. The work will be done on the existing 2.8 branch. There was a little-publicized 2.8.2b tag, which is just 2.8.2 plus a fix for MSFBO on Mac OS X. So the first change I'll make to the 2.8 branch is to fold in the MSFBO fix from 2.8.2b. Other changes I have in mind: * The biggest change is to backport current svn trunk osgAnimation and the FBX plugin. This will require changes to other parts of OSG, and so far I've identified these: - Changes to osgDB required by FBX. - Un-deprecation of the osgAnimation dotosg wrapper. - r10671 Core changes required for osgAnimation. - r10672 Core changes required for osgAnimation. - r11009 (only the portion applicable to the BVH plugin, so that it is compatible with osgAnimation). (This is a pretty complex change, and it's about as complex as I would want to get. In a test merge, I ran into quite a few merge conflicts that had to be resolved manually, with risk of introducing error. Hopefully everything else will be much simpler to merge over to the 2.8 branch.) * Fix for osgUtil::Optimizer FlattenStaticTransformsVisitor (r11131). * Fix for OcclusionQueryNode (r10933 and r11127). * Mac OS X 10.6 support. Not yet sure which svn revisions. * New Xcode updates for osgAnimation. * A run of genwrappers to support any and all API changes. * Possibly backport some examples such as osganimationviewer, haven't looked at them yet. What I'd like from the community: * Any suggestions for other changes? Ideally, they should be modular, tight changes that merge onto the 2.8 branch with a minimum of conflicts. Please post requests using the specific svn revision number. (Also, please don't suggest anything unless you are willing and able to test the change once it's in on the 2.8 branch.) * Anyone out there with Mac OS X experience? Specific things I'd like assistance with would be: - Input on which svn revisions are required to enable support for Mac OS X 10.6. The goal is to be able to build OSG 2.8.3 against the 10.6 SDK. - Somebody with a Mac that already has 10.6, for testing. I have 10.5 but can upgrade if no one else steps forward. - An Xcode expert to create appropriate Xcode files for the 2.8.3 release (needs to work with the osgAnimation backport). If everything goes well, I see no reason why we can't release by end of March, so I'd like to set this schedule: * All change requests by end of day Friday 12 March. * All code changes in by 17 March. * All Xcode and genwrapper changes in by 22 March. * Release candidate 1, 22 March. * Testing period, 23-30 March. * Release, 31 March. Please give this some thought, and thanks in advance for pitching in. -Paul ___ 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] Gearing up for OpenSceneGraph-2.8.2, OpenSceneGraph-2.10 and VirtualPlanetBuilder-1.0 releases
I'd like to see the SceneGraphOrderRenderBin implementation if it could fit in. It was discussed in May. andy -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Saturday, June 20, 2009 6:27 AM To: OpenSceneGraph Users Subject: [osg-users] Gearing up for OpenSceneGraph-2.8.2, OpenSceneGraph-2.10 and VirtualPlanetBuilder-1.0 releases Hi All, Over the next six weeks I'd like to push out three stable software releases, it's not something I can do on my own as testing, bug fixing and feature refinement all items that community participation are essential to ensure quality software goes out the door. -- OpenSceneGaph-2.8.2 release, aiming for end of June (next two weeks) First up will be another patch release of the OpenSceneGraph-2.8 series. In theory the 2.8 branch should build and run across without problems as I generally stick to low risk changes, but... as we found out with 2.8.1 even changes that look uncontroversial can unwittingly introduce new bugs break end user applications - testing against a wide range of applications and platforms is absolutely essential to catch problems prior to a stable release. Testing out release candidates can be pretty dull, but it's crucial so please make the effort to pull down the rc's and test against your own applications. As I have two other major releases to get out, it would be very helpful for driving the 2.8.2 release forward if engineers that have write access to the OSG-2.8 branch come forward to pick up the batton and drive the 2.8.2-rc series, both in terms of coordinating with the community and merging bug fixes. Volunteers please come forward ;-) -- OpenSceneGraph-2.10 and VirtualPlanetBuilder-1.0 releases, aiming for end of July (in time for Siggraph) The next two releases are VirtualPlanetBuilder-1.0 and OpenSceneGraph-2.10. VPB is now broadly feature complete, but in need of serious testing, debugging, refinement and of course documentation. The key feature I have just added was patching of previously built databases, and support for database revisions. The database revision support is something that is part of OSG-svn/trunk, and will be part of the OSG-2.9.5 that I'll roll out on Monday, so VPB-1.0 will either have to go out against OSG-2.9.5 or wait for the stable OSG-2.10 release. The VPB stable release really should go out with stable OSG release so we should work towards getting OSG-2.10 and VPB-1.0 tested in parallel and released in quick succession. In terms of feature for OSG-2.10, it's mostly feature complete but there are a number of loose ends that need tying up: Out of the box audio support for the ffmpeg plugin Fix pause and some playback timing issues in the ffmpeg plugin Add support for recording movies to osgViewer using ffmpeg plugin. Move the xine-lib plugin out into Deprecated. Add support for clipping planes to osgVolume. Tidy up the Present3D application + plugin and provide online resources. Other stuff that I can't think of right now... Other stuff that that community needs/would like to tackle for OSG-2.10. -- Community Coordination As a general development philosophy note, When it comes to stable release Quality if King, features are expandable - so please think like this when considering what extras you are thinking about contributing over the next month and half, testing and bug fixing and existing feature refinement are the top priority. Over the next six weeks I'll be away for weeks family holiday at the beginning of July, and week training/consultancy on the 3rd week of July, so the amount of time that I can do coding, testing, bug fixing and community coordination will have to fitted in to four weeks work. The community no doubt will also be similarly distracted at various times, so for us to get everything done will require good coordination and extra level of effort. Let me when you available to help out and when you won't be available. Also managers of groups that use the OSG need to think about allotting time for engineers to help out with testing, as a good quality release that works with your own software is a real project benefit so well worth investing in. Many thanks in advance for you help, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.1 release candidate five tagged
Windows XP with NVidia card has been fine so far. I'm using cmake 2.6 patch 2. I'm working on OSX 32 and 64 bit, and linux 64 bit. andy -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Tuesday, May 19, 2009 9:21 AM To: OpenSceneGraph Users Subject: Re: [osg-users] OpenSceneGraph-2.8.1 release candidate five tagged Hi All, Thanks for the testing. So far we have 3 confirmations for linux distro's, one for OSX, none for Window or other systems yet. If you are currently doing a build and test and it hasn't completed yet please tell me so I know what I might be able to do the final tag of 2.8.1. So far things look good for the release this afternoon. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.1 release candidate five tagged
Well, everything seems to have built well and compiled with our stuff. I'm having trouble completing the test that I want to do, but the problem is on my end, and I don't have time for it, sorry. I believe it is working (passed our unittests, compiled). andy -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Andy Skinner Sent: Tuesday, May 19, 2009 10:27 AM To: OpenSceneGraph Users Subject: Re: [osg-users] OpenSceneGraph-2.8.1 release candidate five tagged Windows XP with NVidia card has been fine so far. I'm using cmake 2.6 patch 2. I'm working on OSX 32 and 64 bit, and linux 64 bit. andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.1 release candidate five tagged
I'll try, but not sure I can finish this afternoon. I was still working on rc 4. andy -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Monday, May 18, 2009 12:20 PM To: OpenSceneGraph Users Subject: [osg-users] OpenSceneGraph-2.8.1 release candidate five tagged Hi All, I've just tagged another release candidate, this time we've hit 2.8.1-rc5. Fingers crossed this will be our latest rc and we can quickly move on to tagging 2.8.1 and get some new binaries posted. http://www.openscenegraph.org/projects/osg/wiki/Downloads Source Code: ¶ source package : OpenSceneGraph-2.8.1-rc5.zip svn tag: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.1-rc5 OpenSceneGraph Could users please test out this latest rc5 this afternoon/evening and if things look good on the major platforms I'll tag 2.8.1 tomorrow morning. Thanks for your assistance, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 2.8.1
How much feedback do you need for OSG 2.8.1? thanks, andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.1 release candidate three tagged
RC3 seems OK to me on Win32, linux 64, and Intel mac 32. thanks, andy -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Thursday, April 23, 2009 10:41 AM To: OpenSceneGraph Users Subject: [osg-users] OpenSceneGraph-2.8.1 release candidate three tagged Hi All, (from my blog at blog.openscenegraph.org) I've just tagged the 2.8.1 release candidate 3. The are a couple of fixes since rc2: * Fix to the subsurface handling in OpenFlight files * Removal of an old hack to PolygonOffset's unit multiplier for ATI cards that is no longer required. * A couple of typo/spelling fixes. * Build fix for collada under OSX. * Addition of GL_RGB8 support to osg::image::computeNumComponts() * Fix to DatabasePager to prevent a crash that occurred when apps that did't set the active contexts (note, osgViewer automatically sets the active contexts so was unaffected by this bug.) You can grab the source code from: source package : OpenSceneGraph-2.8.1-rc3.zip svn tag: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.1-rc3 OpenSceneGraph Please test with your apps and various build environments, and send in feedback of success or failures to osg-users mailing lists/forum so we can track convergence to the final 2.8.1 stable release. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.1 release candidate three tagged
Thanks. Sorry I'm slow--I have built rc2 on Intel Mac, win32, and Linux 64. I have tried it in my app on win32. I guess instead of trying what I have on the other platforms, I should get the new one. I've had a lot going on, so haven't been able to give quick responses. andy -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Thursday, April 23, 2009 10:41 AM To: OpenSceneGraph Users Subject: [osg-users] OpenSceneGraph-2.8.1 release candidate three tagged Hi All, (from my blog at blog.openscenegraph.org) I've just tagged the 2.8.1 release candidate 3. The are a couple of fixes since rc2: * Fix to the subsurface handling in OpenFlight files * Removal of an old hack to PolygonOffset's unit multiplier for ATI cards that is no longer required. * A couple of typo/spelling fixes. * Build fix for collada under OSX. * Addition of GL_RGB8 support to osg::image::computeNumComponts() * Fix to DatabasePager to prevent a crash that occurred when apps that did't set the active contexts (note, osgViewer automatically sets the active contexts so was unaffected by this bug.) You can grab the source code from: source package : OpenSceneGraph-2.8.1-rc3.zip svn tag: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.1-rc3 OpenSceneGraph Please test with your apps and various build environments, and send in feedback of success or failures to osg-users mailing lists/forum so we can track convergence to the final 2.8.1 stable release. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 2.8.1
This seems to work, too. I haven't done what I'd call a thorough qualification, but I'm happy. thanks, andy From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Wednesday, March 18, 2009 12:39 PM To: OpenSceneGraph Users Subject: Re: [osg-users] OSG 2.8.1 Hi Andy, 2009/3/18 Andy Skinner andy.skin...@mathworks.commailto:andy.skin...@mathworks.com You know, I was thinking that using SVN was going to get me the latest, but I bet I'm just getting SVN from when 2.8.0 was made. I'm using the line (copied from downloads page): svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.0 OpenSceneGraph Was that the wrong thing? You're just picking up on the 2.8.0 tag, which is effectively set is stone now as it maps directly to what the 2.8.0 binaries etc. were built from. The version of test against is the OSG-2.8 branch, this is what we used to source the 2.8.0 tag, and where all the patches for the ongoing 2.8.x series have been applied, and when it comes to making 2.8.1 it'll be sourced directly from the OSG-2.8. To get the OSG-2.8 branch us: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/http://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/OpenSceneGraph-2.8http://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/OpenSceneGraph-2.8OpenSceneGraph-2.8http://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/OpenSceneGraph-2.8 OpenSceneGraph 2.8 in theory should be like 2.8.0 except for a number of bug fixes that've been applied. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSG 2.8.1
I've built the OSG successfully, but it is going to take me longer to test it with our software. Last time I just built it without updating with our code, and now I'm finding that I have to change some of our BoundingSphere code that doesn't compile. I'll give feedback on the 2.8.1 as soon as I can. andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 2.8.1
You know, I was thinking that using SVN was going to get me the latest, but I bet I'm just getting SVN from when 2.8.0 was made. I'm using the line (copied from downloads page): svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.0 OpenSceneGraph Was that the wrong thing? First the BoundingSphere issue was me getting half old and half new OSG. I got past that and had a problem with BoundingBox, but that turned out to be from the forward declaration, and it isn't a class anymore. Turns out the forward decl was unnecessary (we were already including Drawable), so I just removed it. Let me know whether I need to do it again with a more recent version from SVN, and what specifically my command should be. Thanks, andy From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Wednesday, March 18, 2009 11:05 AM To: OpenSceneGraph Users Subject: Re: [osg-users] OSG 2.8.1 HI Andy, 2009/3/18 Andy Skinner andy.skin...@mathworks.commailto:andy.skin...@mathworks.com I've built the OSG successfully, but it is going to take me longer to test it with our software. Thanks for the testing. Are you building against OSG-2.8.0 or the OSG-2.8 branch? Last time I just built it without updating with our code, and now I'm finding that I have to change some of our BoundingSphere code that doesn't compile. I'll give feedback on the 2.8.1 as soon as I can. What problems are you seeing with BoundingSphere code? The main change was the introduction of templates to enable use of double and float versions of BoundingSphere. The defaults should be the same as before though, i.e. BoundingSphere - floating point BoundingSphere. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Release schedule for OpenSceneGraph-2.8.1
I definitely want to give the 2.8.0 trunk a try, and will try to do it in relatively soon. It might be next week. andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] atomic_xor_uint_nv on Solaris
A const cast does remove the second error (and atomic_cas_ptr does seem like it
could have used a const argument, since this is the comparison arg, which
shouldn't be changed).
I still haven't gotten rid of the atomic_xor_uint_nv issue, though, so I can't
build the OpenSceneGraph on all our platforms. The code looks like:
_OPENTHREADS_ATOMIC_INLINE unsigned
Atomic::XOR(unsigned value)
{
#if defined(_OPENTHREADS_ATOMIC_USE_GCC_BUILTINS)
return __sync_fetch_and_xor(_value, value);
#elif defined(_OPENTHREADS_ATOMIC_USE_MIPOSPRO_BUILTINS)
return __xor_and_fetch(_value, value);
#elif defined(_OPENTHREADS_ATOMIC_USE_SUN)
return atomic_xor_uint_nv(_value, value);
#elif defined(_OPENTHREADS_ATOMIC_USE_MUTEX)
ScopedLockMutex lock(_mutex);
_value ^= value;
return _value;
#else
_value ^= value;
return _value;
#endif
}
The line that complains that atomic_xor_uint_nv() needs a prototype is the one
inside the condition for _OPENTHREADS_ATOMIC_USE_SUN.
If anyone has an idea of a include I'm supposed to have, or something I'm
supposed to define, please help.
thanks,
andy
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Andy Skinner
Sent: Tuesday, January 06, 2009 1:45 PM
To: OpenSceneGraph Users
Subject: [osg-users] atomic_xor_uint_nv on Solaris
I'm trying to build a recent SVN version, and get errors for
include/OpenThreads/Atomic:
line 183: Error, badfunccp: The function atomic_xor_uint_nv must have a
prototype.
I'm not sure about this one. How is that supposed to be defined?
line 243: Error, badargtype2: Formal argument 2 of type void* in call to
atomic_cas_ptr(volatile void* void* void*) is being passed const void*const.
Is this one just a const issue? Should it use a const cast, or is this a sign
of a problem?
thanks
andy
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] atomic_xor_uint_nv on Solaris
Thanks. I've sent an email to Blasius (hoping I got the email from Gmane correctly), and will see if he has a suggestion. andy -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Wednesday, January 07, 2009 9:05 AM To: OpenSceneGraph Users Subject: Re: [osg-users] atomic_xor_uint_nv on Solaris Hi Andy, I don't have a Sun box or up to date knowledge to be about to suggestion resolution of this problem, save for reverting the addition of this code. The code was part of the submission below from Blasius Czink, perhaps we just remove the elements that are problematic - the OSG itself doesn't use the and, or and xor features. Robert. -- r9059 | robert | 2008-10-27 10:42:58 + (Mon, 27 Oct 2008) | 37 lines From Blasius Czink, Among other things I added support for atomic operations on BSD-like systems and additional methods (for and, or, xor). and a later post the same osg-submissions thread: it's been a while since I have made the changes but I think it was due to problems with static builds of OpenThreads on windows. I was using OpenThreads in a communication/synchronisation library (without OpenSceneGraph). It seems I forgot to post a small change in the CMakeLists file of OpenThreads. If a user turns DYNAMIC_OPENTHREADS to OFF (static build) OT_LIBRARY_STATIC will be defined in the Config. Without these changes a windows user will always end up with a __declspec(dllexport) or __declspec(dllimport) which is a problem for static builds. And another post from Blasius on this topic: I tested with VS2005 and VS2008. For 32 bit everything works as expected. For x64 and VS2008 I could successfully do the cmake-configure and then the compilation but I had occasional crashes of cmTryCompileExec.exe (during the cmake-configure phase) which seems to be a cmake bug. With VS2005 and 64bit cmake does not set _OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED although the interlocked functionality should be there. If I place the source snippet from the CHECK_CXX_SOURCE_RUNS macro to a separate sourcefile I can compile and run the resulting executable successfully. Forcing OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED (on VS2005/x64) reveals a bug in intrin.h which seems to be fixed in VS2008 but not in VS2005. In case anyone is interested the lines: __MACHINEI(unsigned char _interlockedbittestandset(long *a, long b)) __MACHINEI(unsigned char _interlockedbittestandreset(long *a, long b)) __MACHINEX64(unsigned char _interlockedbittestandset64(__int64 *a, __int64 b)) __MACHINEX64(unsigned char _interlockedbittestandreset64(__int64 *a, __int64 b)) should be changed to: __MACHINEI(unsigned char _interlockedbittestandset(long volatile *a, long b)) __MACHINEI(unsigned char _interlockedbittestandreset(long volatile *a, long b)) __MACHINEX64(unsigned char _interlockedbittestandset64(__int64 volatile *a, __int64 b)) __MACHINEX64(unsigned char _interlockedbittestandreset64(__int64 volatile *a, __int64 b)) The worst thing that can happen is that interlocked funtionality is not detected during cmake-configure and the mutex fallback is used. Which reminds me another small glitch in the Atomic header so I attached a corrected version. Why is the OT_LIBRARY_STATIC added to the config file? It is not needed anywhere. OT_LIBRARY_STATIC is needed if you are doing static-builds on Windows. See my previous post on that. ___ 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] atomic_xor_uint_nv on Solaris
I've not heard from Blasius Czink yet, but I have found out that there is a /usr/include/sys/atomic.h that declares things like atomic_or_uint_nv(), but does not declare atomic_xor_uint_nv(). Maybe the xor operation could be removed instead of the whole thing. I can't find any reference to xor in the header file. andy -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Wednesday, January 07, 2009 9:05 AM To: OpenSceneGraph Users Subject: Re: [osg-users] atomic_xor_uint_nv on Solaris Hi Andy, I don't have a Sun box or up to date knowledge to be about to suggestion resolution of this problem, save for reverting the addition of this code. The code was part of the submission below from Blasius Czink, perhaps we just remove the elements that are problematic - the OSG itself doesn't use the and, or and xor features. Robert. -- r9059 | robert | 2008-10-27 10:42:58 + (Mon, 27 Oct 2008) | 37 lines From Blasius Czink, Among other things I added support for atomic operations on BSD-like systems and additional methods (for and, or, xor). and a later post the same osg-submissions thread: it's been a while since I have made the changes but I think it was due to problems with static builds of OpenThreads on windows. I was using OpenThreads in a communication/synchronisation library (without OpenSceneGraph). It seems I forgot to post a small change in the CMakeLists file of OpenThreads. If a user turns DYNAMIC_OPENTHREADS to OFF (static build) OT_LIBRARY_STATIC will be defined in the Config. Without these changes a windows user will always end up with a __declspec(dllexport) or __declspec(dllimport) which is a problem for static builds. And another post from Blasius on this topic: I tested with VS2005 and VS2008. For 32 bit everything works as expected. For x64 and VS2008 I could successfully do the cmake-configure and then the compilation but I had occasional crashes of cmTryCompileExec.exe (during the cmake-configure phase) which seems to be a cmake bug. With VS2005 and 64bit cmake does not set _OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED although the interlocked functionality should be there. If I place the source snippet from the CHECK_CXX_SOURCE_RUNS macro to a separate sourcefile I can compile and run the resulting executable successfully. Forcing OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED (on VS2005/x64) reveals a bug in intrin.h which seems to be fixed in VS2008 but not in VS2005. In case anyone is interested the lines: __MACHINEI(unsigned char _interlockedbittestandset(long *a, long b)) __MACHINEI(unsigned char _interlockedbittestandreset(long *a, long b)) __MACHINEX64(unsigned char _interlockedbittestandset64(__int64 *a, __int64 b)) __MACHINEX64(unsigned char _interlockedbittestandreset64(__int64 *a, __int64 b)) should be changed to: __MACHINEI(unsigned char _interlockedbittestandset(long volatile *a, long b)) __MACHINEI(unsigned char _interlockedbittestandreset(long volatile *a, long b)) __MACHINEX64(unsigned char _interlockedbittestandset64(__int64 volatile *a, __int64 b)) __MACHINEX64(unsigned char _interlockedbittestandreset64(__int64 volatile *a, __int64 b)) The worst thing that can happen is that interlocked funtionality is not detected during cmake-configure and the mutex fallback is used. Which reminds me another small glitch in the Atomic header so I attached a corrected version. Why is the OT_LIBRARY_STATIC added to the config file? It is not needed anywhere. OT_LIBRARY_STATIC is needed if you are doing static-builds on Windows. See my previous post on that. ___ 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] atomic_xor_uint_nv on Solaris
I'm trying to build a recent SVN version, and get errors for include/OpenThreads/Atomic: line 183: Error, badfunccp: The function atomic_xor_uint_nv must have a prototype. I'm not sure about this one. How is that supposed to be defined? line 243: Error, badargtype2: Formal argument 2 of type void* in call to atomic_cas_ptr(volatile void* void* void*) is being passed const void*const. Is this one just a const issue? Should it use a const cast, or is this a sign of a problem? thanks andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] reconstructing a decomposed matrix
I'd like to make sure I understand something I'm doing. I'm calling decompose() on a modelview matrix. I get a translation vector, rotation quaternion, scale vector, and scale orientation quaternion. How do I put them back together to get the original matrix? As I said, I'm trying to check my understanding of what it is doing. I have converted the translation vector to a translation matrix, the scale vector to a scale matrix, and the two quaternions into rotation matrices. (Maybe they should be something else?) Then I've tried multiplying matrices in various orders, and I haven't gotten it right. I don't see decompose used in the examples. Thanks, andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] reconstructing a decomposed matrix
Hmmm. Although I'd appreciate some help, I see that this has been asked recently, with lots of jokes and no answers. :) I'll fiddle with it some more. But if the David that asked before learned anything, I'd appreciate knowing, too. Thanks, andy From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Skinner Sent: Thursday, October 09, 2008 2:27 PM To: OpenSceneGraph Users Subject: [osg-users] reconstructing a decomposed matrix I'd like to make sure I understand something I'm doing. I'm calling decompose() on a modelview matrix. I get a translation vector, rotation quaternion, scale vector, and scale orientation quaternion. How do I put them back together to get the original matrix? As I said, I'm trying to check my understanding of what it is doing. I have converted the translation vector to a translation matrix, the scale vector to a scale matrix, and the two quaternions into rotation matrices. (Maybe they should be something else?) Then I've tried multiplying matrices in various orders, and I haven't gotten it right. I don't see decompose used in the examples. Thanks, andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] reconstructing a decomposed matrix
Actually, looks like I can ignore scale orientation and multiply scale, rotation, and translation, and get the original. I don't really understand scale orientation. andy From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Skinner Sent: Thursday, October 09, 2008 2:33 PM To: OpenSceneGraph Users Subject: Re: [osg-users] reconstructing a decomposed matrix Hmmm. Although I'd appreciate some help, I see that this has been asked recently, with lots of jokes and no answers. :) I'll fiddle with it some more. But if the David that asked before learned anything, I'd appreciate knowing, too. Thanks, andy From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Skinner Sent: Thursday, October 09, 2008 2:27 PM To: OpenSceneGraph Users Subject: [osg-users] reconstructing a decomposed matrix I'd like to make sure I understand something I'm doing. I'm calling decompose() on a modelview matrix. I get a translation vector, rotation quaternion, scale vector, and scale orientation quaternion. How do I put them back together to get the original matrix? As I said, I'm trying to check my understanding of what it is doing. I have converted the translation vector to a translation matrix, the scale vector to a scale matrix, and the two quaternions into rotation matrices. (Maybe they should be something else?) Then I've tried multiplying matrices in various orders, and I haven't gotten it right. I don't see decompose used in the examples. Thanks, andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG method for pushing/ popping entire openGL state machine?
Robert, I've got a drawImplementation() method that gets the projection and modelview matrices and does something with them, pushes both matrices and sets up pixel coordinates (glOrtho in projection, glLoadIdentity in modelview), calls osg::Geometry::drawImplementation(), and then does the pops for both matrices. Assume that I've got the OpenGL calls right (matrix mode, etc), since I haven't spelled them out and you don't have to debug that, and it seems pretty simple to me. So I'm interested in what I might have to take into account regarding state left by OSG. Could you give guidance about the sorts of things I'd have to do if there are vertex arrays still around? You suggest checking the current vertex array state from osg::State, but I don't know what I'd actually need to do after I checked. I could disable the vertex arrays, but I don't see anything for restoring that. If there are a number of things that drawImplementation should check and handle, it may be that useful to have a routine we could call, since it seems it could be relevant in any drawImplementation. The specific problem is some geometry (points) that doesn't appear when drawn after an object with my drawImplementation method. I'm still running in 2.4. Are there known fixes related to this in 2.6? thanks, andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Wednesday, August 27, 2008 11:30 AM To: OpenSceneGraph Users Subject: Re: [osg-users] OSG method for pushing/ popping entire openGL state machine? Hi Brett, There is no OSG call to push/pop the OpenGL state, if your own code modifies the OpenGL state that you'll need to do the push/pop yourself to make sure that the state is the same after as it was when entering your code. In your code example you are missing push/popping client state so perhaps you should add this. You'll also need to consider what state the OSG leaves OpenGL on entering your code segment. Assigning a StateSet to your custom drawable is a good way of setting various OpenGL state you wish. Also make sure you are inheriting what state you require and not inappropriate state down to your drawable. Also be wary of the vertex array settings that the OSG will have set OpenGL up as, the OSG uses lazy state updating so won't change state that it doesn't need to change, so it could be that some vertex arrays are left on on entering your code. You can check what the current vertex array state is from osg::State's access methods - go browse through include/osg/State to see the range of methods open to you. Robert. On Wed, Aug 27, 2008 at 3:37 PM, brettwiesner [EMAIL PROTECTED] wrote: Hi, I've got a third party product that does a bunch of openGL stuff inside the drawImplementation of a custom drawable. The third party stuff I use seems to leak state (it changes a bunch of indeterminable stuff in openGL) and that's causing weirdness with the rendering of the rest of my scene (textures turn blueish for example). I'd like to save the entire openGL state machine before the third party touches openGL, then restore it after. I'm doing the following but it's not quite working for me. glPushAttrib(GL_ALL_ATTRIB_BITS); do open gl stuff glPopAttrib(); Is there an OSG call to make to do this? Perhaps other openGL calls? Thanks, Brett ___ 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] OSG method for pushing/ popping entire openGLstate machine?
I'm not, but I'm pushing and popping the matrices. I didn't think I was changing anything else. andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Thursday, August 28, 2008 11:11 AM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] OSG method for pushing/ popping entire openGLstate machine? Could you give guidance about the sorts of things I'd have to do if there are vertex arrays still around? Are you doing glPushClientAttrib/glPopClientAttrib? -Paul ___ 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] Group::getNumChildren()
This method returns an unsigned int. It calls size() on the vector, which returns size_type. In our builds of software using OSG, we're getting warnings about a conversion of a 64 bit value to unsigned int. Has the OSG project had to change the type of common methods like this? Does it go well? I haven't had time to do any compiling of OSG for a long time (since we got 2.4.0 built and integrated). In this case, I'm adding a new file that gives this warning, and we've got structure in place to make it difficult to add files with warnings in compilation. I don't think it is likely to be a problem. One possibility is to cast it in the method. Is that what should be done? thanks andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shifting OpenSceneGraph-2.6 to early August release
Actually, I think you should always go away on vacation as you're about to make a release. :) I would be more comfortable with a little time to let the dust settle than what is usually given. andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] AutoTransform scale implementation
I'd like to know more about the AutoTransform auto-scale implementation. We want something similar, but we think we need to account for non-uniform scaling. Could I get a description of CullingSet::computePixelSizeVector()? I see it was written in 2002, but I'd appreciate any help in understanding it. I see that it uses the projection matrix. It seems to get the same scaling for objects at different depths, so I think it takes perspective into account. On the other hand, the projection matrix is changed after the cull (after calculating near and far), so it won't be the same as used in AutoTransform to get this scale. Any info on what this does would be appreciated. Thanks, andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] mac -install_name
Thanks, but that's what I'm trying to avoid. Don't you have to do the -id version for every file (changing its own name) and the -change version for every dependency in every file? I'm hoping I can do something in the link commands and avoid having to patch up the files. andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martins Innus Sent: Tuesday, May 27, 2008 1:03 PM To: OpenSceneGraph Users Subject: Re: [osg-users] mac -install_name Andy, I use install_name_tool -change . and install_name_tool -id ... in a script as a Run Script Build phase. I don't know if you can do it in XCode directly. Seems to work. Let me know if you need more info and I'll dig up the exact script. Martins Andy Skinner wrote: I'll admit to being a little past the limit of my knowledge here ... We would like to specify the -install_name arg with which we link the shared libraries. I think it is because we don't want the paths where these things were built to be in the files. We're trying to replace the value with something like: @load_path/filename. Is there a way to specify the -install_name argument on the Mac? I tried setting it in our linker flags, then saw it was in there already, and I think it is added by the OSG build. I have looked at the gmane archive, and found some mention of -install_name, but nothing I can see how to use. thanks andy ___ 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] mac -install_name
When I added -install_name something to our LDFLAGS, it complained that the option was in there twice. So I assumed CMAKE was putting it in. Maybe I should look to see if we're doing it somewhere. andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martins Innus Sent: Tuesday, May 27, 2008 2:24 PM To: OpenSceneGraph Users Subject: Re: [osg-users] mac -install_name Yeah, thats what I do, but I only have a couple files in my case I need to worry about. Although I just tried adding: -install_name @executable_path/../Frameworks/file.dylib to LDFLAGS and that seemed to work. I do this in a Makefile project and use the resulting dylib in a larger XCode project. Then i didn't have to do the install_name_tool voodoo. Martins Andy Skinner wrote: Thanks, but that's what I'm trying to avoid. Don't you have to do the -id version for every file (changing its own name) and the -change version for every dependency in every file? I'm hoping I can do something in the link commands and avoid having to patch up the files. andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martins Innus Sent: Tuesday, May 27, 2008 1:03 PM To: OpenSceneGraph Users Subject: Re: [osg-users] mac -install_name Andy, I use install_name_tool -change . and install_name_tool -id ... in a script as a Run Script Build phase. I don't know if you can do it in XCode directly. Seems to work. Let me know if you need more info and I'll dig up the exact script. Martins Andy Skinner wrote: I'll admit to being a little past the limit of my knowledge here ... We would like to specify the -install_name arg with which we link the shared libraries. I think it is because we don't want the paths where these things were built to be in the files. We're trying to replace the value with something like: @load_path/filename. Is there a way to specify the -install_name argument on the Mac? I tried setting it in our linker flags, then saw it was in there already, and I think it is added by the OSG build. I have looked at the gmane archive, and found some mention of -install_name, but nothing I can see how to use. thanks andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Projection vs Camera
I found a dusty part of our code where we have a Projection and a Camera. I've found an old email (2006) from this list about how the Projection is deprecated in favor of the Camera. I just wanted to check-is this correct? If we've got a Camera, we don't need a Projection? thanks andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Projection vs Camera
Thanks. Turns out we didn't have a transform--the Projection was a workaround for some bug that has since been fixed. Apparently the near and far clipping planes weren't correct at some point, and for some reason having this Projection node helped. I've removed it, and all seems well. thanks andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Wednesday, May 21, 2008 8:37 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Projection vs Camera Hi Andy, On Wed, May 21, 2008 at 1:11 PM, Andy Skinner [EMAIL PROTECTED] wrote: I found a dusty part of our code where we have a Projection and a Camera. I've found an old email (2006) from this list about how the Projection is deprecated in favor of the Camera. I just wanted to check-is this correct? If we've got a Camera, we don't need a Projection? osg::Projection existed before the days of osg::Camera, with the arrival of the later two summers ago the former became a bit obsolete, but is kept around for backwards compatibility. osg::Camera is effectively an osg::Projection + an osg::MatrixTransform all round into one class, plus a buck load of other Camera related features. So it's likely you won't be removing an osg::Projection node, but a osg::Projection node and a Transform placed above or below this osg::Projection node as Projection node on its own it's really that useful. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] question about warning in CullVisitor.cpp
There is an osg::notify at osg::WARN level in the CullVisitor in updateCalculatedNearFar(matrix, drawable, isBillboard). There are several, actually, but I'm asking about this one: if (d_near0.0) osg::notify(osg::WARN)2) sett near with d_near=d_near std::endl; else _computed_znear = d_near; Is there a specific case represented here, when d_near is negative? Does that mean something specific? An in-house customer of our code is trying to put an object at (just in, I hope) the near clipping plane, and I think it is this object giving the d_near 0.0. Is the computed_znear not supposed to be 0, I'd guess? I'm trying to decide what we're seeing here. Thanks, andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] question about warning in CullVisitor.cpp
I'll see about turning on the warnings. I actually haven't gotten the warning messages, but stepping through the code I found that it went through the case where the warning would come out if we were listening. I've found out more about the situation. Someone created the object to be near the camera (which is using an orthographic projection, by the way). However, part of it extends toward the camera, and I think goes behind the camera. This doesn't set a new calculated near z, and the object is completely clipped out, instead of being partly clipped out. There are a few ways we could work around this. I've got to think a bit to decide whether OSG should have set some near Z from this, even if it couldn't set it to the near Z that went behind the camera. thanks, andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Wednesday, May 21, 2008 12:31 PM To: OpenSceneGraph Users Subject: Re: [osg-users] question about warning in CullVisitor.cpp Hi Andy, I haven't seen warnings like this for a lng while... they usually suggest that some internal computation of the near/far distances for objects in the scene is in some way messed up. Is it possible to recreate this warning with osgviewer when loading one of your models? Robert. On Wed, May 21, 2008 at 5:04 PM, Andy Skinner [EMAIL PROTECTED] wrote: There is an osg::notify at osg::WARN level in the CullVisitor in updateCalculatedNearFar(matrix, drawable, isBillboard). There are several, actually, but I'm asking about this one: if (d_near0.0) osg::notify(osg::WARN)2) sett near with d_near=d_near std::endl; else _computed_znear = d_near; Is there a specific case represented here, when d_near is negative? Does that mean something specific? An in-house customer of our code is trying to put an object at (just in, I hope) the near clipping plane, and I think it is this object giving the d_near 0.0. Is the computed_znear not supposed to be 0, I'd guess? I'm trying to decide what we're seeing here. Thanks, andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgPlugins directory name change?
Hi. Our windows plugin directory used to be named osgplugins-version number. Now they seem to be osgPlugins-version number. Anyone familiar with this change? I know that windows doesn't care about case, but we have all kinds of systems here, and I'm not sure we don't have a script that runs on a different platform to copy Windows libraries around. Is it intentional (and not changing) that the plugins directory on Windows is now osgPlugins-version number and not osgplugins-version number? I'd like that, but I didn't see it mentioned, and it doesn't match our own code and makefiles. thanks andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgPlugins directory name change?
Hmmm. I found an email message from a long time ago with me asking and Robert saying they should be the same. He was guessing that it was vis studio making them lower case. But I can't find anything else about it (I'm sure we talked about this at some point, but I haven't found a case-sensitive web search). So I guess I'll just switch my stuff to use osgPlugins all over. Again, it doesn't seem to matter on windows. thanks andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean-Sébastien Guay Sent: Tuesday, April 29, 2008 3:38 PM To: OpenSceneGraph Users Subject: Re: [osg-users] osgPlugins directory name change? Hi Andy, Hi. Our windows plugin directory used to be named osgplugins-version number. Now they seem to be osgPlugins-version number. To my knowledge, on Windows and Linux, it has always been osgPlugins-version (with a capital P). I haven't seen any change there. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test SVN of OpenSceneGraph
We use cmake for everything, and don't treat the mac differently than unix at this point. andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Thursday, April 24, 2008 12:30 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Please test SVN of OpenSceneGraph On Thu, Apr 24, 2008 at 5:12 PM, Andy Skinner [EMAIL PROTECTED] wrote: The latest SVN reports version 2.3.11, and builds on our solaris, mac, win32, and linux 64 systems. Thanks for the feedback Andy, its good to hear things working. What version of Mac/build system are you using? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test SVN of OpenSceneGraph in pre for2.3.9devrelease
On all three platforms on which I compiled, I got an error: FrameBufferObject:619: error: 'COLOR_BUFFER15' is not a member of 'osg::Camera'. I just did svn update in my root directory before compiling. Should I have done something else? andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Friday, April 18, 2008 9:41 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Please test SVN of OpenSceneGraph in pre for2.3.9devrelease Hi All, Many thanks for the the testing and feedback. Alas I'm afraid I'll now further testing as this morning I've checked in a couple of bug fixes that will need build and runtime testing. I also forgot to mention, the SVN version of the OSG is now under feature freeze, so only bug and build fixes from here on out to 2.4. Could users do an svn update, build and run to see if the SVN version is ready for 2.3.9? Thanks in advance, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test SVN of OpenSceneGraph in prefor2.3.9devrelease
OK, latest SVN compiled on those same platforms. It is a good bit more work to try it out with our code, and I may wait until 2.3.9 for that. I don't expect a problem once it compiles, but I'll check it before 2.4. andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Skinner Sent: Friday, April 18, 2008 11:08 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Please test SVN of OpenSceneGraph in prefor2.3.9devrelease On all three platforms on which I compiled, I got an error: FrameBufferObject:619: error: 'COLOR_BUFFER15' is not a member of 'osg::Camera'. I just did svn update in my root directory before compiling. Should I have done something else? andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Friday, April 18, 2008 9:41 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Please test SVN of OpenSceneGraph in pre for2.3.9devrelease Hi All, Many thanks for the the testing and feedback. Alas I'm afraid I'll now further testing as this morning I've checked in a couple of bug fixes that will need build and runtime testing. I also forgot to mention, the SVN version of the OSG is now under feature freeze, so only bug and build fixes from here on out to 2.4. Could users do an svn update, build and run to see if the SVN version is ready for 2.3.9? Thanks in advance, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test SVN of OpenSceneGraph in pre for 2.3.9 devrelease
It built for me in windows and linux 64 bit. I'm still trying to get a solaris machine, and that is often where there has been trouble. andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Thursday, April 17, 2008 10:45 AM To: OpenSceneGraph Users Subject: [osg-users] Please test SVN of OpenSceneGraph in pre for 2.3.9 devrelease Hi All, I'm planning to make a 2.3.9 dev release today. Could SVN users do an svn update and try out compile and build. I have just checked in updates to the Quicktime plugin from Stephan Huber, these will need to be tested by Windows and OSX users that use the Quicktime plugin. Thanks in advance for you efforts, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test SVN of OpenSceneGraph in pre for 2.3.9devrelease
This worked on Solaris, too. andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Thursday, April 17, 2008 2:59 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Please test SVN of OpenSceneGraph in pre for 2.3.9devrelease Hi Andy et. al, On Thu, Apr 17, 2008 at 6:24 PM, Andy Skinner [EMAIL PROTECTED] wrote: It built for me in windows and linux 64 bit. I'm still trying to get a solaris machine, and that is often where there has been trouble. Thanks for the testing. I'll leave tagging 2.3.9 till tomorrow, and hope that by then I'll get some more feedback on Solaris and other platforms. Thanks, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] AutoTransform and reference frame
I'm trying to understand how to use AutoTransform to make an object that keeps its rotation and scale the same as I transform the scene or change the size of the window. The rotation part seems fine, but I've had some problem with the scale. I set AutoScaleToScreen to true and apply a scale for the aspect ratio below the AutoTransform. I'm not sure how AutoTransform should interact with setting the reference frame. I guess the difference in AutoTransform and a MatrixTransform with an absolute reference frame is that the AutoTransform should allow the rotation (and scale?) to affect the position of an object without changing its orientation or size. An absolute reference frame wouldn't apply any transforms above it, right? Any help on understanding how I'd use the reference frame and the AutoTransform, possibly together, would be appreciated. thanks, andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Testing of OSG and VPB SVN in prep for nex devreleases and 2.4 stable release
Sorry, just getting to it. I can do all those you mention, but give me some time. andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Monday, March 31, 2008 6:53 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Testing of OSG and VPB SVN in prep for nex devreleases and 2.4 stable release Thanks to Nicolas and David for build feedback. It'd be useful to have feedback from Windows, OSX, Solaris etc before I go tag another dev release. Thanks in advance for your efforts. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Testing of OSG and VPB SVN in prep for nex devreleases and 2.4 stable release
So far, my windows and OSX compilations have been fine. The Solaris compilation failed on OpenFlight/LightSourcePaletteManager.cpp, needing an include for the sprintf call. Adding #includestdio.h to the list of #includes in that file works fine. I'm up to about 85% now. andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Monday, March 31, 2008 6:53 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Testing of OSG and VPB SVN in prep for nex devreleases and 2.4 stable release Thanks to Nicolas and David for build feedback. It'd be useful to have feedback from Windows, OSX, Solaris etc before I go tag another dev release. Thanks in advance for your efforts. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenGL API RE: Mac OpenGL integration / CGLMacro.h
I've build 2.3.6 on solaris with and without this define that disables the macros. What are suggested examples to compare? We don't run the examples or osgviewer often, so spelling out suggested steps and examples and data might be useful. thanks andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Weiblen Sent: Friday, March 21, 2008 6:57 PM To: OpenSceneGraph Users Subject: Re: [osg-users] OpenGL API RE: Mac OpenGL integration / CGLMacro.h Hi Andy, Yikes! Yes, pls test w/ those Sun vertex macros disabled, and send to osg-submissions as appropriate. It's one thing for a developer to decide to use macro wrappers in their end application, but portable middleware libraries like OSG must avoid such trickery. cheers -- mew On Fri, Mar 21, 2008 at 7:12 AM, Andy Skinner [EMAIL PROTECTED] wrote: Thanks, Mike, for putting it in this perspective. Now that you mention it, we agree that this would break things that we use. This raises an issue found recently as we were building OSG on Solaris. On our Solaris machines, /usr/include/GL/gl.h has, near the bottom, a bit of code like: #ifndef SUN_OGL_NO_VERTEX_MACROS #ifndef LINUX #include GL/glmacros.h #endif /* LINUX */ #endif /* SUN_OGL_NO_VERTEX_MACROS */ glmacros.h contains defines for things like glVertex2f, calling a function from a function table and passing a current context in. This broke a bit of code in OSG that was defining a class with methods with the names of OpenGL functions. Those functions declarations had the Sun define applied, so wouldn't compile. Robert had to change the names of the methods. Maybe we should be compiling OSG with SUN_OGL_NO_VERTEX_MACROS. If I get time, I may try it both ways and see if I can compare. Thoughts from people who know more about this? thanks, andy -- Mike Weiblen -- Austin Texas USA -- http://mew.cx/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Testing of SVN version please
I didn't do the update, but I did the same thing you did, and it compiled for me. So I'm set. I was just about to send you my file. andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Friday, March 14, 2008 9:44 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Testing of SVN version please Hi Andy, On Fri, Mar 14, 2008 at 1:30 PM, Andy Skinner [EMAIL PROTECTED] wrote: I've just seen a compile error in osgviewerWX.cpp on OSX, complaining that cout is not a member of std. I'll get back to you about it as soon as I can. To try and fix this I've added an include iostream to osgviewerWX.cpp, could you do an svn update and let me know if its fixed. Thanks, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Testing of SVN version please
I didn't see the original post here, but I'm downloading SVN now. I'll try to build on solaris, windows, and linux. But it will take me a bit to get it set up to build under our environments, so hang on a bit. thanks andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean-Sébastien Guay Sent: Thursday, March 13, 2008 12:52 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Testing of SVN version please Hi Robert, I am now preparing for another developer release of the OpenSceneGraph and VirtualPlanetBuilder. I'd very much appreciate testing across platforms, please write if things compile and run fine or not. If there are any errors I'll try and get them merged in time for the dev releases that I plan to make in a few hours. Sorry I won't be able to test this time, I have to head out. I'll test tomorrow, but you'll have made the dev release by then if all goes well... I'll have to let others test on Windows. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Testing of SVN version please
I hit a problem compiling on solaris. I've attached a part of the output. I don't see what it wrong. It says line 61 of the header file SceneGraphBuilder has an error: line 61: Error, norparerr: ) expected instead of - and line 61 looks like: void glColor4f(GLfloat red, GLfloat green, GLfloat blue, GLfloat alpha); I don't yet know what that is about. andy [ 22%] Building CXX object src/osgUtil/CMakeFiles/osgUtil.dir/SceneGraphBuilder.o /hub/share/apps/BuildTools/compilers/sol64/SUNWspro_studio12_20071130/opt/SUNWspro/bin/CC -DosgUtil_EXPORTS -xO4 -xlibmil -xspace -xlibmieee -library=stlport4,Crun -mt -features=tmplife -norunpath -mr -errtags=yes -xcode=pic32 -m64 -xtarget=generic -xarch=sparcvis -xO4 -xlibmil -xspace -xlibmieee -library=stlport4,Crun -mt -features=tmplife -norunpath -mr -errtags=yes -xcode=pic32 -m64 -xtarget=generic -xarch=sparcvis -KPIC -I/mathworks/devel/sandbox/askinner/A3p0/3p/derived/sol64/openscenegraph/include -DOSGUTIL_LIBRARY -o src/osgUtil/CMakeFiles/osgUtil.dir/SceneGraphBuilder.o -c /mathworks/devel/sandbox/askinner/A3p0/3p/derived/sol64/openscenegraph/src/osgUtil/SceneGraphBuilder.cpp /mathworks/devel/sandbox/askinner/A3p0/3p/derived/sol64/openscenegraph/include/osg/GraphicsThread, line 55: Warning, hidevf: osg::SwapBuffersOperation::operator() hides the virtual function osg::GraphicsOperation::operator()(osg::Object*). /mathworks/devel/sandbox/askinner/A3p0/3p/derived/sol64/openscenegraph/include/osg/GraphicsThread, line 89: Warning, hidevf: osg::ReleaseContext_Block_MakeCurrentOperation::operator() hides the virtual function osg::GraphicsOperation::operator()(osg::Object*). /mathworks/devel/sandbox/askinner/A3p0/3p/derived/sol64/openscenegraph/include/osg/GraphicsThread, line 98: Warning, hidevf: osg::BlockAndFlushOperation::operator() hides the virtual function osg::GraphicsOperation::operator()(osg::Object*). /mathworks/devel/sandbox/askinner/A3p0/3p/derived/sol64/openscenegraph/include/osg/GraphicsThread, line 108: Warning, hidevf: osg::FlushDeletedGLObjectsOperation::operator() hides the virtual function osg::GraphicsOperation::operator()(osg::Object*). /mathworks/devel/sandbox/askinner/A3p0/3p/derived/sol64/openscenegraph/include/osg/GraphicsThread, line 119: Warning, hidevf: osg::RunOperations::operator() hides the virtual function osg::GraphicsOperation::operator()(osg::Object*). /mathworks/devel/sandbox/askinner/A3p0/3p/derived/sol64/openscenegraph/include/osgText/Text3D, line 164: Warning, hidevf: osgText::Text3D::supports hides the virtual function osg::Drawable::supports(const osg::PrimitiveIndexFunctor) const. 6 Warning(s) detected. /mathworks/devel/sandbox/askinner/A3p0/3p/derived/sol64/openscenegraph/include/osg/GraphicsThread, line 55: Warning, hidevf: osg::SwapBuffersOperation::operator() hides the virtual function osg::GraphicsOperation::operator()(osg::Object*). /mathworks/devel/sandbox/askinner/A3p0/3p/derived/sol64/openscenegraph/include/osg/GraphicsThread, line 89: Warning, hidevf: osg::ReleaseContext_Block_MakeCurrentOperation::operator() hides the virtual function osg::GraphicsOperation::operator()(osg::Object*). /mathworks/devel/sandbox/askinner/A3p0/3p/derived/sol64/openscenegraph/include/osg/GraphicsThread, line 98: Warning, hidevf: osg::BlockAndFlushOperation::operator() hides the virtual function osg::GraphicsOperation::operator()(osg::Object*). /mathworks/devel/sandbox/askinner/A3p0/3p/derived/sol64/openscenegraph/include/osg/GraphicsThread, line 108: Warning, hidevf: osg::FlushDeletedGLObjectsOperation::operator() hides the virtual function osg::GraphicsOperation::operator()(osg::Object*). /mathworks/devel/sandbox/askinner/A3p0/3p/derived/sol64/openscenegraph/include/osg/GraphicsThread, line 119: Warning, hidevf: osg::RunOperations::operator() hides the virtual function osg::GraphicsOperation::operator()(osg::Object*). /mathworks/devel/sandbox/askinner/A3p0/3p/derived/sol64/openscenegraph/include/osgUtil/SceneGraphBuilder, line 61: Error, norparerr: ) expected instead of -. /mathworks/devel/sandbox/askinner/A3p0/3p/derived/sol64/openscenegraph/src/osgUtil/SceneGraphBuilder.cpp, line 174: Error, nodirdecl: No direct declarator preceding (. /mathworks/devel/sandbox/askinner/A3p0/3p/derived/sol64/openscenegraph/src/osgUtil/SceneGraphBuilder.cpp, line 177: Error, nocommaerr: , expected instead of .. /mathworks/devel/sandbox/askinner/A3p0/3p/derived/sol64/openscenegraph/src/osgUtil/SceneGraphBuilder.cpp, line 178: Error, nodeclerr: A declaration was expected instead of }. /mathworks/devel/sandbox/askinner/A3p0/3p/derived/sol64/openscenegraph/src/osgUtil/SceneGraphBuilder.cpp, line 180: Error, nodirdecl: No direct declarator preceding (. /mathworks/devel/sandbox/askinner/A3p0/3p/derived/sol64/openscenegraph/src/osgUtil/SceneGraphBuilder.cpp, line 183: Error, nocommaerr: , expected instead of ..
Re: [osg-users] Testing of SVN version please
It seems that there is a SUN_OGL_NO_VERTEX_MACROS define that I should set. If I google that, I get a lot of source references, and a few people who had to use it. I'm trying it now. One of them said that Sun's GLU wouldn't work if you compile your code with this define. Here is one comment: SunOS: OpenGL apps must be compiled with SUN_OGL_NO_VERTEX_MACROS defined so that macros aren't used for OpenGL API functions. This also means that Sun's stock GLUT and GLU libraries won't work with Chromium. After you've produced new GLUT and GLU libraries you may have to edit SunOS.mk and modify your LD_LIBRARY_PATH to select the new libraries. Another: - I had to specify -DSUN_OGL_NO_VERTEX_MACROS on the compile line for source files that called OpenGL routines using the scope operator (e.g. ::glColor4fv( p );). Loosely speaking, SUN implements OpenGl calls indirectly through some sort of table of function pointers (via #define) for performance reasons. The scope operator :: says there is a global function to call which is not found and results in a compiler error. The SUN_OGL_NO_VERTEX_MACROS macro specifies that the actual OpenGl routines are to be accessed and fixes the problem. The alternative is to remove the scope operator from the OpenGl calls. So they had a problem when the :: was there, and we're having a problem because this isn't a call, but a declaration. I think your approach will resolve it without me having to wonder about side effects to using that define above. thanks andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Thursday, March 13, 2008 2:34 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Testing of SVN version please On Thu, Mar 13, 2008 at 6:15 PM, Andy Skinner [EMAIL PROTECTED] wrote: I built SceneGraphBuilder.i to get a look at the preprocessed code. This looks like: void ( * sunOglCurPrimTablePtr - oglColor4f ) ( sunOglCurrentContext , GLfloat red , GLfloat green , GLfloat blue , GLfloat alpha ) ; There is definitely something whacky there. I'll give renaming a try, and try to find out where this is coming from. I'll go ahead an rename the methods, just removing the gl prefix. I'll check in this change once I've got things built. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Testing of SVN version please
I'm not finished yet, but your change plus my include in GraphicsWindowX11 seem to work. (See my other email for that.) andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Thursday, March 13, 2008 2:55 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Testing of SVN version please Hi Andy, Thanks for the looking into this. Darn frustrating how some vendors try to be clever but in the end just make there code more fragile... I've gone ahead and remove all the gl and glu prefixes from the SceneGraphBuilder methods. I've also updated the wrappers to honour this. Could you do an svn update and let me know how you get on. It's too late in the day now for me to do a dev release so I'll leave it for now and let testing be done overnight (UK time) and if things look solid overnight I'll go do a dev release tomorrow morning. Cheers, Robert. On Thu, Mar 13, 2008 at 6:42 PM, Andy Skinner [EMAIL PROTECTED] wrote: It seems that there is a SUN_OGL_NO_VERTEX_MACROS define that I should set. If I google that, I get a lot of source references, and a few people who had to use it. I'm trying it now. One of them said that Sun's GLU wouldn't work if you compile your code with this define. Here is one comment: SunOS: OpenGL apps must be compiled with SUN_OGL_NO_VERTEX_MACROS defined so that macros aren't used for OpenGL API functions. This also means that Sun's stock GLUT and GLU libraries won't work with Chromium. After you've produced new GLUT and GLU libraries you may have to edit SunOS.mk and modify your LD_LIBRARY_PATH to select the new libraries. Another: - I had to specify -DSUN_OGL_NO_VERTEX_MACROS on the compile line for source files that called OpenGL routines using the scope operator (e.g. ::glColor4fv( p );). Loosely speaking, SUN implements OpenGl calls indirectly through some sort of table of function pointers (via #define) for performance reasons. The scope operator :: says there is a global function to call which is not found and results in a compiler error. The SUN_OGL_NO_VERTEX_MACROS macro specifies that the actual OpenGl routines are to be accessed and fixes the problem. The alternative is to remove the scope operator from the OpenGl calls. So they had a problem when the :: was there, and we're having a problem because this isn't a call, but a declaration. I think your approach will resolve it without me having to wonder about side effects to using that define above. thanks andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Thursday, March 13, 2008 2:34 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Testing of SVN version please On Thu, Mar 13, 2008 at 6:15 PM, Andy Skinner [EMAIL PROTECTED] wrote: I built SceneGraphBuilder.i to get a look at the preprocessed code. This looks like: void ( * sunOglCurPrimTablePtr - oglColor4f ) ( sunOglCurrentContext , GLfloat red , GLfloat green , GLfloat blue , GLfloat alpha ) ; There is definitely something whacky there. I'll give renaming a try, and try to find out where this is coming from. I'll go ahead an rename the methods, just removing the gl prefix. I'll check in this change once I've got things built. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] intersect() methods in LineSegment (probably others)
Thanks! Hopefully Robert can give it a look when he gets back. thanks, andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean-Sébastien Guay Sent: Tuesday, February 12, 2008 9:21 AM To: OpenSceneGraph Users Subject: Re: [osg-users] intersect() methods in LineSegment (probably others) Hi Andy, J-S, did you get to do any timing with my proposed use of doubles in the intersection code? I did some tests last night. Full results below. The executive summary is this: For 2,244,800 samples (individual ray tests), Floats: 113.121566 seconds (original) Doubles: 113.954178 seconds (your patch) Difference: ~0.730655 % Floats: 19844.138 samples / second Doubles: 19699.146 samples / second So with doubles, it is less than one percent slower, which I don't think is significant over that many samples... I did not have the time to do multiple tests though (because that 0.7% might even be due to some other activity on my machine) but I think we can safely say it's not a significant difference. You can quote me on that :-) BTW, for reference, using the kdtree took 13.366302 seconds to do the same thing :-) See below. Hope this helps, J-S Detailed results: === LineSegmentIntersector, float (original) === - Parsing command-line arguments. Using 5 bands (25 coefficients) and 400 samples per vertex. Deleting previously calculated data files to recalculate them. - Loading model file data/PRT_test_scene_9b.ive. - Optimizing model data/PRT_test_scene_9b.ive. - Loading/Computing SH coefficients for lighting [L] Checking for precomputed radiance transfer data file data/PRT_test_scene_9b/lighting_25_400.prt: Not found. Computing. 0.534819 seconds. (747.917 samples/sec) [DS] Checking for precomputed radiance transfer data file data/PRT_test_scene_9b/Wall2_geode_0_25_400_DS.prt: Not found. Computing. (1017 vertices) 15.1999 seconds. (26763.4 samples/sec) [DS] Checking for precomputed radiance transfer data file data/PRT_test_scene_9b/Wall1_geode_0_25_400_DS.prt: Not found. Computing. (930 vertices) 13.9724 seconds. (26624 samples/sec) [DS] Checking for precomputed radiance transfer data file data/PRT_test_scene_9b/Floor_geode_0_25_400_DS.prt: Not found. Computing. (1596 vertices) 21.7206 seconds. (29391.5 samples/sec) [DS] Checking for precomputed radiance transfer data file data/PRT_test_scene_9b/Sphere_geode_0_25_400_DS.prt: Not found. Computing. (1040 vertices) 40.901 seconds. (10170.9 samples/sec) [DS] Checking for precomputed radiance transfer data file data/PRT_test_scene_9b/Cube_geode_0_25_400_DS.prt: Not found. Computing. (1029 vertices) 21.3278 seconds. (19298.8 samples/sec) Total time for loading transfer functions: 113.121566 seconds. Total loading/computing time: 113.657229 seconds. Precalculation done, exiting. === LineSegmentIntersector, double (Andy Skinner's modification) === - Parsing command-line arguments. Using 5 bands (25 coefficients) and 400 samples per vertex. Deleting previously calculated data files to recalculate them. - Loading model file data/PRT_test_scene_9b.ive. - Optimizing model data/PRT_test_scene_9b.ive. - Loading/Computing SH coefficients for lighting [L] Checking for precomputed radiance transfer data file data/PRT_test_scene_9b/lighting_25_400.prt: Not found. Computing. 0.524556 seconds. (762.55 samples/sec) [DS] Checking for precomputed radiance transfer data file data/PRT_test_scene_9b/Wall2_geode_0_25_400_DS.prt: Not found. Computing. (1017 vertices) 15.6853 seconds. (25935.1 samples/sec) [DS] Checking for precomputed radiance transfer data file data/PRT_test_scene_9b/Wall1_geode_0_25_400_DS.prt: Not found. Computing. (930 vertices) 14.2079 seconds. (26182.6 samples/sec) [DS] Checking for precomputed radiance transfer data file data/PRT_test_scene_9b/Floor_geode_0_25_400_DS.prt: Not found. Computing. (1596 vertices) 21.8676 seconds. (29193.9 samples/sec) [DS] Checking for precomputed radiance transfer data file data/PRT_test_scene_9b/Sphere_geode_0_25_400_DS.prt: Not found. Computing. (1040 vertices) 40.8934 seconds. (10172.8 samples/sec) [DS] Checking for precomputed radiance transfer data file data/PRT_test_scene_9b/Cube_geode_0_25_400_DS.prt: Not found. Computing. (1029 vertices) 21.3 seconds. (19324 samples/sec) Total time for loading transfer functions: 113.954178 seconds. Total loading/computing time: 114.479672 seconds. Precalculation done, exiting. === Adrian Egli's kdtree
Re: [osg-users] intersect() methods in LineSegment (probably others)
J-S, did you get to do any timing with my proposed use of doubles in the intersection code? Thanks, andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] intersect() methods in LineSegment (probably others)
I got the LineSegment::intersect() method to work when I converted the vectors you get from finding the difference between the start and the sphere center, and the difference between the start and the end, to Vec3d. You want the dot product to be in doubles. In my version, I get the difference in terms of Vec3, and then convert them to Vec3d. The rest of the method is in doubles until setting r1 and r2. Another approach would be to change the internal representation of _e and _s to Vec3d, or maybe just keep _e - _s as a Vec3d so you don't have to subtract that one each time. So is anyone counting on this being floats for performance? Would anyone else welcome this calculation in doubles? I don't mind adding some code in our own source if other people don't want this in doubles, but I'd have to make my own IntersectVisitor as well as my own LineSegment, when all I really want to replace is the LineSegment. Having an almost-but-not-quite copy of a class and having to watch the original for updates doesn't sound like any fun. If I could get IntersectVisitor to use a class derived from LineSegment, with just the changes I want, that might not be bad. I think I'll submit a version of LineSegment, and you (Robert and the mailing list) can tell me what you think. andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Skinner Sent: Tuesday, February 05, 2008 8:57 AM To: OpenSceneGraph Users Subject: [osg-users] intersect() methods in LineSegment (probably others) I'm not sure what changed (in OSG or our code), but one of our unittests is failing on Windows as I try to upgrade our software to OSG 2.3.3. The picking I'm doing isn't hitting anything. It appears that the use of floats in the LineSegment::intersect(BoundingSphere) method may be hurting us. I've seen mentions on this in the list archives. Is the calculation done in this method done in float on purpose? If some of the intermediate value in this calculation were done in double, would it slow things down too much? We're squaring some large numbers and subtracting them from each other, and it isn't holding up for us. I'm going to experiment with doing some of this in double, but since it seems known that there are precision problems in this code, I wonder if it has remained in float for a reason. I could try to make an example for this, but because there seems to be an awareness of the issue, I'll raise it now. Thoughts? thanks andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] intersect() methods in LineSegment (probably others)
In your work, could you give me an idea of how often you intersect with a particular line segment object? I'm trying to decide if it is worth it to keep a Vec3d in the class (marking whether it is valid), or keeping double versions of _s and _e. thanks, andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean-Sébastien Guay Sent: Wednesday, February 06, 2008 9:52 AM To: OpenSceneGraph Users Subject: Re: [osg-users] intersect() methods in LineSegment (probably others) Hello Andy, So is anyone counting on this being floats for performance? Would anyone else welcome this calculation in doubles? If you submit a patch, I can test it out in my Masters project which uses LineSegmentIntersector pretty heavily (not-quite-realtime raytracing :-) ) so that will tell us if there is really a performance difference. Off hand I can't really say, so I'd prefer to do some benchmarking. I don't mind adding some code in our own source if other people don't want this in doubles, but I'd have to make my own IntersectVisitor as well as my own LineSegment, when all I really want to replace is the LineSegment. Having an almost-but-not-quite copy of a class and having to watch the original for updates doesn't sound like any fun. I totally understand... It'll be a matter of the performance vs correctness tradeoff I guess, so as I said I can provide some answer to the performance side of that question and see what Robert thinks when he comes back. So please, submit your changes and we'll see. Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] intersect() methods in LineSegment (probably others)
I've submitted a change to the submission list. Please take a look and tell me if and how much it affects timing. thanks andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean-Sébastien Guay Sent: Wednesday, February 06, 2008 11:11 AM To: OpenSceneGraph Users Subject: Re: [osg-users] intersect() methods in LineSegment (probably others) Hello Adrian, :-) only the first version of my kd.tree. latest i still extermly slow with about 700K-800K intersection test per second. there are latest kd-Tree ray check with more than ++ 6M rays per second. www.ompf.org http://www.ompf.org :-) Don't take it personally, I didn't mean it's slow at 100k intersections per second! Remember each application will be different, so you cannot compare 100k in my program to 700-800k in yours. My program probably does more processing between intersection tests than yours, since it traces in a sphere at each vertex and then stores that as vertex attributes in the Spherical Harmonics basis... Your program is just raytracing from the viewpoint and displaying that, which is simpler... And I recently integrated the last version of your kdtree in my application, and it works well... If you have a newer one, you can send it to me if you want... :-) J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] intersect() methods in LineSegment (probably others)
I'm not sure what changed (in OSG or our code), but one of our unittests is failing on Windows as I try to upgrade our software to OSG 2.3.3. The picking I'm doing isn't hitting anything. It appears that the use of floats in the LineSegment::intersect(BoundingSphere) method may be hurting us. I've seen mentions on this in the list archives. Is the calculation done in this method done in float on purpose? If some of the intermediate value in this calculation were done in double, would it slow things down too much? We're squaring some large numbers and subtracting them from each other, and it isn't holding up for us. I'm going to experiment with doing some of this in double, but since it seems known that there are precision problems in this code, I wonder if it has remained in float for a reason. I could try to make an example for this, but because there seems to be an awareness of the issue, I'll raise it now. Thoughts? thanks andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.3.2 dev release tagged.
So whenever OpenThreads is modified, it increments to the current OSG version? Just seeing what to expect. thanks andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Wednesday, January 23, 2008 4:11 AM To: OpenSceneGraph Users Subject: Re: [osg-users] OpenSceneGraph-2.3.2 dev release tagged. Hi Andy, On Jan 22, 2008 8:31 PM, Andy Skinner [EMAIL PROTECTED] wrote: I'm sure I've asked this before, and if there's an answer, sorry. I'll try to remember. :) Should the OpenThreads library version increment to keep track of the OSG one, even when the OpenThreads library hasn't changed? No it shouldn't need to increment if it hasn't been modified at all. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.3.2 dev release tagged.
This was all on our end. I still had a previous SVN version in the place I should have had our checked-in version, and it confused the integration. I'm all set now. I was pleased to not have to make any changes for Solaris. thanks, andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Tuesday, January 15, 2008 9:43 AM To: OpenSceneGraph Users Subject: Re: [osg-users] OpenSceneGraph-2.3.2 dev release tagged. On Jan 15, 2008 2:37 PM, Andy Skinner [EMAIL PROTECTED] wrote: I wonder whether something got merged incorrectly (we've store what we get from OSG in Perforce, then update it with changes when we update). Could you investigate this and let us know if you've sorted the problem out, so at least I know that there isn't a remaining issue on the OSG side. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.3.2 dev release tagged.
There error I got (on 32 bit linux) is: [ 6%] Building CXX object src/osg/CMakeFiles/osg.dir/GLObjects.o /mathworks/hub/Linux/glibc-2.3.6/i686/apps/gcc-4.1.1/bin/c++ -Dosg_EXPORTS -O3 -march=pentium4 -mfpmath=sse -pipe -pthread -fPIC -fPIC -I/mathworks/devel/sandbox/askinner/Amake/3p/derived/glnx86/openscenegra ph/include -DOSG_LIBRARY -o src/osg/CMakeFiles/osg.dir/GLObjects.o -c /mathworks/devel/sandbox/askinner/Amake/3p/derived/glnx86/openscenegraph /src/osg/GLObjects.cpp /mathworks/devel/sandbox/askinner/Amake/3p/derived/glnx86/openscenegraph /src/osg/GLObjects.cpp: In function 'void osg::flushDeletedGLObjects(unsigned int, double, double)': /mathworks/devel/sandbox/askinner/Amake/3p/derived/glnx86/openscenegraph /src/osg/GLObjects.cpp:36: error: 'flushDeletedQueryObjects' is not a member of 'osg::OcclusionQueryNode' /mathworks/devel/sandbox/askinner/Amake/3p/derived/glnx86/openscenegraph /src/osg/GLObjects.cpp: In function 'void osg::flushAllDeletedGLObjects(unsigned int)': /mathworks/devel/sandbox/askinner/Amake/3p/derived/glnx86/openscenegraph /src/osg/GLObjects.cpp:53: error: 'flushDeletedQueryObjects' is not a member of 'osg::OcclusionQueryNode' /mathworks/devel/sandbox/askinner/Amake/3p/derived/glnx86/openscenegraph /src/osg/GLObjects.cpp: In function 'void osg::discardAllDeletedGLObjects(unsigned int)': /mathworks/devel/sandbox/askinner/Amake/3p/derived/glnx86/openscenegraph /src/osg/GLObjects.cpp:68: error: 'discardDeletedQueryObjects' is not a member of 'osg::OcclusionQueryNode' gmake[4]: *** [src/osg/CMakeFiles/osg.dir/GLObjects.o] Error 1 andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Tuesday, January 15, 2008 4:08 AM To: OpenSceneGraph Users Subject: Re: [osg-users] OpenSceneGraph-2.3.2 dev release tagged. Hi Andy, On Jan 14, 2008 8:12 PM, Andy Skinner [EMAIL PROTECTED] wrote: I'm having trouble compiling. (Sorry if this has been discussed and I missed it.) It can't find flushDeletedQueryObjects() in OcclusionQueryNode. Is this fixed in SVN? No, I wasn't aware of any problem either. I'll just do another make clean and see if it comes up with anything. Could you provide the exact compile error you are getting and on what platform. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.3.2 dev release tagged.
I wonder whether something got merged incorrectly (we've store what we get from OSG in Perforce, then update it with changes when we update). thanks, andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Tuesday, January 15, 2008 9:02 AM To: OpenSceneGraph Users Subject: Re: [osg-users] OpenSceneGraph-2.3.2 dev release tagged. Hi Andy, I have doubled checked and the errors you get suggest methods are missing that are clearly defined and are checked into the 2.3.2 release. You can even browse these online: http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph -2.3.2/include/osg/OcclusionQueryNode This is for the 2.3.2, so it looks to me like you have an out of date version of OcclusionQueryNode for some reason. Robert. On Jan 15, 2008 1:42 PM, Andy Skinner [EMAIL PROTECTED] wrote: There error I got (on 32 bit linux) is: [ 6%] Building CXX object src/osg/CMakeFiles/osg.dir/GLObjects.o /mathworks/hub/Linux/glibc-2.3.6/i686/apps/gcc-4.1.1/bin/c++ -Dosg_EXPORTS -O3 -march=pentium4 -mfpmath=sse -pipe -pthread -fPIC -fPIC -I/mathworks/devel/sandbox/askinner/Amake/3p/derived/glnx86/openscenegra ph/include -DOSG_LIBRARY -o src/osg/CMakeFiles/osg.dir/GLObjects.o -c /mathworks/devel/sandbox/askinner/Amake/3p/derived/glnx86/openscenegraph /src/osg/GLObjects.cpp /mathworks/devel/sandbox/askinner/Amake/3p/derived/glnx86/openscenegraph /src/osg/GLObjects.cpp: In function 'void osg::flushDeletedGLObjects(unsigned int, double, double)': /mathworks/devel/sandbox/askinner/Amake/3p/derived/glnx86/openscenegraph /src/osg/GLObjects.cpp:36: error: 'flushDeletedQueryObjects' is not a member of 'osg::OcclusionQueryNode' /mathworks/devel/sandbox/askinner/Amake/3p/derived/glnx86/openscenegraph /src/osg/GLObjects.cpp: In function 'void osg::flushAllDeletedGLObjects(unsigned int)': /mathworks/devel/sandbox/askinner/Amake/3p/derived/glnx86/openscenegraph /src/osg/GLObjects.cpp:53: error: 'flushDeletedQueryObjects' is not a member of 'osg::OcclusionQueryNode' /mathworks/devel/sandbox/askinner/Amake/3p/derived/glnx86/openscenegraph /src/osg/GLObjects.cpp: In function 'void osg::discardAllDeletedGLObjects(unsigned int)': /mathworks/devel/sandbox/askinner/Amake/3p/derived/glnx86/openscenegraph /src/osg/GLObjects.cpp:68: error: 'discardDeletedQueryObjects' is not a member of 'osg::OcclusionQueryNode' gmake[4]: *** [src/osg/CMakeFiles/osg.dir/GLObjects.o] Error 1 andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Tuesday, January 15, 2008 4:08 AM To: OpenSceneGraph Users Subject: Re: [osg-users] OpenSceneGraph-2.3.2 dev release tagged. Hi Andy, On Jan 14, 2008 8:12 PM, Andy Skinner [EMAIL PROTECTED] wrote: I'm having trouble compiling. (Sorry if this has been discussed and I missed it.) It can't find flushDeletedQueryObjects() in OcclusionQueryNode. Is this fixed in SVN? No, I wasn't aware of any problem either. I'll just do another make clean and see if it comes up with anything. Could you provide the exact compile error you are getting and on what platform. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.3.2 dev release tagged.
I've been trying to get to checking this. We definitely messed it up, because it is in my 2.3.2 .zip file. Busy day--hopefully I'll get it straightened up soon. andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Tuesday, January 15, 2008 11:24 AM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] OpenSceneGraph-2.3.2 dev release tagged. Sorry I'm joining this thread a little late. Seems like your update process must be throwing a wrench into something; the 2.3.2 version of OcclusionQueryNode does, indeed, declare flushDeletedQueryObjects. This was in the SVN head before the 2.3.2 tag was created. Not sure why you apparently got an update to GLObjects.cpp but not to OcclusionQueryNode. They were part of the same check in / revision. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com 303 859 9466 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Skinner Sent: Tuesday, January 15, 2008 7:37 AM To: OpenSceneGraph Users Subject: Re: [osg-users] OpenSceneGraph-2.3.2 dev release tagged. I wonder whether something got merged incorrectly (we've store what we get from OSG in Perforce, then update it with changes when we update). thanks, andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Tuesday, January 15, 2008 9:02 AM To: OpenSceneGraph Users Subject: Re: [osg-users] OpenSceneGraph-2.3.2 dev release tagged. Hi Andy, I have doubled checked and the errors you get suggest methods are missing that are clearly defined and are checked into the 2.3.2 release. You can even browse these online: http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/Open SceneGraph -2.3.2/include/osg/OcclusionQueryNode This is for the 2.3.2, so it looks to me like you have an out of date version of OcclusionQueryNode for some reason. Robert. On Jan 15, 2008 1:42 PM, Andy Skinner [EMAIL PROTECTED] wrote: There error I got (on 32 bit linux) is: [ 6%] Building CXX object src/osg/CMakeFiles/osg.dir/GLObjects.o /mathworks/hub/Linux/glibc-2.3.6/i686/apps/gcc-4.1.1/bin/c++ -Dosg_EXPORTS -O3 -march=pentium4 -mfpmath=sse -pipe -pthread -fPIC -fPIC -I/mathworks/devel/sandbox/askinner/Amake/3p/derived/glnx86/op enscenegra ph/include -DOSG_LIBRARY -o src/osg/CMakeFiles/osg.dir/GLObjects.o -c /mathworks/devel/sandbox/askinner/Amake/3p/derived/glnx86/open scenegraph /src/osg/GLObjects.cpp /mathworks/devel/sandbox/askinner/Amake/3p/derived/glnx86/open scenegraph /src/osg/GLObjects.cpp: In function 'void osg::flushDeletedGLObjects(unsigned int, double, double)': /mathworks/devel/sandbox/askinner/Amake/3p/derived/glnx86/open scenegraph /src/osg/GLObjects.cpp:36: error: 'flushDeletedQueryObjects' is not a member of 'osg::OcclusionQueryNode' /mathworks/devel/sandbox/askinner/Amake/3p/derived/glnx86/open scenegraph /src/osg/GLObjects.cpp: In function 'void osg::flushAllDeletedGLObjects(unsigned int)': /mathworks/devel/sandbox/askinner/Amake/3p/derived/glnx86/open scenegraph /src/osg/GLObjects.cpp:53: error: 'flushDeletedQueryObjects' is not a member of 'osg::OcclusionQueryNode' /mathworks/devel/sandbox/askinner/Amake/3p/derived/glnx86/open scenegraph /src/osg/GLObjects.cpp: In function 'void osg::discardAllDeletedGLObjects(unsigned int)': /mathworks/devel/sandbox/askinner/Amake/3p/derived/glnx86/open scenegraph /src/osg/GLObjects.cpp:68: error: 'discardDeletedQueryObjects' is not a member of 'osg::OcclusionQueryNode' gmake[4]: *** [src/osg/CMakeFiles/osg.dir/GLObjects.o] Error 1 andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Tuesday, January 15, 2008 4:08 AM To: OpenSceneGraph Users Subject: Re: [osg-users] OpenSceneGraph-2.3.2 dev release tagged. Hi Andy, On Jan 14, 2008 8:12 PM, Andy Skinner [EMAIL PROTECTED] wrote: I'm having trouble compiling. (Sorry if this has been discussed and I missed it.) It can't find flushDeletedQueryObjects() in OcclusionQueryNode. Is this fixed in SVN? No, I wasn't aware of any problem either. I'll just do another make clean and see if it comes up with anything. Could you provide the exact compile error you are getting and on what platform. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http
Re: [osg-users] OpenSceneGraph-2.3.2 dev release tagged.
I'm having trouble compiling. (Sorry if this has been discussed and I missed it.) It can't find flushDeletedQueryObjects() in OcclusionQueryNode. Is this fixed in SVN? thanks andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Monday, January 14, 2008 6:34 AM To: OpenSceneGraph Users Subject: [osg-users] OpenSceneGraph-2.3.2 dev release tagged. Hi All, I've just tagged the OpenSceneGraph-2.3.3 dev release: As usual you can grab the latest from the DeveloperReleases page: http://www.openscenegraph.org/projects/osg/wiki/Downloads/DeveloperRelea ses * OpenSceneGraph-2.3.2, released on 14th January 2008. Changes include : new Geometry shader support, read/write support for osgTerrain NodeKit in .ive plugin, bug and typo fixes. source package : OpenSceneGraph-2.3.2.zip svn tag: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph -2.3.2 OpenSceneGraph Thanks all folks :-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] question about cleaning up an OpenGL context
We are using the OSG along with JOGL to provide and manage contexts. In general, this has worked well, and we have seen others reporting the same thing on this mailing list. (We're not yet using the embedded graphics window, however, but have our own SceneView, etc.) One thing that we had to be careful to do was manage context IDs correctly. We use multiple windows, and windows can be removed and return, so that their contexts can be removed and remade. We discovered that if we were removing a window and creating it again, we could use JOGL and some fancy footwork to tell the OSG to clean up a context (releaseAllGLObjects() and flushAllDeletedGLObjects()) and stop drawing in it until the context is initialized again. We seem to be doing alright with that, since it seems we're getting notified about the context going away (removeNotify() in Java). However, in some cases, as with the JOGL lightweight canvas, which uses a PBuffer, a context can be recreated when the object is resized. We don't seem to be getting any messages in time to clean up OSG's OpenGL objects while the context is current. Is there a way, or would it make sense, to allow us to clean up all of the OpenGL objects associated with a context, without that context being current? I don't know what happens to OpenGL objects when their context goes away, and I'm wondering whether, in this case, we can tell OSG to clean up its stuff but it doesn't need to tell OpenGL anything. thanks, andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] question about cleaning up an OpenGL context
Thanks, we'll study this. This is the kind of stuff you make changes in very carefully. :) andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Wednesday, January 09, 2008 10:27 AM To: OpenSceneGraph Users Subject: Re: [osg-users] question about cleaning up an OpenGL context Hi Andy, Sharing contexts should be able to get around some of the issues of resizing cause contexts to be recreated, although this depends very much on the window API your using. W.r.t cleaning all contexts, your can use node-relaseGLObjects() without passing in State* and it'll release all the GL obejcts for all contexts. Now this dumps the GL Object ID's in the respective deleted OpenGL object caches that the OSG maintains, these you then need to flush from the appropriate graphics context, or... if you are using the latest OSG SVN you can use the new discard functionality, that just throws away the cached OpenGL ID's without calling OpenGL at all, so its doesn't require the context to be current, or even still alive. The new functions for doing flush and discard can be found in include/osg/GLObjects: /** Flush all deleted OpenGL objects within the specified availableTime. * Note, must be called from a thread which has current the graphics context associated with contextID. */ extern OSG_EXPORT void flushDeletedGLObjects(unsigned int contextID, double currentTime, double availableTime); /** Flush all deleted OpenGL objects. * Note, must be called from a thread which has current the graphics context associated with contextID. */ extern OSG_EXPORT void flushAllDeletedGLObjects(unsigned int contextID); /** Discard all deleted OpenGL objects. * Note, unlike flushAllDeletedObjectObjects discard does not * do any OpenGL calls so can be called from any thread, but as a consequence it * also doesn't remove the associated OpenGL resource so discard should only be * called when the associated graphics context is being/has been closed. */ extern OSG_EXPORT void discardAllDeletedGLObjects(unsigned int contextID); I presume this is exactly what you're looking for :-) Robert. On Jan 9, 2008 2:58 PM, Andy Skinner [EMAIL PROTECTED] wrote: We are using the OSG along with JOGL to provide and manage contexts. In general, this has worked well, and we have seen others reporting the same thing on this mailing list. (We're not yet using the embedded graphics window, however, but have our own SceneView, etc.) One thing that we had to be careful to do was manage context IDs correctly. We use multiple windows, and windows can be removed and return, so that their contexts can be removed and remade. We discovered that if we were removing a window and creating it again, we could use JOGL and some fancy footwork to tell the OSG to clean up a context (releaseAllGLObjects() and flushAllDeletedGLObjects()) and stop drawing in it until the context is initialized again. We seem to be doing alright with that, since it seems we're getting notified about the context going away (removeNotify() in Java). However, in some cases, as with the JOGL lightweight canvas, which uses a PBuffer, a context can be recreated when the object is resized. We don't seem to be getting any messages in time to clean up OSG's OpenGL objects while the context is current. Is there a way, or would it make sense, to allow us to clean up all of the OpenGL objects associated with a context, without that context being current? I don't know what happens to OpenGL objects when their context goes away, and I'm wondering whether, in this case, we can tell OSG to clean up its stuff but it doesn't need to tell OpenGL anything. thanks, andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.3.0 dev release tagged.
Robert, the source package link doesn't work for me. andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Monday, December 17, 2007 4:33 PM To: OpenSceneGraph Users Subject: [osg-users] OpenSceneGraph-2.3.0 dev release tagged. Hi All, After a weeks delay I've finally got on top of submissions, and able to tag the 2.3.0 dev release. Details can be found at: http://www.openscenegraph.org/projects/osg/wiki/Downloads/DeveloperRelea ses My entry on this page is: * OpenSceneGraph-2.3.0, released on 17th December 2007. Changes include : Bug and typo fixes, new double and external data support in Vec*Array classes, new double and Dbase .dbx support in ShapeFile plugin, new .cfg Producer config file loader, 64 bit OSG Archive support under Windows, support for continuation records in OpenFlight plugin, improvements to COLLADA plugin, new osgText::Text3D class for 3D geometry text, enhancements to PolytopeIntersector and addition of live video support in Quicktime plugin. source package : OpenSceneGraph-2.3.0.zip svn tag: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph -2.3.0 OpenSceneGraph The OpenSceneGraph-2.3.0.zip link is currently broken though, so it looks like the script on the server for building release is down. Luigi?? Can you help us? :-) Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Solaris compilation issues in SVN
Here are some compilation fixes I ran into. andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Wednesday, December 12, 2007 5:00 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Solaris compilation issues in SVN Hi Andy, Yesterday I merged a submission to DatabasePager.cpp that included use of various stl alogorithms - such as sort and find and others, the submission added a using namespace std, but I don't like importing whole namespaces so I removed the code and then added std:: where appropriate, clearly I missed a few. I've just done a search for find and sort and added std:: in the appropriate places. I may have missed a few though, could you do a svn update and let me know how you get on. Robert. On Dec 11, 2007 7:34 PM, Andy Skinner [EMAIL PROTECTED] wrote: I'm looking for the same kinds of things we've been struggling with in the past--standard template library functions that aren't in the solaris compiler's headers. We've fixed them in the past by adding includes to stdlib.h or similar. I am looking at a couple in DatabasePager.cpp. I could try to fix them in a similar way, but I notice that there are occurrences of these functions with std:: in front of them. For example, one call to find() is std::find(...), and another is just find(...). The first compiles for me, the second doesn't. At my company, we would address this with the std:: prefix. But I thought we didn't want to do that in the OSG. Should I address these with std::, as other calls in this file do? Or remove the std:: from the other calls and find the right include to fix it? andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g fixes.tar.gz Description: fixes.tar.gz ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Solaris compilation issues in SVN
I'm looking for the same kinds of things we've been struggling with in the past--standard template library functions that aren't in the solaris compiler's headers. We've fixed them in the past by adding includes to stdlib.h or similar. I am looking at a couple in DatabasePager.cpp. I could try to fix them in a similar way, but I notice that there are occurrences of these functions with std:: in front of them. For example, one call to find() is std::find(...), and another is just find(...). The first compiles for me, the second doesn't. At my company, we would address this with the std:: prefix. But I thought we didn't want to do that in the OSG. Should I address these with std::, as other calls in this file do? Or remove the std:: from the other calls and find the right include to fix it? andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Solaris compilation issues in SVN
A friend pointed out that find and sort really are stl functions, and not the same thing as the stdlib functions I was looking into before. andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Skinner Sent: Tuesday, December 11, 2007 2:35 PM To: OpenSceneGraph Users Subject: [osg-users] Solaris compilation issues in SVN I'm looking for the same kinds of things we've been struggling with in the past--standard template library functions that aren't in the solaris compiler's headers. We've fixed them in the past by adding includes to stdlib.h or similar. I am looking at a couple in DatabasePager.cpp. I could try to fix them in a similar way, but I notice that there are occurrences of these functions with std:: in front of them. For example, one call to find() is std::find(...), and another is just find(...). The first compiles for me, the second doesn't. At my company, we would address this with the std:: prefix. But I thought we didn't want to do that in the OSG. Should I address these with std::, as other calls in this file do? Or remove the std:: from the other calls and find the right include to fix it? andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] StateSet::merge question
My co-worker Mario found this thread from July, and we have the same question that Paul did. http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/17046/fo cus=17087 Should StateSet::merge() support PROTECTED mode? It supports OVERRIDE on one stateset, but never checks the mode on the other. We don't mind submitting a patch for this, but want to check if we're missing something first. thanks, andy The MathWorks ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Last call for feedback before 2.2
I don't know why our setup is different, although we've learned how many of our platforms have differences over the last few months. :) I'd love to see the preprocessed code for Tessellator.cpp on the different systems that had different effects, and be able to compare them. If anyone who has been involved with this wouldn't mind contributing and knows how to make Tessellator.i on their system, I'd love to see them, along with details of how you're set up. You could mail them to me directly. But that's stricly if you're interested in finding the root, because we all seem to have something that works for now. Thanks, andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Thursday, October 04, 2007 9:17 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Last call for feedback before 2.2 Hi Andy, On 10/4/07, Andy Skinner [EMAIL PROTECTED] wrote: OK, my OSG CMake makefile build failed in Tessellator.cpp. But when I set the variable you added to OFF, it got past that file. It is still building, and I need to run this past all my platforms, but this seems OK. What I don't understand yet is why your setup is the only Mac one that has reported a problem with the orignal GLU setup. Have you installed a custom version of OpenGL? Are you using different build options? Either way the new CMake option allows you to tweak things on any platform to what works for you. The issue is broader than tesselating, because it is specifying types for callbacks, and the tesselator callback is just one. If we ever add others, we'll need the same issue. Potentially this could be an issue, but so far throughout the life of the OSG project (now 8 years old) the only callback issue like this has been the Mac tessellator callback issue. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.1.14 dev version released
The link to the .zip file isn't working for me. http://www.openscenegraph.org/downloads/developer_releases/OpenSceneGrap h-2.1.14.zip andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Wednesday, October 03, 2007 8:26 AM To: OpenSceneGraph Users Subject: [osg-users] OpenSceneGraph-2.1.14 dev version released Hi All, Thanks for the all the testing this weeks, does look like we're getting converged for 2.2 just fine. I have just tagged the 2.1.14 developer release, this is the last one planned before 2.2 so please test :-) http://www.openscenegraph.org/projects/osg/wiki/Downloads/DeveloperRelea ses * OpenSceneGraph-2.1.14, released on 3rd Octoberr 2007. Main changes are build/executation fixes for OSX/Mingw/Cygwin, full range of threading models now enabled in CompositeViewer and improvements to the ShadowMap implementation. This will the last developer relese before 2.2 (due to be made Thursday 4th October) so please test thoroughly. source package : OpenSceneGraph-2.1.14.zip svn tag: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph -2.1.14 OpenSceneGraph -- As ever please test, test test! Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
