Re: [osg-users] New ffmpeg plugin checked into svn/trunk
Hi Jason, On Fri, Feb 27, 2009 at 9:14 PM, Jason Daly jd...@ist.ucf.edu wrote: So, is it your intention that the AudioSink interface would be implemented by another plugin (e.g.: an openal plugin)? That's a very good question... how to do we provide an AudioSink, and how far should we go in automating it. Tanguy's original implement has the AudioSink base classes attached to the custom FFmpegImageStream, so you'd read the movie in your application, then at the application level wire up the audio API to this image stream via a custom AuidoSink. My initial plan is to provide a similar solution - have the application wire up its own AudioSink to the AudioStream attached to the loaded ImageStream. The next step after this is open to debate. With integration of ffmpeg plugin I wasn't banking on tackling audio integration, but the fact that ffmpeg doesn't provide means of playing audio means that we have to provide some mechanism, the application wiring above is one solution, but it's not the out of the box solution that we currently have with xine-lib and quicktime so isn't a drop in replacement. To have a drop in replacement we'll need to provide a scheme to automatically provide the AudioSink. My current thoughts on how to provide this are that we could have an AudioSink prototype attached to osgDB::Registry that is NULL by default, but the application developer can assign one, and have this be cloned by the ffmpeg plugin etc. Potentially we could assign it on demand too if one isn't already assigned we could load a plugin such as a OpenAL to provide it. Further down the line perhaps the osgAudio library could provide the AudioSink prototype. I am open to suggestions on how best to address this issue. Two goals are clear - first that app developer should be able to provide their own audio implementation, and secondly a basic audio implementation should be loadable automatically as a fallback. Without the later we can't even consider deprecating the xine-lib and quicktime plugins. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Disabling small feature culling for a subgraph
Hi Per, I'm a bit rusty on this topic, too many topics coming flying by each day that niche stuff drops out of focus quite quickly... Something I can answer right away is to to explain the relationship between the CullingSet CullingMode and CullingMask. The Mode is the base mode that specifies what the overall mode should be, while the CullingMask is the current active subset of this mode, that handles the fact that different faces of the view frustum get disabled when subgraphs are completely inside the faces of the view frustum. At least that what I can recall/work out from a brief look through the code. Robert. On Fri, Feb 27, 2009 at 9:16 PM, Per Fahlberg pe...@remograph.com wrote: A correction, my earlier proposed fix also solves this problem if the cull callback is changed to also modify the culling mode of the cull visitor, so that the callback reads something like this: ... osg::CullSettings::CullingMode cullVisitorCullingMode = cv-getCullingMode(); osg::CullingSet cs = cv-getCurrentCullingSet(); osg::CullingSet::Mask cullingSetMask = cs.getCullingMask(); cv-setCullingMode(cullVisitorCullingMode | osg::CullSettings::SMALL_FEATURE_CULLING); cs.setCullingMask(cullingSetMask | osg::CullSettings::SMALL_FEATURE_CULLING); traverse(node,nv); cs.setCullingMask(cullingSetMask); cv-setCullingMode(cullVisitorCullingMode); ... I'm a bit confused about all the culling masks/modes and which ones to modify and how they are propagated when the cull visitor traverses the scenegraph. Regards, Per Per Fahlberg wrote: Hi Robert, I've been busy with other work and only now been able to try your proposed change and found that it doesn't quite work as expected. When I run the attached modified osgscribe example with the attached box-sphere.osg model the small feature culling only culls the entire model, i.e. both the box and the sphere together not separately as I was expecting. If small feature culling is turned on on the camera the box and sphere is culled by the small feature culling individually. I would like to enable small feature culling on quite large subgraphs and it seams that it only turns on small feature culling on the node with the callback not on the nodes bellow it. This feels very similar to the problem I was originally trying to solve, where the disabling of small feature culling wasn't propagated downwards but the fix I submitted then didn't fix this problem. Do I need to add the callback to all nodes that I wish to be culled by small feature culling or is this a problem in osg? Regards, Per Robert Osfield wrote: Hi Per, On Wed, Jan 28, 2009 at 8:55 PM, Per Fahlberg pe...@remograph.com wrote: I don't really understand how this is not a bug since it is possible to switch small feature culling on for a subgraph but not switch it off? The scene graph itself doesn't support switching off small feature culling in a subgraph. The way you tried to add this back in was inappropriate, so didn't work. My proposed change to just enable small feature culling for subgraphs that needn't it didn't require disabling culling for subgraphs so would be more efficient as culling would never be complete disabled. Disabling culling for a deeply embedded subgraph causes all the parents culling to be disabled as well, which prevents early termination of traversal that would otherwise be done so I wouldn't recommend it. I will however scratch my head and try to figure out if I can somehow easily invert the enabling and disabling of small feature culling in my program. You could just use LOD's, this is effectively all that small feature culling simulates. Alternatively you could just set the bounding box of the drawables of interest to an artificially large size to prevent the small feature culling from effecting them. 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] extend osgforest with a tree position raster mask
HI Christian, The way to use a mask like this would be to read an osg::Image and read from it directly. There is no reason to require the use Texture2D - this is only required if you want to do operations down on the GPU. osg::Image does have access methods for getting individual pixels. However, the way I'd tackle this problem would be by providing boundary polygons which are then tessellated to provide a triangular mesh that acts to describe the forest coverage. One would then compute the area for each of these triangles and then have a map of accumulated area to index position into the triangle list. This would give us the ability to have a random value map to a particular triangle, one then can use two more random values to provide the baricentric coords within than triangle and form this to the final XY location. From the XY location you then intersect the terrain and place the tree. A variation on this would be use the a subset of the actual terrain mesh, as this would then avoid the need for doing the intersection test as you'd get the correct XYZ location. The boundaries of the terrain triangles would might also be something that you'd want to manage to avoid an artificial look, this could be done by trimming a copy of the terrain triangles of interest by the polygonal boundary. A further variation on this would be to add probability weights to the vertices of the coverage mesh so you can change the density of trees across the model, one also could through in tree type variation at the same time. All of this is well outside the scope of the osgforest example though, but hopefully should give you a few ideas. Robert. On Sat, Feb 28, 2009 at 12:24 AM, Christian Sam osgfo...@tevs.eu wrote: hi, i would like to extend the example-program osgforest in a way so that the placement of trees becomes user-controllable via an additional raster mask. in detail: a 1bit rasterfile should mark treeless areas with a value of 0 and tree-covered areas with a value of 1. subsequent this mandatory partitioning, i would like use the existing, random placement of trees in tree-covered areas. i'm new to osg, so i have a few questions about how to implement this, and would also be happy to get some clues from you. * can i use a simple osg::texture2D (nearest neighbour worldcoordinate scaled to osgforest's terrain extent), as raster mask? * if yes, how can i query/access a raster value at a specific texture coordinate? * how can i prevent that the raster mask will be rendered in the final scene? (would a nodemask be the right way, or are there any better/simpler ways?) * in this first approach i will only implement 2 different tree regions: covered and non-covered. my plan is to extend to the existing createTreeList function with a simple check for the raster mask value at the randomly generated tree position coordinates. only if it happens to lie inside a tree-covered area, the tree will be pushed into the trees list. maybe someone knows a more elegant way? best regards, christian -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7664#7664 ___ 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.org stats
Hi JS, On Fri, Feb 27, 2009 at 9:26 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: OK, seems I understand the basics after all. So why are competing standards a bad thing if they're inherent to the nature of open standards? Or conversely, why are open standards so desirable if by their nature, they bring about competing standards which are undesirable? Competing standards are a bad thing as it breaks interoperability and divides the market place into targeting one or other, or both standards. For software vendors trying to use the standards they just one a workable solution, with minimum of effort, so naturally will want to target one rather than two standards, as supporting two is often far harder than twice as much work as inconsistencies creep in, and you often end up targeting the lowest common denominator of both. If you do just target one of the standards then your market is potentially diminished. Multiple standards covering the same area are bad for software vendors. For the hardware vendors multiple standards means again they have to target one, or both. Target one as they only cover part of the market, target two and their resources will be stretched. If one is targeting two then outside and internal pressures can exist to skew the effort made to supporting one or other of the standards, only in a perfect world might you see equal support. In our case, OpenGL should have been dominant - it has all the right attributes, it was open, it was cross platform, it was mature and extensible. Direct3D when MS introduced was non of these things, it was awful, it wasn't even completive under Windows let alone dropping all the other positives attributes that OpenGL had like portability and openness. However, MS would be MS if it didn't use it's monopoly position and dirty tactics to manipulate the market, and to try and kill OpenGL under Windows. Yes MS eventually got Direct3D so they it was feature competitive to OpenGL, but it still lacks the major features of OpenGL - it's openness, portability and extensibility. If the market had not been artificially skewed by MS's monopoly Direct3D would never have got a foot hold. Now stretch the surface on what this has meant for hardware vendors, MS's has a huge hold over them, it has the ability to deicide what features get exposed in hardware or not, the hardware vendors have hardware to develop and this takes years, if they feel that a certain feature is worthy of inclusion it has to work with MS to get it in the spec, but MS always has the right to ignore them as it's in control. DIrect3D isn't extensible so if MS doesn't support their hardware features then they are screwed, their is silicon going to waste, and silicon costs money to manufacture - your profit margins are very much on the line. This means the hardware vendors have little wiggle room not to do as MS wishes, and MS plays then off against each other. MS also gets to influence their other efforts, if they go too far out of line in other areas like pushing OpenGL MS can just not play ball, they can drop them in it by not supporting their cards fully. Since MS successfully got Direct3D to be dominant on the dominant desktop platform, not support Direct3D well for the hardware vendors is suicide, and will extra pressure from MS to sideline OpenGL it won't be too surprising that the OpenGL dev teams will be smaller and less well funded. With the growth of alternate platforms the OpenGL teams will be even more stretched, as they don't just have Windows 2000, XP, Vista and 7 to support but they have Linux, FreeBSD, OSX, Solaris, embedded platforms. Now market size is smaller for these other platforms so revenue is also less significant. It's easy to see that given this situation a hardware vendor might choose an easy life and just focus on Direct3D and sideline OpenGL. Now with a sidelined OpenGL, the quality and feature support will suffer, and it'll become less compelling a platform, it certainly has been under a lot of pressure. But it's software vendors like ourselves that are the pain in the butts, we demand OpenGL support, because we require portability, we require access to OpenGL extensions to get the best out of the hardware, we need longevity of support without having to refactor our code every couple of years to target the latest hardware features exposed by the next Direct3D version. Thankfully the hardware vendors have listened to our needs are kept OpenGL alive, albeit it far less vibrant than it would be if the hardware vendors weren't beholden to the whims of MS. So... the suggestion that somehow competing standards is a good thing for us rather galling. The market reality really is pretty ugly. It's are area of the market that really really deserves and Anti-trust case, but alas MS has those best placed to request it (the hardware vendors that develop OpenGL) by the balls so they won't complain, if they do MS just has to squeeze and their will
Re: [osg-users] Texture corruption in VPB.
On Sat, Feb 28, 2009 at 6:49 AM, J.P. Delport jpdelp...@csir.co.za wrote: Hi, I think you might be running into the corner equalisation bug. Search osg-submissions for the thread vpb - fix for corner equalisation The fix is not yet merged in vpb. I will be back on VPB very soon, so will be testing and merging fixes like the corner equalisation bug. Normally I'd respond quicker, but the last time I tried to testing of VPB I came across gdal bugs that looked to do with the particular build of gdal and haven't yet had time to go investigate and resolve this. I'm also out from under my OSG work load though... Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem compiling latest trunk, ffmpeg problem
HI Alejandro, Which version of ffmpeg do you have installed? As J.P. mentioned ffmpeg is a bit of moving target and were' only just getting into learning about FFmpeg foibles. We'll probably need to add version checking into our FindFFmpeg.cmake to avoid these issue. Also migrating the code across from not using deprecated functions will be a possible solution. Adopting use ffmpeg suggest use of swscale isn't though as it's GPL'd, so we may have to create our own local equivalents for colour conversion. Robert. On Sat, Feb 28, 2009 at 5:43 AM, Alejandro Aguilar Sierra algsie...@gmail.com wrote: Hi, I just updated both ffmpeg and osg/trunk, compiled and instaled ffmpeg but osg can't compile because these errors: [ 98%] Building CXX object src/osgPlugins/ffmpeg/CMakeFiles/osgdb_ffmpeg.dir/FFmpegDecoderVideo.o /home/ale/src/osg/trunk/src/osgPlugins/ffmpeg/FFmpegDecoderVideo.cpp: In member function 'void osgFFmpeg::FFmpegDecoderVideo::publishFrame(double)': /home/ale/src/osg/trunk/src/osgPlugins/ffmpeg/FFmpegDecoderVideo.cpp:228: error: 'img_convert' was not declared in this scope /home/ale/src/osg/trunk/src/osgPlugins/ffmpeg/FFmpegDecoderVideo.cpp: In member function 'void osgFFmpeg::FFmpegDecoderVideo::yuva420pToRgba(AVPicture*, const AVPicture*, int, int)': /home/ale/src/osg/trunk/src/osgPlugins/ffmpeg/FFmpegDecoderVideo.cpp:264: error: 'img_convert' was not declared in this scope make[2]: *** [src/osgPlugins/ffmpeg/CMakeFiles/osgdb_ffmpeg.dir/FFmpegDecoderVideo.o] Error 1 make[1]: *** [src/osgPlugins/ffmpeg/CMakeFiles/osgdb_ffmpeg.dir/all] Error 2 make: *** [all] Error 2 Before updating ffmpeg, I got other ffmpeg related compilation errors. Any hint? My system is GNU/Linux 2.6.26-1-686 Debian Sid, gcc 4.3.1. Regards, -- A. ___ 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] Problem compiling latest trunk, ffmpeg problem
Hi Robert, if you compile newer ffmpeg without GPL functions, it still has its own versions of the swscale functions implemented. You then just do not link to the (maybe faster) GPL swscale library. I've tested this on Debian and it worked for our app. I'll send some references and code later. jp Robert Osfield wrote: HI Alejandro, Which version of ffmpeg do you have installed? As J.P. mentioned ffmpeg is a bit of moving target and were' only just getting into learning about FFmpeg foibles. We'll probably need to add version checking into our FindFFmpeg.cmake to avoid these issue. Also migrating the code across from not using deprecated functions will be a possible solution. Adopting use ffmpeg suggest use of swscale isn't though as it's GPL'd, so we may have to create our own local equivalents for colour conversion. Robert. On Sat, Feb 28, 2009 at 5:43 AM, Alejandro Aguilar Sierra algsie...@gmail.com wrote: Hi, I just updated both ffmpeg and osg/trunk, compiled and instaled ffmpeg but osg can't compile because these errors: [ 98%] Building CXX object src/osgPlugins/ffmpeg/CMakeFiles/osgdb_ffmpeg.dir/FFmpegDecoderVideo.o /home/ale/src/osg/trunk/src/osgPlugins/ffmpeg/FFmpegDecoderVideo.cpp: In member function 'void osgFFmpeg::FFmpegDecoderVideo::publishFrame(double)': /home/ale/src/osg/trunk/src/osgPlugins/ffmpeg/FFmpegDecoderVideo.cpp:228: error: 'img_convert' was not declared in this scope /home/ale/src/osg/trunk/src/osgPlugins/ffmpeg/FFmpegDecoderVideo.cpp: In member function 'void osgFFmpeg::FFmpegDecoderVideo::yuva420pToRgba(AVPicture*, const AVPicture*, int, int)': /home/ale/src/osg/trunk/src/osgPlugins/ffmpeg/FFmpegDecoderVideo.cpp:264: error: 'img_convert' was not declared in this scope make[2]: *** [src/osgPlugins/ffmpeg/CMakeFiles/osgdb_ffmpeg.dir/FFmpegDecoderVideo.o] Error 1 make[1]: *** [src/osgPlugins/ffmpeg/CMakeFiles/osgdb_ffmpeg.dir/all] Error 2 make: *** [all] Error 2 Before updating ffmpeg, I got other ffmpeg related compilation errors. Any hint? My system is GNU/Linux 2.6.26-1-686 Debian Sid, gcc 4.3.1. Regards, -- A. ___ 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 -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem compiling latest trunk, ffmpeg problem
Hi, J.P. Delport wrote: Hi Robert, if you compile newer ffmpeg without GPL functions, it still has its own versions of the swscale functions implemented. You then just do not link to the (maybe faster) GPL swscale library. I've tested this on Debian and it worked for our app. I'll send some references and code later. See e.g. here: http://lists.mplayerhq.hu/pipermail/libav-user/2008-November/001618.html and http://lists.mplayerhq.hu/pipermail/libav-user/2008-June/000683.html jp jp Robert Osfield wrote: HI Alejandro, Which version of ffmpeg do you have installed? As J.P. mentioned ffmpeg is a bit of moving target and were' only just getting into learning about FFmpeg foibles. We'll probably need to add version checking into our FindFFmpeg.cmake to avoid these issue. Also migrating the code across from not using deprecated functions will be a possible solution. Adopting use ffmpeg suggest use of swscale isn't though as it's GPL'd, so we may have to create our own local equivalents for colour conversion. Robert. On Sat, Feb 28, 2009 at 5:43 AM, Alejandro Aguilar Sierra algsie...@gmail.com wrote: Hi, I just updated both ffmpeg and osg/trunk, compiled and instaled ffmpeg but osg can't compile because these errors: [ 98%] Building CXX object src/osgPlugins/ffmpeg/CMakeFiles/osgdb_ffmpeg.dir/FFmpegDecoderVideo.o /home/ale/src/osg/trunk/src/osgPlugins/ffmpeg/FFmpegDecoderVideo.cpp: In member function 'void osgFFmpeg::FFmpegDecoderVideo::publishFrame(double)': /home/ale/src/osg/trunk/src/osgPlugins/ffmpeg/FFmpegDecoderVideo.cpp:228: error: 'img_convert' was not declared in this scope /home/ale/src/osg/trunk/src/osgPlugins/ffmpeg/FFmpegDecoderVideo.cpp: In member function 'void osgFFmpeg::FFmpegDecoderVideo::yuva420pToRgba(AVPicture*, const AVPicture*, int, int)': /home/ale/src/osg/trunk/src/osgPlugins/ffmpeg/FFmpegDecoderVideo.cpp:264: error: 'img_convert' was not declared in this scope make[2]: *** [src/osgPlugins/ffmpeg/CMakeFiles/osgdb_ffmpeg.dir/FFmpegDecoderVideo.o] Error 1 make[1]: *** [src/osgPlugins/ffmpeg/CMakeFiles/osgdb_ffmpeg.dir/all] Error 2 make: *** [all] Error 2 Before updating ffmpeg, I got other ffmpeg related compilation errors. Any hint? My system is GNU/Linux 2.6.26-1-686 Debian Sid, gcc 4.3.1. Regards, -- A. ___ 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 -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem compiling latest trunk, ffmpeg problem
Hi, I'll send some references and code later. See e.g. here: http://lists.mplayerhq.hu/pipermail/libav-user/2008-November/001618.html and http://lists.mplayerhq.hu/pipermail/libav-user/2008-June/000683.html e.g. img_convert vs swscale ---8--- #if defined IPF_USE_SWSCALE int err = sws_scale(ConvertToSaveCtx_, InputFrame_-data, InputFrame_-linesize, 0, cc-height, SaveFrame_-data, SaveFrame_-linesize); #else img_convert((AVPicture *)SaveFrame_, cc-pix_fmt, (AVPicture *)InputFrame_, InputFrameFormat_, cc-width, cc-height); #endif You have to create the swscale context earlier, e.g. ConvertToSaveCtx_ = sws_getContext(ImageFormat_.getWidth(), ImageFormat_.getHeight(), InputFrameFormat_, ImageFormat_.getWidth(), ImageFormat_.getHeight(), SaveFrameFormat_, SWS_BILINEAR, NULL, NULL, NULL); ---8--- One other thing that changed at some stage was this. The version might have to be tuned: #if LIBAVFORMAT_VERSION_INT ((5216) + (18) + 0) url_fclose(FormatContext_-pb); #else url_fclose(FormatContext_-pb); #endif ---8--- jp -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Lightning problem with camera point of view
jonim8or wrote: I have the same problem, with lights switching on and off for one shape in my scene. I have a similar problem in a scene with large flat terrain areas. When there is no vertex in close view it seems that OpenGL can't determine the appropriate lighting for the surface and therefore doesn't. Adding points with normals to the large area solves the problem. HTH, -- Steven Saunderson -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7681#7681 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New ffmpeg plugin checked into svn/trunk
Hi Robert and Jason, Sorry I came late, but did you try osgAL? I worked a bit on it and used osgAL on top of both OpenAL and OpenAL-Soft, and it worked very well. osgAL also contains OpenAL++, which is a layer ontop of OpenAL. That should be interesting to merge what you did with osgAL, isn't it? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Sat, 28 Feb 2009 09:02:57 +0100, Robert Osfield robert.osfi...@gmail.com a écrit: Hi Jason, On Fri, Feb 27, 2009 at 9:14 PM, Jason Daly jd...@ist.ucf.edu wrote: So, is it your intention that the AudioSink interface would be implemented by another plugin (e.g.: an openal plugin)? That's a very good question... how to do we provide an AudioSink, and how far should we go in automating it. Tanguy's original implement has the AudioSink base classes attached to the custom FFmpegImageStream, so you'd read the movie in your application, then at the application level wire up the audio API to this image stream via a custom AuidoSink. My initial plan is to provide a similar solution - have the application wire up its own AudioSink to the AudioStream attached to the loaded ImageStream. The next step after this is open to debate. With integration of ffmpeg plugin I wasn't banking on tackling audio integration, but the fact that ffmpeg doesn't provide means of playing audio means that we have to provide some mechanism, the application wiring above is one solution, but it's not the out of the box solution that we currently have with xine-lib and quicktime so isn't a drop in replacement. To have a drop in replacement we'll need to provide a scheme to automatically provide the AudioSink. My current thoughts on how to provide this are that we could have an AudioSink prototype attached to osgDB::Registry that is NULL by default, but the application developer can assign one, and have this be cloned by the ffmpeg plugin etc. Potentially we could assign it on demand too if one isn't already assigned we could load a plugin such as a OpenAL to provide it. Further down the line perhaps the osgAudio library could provide the AudioSink prototype. I am open to suggestions on how best to address this issue. Two goals are clear - first that app developer should be able to provide their own audio implementation, and secondly a basic audio implementation should be loadable automatically as a fallback. Without the later we can't even consider deprecating the xine-lib and quicktime plugins. 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] Bugs in plugin-gz
Hi guys, i found tow bugs in plugin-gz in osg2.8. 1. ln174 in ReaderWriterGZ.cpp std::ifstream fin(fileName.c_str()); // error code std::ifstream fin(fileName.c_str(), std::ios_base::in|std::ios_base::binary);// should be opend as binary 2. ln260 in ReaderWriterGZ.cpp strm.avail_in = fin.readsome((char*)in, CHUNK); It can't work as expected on ms's implementation.(http://support.microsoft.com/kb/246934/en-us) You can take read for replace. Should i report bugs this way? And any question please me know. with regards, renliwei ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Bugs in plugin-gz
Hi Renliwei Yes bugs can be reported to this list, If you're also providing a fix for a bug you have come across then see this page http://www.openscenegraph.org/projects/osg/wiki/MailingLists/SubmissionsProt ocol It contains the instructions on the correct way to submit the fix or enhancement. __ Gordon Tomlinson mailto:gor...@gordontomlinson.com gor...@gordontomlinson.com IM: mailto:gordon3db...@3dscenegraph.com gordon3db...@3dscenegraph.com http://www.vis-sim.com/ www.vis-sim.com http://www.gordontomlinson.com/ www.gordontomlinson.com __ From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of lwren Sent: Saturday, February 28, 2009 7:39 AM To: osg-users@lists.openscenegraph.org Subject: [osg-users] Bugs in plugin-gz Hi guys, i found tow bugs in plugin-gz in osg2.8. 1. ln174 in ReaderWriterGZ.cpp std::ifstream fin(fileName.c_str()); // error code std::ifstream fin(fileName.c_str(), std::ios_base::in|std::ios_base::binary);// should be opend as binary 2. ln260 in ReaderWriterGZ.cpp strm.avail_in = fin.readsome((char*)in, CHUNK); It can't work as expected on ms's implementation.( http://support.microsoft.com/kb/246934/en-us http://support.microsoft.com/kb/246934/en-us) You can take read for replace. Should i report bugs this way? And any question please me know. with regards, renliwei ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem compiling latest trunk, ffmpeg problem
HI J.P, Thanks for the links and pointers. When I get back to coding I'll have a look at making the changes to swscale. The other route would be to do the colour conversion down on the GPU, but this would have to be just an option. Robert. On Sat, Feb 28, 2009 at 10:38 AM, J.P. Delport jpdelp...@csir.co.za wrote: Hi, I'll send some references and code later. See e.g. here: http://lists.mplayerhq.hu/pipermail/libav-user/2008-November/001618.html and http://lists.mplayerhq.hu/pipermail/libav-user/2008-June/000683.html e.g. img_convert vs swscale ---8--- #if defined IPF_USE_SWSCALE int err = sws_scale(ConvertToSaveCtx_, InputFrame_-data, InputFrame_-linesize, 0, cc-height, SaveFrame_-data, SaveFrame_-linesize); #else img_convert((AVPicture *)SaveFrame_, cc-pix_fmt, (AVPicture *)InputFrame_, InputFrameFormat_, cc-width, cc-height); #endif You have to create the swscale context earlier, e.g. ConvertToSaveCtx_ = sws_getContext(ImageFormat_.getWidth(), ImageFormat_.getHeight(), InputFrameFormat_, ImageFormat_.getWidth(), ImageFormat_.getHeight(), SaveFrameFormat_, SWS_BILINEAR, NULL, NULL, NULL); ---8--- One other thing that changed at some stage was this. The version might have to be tuned: #if LIBAVFORMAT_VERSION_INT ((5216) + (18) + 0) url_fclose(FormatContext_-pb); #else url_fclose(FormatContext_-pb); #endif ---8--- jp -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ 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.org stats
Hi Jason, Ever try DosBox ( http://dosbox.com/information.php?page=0 ) ? Yes, of course, but running it on the real hardware is its own reward. :-) Plus, I hate how nothing in DosBox really runs that well (even something that ran well on a 486DX/33 has trouble in DosBox, and I have to spend about 5 minutes each time finding the right settings...). So I prefer keeping the machines around, getting them out every year or so when I feel like it and having things run exactly like they used to. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com 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
Re: [osg-users] openscenegraph.org stats
Hi Robert, Competing standards are a bad thing as it breaks interoperability and divides the market place into targeting one or other, or both standards. I understand your points, but I don't see how that's different from any market... I could give lots of examples of similar competition: Mac vs Windows vs Linux, diesel vs gasoline, digital cable vs satellite, ... And in all those cases, they either coexist trying to gain higher market share from competitors, or one dies (Blu-ray vs HD-DVD for example) because of market forces (i.e. the consumer decides, sometimes based on merit, sometimes based on other factors). I don't see how we can do anything to change that, we just have to accept it and try to drive OpenGL to take DirectX's market share (which is what we're trying to do, of course). I can also think of many reasons why competition is good, one of which is faster rate of innovation. I think if it weren't Direct3D, if some other standard were competing with OpenGL, we'd be having this same discussion. Even if that other standard was also an open standard (which could happen because of the nature of open standards). So I don't really see the point in discussing it, we can only accept it and try to make the best of it. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com 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
Re: [osg-users] dynamic vertex array howto
Hi Paulo, What am I doing wrong? Do I need to call some method to flag that the array changed? Yep, good intuition: _geometry-dirty(); Also, since you're changing the vertices each frame, set _geometry-setUseDisplayList(false); or otherwise you'll get bad performance. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com 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
Re: [osg-users] New ffmpeg plugin checked into svn/trunk
I understand. And what about using code from osgAL for your needs? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Sat, 28 Feb 2009 14:02:51 +0100, Robert Osfield robert.osfi...@gmail.com a écrit: Hi Sukender, On Sat, Feb 28, 2009 at 11:16 AM, Sukender suky0...@free.fr wrote: Sorry I came late, but did you try osgAL? I worked a bit on it and used osgAL on top of both OpenAL and OpenAL-Soft, and it worked very well. osgAL also contains OpenAL++, which is a layer ontop of OpenAL. That should be interesting to merge what you did with osgAL, isn't it? I haven't tried osgAL. My expectation is that work on refining osgAL would lead to an osgAudio that could then be integrated with the core OSG when it's ready. I don't know how close this might be, and have to defer to yourself and others working on it for information on how close this point might be. I would like an osgAudio to be configurable with different backend audio libraries as well, to enable better portability and flexibility with how end users set things up. The ffmpeg audio requirements are a bit more modest than full OpenAL integration, so doesn't directly push for us to integrate osgAL/osgAudio right away. The work I've done so far is to focus on a the bare minimum functionality required to wire up an audio stream read from a movie plugin to a mechanism for adding support for playing it. I certainly want this mechanism to be compatible with integration with osgAL/osgAudio, but until osgAudio is in the core we can't target just this as a solution. The number of classes involved are pretty small, so I think we can probably get away with a minimalist near-term solution. Then once osgAudio is ready for integration we can look to evolving things so they naturally fit together, be this before or after 2.10. 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] dynamic vertex array howto
Hi, it worked just fine. I guessed so, because I noticed the dirty method not on the geometry but on the vertex array autocomplete, I was asking because sometimes the documentation has only the code listing and not an actual explanation. I guess I could have tried it, but it was also to confirm that I was doing the right thing. Thank you =) Jean-Sébastien Guay wrote: Hi Paulo, What am I doing wrong? Do I need to call some method to flag that the array changed? Yep, good intuition: _geometry-dirty(); Also, since you're changing the vertices each frame, set _geometry-setUseDisplayList(false); or otherwise you'll get bad performance. Hope this helps, J-S ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture corruption in VPB.
Thanks JP, I wasn't aware of that bug. The patch fixed the artifacts I was seeing. Ken. J.P. Delport wrote: Hi, I think you might be running into the corner equalisation bug. Search osg-submissions for the thread vpb - fix for corner equalisation The fix is not yet merged in vpb. jp Ken Sewell wrote: VPB seems to be corrupting parts of its textures. I've attached the file I used to replicate the issue (uv.png). The other two images show the corrupted texels. Hopefully the images make it through my mail system. I built it with the following command: osgdem --terrain --geocentric --whole-globe -t uv.png Is anyone else seeing this artifact? OpenSuSE 11.0/Kubuntu 8.10 64-bit, OpenSceneGraph 2.8.0, VPB svn 953. Ken ___ 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] Is the build complete?
Robert, Thank you for your post and information. I tried another make and here are the results: ... [ 49%] Built target example_osgwidgetstyled [ 49%] Built target example_osgwidgettable [ 49%] Built target example_osgwidgetwindow [ 49%] Built target example_osgpdf [ 49%] Built target example_osgintrospection [ 49%] Built target example_osgviewerGLUT [ 49%] Built target example_osgviewerWX [ 50%] Built target example_osgviewerCocoa Like you said the second build was much faster, 2 min, but again the build process stops right at the 50% mark. Does this look like it completed the build process? Is there some way to check to be sure? Thanks again. --- On Fri, 2/27/09, Robert Osfield robert.osfi...@gmail.com wrote: From: Robert Osfield robert.osfi...@gmail.com Subject: Re: [osg-users] Is the build complete? To: jasonkrup...@yahoo.com, OpenSceneGraph Users osg-users@lists.openscenegraph.org Date: Friday, February 27, 2009, 7:27 AM Hi Jason. Cmake build reports overall progress of the build, so if it says its 50% by it's estimate you are half way through the build of all OSG targets. Do another make and you should see it complete rapidly reaching 100% on the final target. Robert. On Fri, Feb 27, 2009 at 12:36 PM, Jason Rupert jasonkrup...@yahoo.com wrote: New to OpenSceneGraph and working on Mac OSX. I navigated to the OpenSceneGraph folder and typed make The build made it all the way to the following lines: ... Scanning dependencies of target example_osgviewerCocoa [ 49%] Building CXX object examples/osgviewerCocoa/CMakeFiles/example_osgviewerCocoa.dir/ViewerCocoa.mm.o [ 50%] Building CXX object examples/osgviewerCocoa/CMakeFiles/example_osgviewerCocoa.dir/main.m.o cc1obj: warning: command line option -fvisibility-inlines-hidden is valid for C++/ObjC++ but not for ObjC cc1obj: warning: command line option -fvisibility-inlines-hidden is valid for C++/ObjC++ but not for ObjC Linking CXX executable ../../bin/osgviewerCocoa ld warning: duplicate dylib ../../lib/libosg.2.9.0.dylib ld warning: duplicate dylib ../../lib/libosg.2.9.0.dylib [ 50%] Built target example_osgviewerCocoa Did the build complete at 50%? I went to sleep prior to this point, so I wasn't sure if my computer went to sleep or the hard-drive went to sleep prior to it getting to this point. Thanks for any feedback you can provide. Jason ___ 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] Coordinates in VPB database
Pardon the elementary question...I'm a newbie with OSG and VPB. I've search around but haven't found a simple example that illustrates what I'd like to do. Essentially, I've built a VPB whole-earth database and got it loaded in my application. There are two things I'd like to do at this point: 1) Place a model at some point relative to the earth by latitude, longitude, and possibly altitude. 2) Perform an intersection test from the mouse cursor to find the latitude and longitude of the point on the earth's surface that the mouse is intersecting with. In short, if the mouse is hovering over the planet's surface, transform that point from screen coords to world coordinates, and then convert to lat/lon. At this point, given my little experience with OSG at the moment on how to proceed. I'm really not looking for hand-outs...but if you can point me to a simple (easily digestible) example I'd be just as grateful. Thank you in advance! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7694#7694 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Coordinates in VPB database
Re #1: Your whole-earth database is in geocentric (earth-centered XYZ) coordinates. In the class osg::EllipsoidModel (in osg/CoordinateSystemNode) there are functions to convert from lat/long to geocentric and back. You can these to calcuate the XYZ at which to place your model. Then use the XYZ to create an osg/MatrixTransform, and put your model node under it. Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : +1.703.652.4791 On Sat, Feb 28, 2009 at 4:53 PM, B. McMahan osgfo...@tevs.eu wrote: Pardon the elementary question...I'm a newbie with OSG and VPB. I've search around but haven't found a simple example that illustrates what I'd like to do. Essentially, I've built a VPB whole-earth database and got it loaded in my application. There are two things I'd like to do at this point: 1) Place a model at some point relative to the earth by latitude, longitude, and possibly altitude. 2) Perform an intersection test from the mouse cursor to find the latitude and longitude of the point on the earth's surface that the mouse is intersecting with. In short, if the mouse is hovering over the planet's surface, transform that point from screen coords to world coordinates, and then convert to lat/lon. At this point, given my little experience with OSG at the moment on how to proceed. I'm really not looking for hand-outs...but if you can point me to a simple (easily digestible) example I'd be just as grateful. Thank you in advance! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7694#7694 ___ 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] Coordinates in VPB database
EllipsoidModel and CoordinateSystemNode also provide you with a local up vector, which will be a component of the orientation part of your MatrixTransform. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ +1 303 859 9466 _ From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Glenn Waldron Sent: Saturday, February 28, 2009 3:04 PM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Coordinates in VPB database Re #1: Your whole-earth database is in geocentric (earth-centered XYZ) coordinates. In the class osg::EllipsoidModel (in osg/CoordinateSystemNode) there are functions to convert from lat/long to geocentric and back. You can these to calcuate the XYZ at which to place your model. Then use the XYZ to create an osg/MatrixTransform, and put your model node under it. Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : +1.703.652.4791 On Sat, Feb 28, 2009 at 4:53 PM, B. McMahan osgfo...@tevs.eu wrote: Pardon the elementary question...I'm a newbie with OSG and VPB. I've search around but haven't found a simple example that illustrates what I'd like to do. Essentially, I've built a VPB whole-earth database and got it loaded in my application. There are two things I'd like to do at this point: 1) Place a model at some point relative to the earth by latitude, longitude, and possibly altitude. 2) Perform an intersection test from the mouse cursor to find the latitude and longitude of the point on the earth's surface that the mouse is intersecting with. In short, if the mouse is hovering over the planet's surface, transform that point from screen coords to world coordinates, and then convert to lat/lon. At this point, given my little experience with OSG at the moment on how to proceed. I'm really not looking for hand-outs...but if you can point me to a simple (easily digestible) example I'd be just as grateful. Thank you in advance! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7694#7694 ___ 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] dynamic vertex array howto
Skylark wrote: Yep, good intuition: _geometry-dirty(); Also, since you're changing the vertices each frame, set _geometry-setUseDisplayList(false); or otherwise you'll get bad performance. Thanks for the tip about the futility of a display list in this case. I have a sky dome that follows the camera so your comment has helped me. But I can't find any reference to a dirty function. Do you mean dirtyBounds (which I do use) or am I missing something ? There is dirtyDisplayList but this is irrelevant when there is no list. Thanks, -- Steven Saunderson -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7697#7697 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem compiling latest trunk, ffmpeg problem
Hi Robert, I updated ffmpeg a month and a half ago in order to be able to encode videos to h264, so I need that version, I can't downgrade it. It is SVN-r17646. I agree on not using deprecated functions. Best regards, -- A. On Sat, Feb 28, 2009 at 3:33 AM, Robert Osfield robert.osfi...@gmail.com wrote: HI Alejandro, Which version of ffmpeg do you have installed? As J.P. mentioned ffmpeg is a bit of moving target and were' only just getting into learning about FFmpeg foibles. We'll probably need to add version checking into our FindFFmpeg.cmake to avoid these issue. Also migrating the code across from not using deprecated functions will be a possible solution. Adopting use ffmpeg suggest use of swscale isn't though as it's GPL'd, so we may have to create our own local equivalents for colour conversion. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] dynamic vertex array howto
Hi Steven, Thanks for the tip about the futility of a display list in this case. I have a sky dome that follows the camera so your comment has helped me. But I can't find any reference to a dirty function. Do you mean dirtyBounds (which I do use) or am I missing something ? There is dirtyDisplayList but this is irrelevant when there is no list. Sorry for the confusion, I meant dirtyDisplayList() if you're using display lists and you change the vertex data not too often. If it changes every frame then just disable display lists and there is no dirty needed. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com 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
Re: [osg-users] Problem executing a few of the tests...
Ugh... I just checked my PATH and noticed OpenSceneGraph/bin was missing, so I added that and all the Examples ran. It is the simple things... --- On Sat, 2/28/09, Jason Rupert jasonkrup...@yahoo.com wrote: From: Jason Rupert jasonkrup...@yahoo.com Subject: [osg-users] Problem executing a few of the tests... To: osg-users@lists.openscenegraph.org Date: Saturday, February 28, 2009, 11:49 PM Well, I am slowly getting to a point to where I am able to execute the OpenSceneGraph examples. I ran the bat file and a few of them executed with no problems, but I received the following output: $ sh ./runexamples.bat osgversion OpenSceneGraph Library 2.9.0 osgunittests ./runexamples.bat: line 5: osgunittests: command not found ./runexamples.bat: line 6: osgunittests: command not found ./runexamples.bat: line 7: osgunittests: command not found osglauncher ... ./runexamples.bat: line 196: osgtexturerectangle: command not found osgvertexprogram ./runexamples.bat: line 199: osgvertexprogram: command not found osgwindows ./runexamples.bat: line 202: osgwindows: command not found $ I am guessing this is not expected, so just curious about what I could have missed. Thanks again for any feedback. ___ 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
