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 con
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] Investigating using OSG as a graphics backend for our real-time physics simulation system
Wow, thanks, that's some great information indeed. The OSG community seems really great, and is a huge selling point. I guess I'm going to have to write a prototype of my engine using both OSG, and Magnum, http://mosra.cz/blog/magnum.php They both seem like great choices, but with different philosophies, going to have to try both to see which ones a better fit. Thanks again for all the great info! > On Jun 23, 2017, at 11:44 AM, Chris Hanson wrote: > > Man, there was some really great material written here. > >> On Fri, Jun 23, 2017 at 1:38 AM, Robert Osfield >> wrote: >> Hi Andy, >> >> I would have thought the OSG would work fine for your task, you have >> happily mix and match 3D and 2D subgraphs (2D is just 3D in a single >> plane.) Portability is excellent as most of the code is pure C++ and >> OpenGL. >> >> As for for Tom Forsythe's blog, I can only guess he's never used a >> professional grade scene graph that is well designed. >> >> Long term future of the OSG is tied to OpenGL as it's designed from >> the ground up as an OpenGL scene graph. If were to try and generalize >> it to handle multiple back-end API's we'd have to radically change >> large parts of the API and implementation, backwards compatibility >> would be lost and with it we'd bificate the community between the >> OSG/GL version and the OSG/MultipleAPIs. >> >> Apple have been moving away from cross platform standards towards >> their own proprietary standards. Metal probably doesn't have a great >> future, if Apple drop the ball on the iPhone and it looses market >> share it'll be histoy. I suspect Direct3D is also tied to Microsoft >> remaining relevant, they've lost the phone market and desktop isn't >> growing. Personally I think the API best placed for the future is >> Vulkan as it's cross platform and provides good threading and low >> level control support. >> >> Long term I see a Vulkan scene graph as being a successor to the OSG, >> and on the OSG community part I think the best route would be such a >> scene graph be developed to fit in with OSG in such a way that >> existing OSG users can migrate across without having to dump on API >> completely and start a fresh. I've discussed my thoughts on this >> topic extensively over the last two years, have done quite a bit >> design work, but alas haven't had the time get the next OSG stable >> release out so I have clear run at starting a new scene graph. >> >> Quite a bit of my work on the OSG in the last year has taken ideas >> that I came up with for the new scene graph so cross pollination has >> already started. My plan for the OSG is for it's API to be evolved >> whilst avoiding major API breaks, so it'll be a stable base for >> application for years to come. My expectation is the new dev work on >> the OSG should start to slow down with the majority of work being >> maintenance. The OSG is already 18 years old, users still pop up from >> time to time about porting from OSG versions a decade old, so my guess >> is that the OSG will be still be relevant to many users for quite a >> few years to come. >> >> Robert. >> >> >> Robert. >> >> On 22 June 2017 at 23:33, Andy Somogyi wrote: >> > Hi All, >> > >> > We're evaluating using OSG as a possible graphics backend for our >> > real-time physics simulation project, and I've got a few questions: >> > >> > * We suport Mac, Windows and Linux, how good is cross-platform support >> > with OSG? >> > >> > * It looks like it’s pretty easy is it to hook up Magnum to an existing >> > native window, just would like to confirm. Say on Windows, I create a new >> > Win32 window, or on Mac I create a Cocoa window, is it possible to hook up >> > OSG to that window. I know that I'll have to grab the window events >> > (mouse, resize, etc...) in my app and forward them to OSG, that's not a >> > big deal. We'll be using the native toolkit on each platform for the gui, >> > i.e. WPF on Windows, Cocoa on Mac and GTK on Linux, so it's important that >> > we can hook up our rendering code to native windows. >> > >> > * Much of our application will entail displaying highly dynamic deformable >> > elastic surfaces and particle systems with programmatically generated >> > textures, do you thing OSG is a good fit? Does OSG have mesh node types >> > where it’s easy from t
[osg-users] Investigating using OSG as a graphics backend for our real-time physics simulation system
Hi All, We're evaluating using OSG as a possible graphics backend for our real-time physics simulation project, and I've got a few questions: * We suport Mac, Windows and Linux, how good is cross-platform support with OSG? * It looks like it’s pretty easy is it to hook up Magnum to an existing native window, just would like to confirm. Say on Windows, I create a new Win32 window, or on Mac I create a Cocoa window, is it possible to hook up OSG to that window. I know that I'll have to grab the window events (mouse, resize, etc...) in my app and forward them to OSG, that's not a big deal. We'll be using the native toolkit on each platform for the gui, i.e. WPF on Windows, Cocoa on Mac and GTK on Linux, so it's important that we can hook up our rendering code to native windows. * Much of our application will entail displaying highly dynamic deformable elastic surfaces and particle systems with programmatically generated textures, do you thing OSG is a good fit? Does OSG have mesh node types where it’s easy from the CPU side to update vertex positions and add/remove vertices? * We also plan to do a bit of 2D drawing (objects in a tree structure), How easy would it be to also use OSG for 2D trees? * I think a scene graph approach would be a good fit for us, as I’ve worked a lot with open inventor in the past. Part of what we'll be doing will be constructive solid geometry, similar to OpenSCAD, http://www.openscad.org, and a scene graph we think is a good way to represent this kind of geometry. There are however some criticisms of scene graphs, namely Tom Forsythe’s blog: http://tomforsyth1000.github.io/blog.wiki.html#%5B%5BScene%20Graphs%20-%20just%20say%20no%5D%5D I would tend to disagree with Jon, as I conceptualize things in space as all relative to the original, and things relative to each other (I worked with robotic arm manipulation before, so I tend to think in terms of transforms). How would you guys respond do Jon’s issues? * It would appear that Apple, in their infinite wisdom (sarcasm) is slowly deprecating OpenGL in favor of metal. In the future, do you think OSG could have different backends (metal, directx)? Thanks, -- Andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Android build failure with Android NDK r13
Hi, I followed this page to build OpenSceneGraph 3.4 for Android. http://www.openscenegraph.org/index.php/documentation/ platform-specifics/android/178-building-openscenegraph-for-android-3-4 It builds successfully with NDK r10e. However, with the current NDK release, r13. I got these error in the cmake stage, on an Fedora 23 GNU/Linux x86-64 system: cmake `pwd`/../osg.git/ -DCMAKE_TOOLCHAIN_FILE=`pwd`/../osg.git/PlatformSpecifics/Android/android.toolchain.cmake -DOPENGL_PROFILE="GLES2" -DDYNAMIC_OPENTHREADS=OFF -DDYNAMIC_OPENSCENEGRAPH=OFF -DANDROID_NATIVE_API_LEVEL=15 -DCMAKE_INSTALL_PREFIX=/share/software/open_scene_graph/installed-android-armeabi-v7a -DBUILD_OSG_EXAMPLES=true CMake Error at PlatformSpecifics/Android/android.toolchain.cmake:663 (message): Could not find any working toolchain in the NDK. Probably your Android NDK is broken. Call Stack (most recent call first): /usr/share/cmake/Modules/CMakeDetermineSystem.cmake:98 (include) CMakeLists.txt:114 (PROJECT) CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage -- Configuring incomplete, errors occurred! NDK r13 uses clang as the default compiler, instead of gcc. Would that be related to the error? Thanks for any help on this. -- Andy Tai, a...@atai.org, Skype: licheng.tai, Line: andy_tai, WeChat: andytai1010 Year 2016 民國105年 自動的精神力是信仰與覺悟 自動的行為力是勞動與技能 ___ 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
Subject: Re: [osg-users] ShaderComposer::releaseGLObjects warning
Hi Andy,
On 26 April 2016 at 20:31, Andy Skinner
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
mailto:robert.osfi...@gmail.com>> 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
Re: [osg-users] Compute near far and multiple cameras
I finally got around to looking at this problem again, so I wanted to post some more details on my solution as guided by Fred and Farshid's conversation in the thread linked above. Farshid's cull callback attached to the pre-render camera is the correct solution, the key being that the traversal operation has to happen before the near/far values are read out. I think I missed that (obvious) fact the first time I tried to solve it this way. There are a few more gotchyas to consider: 1) The cull visitor does some extra clamping of the near plane after the camera traversal returns. This logic is important if you plan to have the camera inside your geometry's bounds, like if you're using a first person manipulator to walk around your model. In that case the computed near plane can be a large negative number since one of the bounding-box borders is behind the camera. The logic you need to add is extracted from CullVisitor::popProjectionMatrix(). It consists of a call to computeNearFarPlane() (which Farshid has in his example), plus a call to clampProjecitonMatrix(...) which clamps the near plane to a proper positive value. You can call getProjectionMatrix() on the CullVisitor to get the current projection matrix that you need to pass into the clamp function. Note that getProjectionMatrix() returns a ref, so you probably want to make a copy of the matrix since the clamp function modifies it and you don't want that to happen twice (once when you call it on the ref, and again when the CullVisitor calls popProjectionMatrix). After this call the projection matrix and near/far values will be identical to the projection matrix that will be used to render the pre-render camera. 2) Be sure to set the pre-render camera near/far mode to COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES (or _PRIMITIVES if you choose), but whatever camera you push the planes to should be set to DO_NOT_COMPUTE_NEAR_FAR. Otherwise it will overwrite your settings on its cull pass. With this, I was able to get my near/far clipping working correctly. Thanks, - Andy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=56609#56609 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [3rdparty] Removing a View from Scene
Hi,
I set up multiple views in a sence.I need to use keyboarding to remove one of
them.
Please,how to achieve it in Visual Studio 2008 .
Thank you!
Cheers,
Andy
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=53498#53498
/**
*Write by FlySky
*zz...@163.com http://www.OsgChina.org
**/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
//¶¯Ì¬É¾³ýÊÓͼ´°¿Ú
class DeletSlaveView:public osgGA::GUIEventHandler
{
public:
bool handle(const osgGA::GUIEventAdapter& ea,osgGA::GUIActionAdapter&aa
)
{
osg::ref_ptr view =
dynamic_cast(&aa);
osg::ref_ptr viewer =
dynamic_cast(view->getViewerBase());
switch(ea.getEventType())
{
case osgGA::GUIEventAdapter::KEYDOWN:
{
if (ea.getKey()=='q')
{
//viewer->stopThreading();
viewer->removeView(view);
//viewer->startThreading();
}
}
break;
default:
break;
}
return false;
}
};
int main()
{
//´´½¨CompositeViewer¶ÔÏó
osg::ref_ptr viewer = new
osgViewer::CompositeViewer() ;
//¶ÁÈ¡Å£µÄÄ£ÐÍ
osg::ref_ptr cow = osgDB::readNodeFile("cow.osg") ;
//¶ÁÈ¡·É»úÄ£ÐÍ
osg::ref_ptr cessna = osgDB::readNodeFile("cessna.osg");
//ÓÅ»¯³¡¾°Êý¾Ý
osgUtil::Optimizer optimizer ;
optimizer.optimize(cow.get());
optimizer.optimize(cessna.get());
//ÉèÖÃͼÐλ·¾³ÌØÐÔ
osg::ref_ptr traits = new
osg::GraphicsContext::Traits();
traits->x = 100;
traits->y = 100;
traits->width = 900;
traits->height = 700;
traits->windowDecoration = true;
traits->doubleBuffer = true;
traits->sharedContext = 0;
//´´½¨Í¼Ðλ·¾³ÌØÐÔ
osg::ref_ptr gc =
osg::GraphicsContext::createGraphicsContext(traits.get());
if (gc->valid())
{
osg::notify(osg::INFO)<<" GraphicsWindow has been created
successfully."<setClearColor(osg::Vec4f(0.2f,0.2f,0.6f,1.0f));
gc->setClearMask(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
}
else
{
osg::notify(osg::NOTICE)<<" GraphicsWindow has not been
created successfully."< view = new osgViewer::View;
viewer->addView(view.get());
//ÉèÖÃÊÓͼ³¡¾°Êý¾Ý
view->setSceneData(cow.get());
//ÉèÖÃÏà»úÊÓ¿Ú¼°Í¼Ðλ·¾³
view->getCamera()->setViewport(new osg::Viewport(0,0,
traits->width/2, traits->height/2));
view->getCamera()->setGraphicsContext(gc.get());
//ÉèÖòÙ×÷Æ÷
view->setCameraManipulator(new osgGA::TrackballManipulator);
//Ìí¼Óʼþ´¦Àí
view->addEventHandler( new osgViewer::StatsHandler );
view->addEventHandler( new osgViewer::WindowSizeHandler );
view->addEventHandler( new osgViewer::ThreadingHandler );
view->addEventHandler( new osgViewer::RecordCameraPathHandler );
}
//ÊÓͼ¶þ
{
osg::ref_ptr view = new osgViewer::View;
viewer->addView(view.get());
view->setSceneData(cessna.get());
view->getCamera()->setViewport(new
osg::Viewport(traits->width/2,0, traits->width/2, traits->height/2));
view->getCamera()->setGraphicsContext(gc.get());
view->setCameraManipulator(new osgGA::TrackballManipulator);
}
//ÊÓͼÈý
{
osg::ref_ptr view = new osgViewer::View;
viewer->addView(view.get());
view->setSceneData(cessna.get());
//¸ù¾Ý·Ö±æÂÊÀ´È·¶¨ºÏÊʵÄͶӰÀ´±£Ö¤ÏÔʾµÄͼÐβ»±äÐÎ
double fovy, aspectRatio, zNear, zFar;
view->getCamera()->getProjectionMatrixAsPerspective(fovy,
aspectRatio, zNear, zFar);
double newAspectRatio = double(traits->width) /
double(traits->height/2);
double aspectRatioChange = newAspectRatio / aspectRatio;
if (aspectRatioChange != 1.0)
{
view->getCamera()->getProjectionMatrix() *=
[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] Compute near far and multiple cameras
Hey Sebastian, I've been looking at this off-and-on for a while now, though I have no clean solution. From my investigation it looks like the osg::CullVisitor tweaks the _computed_znear and _computed_zfar values to their needed settings during the handlle_cull_callbacks_and_traversal() call in the apply(osg::Camera&) method. Once the traversal call is complete, the znear and zfar values are correct for all the geometry under that camera. The problem is that between that point and the code a few lines down where the z-values are reset for the next camera there is no mechanism to install a callback to retrieve the computed values. The two solutions I was going to try were: 1) Attach a custom node to the scenegraph in a way that assures it is the last node traversed, is always visited, yet doesn't influence the scene bounds, and then cache off the znear and zfar values from the CullVisitor using a cull callback on that node (seems tricky to manage) Or: 2) Subclass the osg::CullVisitor (which we've already done anyway in our project), copy/paste the virtual apply(osg::Camera&) method body, and insert the code that I needed to cache / broadcast the z-values after the traversal. In either case the callback or broadcast mechanism could update the projections for any other cameras down the pipeline before they're hit by the CullVisitor. What I really want is the ability to give one camera references to other cameras as sort of "projection slaves" and have the osg::CullVisitor set the slave projections after the traversal. I haven't dug through the osg code enough to see if that paradigm is valid or if there's a more obvious solution I'm overlooking. Note that this is all in theory. I haven't been tasked to fix this issue yet in our code, we've just been using hard-coded fixed near/far values in the interim. - Andy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=50742#50742 ___ 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
#include
#include
#include
#include
int main(int argc, char *){
// GL_LINES
osg::ref_ptr 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_ptr 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_ptr 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_ptr 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_ptr geom(new osg::Geometry());
osg::ref_ptr stateSet(geom->getOrCreateStateSet());
osg::ref_ptr pColor = new osg::Vec4Array;
pColor->push_back( osg::Vec4( 0.0f, 1.0f, 0.0f, 1.0f) );
osg::ref_ptr p(new osg::Point());
osg::ref_ptr 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_ptrroot = new osg::Geode;
root->addDrawable ( X.get() );
root->addDrawable( tri.get() );
root->addDrawable( geom.get() );
// This is needed
osg::ref_ptrclipper = 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] Licensing of OSG's built-in application executables
Hi all, Does the OSG license allow for distributing the osgviewer.exe and osgconv.exe (or other) executables that are included with the SDK? We want to include those apps in our release so that we can debug cached .ive and .osg files on our customer's machines. I'm just not sure if we would need to write our own simple viewer app so it's a proper derived binary, or if it's okay to just distribute the pre-built ones. Thanks, - Andy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=36848#36848 ___ 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
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 > 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] 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
[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] Graphical issues with display lists on ATI 5870 cards
Hi Wojtek, Thanks for the input, good to know we aren't the only ones seeing issues. We rolled back the drivers to 10.4 and all the issues magically disappeared. I'm disappointed that ATI's QA process doesn't test for such basic feature support with their latest driver releases. We'll have to keep a close eye on this now. Thanks, - Andy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=29615#29615 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Graphical issues with display lists on ATI 5870 cards
Hi everyone, My company has been developing products using OSG for a few years now, and recently we've noticed some rendering issues on two machines that are both running ATI 5870 cards using the latest ATI drivers (Catalyst 10.6). We wanted to know if anyone running similar hardware has seen these issues. We are using the 2.8.2 release of OSG. We notice two major graphical problems: * Incorrect lighting on primitives - flat geometry with equal vertex normals at all vertices appears to have incorrect lighting over the surface (using the default osgviewer lighting) * Corrupted textures - either a single pixel color over the entire surface or it looks like the UV coordinates were run through a blender We have tested rendering using the OSGViewer with a simple .osg file containing two triangles (forming a quad) with identical per-vertex normals and simple per-vertex UVs. What we have found is that we either have to disable display lists on the geometry in order to have the quad render correctly, or else we seem to be able to get correct results by adding additional (bogus) values to the per-vertex normal and UV lists to pad them. We believe this means that somewhere between OSG and the GPU the per-vertex data in the display list is getting corrupted and normals/UVs are getting lost. We have not experienced this issue in any other 3D apps on this hardware, including ones that use display lists. We also do not have the rendering issues with our app on other hardware (tested using several nVidia cards and and older ATI card). We think this may be an ATI driver bug, but we're not sure at this point and would like to hear if anyone else has run into these issues. Thanks. - Andy Peruggi Applied Research Associates, Inc[/list] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=29501#29501 ___ 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 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 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 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 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
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
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] [build] Build problem
Hi, ... Thanks I decided to add a virtual box with a 32 bit Ubuntu OS and install it there Thank you! Cheers, Andy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22407#22407 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [build] Build problem
Hi, I have been trying to build OpenScenGraph on RedHat Linux 5 64 bit and get the error missiing glu.h and glut.h files. They are suppose to reside in the /usr/local/include/GL directory. I have installed all the packages with RedHat and those files do not exist. I had OSG on a 32 bit version with RedHat 4 and it worked fine Has anyone seen this problem and where and how do I go about resolving this to get it installed? Thank you! Cheers, Andy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22059#22059 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Setting my ZNear and ZFar clipping planes?
Jason Daly wrote: > Andy Lundell wrote: > Viewer is-a ViewerBase and an osgViewer::View > osgViewer::View is-a osg::View > osg::View has-a Camera > Camera is-a CullSettings > [...] > It's a long (and fairly winding) road to travel, but it makes sense once > you get there :-) Thank you. I've got it now. > A ComputeStereoMatricesCallback in osgUtil::SceneView is probably what > you're looking for. You can get to the SceneView object through > osgViewer::Renderer (just a different inheritance road to travel). I thought that osg::Util::SceneView was being deprecated? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=16762#16762 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Setting my ZNear and ZFar clipping planes?
Hi, I'm trying to set up my system so that I can manually specify the clipping planes. In past projects I would use the SceneView object and the SetComputeNearFarMode method. This project I'm not using a SceneView (Just a "viewer") and I have no idea how to get at this functionality. (I'm also looking for a way to override the code that creates the left-eye,right-eye matrices.) Thank you! Andy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=16746#16746 ___ 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
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
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
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 mailto: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.8>http://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/OpenSceneGraph-2.8OpenSceneGraph-2.8<http://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
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 mailto: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
[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] 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
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
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
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)
ScopedLock 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
[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] reconstructing a decomposed matrix
Thanks. My matrix was scaled, but it was coming together as scale * rotation * translation. But I've made some changes, and I'm not getting the original anymore, and I'm wondering whether I need the orientation again. andy From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David _ Sent: Friday, October 10, 2008 4:31 AM To: OpenSceneGraph Users Subject: Re: [osg-users] reconstructing a decomposed matrix hi Andy finally i did what i wanted to do in a different way and ignored the decompose method. as far as i know you can ignore the scale orientation quat if the original matrix is not scaled From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Date: Thu, 9 Oct 2008 14:55:34 -0400 Subject: 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 La cartera, las gafas. ¿te falta algo? Ahora llévate Messenger en tu móvil<http://www.vivelive.com/abecedario> ___ 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] 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
[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 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
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 sequence timing
Hi Max,
I don't know if this is related but take a look at the attached email.
There appears to be quite a few issues with the osg::Sequence class and
you are probably encountering one of them.
Please try my suggested fix as it seems to work for me.
Regards,
Andy
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Max
Bandazian
Sent: 07 August 2008 18:26
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] osg sequence timing
Hi,
I am experiencing some buggy behavior relating to loaded openflight
files containing sequences, and I would appreciate any suggestions. When
such a file is loaded after the viewer has been running for a bit, the
animation runs at the wrong speed. Here's some sample code that
illustrates the problem:
osg::ref_ptr rootNode = new osg::Group;
osg::ref_ptr viewer = new osgViewer::Viewer;
viewer->setUpViewOnSingleScreen(0);
viewer->setSceneData(rootNode.get());
viewer->setCameraManipulator(new osgGA::TrackballManipulator());
viewer->realize();
while(!viewer->done() && viewer->getFrameStamp()->getFrameNumber()
< 500)
{
viewer->frame();
}
osg::ref_ptr modelNode =
osgDB::readNodeFile("some_animation.flt");
rootNode->addChild(modelNode.get());
while(!viewer->done())
{
viewer->frame();
}
When the animation gets loaded in the above code, it runs much faster
than it ought to for around 5 seconds, and then runs at the normal rate.
It appears to be "catching up" with the frame time. Sending a visitor
down every loaded flt file and setting sync to true on all sequences
seems to fix the problem, but it seems like this should not be
necessary.
Thanks,
Max Bandazian
--- Begin Message ---
Hi All,
I have found a possible bug in osg::Sequence. Can anyone confirm this
and/or let me know if it is fixed in a newer release than 2.4?
To reproduce the bug:
1. Create a template osg::Sequence node (and underlying geometry)
but do not attach the node to the current active scenegraph.
2. At some point during the rendering loop (perhaps on a keystroke)
clone the sequence node (I use the call:
dynamic_cast(templateNode -> clone( osg::CopyOp(
(osg::CopyOp::CopyFlags)osg::CopyOp::DEEP_COPY_NODES ) ) )
3. Set the cloned sequence node duration to a value that makes the
animation run slower (i.e. 2.0).
4. Start the cloned sequence (using setMode()).
5. Repeat steps 2 - 4 and observe that the cloned sequences do not
run slow but run as fast, appearing to ignore the duration that has been
set on them.
Looking at the 'good documentation' (2.4 source code), I see that _start
is being set to _now (osg::Sequence::setMode(), line 192). Should this
not _start not be set to -1.0?
PS: It is also interesting to note that when loading OpenFlight file
with the frameTime set to 0.0, setting duration will have no effect.
Perhaps the OpenFlight loader should provide a very small default
frameTime value if the incoming value from the OpenFlight file is 0.0.
PS2: It also looks like the _nrepRemain value is not being reset when
setMode( START ) is called. To reset the value you must call setDuration
again.
Regards,
Andy
Business Development Manager
Embedded Simulation Group
GE Fanuc Intelligent Platforms
Applied Image Processing (formally Octec)
The Western Centre, Western Rd, Bracknell
Berkshire, England, RG12 1RW
Tel: +44 (0)1344 464908
Fax: +44 (0)1344 465201
Web: http://www.octec.com
GE Fanuc Intelligent Platforms (Bracknell) Ltd, registered in England
and Wales (2393111) at 100 Barbirolli Square, Manchester, M2 3AB, VAT GB
530 094 183
This email is private and confidential and for the addressee only. If
misdirected, please notify us by telephone and confirm that it has been
deleted from your system and any hard copies destroyed. You are strictly
prohibited from using, printing, distributing or disseminating it or any
information contained in it save to the intended recipient.
--- End Message ---
___
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
[osg-users] Job position still vacant!
Hi All, Please excuse the wide distribution but we are still looking for a graphics programmer. If anyone is interested in a full time position and has the basic requirements listed below, please let me know. Excellent maths skills Real time graphics skills C++ programming experience The requirements are listed in order of importance. 'A' level maths (equivalent or better) is a must have. More details can be found on the OpenSceneGraph Job offers web page: http://www.openscenegraph.org/projects/osg/wiki/Community/JobOffers Regards, Andy Business Development Manager Embedded Simulation Group GE Fanuc Intelligent Platforms Applied Image Processing (formally Octec) The Western Centre, Western Rd, Bracknell Berkshire, England, RG12 1RW Tel: +44 (0)1344 464908 Fax: +44 (0)1344 465201 Web: http://www.octec.com GE Fanuc Intelligent Platforms (Bracknell) Ltd, registered in England and Wales (2393111) at 100 Barbirolli Square, Manchester, M2 3AB, VAT GB 530 094 183 This email is private and confidential and for the addressee only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any hard copies destroyed. You are strictly prohibited from using, printing, distributing or disseminating it or any information contained in it save to the intended recipient. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Possible bug in osg::Sequence
Hi All, I have found a possible bug in osg::Sequence. Can anyone confirm this and/or let me know if it is fixed in a newer release than 2.4? To reproduce the bug: 1. Create a template osg::Sequence node (and underlying geometry) but do not attach the node to the current active scenegraph. 2. At some point during the rendering loop (perhaps on a keystroke) clone the sequence node (I use the call: dynamic_cast(templateNode -> clone( osg::CopyOp( (osg::CopyOp::CopyFlags)osg::CopyOp::DEEP_COPY_NODES ) ) ) 3. Set the cloned sequence node duration to a value that makes the animation run slower (i.e. 2.0). 4. Start the cloned sequence (using setMode()). 5. Repeat steps 2 - 4 and observe that the cloned sequences do not run slow but run as fast, appearing to ignore the duration that has been set on them. Looking at the 'good documentation' (2.4 source code), I see that _start is being set to _now (osg::Sequence::setMode(), line 192). Should this not _start not be set to -1.0? PS: It is also interesting to note that when loading OpenFlight file with the frameTime set to 0.0, setting duration will have no effect. Perhaps the OpenFlight loader should provide a very small default frameTime value if the incoming value from the OpenFlight file is 0.0. PS2: It also looks like the _nrepRemain value is not being reset when setMode( START ) is called. To reset the value you must call setDuration again. Regards, Andy Business Development Manager Embedded Simulation Group GE Fanuc Intelligent Platforms Applied Image Processing (formally Octec) The Western Centre, Western Rd, Bracknell Berkshire, England, RG12 1RW Tel: +44 (0)1344 464908 Fax: +44 (0)1344 465201 Web: http://www.octec.com GE Fanuc Intelligent Platforms (Bracknell) Ltd, registered in England and Wales (2393111) at 100 Barbirolli Square, Manchester, M2 3AB, VAT GB 530 094 183 This email is private and confidential and for the addressee only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any hard copies destroyed. You are strictly prohibited from using, printing, distributing or disseminating it or any information contained in it save to the intended recipient. ___ 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
When I added -install_name 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/". >> >> >> >> 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
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/". > > > > 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] 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_near<0.0) osg::notify(osg::WARN)<<"2) sett near with > d_near="< > 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] 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_near<0.0) osg::notify(osg::WARN)<<"2) sett near with d_near="<___ 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] 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] 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- number>. Now they seem to be osgPlugins-. To my knowledge, on Windows and Linux, it has always been osgPlugins- (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
[osg-users] osgPlugins directory name change?
Hi. Our windows plugin directory used to be named osgplugins-. Now they seem to be osgPlugins-. 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- and not osgplugins-? 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] 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
The latest SVN reports version 2.3.11, and builds on our solaris, mac, win32, and linux 64 systems. andy ___ 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
I recently tested 2.3.9 in our software, and although I haven't been able to give it a thorough testing, it does work. I'm currently building SVN (downloaded this morning after your request) on windows, 64 bit linux, solaris, and mac. (We use cmake on everything.) I'll let you know when it is done building, but I won't be able to hook it up to our software at this time. Since I did that very recently, I think it'll be OK. andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Thursday, April 24, 2008 6:51 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Please test SVN of OpenSceneGraph Hi All, I have just reverted yesterdays changes that I made to the various CMakeLists.txt files, and also merged a fix the Windows 3rd party checking sent in my Mattias, these changes are all now in SVN. So... Could you please do another svn update and build to make sure that things are still working fine. Under OSX there may be problems left unresolved with the CMake build but these I'm afraid we'll need to live with for 2.4, so the hand maintained XCode projects will remain the official build route for OSX. Under Windows Visual Studio build could you please check to see if header files are now coming in correctly. Once I have positive reports of builds under Windows, OSX and the unices I'll tag 2.3.11, then tag 2.4 tomorrow morning. 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] 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 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 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
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
[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
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 #include 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] Testing of OSG and VPB SVN in prep for nex devreleases and 2.4 stable release
Oh, and I haven't had time to explore the Solaris OpenGL macros we discussed. I've got 2.3.6 compiled with and without them, including examples, but haven't been able to explore them yet. 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
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] 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 > #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
[osg-users] OpenGL API RE: Mac OpenGL integration / CGLMacro.h
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 #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 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Weiblen Sent: Friday, March 21, 2008 1:21 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Mac OpenGL integration / CGLMacro.h Hi Raphael, I strongly agree w/ Robert on declining to incorporate that Apple extension into OSG. The problem with this "feature" is, while it seems to "enhance" the OpenGL API, it _totally_breaks_ the OpenGL ABI. There are many OpenGL shim libraries (such as gDEBugger, glIntercept, BuGLe and Chromium, to name just a few) that depend on mimicking the existing OpenGL dynamic library ABI. That entire class of tools is rendered unusable by the magic insertion of an additional parameter. For that reason, I believe this Apple extension should be actively *avoided* by any GL developers having any thoughts of portability. Except for vendor lock-in, IMHO Apple would be insane to "require" it of applications in the future. And I agree w/ Richard that this seems to be a "feature" of little practical merit. In quality OpenGL applications, MakeCurrent() just isn't a bottleneck in the pipeline that needs fixing. Not to speak for Robert, I suggest simple test for considering any OpenGL extension for OSG is: Would the ARB officially sanction the extension? I believe the chances in this case are 0. cheers -- mew > -Original Message- > From: [EMAIL PROTECTED] [mailto:osg-users- > [EMAIL PROTECTED] On Behalf Of > [EMAIL PROTECTED] > Sent: Thursday, March 20, 2008 10:41 AM > To: OpenSceneGraph Users > Subject: Re: [osg-users] Mac OpenGL integration / CGLMacro.h > > While Robert makes a good and valid point about corrupting the API (and > reality distortion fields in general), I don't think the original > poster > adequately explained this "feature" of OpenGL on Apple platforms. > > All it amounts to is a #ifdef __APPLE__ and an extra include file in > all the > OSG headers (just like including gl.h) plus a single function call > tucked > away in the OpenGL initialization code. It doesn't change the OpenGL > API as > far as the source code or programmer is concerned. The original poster > sort > of made it sound like each OpenGL call now has an extra parameter > passed > in... which it does, but this is "hidden" by the macro header. No > changes to > OpenGL code required (unless you consider an extra header file an undue > burden and pollution of the API ;-). It does speed up each OpenGL call > on > the CPU side, and can help (God forbid) immediate mode code > considerably. > > It would be fairly simple to add to OSG, albiet tedious, and Robert > (who > obviously is not a Mac user ;-) would have to test it, or have someone > close > to him test it (hundreds of files would be affected). > > Even though I am fully immersed in the Apple reality distortion field, > I > would have to express doubt however that it is worth the change. In the > age > of batched geometry submission (as opposed to immediate mode), and the > increasing reliance on shaders rather than the OpenGL state machine the > value of this feature over time get's increasingly smaller. I have made > this > retro-fit many time to my own projects without any problems... what I > have > failed to see however is any significant performance benefit to well > written > OpenGL code in the first place. > > Richard > > > > Robert Osfield writes: > > > On Thu, Mar 20, 2008 at 1:35 PM, Raphael Sebbe > <[EMAIL PROTECTED]> wrote: > >> thanks for answering. I understand your point regarding cross > platform > >> complexity. However, I am pretty convinced that passing the context > to > >> drawing functions makes sense these days, especially considering the > many > >&g
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 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'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. andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Friday, March 14, 2008 8:34 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Testing of SVN version please Hi Tony et al, On Fri, Mar 14, 2008 at 11:36 AM, Robert Osfield <[EMAIL PROTECTED]> wrote: > While I wait for feedback on the OSX I'll ponder on this issue so more > to see if I can come up with quick solution, but it may well be > something that requires more extensive changes beyond > StateSetManipulator and hence more time so would have to wait till > after 2.3.5. I've implemented a solution to the threading issue in StateSetManipulator. The solution is to clone the StateSet before modifying it, and reassigned this cloned StateSet to the parents of the original StateSet. This process effectively disconnects the original StateSet from the scene graph but otherwise keeps all its variable in tack - so the that the draw traversal that will be running in parallel with the updates (when multi-threaded) will not be affected as it's got its own ref_ptr<> to the StateSet. My testing at this end suggest that the fixes is solid. If things work out this is possible solution that I could add directly to StateSet, providing a convenience function for doing this cloning and reassignment. Could you do an svn update and let me know if the fix works at you end as well. 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'm compiling on OSX right now, too, if you want to hold off for a bit. andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Friday, March 14, 2008 7:12 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Testing of SVN version please Hi Ulrich, On Fri, Mar 14, 2008 at 11:06 AM, Robert Osfield <[EMAIL PROTECTED]> wrote: > I've seen reports of this type of problem before - definition of > static values in headers, can't remember the exact times but its > happened a couple of time in osg history. Fixes would be to move the > definition into the .cpp, to change to using #define or to use an > enum. I'll have a bash with converting it to an enum. Changing to enum certainly keeps things compiling under Linux. Could you do an svn update and let me now how the compile is? Once I've got confirmation that this works I'll go ahead and make 2.3.5. 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] Testing of SVN version please
I've also had a problem with an include needed. include/osgViewer/api/X11/GraphicsWindowX11 has a call to memset() in it. It needs #include in it before that. I put it up near the other includes higher in the file. This is from defining that Sun define and continuing. I've not yet tried your fix. andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Thursday, March 13, 2008 12:31 PM To: OpenSceneGraph Users Subject: [osg-users] Testing of SVN version please Hi All, 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. 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
