Re: [osg-users] VPB build error
Hi Martin, On 28 May 2013 00:44, Martin Naylor martinnay...@virginmedia.com wrote: I found the post and submitted a fix. It just need a minor tweak to include quotation marks to fix the semicolon that appeared in the linker options. Could you the modified file to osg-submissions. Thanks, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWindows Example Crashing on Linux
Hi Micheal, On 27 May 2013 17:39, michael kapelko korn...@gmail.com wrote: I've stripped down my OSG app to the attached archive. Upon exit there's some threading error, not real crash. But when I make my mCamera reference-count-controlled by osg::ref_ptr my app crashes. So may be I'm having my threading exit hanging due to not using osg::ref_ptr. I've just looked at your example and it really is convoluted and wrong in a number of ways, we aren't talking OSG bugs, we are talking bugs in your code. 1) You have an event handler that has a Viewer, and you attach this event handler to the Viewer, which takes a reference, via ref_ptr, to that event handler creating a circular reference. 2) You take a C pointer to the a Camera that you assign to the viewer, which takes a referecence, via ref_ptr, so the Viewer takes ownership and will destruct it it automatically once the Viewer gets destructed, but... you manually call unref() and the event handler to force destruction of the viewer's Camera. This will either cause a dangling pointer in the Viewer or a dangling pointer in the event handler, both of which will attempt to unref() it. The code is crazy. We have lots of OSG example that show as sensible way to use the OSG, none of them have an event handler owning the viewer. Also you'll almost next see examples of code explicitly calling unref(), it's only in very rare cases where you might want to not use ref_ptr and directly call ref() and unref(), and where you do you have to be very careful about management of the pointers involved. I almost never write code that explicitly calls ref() and unref(), instead ref_ptr is my tool, it's robust and easy to use. I'm guessing you've resorted to using the unref() because you created a circular reference without realizing it and tried to hack your way out of this design/implementation error. In you own I strongly recommend that you make the viewer the topmost object in the chain, *always* leave the event handler as a child of the viewer, and *never* use ref()/unref() - use ref_ptr instead. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWindows Example Crashing on Linux
Yeah, I've noticed it's wrong only after I stripped it down. I was using raw pointers, because I tried to hide OSG behind my application API (so that OSG headers are not required at build time). I didn't know of d-pointer approach at that time, but now I'm rewriting it with the approach. Thanks for the feedback. 2013/5/28 Robert Osfield robert.osfi...@gmail.com Hi Micheal, On 27 May 2013 17:39, michael kapelko korn...@gmail.com wrote: I've stripped down my OSG app to the attached archive. Upon exit there's some threading error, not real crash. But when I make my mCamera reference-count-controlled by osg::ref_ptr my app crashes. So may be I'm having my threading exit hanging due to not using osg::ref_ptr. I've just looked at your example and it really is convoluted and wrong in a number of ways, we aren't talking OSG bugs, we are talking bugs in your code. 1) You have an event handler that has a Viewer, and you attach this event handler to the Viewer, which takes a reference, via ref_ptr, to that event handler creating a circular reference. 2) You take a C pointer to the a Camera that you assign to the viewer, which takes a referecence, via ref_ptr, so the Viewer takes ownership and will destruct it it automatically once the Viewer gets destructed, but... you manually call unref() and the event handler to force destruction of the viewer's Camera. This will either cause a dangling pointer in the Viewer or a dangling pointer in the event handler, both of which will attempt to unref() it. The code is crazy. We have lots of OSG example that show as sensible way to use the OSG, none of them have an event handler owning the viewer. Also you'll almost next see examples of code explicitly calling unref(), it's only in very rare cases where you might want to not use ref_ptr and directly call ref() and unref(), and where you do you have to be very careful about management of the pointers involved. I almost never write code that explicitly calls ref() and unref(), instead ref_ptr is my tool, it's robust and easy to use. I'm guessing you've resorted to using the unref() because you created a circular reference without realizing it and tried to hack your way out of this design/implementation error. In you own I strongly recommend that you make the viewer the topmost object in the chain, *always* leave the event handler as a child of the viewer, and *never* use ref()/unref() - use ref_ptr instead. 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] osgWindows Example Crashing on Linux
Hi Abhishek,
I've been doing a code review of the code associated with the stack
trace and I suspect the static variables in the
osg::getGLExtensionDisableString() function could be the cause, one
way around this would be to make sure these static variables are
initialized single threaded rather let them be initialized on demand
as they are right now. I've introduced a OSG_INIT_SINGLETON_PROXY to
call osg::getGLExtensionDisableString() that will be called during
initialization of global variables which should be done single
threaded.
Could you try out svn/trunk, or apply the attached GLExtensions.cpp
and see if this resolves the problem?
Thanks,
Robert.
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield
*
* This library is open source and may be redistributed and/or modified under
* the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or
* (at your option) any later version. The full license is in LICENSE file
* included with this distribution, and on the openscenegraph.org website.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* OpenSceneGraph Public License for more details.
*/
#include osg/GLExtensions
#include osg/GL
#include osg/Notify
#include osg/Math
#include osg/buffered_value
#include stdlib.h
#include string.h
#include stdio.h
#include float.h
#include string
#include vector
#include set
#if defined(WIN32)
#ifndef WIN32_LEAN_AND_MEAN
#define WIN32_LEAN_AND_MEAN
#endif // WIN32_LEAN_AND_MEAN
#ifndef NOMINMAX
#define NOMINMAX
#endif // NOMINMAX
#include windows.h
#elif defined(__APPLE__)
// The NS*Symbol* stuff found in mach-o/dyld.h is deprecated.
// Since 10.3 (Panther) OS X has provided the dlopen/dlsym/dlclose
// family of functions under dlfcn.h. Since 10.4 (Tiger), Apple claimed
// the dlfcn family was significantly faster than the NS*Symbol* family.
// Since 'deprecated' needs to be taken very seriously with the
// coming of 10.5 (Leopard), it makes sense to use the dlfcn family when possible.
#include AvailabilityMacros.h
#if !defined(MAC_OS_X_VERSION_10_3) || (MAC_OS_X_VERSION_MIN_REQUIRED MAC_OS_X_VERSION_10_3)
#define USE_APPLE_LEGACY_NSSYMBOL
#include mach-o/dyld.h
#else
#include dlfcn.h
#endif
#else
#include dlfcn.h
#endif
typedef std::setstd::string ExtensionSet;
static osg::buffered_objectExtensionSet s_glExtensionSetList;
static osg::buffered_objectstd::string s_glRendererList;
static osg::buffered_valueint s_glInitializedList;
static osg::buffered_objectExtensionSet s_gluExtensionSetList;
static osg::buffered_objectstd::string s_gluRendererList;
static osg::buffered_valueint s_gluInitializedList;
float osg::getGLVersionNumber()
{
// needs to be extended to do proper things with subversions like 1.5.1, etc.
char *versionstring = (char*) glGetString( GL_VERSION );
if (!versionstring) return 0.0;
return (findAsciiToFloat(versionstring));
}
bool osg::isExtensionInExtensionString(const char *extension, const char *extensionString)
{
const char *startOfWord = extensionString;
const char *endOfWord;
while ((endOfWord = strchr(startOfWord,' ')) != 0)
{
if (strncmp(extension, startOfWord, endOfWord - startOfWord) == 0)
return true;
startOfWord = endOfWord+1;
}
if (*startOfWord strcmp(extension, startOfWord) == 0)
return true;
return false;
}
bool osg::isGLExtensionSupported(unsigned int contextID, const char *extension)
{
return osg::isGLExtensionOrVersionSupported(contextID, extension, FLT_MAX);
}
bool osg::isGLExtensionOrVersionSupported(unsigned int contextID, const char *extension, float requiredGLVersion)
{
ExtensionSet extensionSet = s_glExtensionSetList[contextID];
std::string rendererString = s_glRendererList[contextID];
// first check to see if GL version number of recent enough.
bool result = requiredGLVersion = osg::getGLVersionNumber();
if (!result)
{
// if not already set up, initialize all the per graphic context values.
if (!s_glInitializedList[contextID])
{
s_glInitializedList[contextID] = 1;
// set up the renderer
const GLubyte* renderer = glGetString(GL_RENDERER);
rendererString = renderer ? (const char*)renderer : ;
// get the extension list from OpenGL.
GLint numExt = 0;
#if !defined(OSG_GLES1_AVAILABLE) !defined(OSG_GLES2_AVAILABLE)
if( osg::getGLVersionNumber() = 3.0 )
{
// OpenGL 3.0 adds the concept of indexed strings and
// deprecates calls to glGetString( GL_EXTENSIONS ), which
// will now generate GL_INVALID_ENUM.
// Get extensions using new
Re: [osg-users] [osgPlugins] How to add Animations stored in Fbx to another Fbx model
void mergeAnimation(osg::Node* mainModel, osg::Node* mergeModel)
{
FindAnimationManagerVisitor famvMain;
mainModel-accept(famvMain);
osgAnimation::AnimationManagerBase* animationManagerMain =
famvMain.getAnimationManager();
if (animationManagerMain == 0)
throw std::logic_error(no animation manager found in main
model);
FindAnimationManagerVisitor famv;
mergeModel-accept(famv);
osgAnimation::AnimationManagerBase* animationManager =
famv.getAnimationManager();
if (animationManager == 0)
throw std::logic_error(no animation manager found in secondary
model);
const osgAnimation::AnimationList list =
animationManager-getAnimationList();
for (osgAnimation::AnimationList::const_iterator ai = list.begin(); ai
!= list.end(); ai++)
animationManagerMain-registerAnimation(*ai);
}
28.05.2013, 08:27, Michael Borst mich...@jborst.de:
Do you have sample code,
maybe i am just missing one importent line or flag to be set
Thank you!
Cheers,
Michael
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=54235#54235
___
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] Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6
Robert, This is great news! I will try out the new code as soon as possible and report back my findings. Thanks, Judson On 5/24/2013 5:42 AM, Robert Osfield wrote: Hi Judson. I have refactored the Viewer/CompositeViewer::checkNeedToDo() method so that it now calls a new Viewer/CompositeViewer::checkEvents() method that checks for available events rather than rely upon the more heavier weight eventTraversals() method. The eventTraversals() method design is focused on being done as part of a full frame and was hacked to work in the case of run or demand but didn't handle me moving the frame() event generation into. There are good reasons to move frame() event, but not so good reasons to do a full event traversal as a means for checking whether a full frame is needed or not. The introduction of the checkEvents() method required quite a few changes in other classes to support it, fingers crossed I haven't broken the build in the process of making these changes, unfortunately I can't test out OSX, iOS, Windows builds so will have rely upon the community to test of these changes that I had to make to the platform specific GraphicsWindow implementations. I have now checked in my changes to svn/trunk, could you test them out and let me know if things are working OK now. 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] Image::computeImageSizeInBytes bug
Hi Marcin,
I have now got on to do a second review your proposed changes for
osg::computeImageSizeInBytes(..) and have now merged these with a some
small changes to retain some of the original functionality - such as
catching dimensions such as 0 and below. This is would produce
different behavior than the original dds plugin version of this code
so I've left the original dds plugin function in place but implemented
the bulk of it via calling the osg::computeImageSizeInBytes(..)
method, the only part that is return is the clamp of dimensions 1 to
1.
The changes are now provided below. Could you test out svn/trunk and
let me know if this works fine with your datasets now.
Cheers,
Robert.
-- $ svn diff
Index: examples/osgphotoalbum/ImageReaderWriter.cpp
===
--- examples/osgphotoalbum/ImageReaderWriter.cpp(revision 13440)
+++ examples/osgphotoalbum/ImageReaderWriter.cpp(working copy)
@@ -170,6 +170,7 @@
// set up the texture.
osg::Texture2D* texture = new osg::Texture2D;
texture-setImage(image);
+texture-setResizeNonPowerOfTwoHint(false);
texture-setFilter(osg::Texture::MIN_FILTER,osg::Texture::LINEAR);
texture-setFilter(osg::Texture::MAG_FILTER,osg::Texture::LINEAR);
Index: src/osg/Image.cpp
===
--- src/osg/Image.cpp (revision 13445)
+++ src/osg/Image.cpp (working copy)
@@ -722,14 +722,49 @@
return (widthInBits/packingInBits +
((widthInBits%packingInBits)?1:0))*packing;
}
-unsigned int Image::computeImageSizeInBytes(int width,int height, int
depth, GLenum pixelFormat,GLenum type,int packing)
+unsigned int Image::computeImageSizeInBytes(int width,int height, int
depth, GLenum pixelFormat,GLenum type,int packing, int slice_packing,
int image_packing)
{
-if (width==0 || height==0 || depth==0) return 0;
+if (width=0 || height=0 || depth=0) return 0;
-return osg::maximum(
-
Image::computeRowWidthInBytes(width,pixelFormat,type,packing)*height*depth,
-computeBlockSize(pixelFormat, packing)
-);
+// Taking advantage of the fact that
+// DXT formats are defined as 4 successive numbers:
+// GL_COMPRESSED_RGB_S3TC_DXT1_EXT 0x83F0
+// GL_COMPRESSED_RGBA_S3TC_DXT1_EXT0x83F1
+// GL_COMPRESSED_RGBA_S3TC_DXT3_EXT0x83F2
+// GL_COMPRESSED_RGBA_S3TC_DXT5_EXT0x83F3
+if( pixelFormat = GL_COMPRESSED_RGB_S3TC_DXT1_EXT
+pixelFormat = GL_COMPRESSED_RGBA_S3TC_DXT5_EXT )
+{
+width = (width + 3) ~3;
+height = (height + 3) ~3;
+}
+
+// 3dc ATI formats
+// GL_COMPRESSED_RED_RGTC1_EXT 0x8DBB
+// GL_COMPRESSED_SIGNED_RED_RGTC1_EXT 0x8DBC
+// GL_COMPRESSED_RED_GREEN_RGTC2_EXT 0x8DBD
+// GL_COMPRESSED_SIGNED_RED_GREEN_RGTC2_EXT0x8DBE
+if( pixelFormat = GL_COMPRESSED_RED_RGTC1_EXT
+pixelFormat = GL_COMPRESSED_SIGNED_RED_GREEN_RGTC2_EXT )
+{
+width = (width + 3) ~3;
+height = (height + 3) ~3;
+}
+
+// compute size of one row
+unsigned int size = osg::Image::computeRowWidthInBytes( width,
pixelFormat, type, packing );
+
+// now compute size of slice
+size *= height;
+size += slice_packing - 1;
+size -= size % slice_packing;
+
+// compute size of whole image
+size *= depth;
+size += image_packing - 1;
+size -= size % image_packing;
+
+return osg::maximum( size, computeBlockSize(pixelFormat, packing) );
}
int Image::computeNearestPowerOfTwo(int s,float bias)
Index: src/osgPlugins/dds/ReaderWriterDDS.cpp
===
--- src/osgPlugins/dds/ReaderWriterDDS.cpp (revision 13448)
+++ src/osgPlugins/dds/ReaderWriterDDS.cpp (working copy)
@@ -400,53 +400,15 @@
UI32 reserved;
} OSG_DDS_HEADER_DXT10;
-static unsigned int ComputeImageSizeInBytes
-( int width, int height, int depth,
- unsigned int pixelFormat, unsigned int pixelType,
- int packing = 1, int slice_packing = 1, int image_packing = 1 )
+static unsigned int ComputeImageSizeInBytes( int width, int height, int depth,
+ unsigned int
pixelFormat, unsigned int pixelType,
+ int packing = 1, int
slice_packing = 1, int image_packing = 1 )
{
if( width 1 ) width = 1;
if( height 1 ) height = 1;
if( depth 1 ) depth = 1;
-
-// Taking advantage of the fact that
-// DXT formats are defined as 4 successive numbers:
-// GL_COMPRESSED_RGB_S3TC_DXT1_EXT 0x83F0
-// GL_COMPRESSED_RGBA_S3TC_DXT1_EXT0x83F1
-// GL_COMPRESSED_RGBA_S3TC_DXT3_EXT0x83F2
-// GL_COMPRESSED_RGBA_S3TC_DXT5_EXT0x83F3
-if( pixelFormat = GL_COMPRESSED_RGB_S3TC_DXT1_EXT
-
Re: [osg-users] Image::computeImageSizeInBytes bug
Hi Robert,
sorry for not submitting second version as I promised but I had
extremely busy and complicated life last couple of months.
I'll try to test your submit this week and give you feedback.
Regards,
Marcin
On Tue, 28 May 2013 15:15:24 +0100, Robert Osfield wrote:
Hi Marcin,
I have now got on to do a second review your proposed changes for
osg::computeImageSizeInBytes(..) and have now merged these with a
some
small changes to retain some of the original functionality - such as
catching dimensions such as 0 and below. This is would produce
different behavior than the original dds plugin version of this code
so I've left the original dds plugin function in place but
implemented
the bulk of it via calling the osg::computeImageSizeInBytes(..)
method, the only part that is return is the clamp of dimensions 1 to
1.
The changes are now provided below. Could you test out svn/trunk and
let me know if this works fine with your datasets now.
Cheers,
Robert.
-- $ svn diff
Index: examples/osgphotoalbum/ImageReaderWriter.cpp
===
--- examples/osgphotoalbum/ImageReaderWriter.cpp(revision
13440)
+++ examples/osgphotoalbum/ImageReaderWriter.cpp(working
copy)
@@ -170,6 +170,7 @@
// set up the texture.
osg::Texture2D* texture = new osg::Texture2D;
texture-setImage(image);
+texture-setResizeNonPowerOfTwoHint(false);
texture-setFilter(osg::Texture::MIN_FILTER,osg::Texture::LINEAR);
texture-setFilter(osg::Texture::MAG_FILTER,osg::Texture::LINEAR);
Index: src/osg/Image.cpp
===
--- src/osg/Image.cpp (revision 13445)
+++ src/osg/Image.cpp (working copy)
@@ -722,14 +722,49 @@
return (widthInBits/packingInBits +
((widthInBits%packingInBits)?1:0))*packing;
}
-unsigned int Image::computeImageSizeInBytes(int width,int height,
int
depth, GLenum pixelFormat,GLenum type,int packing)
+unsigned int Image::computeImageSizeInBytes(int width,int height,
int
depth, GLenum pixelFormat,GLenum type,int packing, int slice_packing,
int image_packing)
{
-if (width==0 || height==0 || depth==0) return 0;
+if (width=0 || height=0 || depth=0) return 0;
-return osg::maximum(
-
Image::computeRowWidthInBytes(width,pixelFormat,type,packing)*height*depth,
-computeBlockSize(pixelFormat, packing)
-);
+// Taking advantage of the fact that
+// DXT formats are defined as 4 successive numbers:
+// GL_COMPRESSED_RGB_S3TC_DXT1_EXT 0x83F0
+// GL_COMPRESSED_RGBA_S3TC_DXT1_EXT0x83F1
+// GL_COMPRESSED_RGBA_S3TC_DXT3_EXT0x83F2
+// GL_COMPRESSED_RGBA_S3TC_DXT5_EXT0x83F3
+if( pixelFormat = GL_COMPRESSED_RGB_S3TC_DXT1_EXT
+pixelFormat = GL_COMPRESSED_RGBA_S3TC_DXT5_EXT )
+{
+width = (width + 3) ~3;
+height = (height + 3) ~3;
+}
+
+// 3dc ATI formats
+// GL_COMPRESSED_RED_RGTC1_EXT 0x8DBB
+// GL_COMPRESSED_SIGNED_RED_RGTC1_EXT 0x8DBC
+// GL_COMPRESSED_RED_GREEN_RGTC2_EXT 0x8DBD
+// GL_COMPRESSED_SIGNED_RED_GREEN_RGTC2_EXT0x8DBE
+if( pixelFormat = GL_COMPRESSED_RED_RGTC1_EXT
+pixelFormat = GL_COMPRESSED_SIGNED_RED_GREEN_RGTC2_EXT )
+{
+width = (width + 3) ~3;
+height = (height + 3) ~3;
+}
+
+// compute size of one row
+unsigned int size = osg::Image::computeRowWidthInBytes( width,
pixelFormat, type, packing );
+
+// now compute size of slice
+size *= height;
+size += slice_packing - 1;
+size -= size % slice_packing;
+
+// compute size of whole image
+size *= depth;
+size += image_packing - 1;
+size -= size % image_packing;
+
+return osg::maximum( size, computeBlockSize(pixelFormat,
packing) );
}
int Image::computeNearestPowerOfTwo(int s,float bias)
Index: src/osgPlugins/dds/ReaderWriterDDS.cpp
===
--- src/osgPlugins/dds/ReaderWriterDDS.cpp (revision 13448)
+++ src/osgPlugins/dds/ReaderWriterDDS.cpp (working copy)
@@ -400,53 +400,15 @@
UI32 reserved;
} OSG_DDS_HEADER_DXT10;
-static unsigned int ComputeImageSizeInBytes
-( int width, int height, int depth,
- unsigned int pixelFormat, unsigned int pixelType,
- int packing = 1, int slice_packing = 1, int image_packing = 1
)
+static unsigned int ComputeImageSizeInBytes( int width, int height,
int depth,
+ unsigned int
pixelFormat, unsigned int pixelType,
+ int packing = 1, int
slice_packing = 1, int image_packing = 1 )
{
if( width 1 ) width = 1;
if( height 1 ) height = 1;
if( depth 1 ) depth = 1;
-
-// Taking advantage of the fact that
-// DXT formats are defined as 4 successive
Re: [osg-users] Culling w/ RTT
Hi Jeremy, This sound very similar to an issue I've encountered before. Does your RTT Camera object use a RELATIVE or ABSOLUTE reference frame? Also, are you applying any ComputeBoundingSphereCallbacks to you scene or override the computeBound method of any nodes? Cheers, Farshid On Mon, May 27, 2013 at 11:07 AM, Jeremy Moles cubic...@gmail.com wrote: Hello everyone! I'm running into a problem in my application where I'm trying to switch between two different subgraphs as the result of some event (key press or similar). The first of these two objects is a standard subgraph with nothing too sophisticated going on. The second of these is a RTT stack of Camera objects. The problem manifests in that if I switch FROM the standard graph (just a random grouping of models) to the RTT Camera stack, the bounds of the previous node are used for the RTT Camera. This means that while the same scene rendered within my RTT stack is fine as long as you don't adjust the view matrix, as soon as you move the scene around it begins to get culled. I can remedy this problem by disabling culling on the main viewer camera when my RTT stack is in effect, but I feel like I'm doing something wrong... the reason I think this is because I can add the RTT stack to my scene as the FIRST scene (and never toggle it to anything else) and the culling occurs correctly. The problem only manifests when I switch from the RTT stack to a standard node AND THE BACK to the RTT scene. Has anyone tried anything like this in the past? Does anyone have any hints? :) __**_ osg-users mailing list osg-users@lists.**openscenegraph.org osg-users@lists.openscenegraph.org http://lists.openscenegraph.**org/listinfo.cgi/osg-users-** openscenegraph.orghttp://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-3.1.7 developer release tagged
Hi Robert I just downloaded the new developer release and wanted to bring what I believe is a typo to your attention. See osg/src/osgViewer/config/PanormaicSphericalDisplay.cpp vs the header osg/include/osgViewer/config/PanoramicSphericalDisplay. I imagine PanormaicSphericalDisplay.cpp should be PanoramicSphericalDisplay.cpp. Ironically, I keep making an alternate typo of the same file! Also, these developer releases are extremely convenient, thank you for taking the time to create them! Regards, Judson On 5/27/2013 5:39 AM, Robert Osfield wrote: Hi All, I have just tagged the latest developer release, OpenSceneGraph-3.1.7. snip ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] adding barrel distortion for stereoscopic rendering in Oculus Rift head set
I just got my Rift dev kit today and plan to look at this a bit as well. I'm a little slammed on time for the next week, so I don't have any estimates but I'll post when I have something to show. If anyone else has already made progress, please share ;) Cheers, Trystan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54267#54267 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Culling w/ RTT
On 05/28/2013 01:20 PM, Farshid Lashkari wrote: Hi Jeremy, This sound very similar to an issue I've encountered before. Does your RTT Camera object use a RELATIVE or ABSOLUTE reference frame? Also, are you applying any ComputeBoundingSphereCallbacks to you scene or override the computeBound method of any nodes? ABSOLUTE. And no, I'm not applying any BoundingSphere callbacks... Cheers, Farshid On Mon, May 27, 2013 at 11:07 AM, Jeremy Moles cubic...@gmail.com mailto:cubic...@gmail.com wrote: Hello everyone! I'm running into a problem in my application where I'm trying to switch between two different subgraphs as the result of some event (key press or similar). The first of these two objects is a standard subgraph with nothing too sophisticated going on. The second of these is a RTT stack of Camera objects. The problem manifests in that if I switch FROM the standard graph (just a random grouping of models) to the RTT Camera stack, the bounds of the previous node are used for the RTT Camera. This means that while the same scene rendered within my RTT stack is fine as long as you don't adjust the view matrix, as soon as you move the scene around it begins to get culled. I can remedy this problem by disabling culling on the main viewer camera when my RTT stack is in effect, but I feel like I'm doing something wrong... the reason I think this is because I can add the RTT stack to my scene as the FIRST scene (and never toggle it to anything else) and the culling occurs correctly. The problem only manifests when I switch from the RTT stack to a standard node AND THE BACK to the RTT scene. Has anyone tried anything like this in the past? Does anyone have any hints? :) ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Culling w/ RTT
Hi Jeremy, I haven't commented yet as I really don't have any answer, there as simply too many unknowns about what you might be doing at your end to be able to guess. If you can't resolve the problem soon then it might be best to create a small example, such as by modifying an existing example, so that others can test the same set up that causes problems. It might be that there is flaw in the way you've set up the scene graph, or a bug lurking somewhere in the OSG that is only revealed with certian types of usage. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-3.1.7 developer release tagged
Hi Judson, On 28 May 2013 18:35, Judson Weissert jud...@mfrac.com wrote: I just downloaded the new developer release and wanted to bring what I believe is a typo to your attention. See osg/src/osgViewer/config/PanormaicSphericalDisplay.cpp vs the header osg/include/osgViewer/config/PanoramicSphericalDisplay. I imagine PanormaicSphericalDisplay.cpp should be PanoramicSphericalDisplay.cpp. Ironically, I keep making an alternate typo of the same file! Opps... the header and class name were fine, but the .cpp was wrong. Fix now checked into svn/trunk. Also, these developer releases are extremely convenient, thank you for taking the time to create them! Thanks for testing them. The dev releases are about getting tags out that can be tested, and as we converge towards the 3.2 stable release my plan is to keep the dev 3.1.x dev release series rev'ing over quickly so that we can get more testing, with each successive dev release becoming closer to the final release. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Culling w/ RTT
Hi Jeremy, One more question, how are you switching between scene graphs ( switch node, node masks, add/remove child)? If your Camera nodes are using ABSOLUTE reference frame, then I believe disabling culling on its parent nodes is the best solution. If you look at the Group::computeBound method, you will notice it ignores child transforms with ABSOLUTE reference frame when computing the bounding sphere. What might be happening is that when you switch to the Camera scene, the group node containing the camera is culling based off a non-representative bounding sphere. Also, if you happen to be using node masks to turn scene graphs on/off, then you might need to manually call dirtyBound() on the nodes. The Node::setNodeMask method does not automatically call dirtyBound(), and this has caused culling issues for me before. Cheers, Farshid On Tue, May 28, 2013 at 11:29 AM, Jeremy Moles cubic...@gmail.com wrote: On 05/28/2013 01:20 PM, Farshid Lashkari wrote: Hi Jeremy, This sound very similar to an issue I've encountered before. Does your RTT Camera object use a RELATIVE or ABSOLUTE reference frame? Also, are you applying any ComputeBoundingSphereCallbacks to you scene or override the computeBound method of any nodes? ABSOLUTE. And no, I'm not applying any BoundingSphere callbacks... Cheers, Farshid On Mon, May 27, 2013 at 11:07 AM, Jeremy Moles cubic...@gmail.commailto: cubic...@gmail.com wrote: Hello everyone! I'm running into a problem in my application where I'm trying to switch between two different subgraphs as the result of some event (key press or similar). The first of these two objects is a standard subgraph with nothing too sophisticated going on. The second of these is a RTT stack of Camera objects. The problem manifests in that if I switch FROM the standard graph (just a random grouping of models) to the RTT Camera stack, the bounds of the previous node are used for the RTT Camera. This means that while the same scene rendered within my RTT stack is fine as long as you don't adjust the view matrix, as soon as you move the scene around it begins to get culled. I can remedy this problem by disabling culling on the main viewer camera when my RTT stack is in effect, but I feel like I'm doing something wrong... the reason I think this is because I can add the RTT stack to my scene as the FIRST scene (and never toggle it to anything else) and the culling occurs correctly. The problem only manifests when I switch from the RTT stack to a standard node AND THE BACK to the RTT scene. Has anyone tried anything like this in the past? Does anyone have any hints? :) __**_ osg-users mailing list osg-users@lists.**openscenegraph.orgosg-users@lists.openscenegraph.org mailto:osg-users@lists.**openscenegraph.orgosg-users@lists.openscenegraph.org http://lists.openscenegraph.**org/listinfo.cgi/osg-users-** openscenegraph.orghttp://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org __**_ osg-users mailing list osg-users@lists.**openscenegraph.org osg-users@lists.openscenegraph.org http://lists.openscenegraph.**org/listinfo.cgi/osg-users-** openscenegraph.orghttp://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera Manipulator or culling behavior change 3.1.2 vs 3.1.6
Hi Robert, I just got the 3.1.7 developer release built. Running the osgviewer application with arguments --run-on-demand --screen 1 dumptruck.osgt results in a regression where the viewer does not respond to mouse or keyboard input (does not render any new frames, does not allow me to exit via escape, does not respond to 's' for stats, etc). Similar behavior occurs in my application, but I have not had a chance to run the code in a debugger yet. Running the osgviewer application without the --run-on-demand flag appears to work as expected. Compiled with Visual C++ 2010, running on Windows 7 (Same machine and compiler settings as my previous tests). Regards, Judson On 5/28/2013 9:39 AM, Judson Weissert wrote: Robert, This is great news! I will try out the new code as soon as possible and report back my findings. Thanks, Judson On 5/24/2013 5:42 AM, Robert Osfield wrote: Hi Judson. I have refactored the Viewer/CompositeViewer::checkNeedToDo() method so that it now calls a new Viewer/CompositeViewer::checkEvents() method that checks for available events rather than rely upon the more heavier weight eventTraversals() method. The eventTraversals() method design is focused on being done as part of a full frame and was hacked to work in the case of run or demand but didn't handle me moving the frame() event generation into. There are good reasons to move frame() event, but not so good reasons to do a full event traversal as a means for checking whether a full frame is needed or not. The introduction of the checkEvents() method required quite a few changes in other classes to support it, fingers crossed I haven't broken the build in the process of making these changes, unfortunately I can't test out OSX, iOS, Windows builds so will have rely upon the community to test of these changes that I had to make to the platform specific GraphicsWindow implementations. I have now checked in my changes to svn/trunk, could you test them out and let me know if things are working OK now. 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Any recent work on CIGI interfaces to OSG?
Hi Chris, I work on an OpenSceneGraph-based image generator for the Federal Aviation Administration that is built on the CIGI protocol. Like you, we originally started from MPV and worked from there. Thankfully we threw all that code away and started from scratch. I don't know how much has changed in MPV in the past five years... Maybe it's a great, well-engineered piece of software now! But if it's like what I remember, I'd only use it as a reference on CIGI concepts, not on how to integrate OSG into a CIGI application. It wasn't designed for multithreading, it was originally built for OSG 0.91, and it uses a library called osgSDL to handle Windowing, threading, and user input... Which makes using any modern OSG code/examples (which expect an osgViewer/osgGA base) problematic to say the least. Also, if you're serious about CIGI support, you may need to roll your own CIGI library. I haven't looked at the 3.3.3 version of CCL, but when it finally became apparent that our wrapper code around CCL 3.3.2 was rivaling the size of CCL itself, we ended up rewriting it from scratch. Again, it's a good solution for teaching you the concepts, but I think it's really best as a reference implementation and not practical for production use... May I ask why you're working on adding a CIGI interface to FlightGear? I'm only curious because we keep asking ourselves why we stuck with CIGI all these years, as no one else actually seems to use it! Any other vendors we deal with always go Well, yeah, you CAN use CIGI with our stuff... But it'd really be better if you used our API instead! And then when you look at their CIGI support, they usually have just wrapped their proprietary packets in CIGI custom packets... Bleh. But if this hasn't thoroughly discouraged you yet... Well, I'm not sure I have any good news for you, really. You're going to find that SO MUCH of CIGI is either incredibly ambiguous or 'implementation defined', that you're going to have trouble writing a general-purpose CIGI wrapper. If you're willing to get more specific, I think a useful area for you to work on is handling EntityCtrl packets at the very least, to add/move/delete entities to a scene graph. That's (to me) the really key/useful feature exposed by CIGI, and is probably the most well-defined part of the protocol. It'll also be your first real taste of how CIGI gets you most of the way, as you'll have to provide an out-of-band way to map entity types to model files, and also a way to let a user specify the coordinate system transform from the WGS84 ellipsoid to their database coordinates. Oh, and CIGI optionally lets you specify a custom ellipsoid, too. I'd save some sanity and leave that particular feature in the not supported column. :) After that... Extending osgGA::NodeTrackerManipulator to follow the Ownship entity in your scene graph would be a good step towards having a functional image generator, if that's what you're aiming for. If you have any specific questions, feel free to ping me and I'll be happy to share the dubious benefits of five years of working on your problem with you. But if you're looking for general advice on implementing CIGI in OSG... Well... In one word: Don't. In slightly more words: Think very hard as to why you're doing it, and what the likelihood is you'll actually ever integrate your solution with a DIFFERENT system that uses CIGI... And is using a compatible version of CIGI... And made the same (or similar enough) choices about the ambiguous or implementation defined features... Good luck. -Chris B On Fri, May 24, 2013 at 5:26 PM, Chris Calef chris.ca...@gmail.com wrote: Hi, I'm new to OSG, coming in from the direction of FlightGear, but I'm here primarily because I am interested in implementing a CIGI interface to FlightGear, and would like to put as much of this work as possible into an OSG module in order to make it useful to the larger OSG community and not only FlightGear developers. I have read the conversations about doing this from several years ago, but have not found any recent discussion or located any available code drops. I have downloaded the MPV example from CIGI at sourceforge, which is based on OSG, and that is quite helpful, but I wanted to introduce myself here and see if anyone can catch me up on any other existing work in this direction, or give me advice about where to start. Much of the CIGI interface is dedicated to higher order simulation functions (ie celestial bodies, ocean conditions, aircraft controls) which are probably too specific to implement at the OSG layer, but I'd like to make at least a virtual wrapper in OSG which could be inherited by FlightGear and other OSG based projects, each of which could determine on its own which functions to support, and how to support them. Any pointers would be welcome. I am applying for funding for this project in one week, so the more information I can gather before then the better. Thanks for all your
Re: [osg-users] Any recent work on CIGI interfaces to OSG?
Our host talks with several different IGs on the backend (OSG, Quantum3D, Aechelon) . All use the CIGI protocol. If it wasn't for CIGI, our host would have to support different ways of communicating with each IG which would be a pain. The OSG-based IG is one that we developed in-house. Like both Chris' , we also spawned our efforts off of Boeing's MPV with our own modifications. Rather than rolling CIGI into OSG, I would suggest using a thread/process that eats CIGI packets that then interfaces with OSG where applicable. A while back, the developer of osgVisual had contemplated writing a CIGI plugin. I don't know where that effort ended up though... -Shayne -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Chris Best Sent: Tuesday, May 28, 2013 2:29 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Any recent work on CIGI interfaces to OSG? Hi Chris, I work on an OpenSceneGraph-based image generator for the Federal Aviation Administration that is built on the CIGI protocol. Like you, we originally started from MPV and worked from there. Thankfully we threw all that code away and started from scratch. I don't know how much has changed in MPV in the past five years... Maybe it's a great, well-engineered piece of software now! But if it's like what I remember, I'd only use it as a reference on CIGI concepts, not on how to integrate OSG into a CIGI application. It wasn't designed for multithreading, it was originally built for OSG 0.91, and it uses a library called osgSDL to handle Windowing, threading, and user input... Which makes using any modern OSG code/examples (which expect an osgViewer/osgGA base) problematic to say the least. Also, if you're serious about CIGI support, you may need to roll your own CIGI library. I haven't looked at the 3.3.3 version of CCL, but when it finally became apparent that our wrapper code around CCL 3.3.2 was rivaling the size of CCL itself, we ended up rewriting it from scratch. Again, it's a good solution for teaching you the concepts, but I think it's really best as a reference implementation and not practical for production use... May I ask why you're working on adding a CIGI interface to FlightGear? I'm only curious because we keep asking ourselves why we stuck with CIGI all these years, as no one else actually seems to use it! Any other vendors we deal with always go Well, yeah, you CAN use CIGI with our stuff... But it'd really be better if you used our API instead! And then when you look at their CIGI support, they usually have just wrapped their proprietary packets in CIGI custom packets... Bleh. But if this hasn't thoroughly discouraged you yet... Well, I'm not sure I have any good news for you, really. You're going to find that SO MUCH of CIGI is either incredibly ambiguous or 'implementation defined', that you're going to have trouble writing a general-purpose CIGI wrapper. If you're willing to get more specific, I think a useful area for you to work on is handling EntityCtrl packets at the very least, to add/move/delete entities to a scene graph. That's (to me) the really key/useful feature exposed by CIGI, and is probably the most well-defined part of the protocol. It'll also be your first real taste of how CIGI gets you most of the way, as you'll have to provide an out-of-band way to map entity types to model files, and also a way to let a user specify the coordinate system transform from the WGS84 ellipsoid to their database coordinates. Oh, and CIGI optionally lets you specify a custom ellipsoid, too. I'd save some sanity and leave that particular feature in the not supported column. :) After that... Extending osgGA::NodeTrackerManipulator to follow the Ownship entity in your scene graph would be a good step towards having a functional image generator, if that's what you're aiming for. If you have any specific questions, feel free to ping me and I'll be happy to share the dubious benefits of five years of working on your problem with you. But if you're looking for general advice on implementing CIGI in OSG... Well... In one word: Don't. In slightly more words: Think very hard as to why you're doing it, and what the likelihood is you'll actually ever integrate your solution with a DIFFERENT system that uses CIGI... And is using a compatible version of CIGI... And made the same (or similar enough) choices about the ambiguous or implementation defined features... Good luck. -Chris B On Fri, May 24, 2013 at 5:26 PM, Chris Calef chris.ca...@gmail.com wrote: Hi, I'm new to OSG, coming in from the direction of FlightGear, but I'm here primarily because I am interested in implementing a CIGI interface to FlightGear, and would like to put as much of this work as possible into an OSG module in order to make it useful to the larger OSG community and not only FlightGear developers.
