Re: [osg-users] Problems with non-resized NPOT textures and trilinear min filter
Hi Dan, On Wed, Feb 25, 2009 at 10:02 PM, Gilbert, Daniel R. daniel.r.gilb...@saic.com wrote: Are others able to reproduce this same behavior using my attached sample? Just tried the test models on my Kubuntu 8.10/Gefore8800GTS cards and I get: npot_skydome_linear_noresize.osg works. npot_skydome_trilinear_noresize.osg fails. npot_skydome_trilinear_resize.osg works. I also don't get any OpenGL errors when npot_skydome_trilinear_noresize.osg fails. Any thoughts on how to attempt a fix? It could well be a driver issue, but also might be an OSG issue... When you have a model without mipmaps you have to generate them, either by using gluScaleImage or using the one of the two hardware mipmap extension. It'd be worth digging into osg::Texture/Texture2D to see what code paths it's taking to ask for the mipmap generation. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problems with VPB and DTED data.
Hi, Sewell, Kenneth R Civ USAF AFMC AFRL/RYZW wrote: what OS are you using? What version of GDAL? On Linux I've not had a problem reading .dt? files. OpenSuSE Linux 11.0, VPB rev 953, OSG 2.8.0 and GDAL 1.6.0. I'm not sure how it's working for you if you're using the version of VPB that checks extensions. Did you modify GDAL to report the .dt? file extensions? You are right, I must have used an earlier version of vpb that did read my files (I have a working DB with the input data as DTED). The newest VPB ignores my .dt2 files. jp Ken Sewell, Kenneth R Civ USAF AFMC AFRL/RYZW wrote: It seems that VPB (SVN revision 953) won't accept DTED data. Looking at the VPB code, VPB gets a list of GDAL supported extensions (and adds a few that GDAL doesn't report). Looking at GDAL, it fails to report the DTED extensions (.dt0, .dt1, .dt2) via the GetMetadataItem(DMD_EXTENSIONS) method. The result is VPB reports that DTED files are not supported. I don't know if the fix belongs in GDAL or VPB, but as a quick work-around add the following lines to the end of the VPB System constructor (src/vpb/System.cpp): addSupportedExtension(dt0, Source::IMAGE | Source::HEIGHT_FIELD, DTED Level 0); addSupportedExtension(dt1, Source::IMAGE | Source::HEIGHT_FIELD, DTED Level 1); addSupportedExtension(dt2, Source::IMAGE | Source::HEIGHT_FIELD, DTED Level 2); Ken. ___ 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 ___ 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] osgswig: iterating over a vertex array
Thanks for the response. I'll try tackling it with ctypes, then. Not an elegant solution, but I think I can get it to work. Randolph On Feb 25, 2009, at 11:35 PM, Gerwin de Haan wrote: Hi Randolph, this is a typical problem of (python) wrappers; the getVertexArray returns a general Array, which is currently not wrapped. The trick would be to somewhere cast the general Array back to its specific type in Python, e.g. a Vec3Array. We've used some of these tricks in the wrappings themselves by a dynamic_cast through C++ run-time type information (not accessible to users), and some you can access yourself, e.g. osg.Node.asLOD . To fix your particular problem we might introduce extensions to Array such as osg.Array.asVec3Array etc, or better would be to automatically let SWIG convert all returning values of Array to its real type. In any case this means diving into SWIG specifics. I'll post this as an issue on the list (http://code.google.com/p/osgswig/issues/detail?id=27), but I cannot give guarantees when it will be picked up. Gerwin On Thu, Feb 26, 2009 at 5:19 AM, Randolph Fritz rfr...@u.washington.edu wrote: I'm writing a prototype OSG to Radiance exporter in Python. I've got to the point of code that iterates over all geodes in the scene graph. Problem is--then what? Is the only way to read the elements of the arrays ctype and pointers? Or is there something a bit simpler and safer? Perhaps-relevant bit of code: def apply_Geode(self,ge): for i in range(ge.getNumDrawables()): geom = ge.getDrawable(i).asGeometry() if geom: arr = geom.getVertexArray() for i in range(arr.getNumElements()): # This doesn't seem to work--what does? arr.accept(i,self.val) -- Randolph Fritz design machine group architecture department university of washington rfr...@u.washington.edu ___ 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] How to use setSampleRatio on terrain generated with VPB?
Hi, have a look at the osgmultitexturecontrol example. Search for setSampleRatio. jp David Karlsson wrote: Hello, I'm having problem with my terrain generated using Virtual planet builder. Basically, what I want to do is to control the resolution/lod-scale of the rendered terrain. If I simply add the node to the scene graph, the terrain is rendered using the most detailed lod-level very far away from the camera resulting in a lot of unnecessary geometry: http://www.student.itn.liu.se/~davka531/render_wireframe2.jpg I found out that I can control this by using setLODScale(...) on the camera, but this will unfortunately change the behaviour of all lod-nodes in the scene - not only the level of detail of the terrain. Instead I tried to use setSampleRatio(...) on the terrain node. The problem in this case is that I can't find a osgTerrain::Terrain node in the .ive file generated from vpb. All I got are osgTerrain::TerrainTile nodes, and I can't get the osgTerrain::TerrainTile::getTerrain(...) functions to return a valid pointer. What have I missed? Aren't TerrainTiles supposed to be connected to a Terrain node? Some addtional info: The command used to build the terrain: osgdem.exe --geocentric --TERRAIN --PagedLOD --max-visible-distance-of-top-level 20 --layer 0 -t dir1 --layer 1 -t dir2 --layer 2 -t dir3 -d heightDir -l 10 -o terrain.ive OSG version: 2.8.0 VPB version: 0.9.9 (revision 953) Finally, I would like to say thank you to the osg community for helping me out with some of my previous posts. Very appreciated! /David ___ 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] OFT: Interesting commentary of the future of OpenGL
Hi Sukender, On Thu, Feb 26, 2009 at 12:15 AM, Sukender suky0...@free.fr wrote: Okay, so admitting we're dropping D3D... Well it's hard to drop something that you have picked up yet :-) In terms of making a D3D backend a goal, as mentioned in my earlier post this has some pros, and lots of cons/risks for the project. Given we are already talking about taking on a risk API refactoring over the next couple of years I'd suggest we should keep conservative and avoid taking on further extra risks/loads. If the API refactoring targeting API's already close to use goes well then one could consider taking further steps w.r.t rendering alternate back ends. Waiting a year or two more will also see some wider market trends work themselves out, there is a chance that D3D will actually be less compelling even under Windows. If we do a good job on helping the hardware vendors properly support OpenGL with robust and feature rich drivers then this will change the landscape as well. As an interim solution the OpenGL subset - Direct3D is something that could be investigated independent of other OSG efforts in coping with new API's. Such an approach could work with the existing OSG as well as future revs. Such a solution might also buy us more time. Will the problem be similar for OpenGL-ES/OpenCL (I mean raytracing and such for OpenCL)? This is not ironic: I don't know much about these. But I wonder if we would have the same abstraction problem with them. I was thinking that if OSG 3 would support these, then why not others (such as D3D)... However, if they're quite close to OpenGL, then yes, the situation is different. We thus could think about OSG not as API agnostic, but as Khronos API agnostic or such. Thoughts? The Khronos API's are all part of family which means language and concepts as well as API style, and end user culture all fit in well together. This includes similarities in GLSL implementations, method naming, coordinate system conventions (for instance where 0,0 is on a viewport or a texture). This should mark it easier to port/support to OpenGL ES, OpenGL 3.0, and OpenCL in addition to OpenGL 1.x + 2.x. This are the soft targets for us - being Khronos API agnostic would certainly be a smaller step than being abstracting totally from the HAL API. Smaller steps are less risky, and in the case of OpenGL ES and OpenCL the benefits of opening out new platforms and new ways of working are very significant - far more significant than any D3D port would ever provide. Less risk, greater benefits, pretty easy decision really :-) This doesn't mean we should look at trying to resolve some of the pressures to support D3D that some existing OSG are seeing. For this I'd see a three pronged approach as being helpful : 1) Campaign individually and as group publicly support of OpenGL and it's promote its benefits. 2) Publicly put pressure on the hardware vendors to better support OpenGL w.r.t driver quality and features. 3) Work with hardware vendors on a suite of unit tests that can test the range of OpenGL features. 4) Come up with compelling benchmarking suite that shows off OSG/OpenGL. 5) Coordinating between us on best practices to sell OpenGL to skeptical clients. 6) Investigate the possibility of using OpenGL subset - Direct3D layer. 1+2 are related, so it would be good to coordinate this, the carrot and stick. Could we start up working group within this community to spear head this? Is this effort works well then we'll get better quality drivers and the visibility of widespread support will help convince those won over my MS marketing that D3D is not necessary or compelling. 3+4 are also related - they are engineering responses to the ongoing problem of driver quality and getting the OSG used actively as a tool for testing and benchmarking. Again a working group without the community could be formed to look at this. Perhaps we might even be able to get funding from Khronos and other bodies to undertake some of this effort. 5 is just us talking really, but it's not a topic that we often chat about. Perhaps putting up some pages on the wiki would help coordinate final conclusions. 6 is a quite different take, again it's an engineering solution. A 3rd party lib to do this would be least work for us, ideally an open source one. Does anyone know of something like this? So... over to your guys, volunteers, suggestions? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to use setSampleRatio on terrain generated with VPB?
Hi, The problem is that I can't find any osgTerrain:Terrain node in the file generated by VPB. The following command always returns NULL: osgTerrain::Terrain* testNode = findTopMostNodeOfTypeosgTerrain::Terrain(terrainNode); /David -Ursprungligt meddelande- Från: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] För J.P. Delport Skickat: den 26 februari 2009 10:20 Till: OpenSceneGraph Users Ämne: Re: [osg-users] How to use setSampleRatio on terrain generated with VPB? Hi, have a look at the osgmultitexturecontrol example. Search for setSampleRatio. jp David Karlsson wrote: Hello, I'm having problem with my terrain generated using Virtual planet builder. Basically, what I want to do is to control the resolution/lod-scale of the rendered terrain. If I simply add the node to the scene graph, the terrain is rendered using the most detailed lod-level very far away from the camera resulting in a lot of unnecessary geometry: http://www.student.itn.liu.se/~davka531/render_wireframe2.jpg I found out that I can control this by using setLODScale(...) on the camera, but this will unfortunately change the behaviour of all lod-nodes in the scene - not only the level of detail of the terrain. Instead I tried to use setSampleRatio(...) on the terrain node. The problem in this case is that I can't find a osgTerrain::Terrain node in the .ive file generated from vpb. All I got are osgTerrain::TerrainTile nodes, and I can't get the osgTerrain::TerrainTile::getTerrain(...) functions to return a valid pointer. What have I missed? Aren't TerrainTiles supposed to be connected to a Terrain node? Some addtional info: The command used to build the terrain: osgdem.exe --geocentric --TERRAIN --PagedLOD --max-visible-distance-of-top-level 20 --layer 0 -t dir1 --layer 1 -t dir2 --layer 2 -t dir3 -d heightDir -l 10 -o terrain.ive OSG version: 2.8.0 VPB version: 0.9.9 (revision 953) Finally, I would like to say thank you to the osg community for helping me out with some of my previous posts. Very appreciated! /David ___ 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] openscenegraph.org stats
Hi All, At the end of last week I ask Jose-Luis about web stats, and the boy came good, adding awstats to the new virtual server, it's only been running since Sunday, so the logs are only a quick snapshot so far, but still interesting no less. First up the operating systems that people are accessing the site from: Windows 154463 60.7 % Windows XP 116617 45.8 % Windows NT 18640.7 % Windows Me 138 0 % Windows Vista 25972 10.2 % Windows CE 10 0 % Windows 98 122 0 % Windows 95 22 0 % Windows 200374992.9 % Windows 200022120.8 % Windows 3.xx7 0 % BSD 281 0.1 % FreeBSD 281 0.1 % Linux 37600 14.7 % Ubuntu 13965 5.4 % Suse27751 % Red Hat 563 0.2 % Mandriva (or Mandrake) 337 0.1 % Fedora 37321.4 % Debian 35791.4 % Centos 462 0.1 % GNU Linux (Unknown or unspecified distribution) 12187 4.7 % Macintosh 12800 5 % Mac OS X12787 5 % Mac OS 13 0 % Others 49212 19.3 % Unknown 48799 19.1 % Sun Solaris 174 0 % Irix162 0 % Symbian OS 74 0 % Unknown Unix system What is pretty stunning is that Window only accounts for 60% of people who visit our website, with only 10% using Vista. Linux comes in at near 15%, while OSX comes in at 5%. The rest of the identifiable platforms are pretty negligible, but the Unknown is massive at 19.1% - which platforms these would map we can only guess. Anyone any ideas about what platforms this Unknown are likely to be? -- Next up the browser stats are pretty revealing too: Firefox No 108762 42.6 % MS Internet ExplorerNo 67805 26.6 % Mozilla No 30931 12.1 % Subversion client No 21572 8.4 % Safari No 14097 5.5 % Opera No 78843 % Konqueror No 21600.8 % CurlYes 508 0.1 % EpiphanyNo 256 0.1 % Unknown ? 253 0 % Others That is a pretty stunning victory for Firefox, adding on Mozilla the total is 54.7%. Also don't forget that svn accounts for 8.4%, so regular browser us is actaully higher than this still. The once dominant browser family of Internet explorer picks up second place, but has less than number of users than the Firefox/Mozilla family. -- Finally the stats for number visitors/hits are: Reported period Month Feb 2009 First visit 22 Feb 2009 - 07:15 Last visit 26 Feb 2009 - 10:50 Unique visitors Number of visitsPages HitsBandwidth Viewed traffic *4786 8060 (1.68 visits/visitor) 72397 (8.98 Pages/Visit) 254795 (31.61 Hits/Visit) 40.30 GB (5242.26 KB/Visit) -- What is clear from this picture is that the OSG community is very different to average computer user, which is not too surprising, but just how different is to me. Or perhaps we just aren't that different, and that perhaps as we aren't a world away from w3schools stats for Firefox adoption: http://www.w3schools.com/browsers/browsers_stats.asp Perhaps this strong showing of non windows OS's and non IE browsers in the graphics community might be useful in helping win over clients that go demanding MS specific solutions. The tide has turned. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Non-standard name for 3rdParty disables FreeType plugin
Hi Paul + Mattias,
I just checked what CMake 2.6.2 has for it's FindFreetype.cmake and
the list of vars is:
# FREETYPE_LIBRARIES, the library to link against
# FREETYPE_FOUND, if false, do not try to link to FREETYPE
# FREETYPE_INCLUDE_DIRS, where to find headers.
# This is the concatenation of the paths:
# FREETYPE_INCLUDE_DIR_ft2build
# FREETYPE_INCLUDE_DIR_freetype2
The OSG's CMakeModules/FindFreeType.cmake (note case difference) also
only defines FREETYPE_INCLUDE_DIRS.
And the CMakeModules/Find3rdpartyDependencies.cmake 's FreeType entries read:
FIND_DEPENDENCY(FREETYPE ft2build.h
freetype;freetype234;freetype234MT;freetype235 ${OSG_3RDPARTY_BIN}
_D)
IF(FREETYPE_FOUND)
#forcing subsequent FindFreeType stuff to not search for
other variables kind of a hack
SET(FREETYPE_INCLUDE_DIR_ft2build ${FREETYPE_INCLUDE_DIR}
CACHE PATH )
SET(FREETYPE_INCLUDE_DIR_freetype2 ${FREETYPE_INCLUDE_DIR}
CACHE PATH )
MARK_AS_ADVANCED(FREETYPE_INCLUDE_DIR_ft2build
FREETYPE_INCLUDE_DIR_freetype2)
ENDIF(FREETYPE_FOUND)
I can't find any reference to FREETYPE_INCLUDE_DIR anywhere. The
Find3rdPartyDependnencies.cmake doesn't contain a
FREETYPE_INCLUDE_DIRS either, but perhaps the FindFreeType.cmake
should later set this.
Robert.
On Thu, Feb 26, 2009 at 12:46 AM, Mattias Helsing helsin...@gmail.com wrote:
Hi Paul,
I think I've seen this reported before so I decided to review the
files involved. I'm not at a windows machine so can't test this now
but in osgPlugins/freetype/CMakeLists.txt it FREETYPE_INCLUDE_DIRS
which might be right on platforms other than windows, but when using
3rdParty deps it should read FREETYPE_INCLUDE_DIR I think. I'll check
this tomorrow when at a windows machine.
I discovered a flaw when using vc90 and my binaries. They have
freetype-2.3.7 which isn't searched for by
Find3rdPArtyDependencies.cmake. Will post a submission for that
tomorrow.
cheers
Mattias
On Wed, Feb 25, 2009 at 11:23 PM, Paul Martz pma...@skew-matrix.com wrote:
(Well, new to me at least, maybe other have seen this?)
While trying to set up a new build dir, I obtained 3rdParty dependencies for
both VS8 and VS9 and made them siblings to my OpenSceneGraph directory, and
named one of them 3rdParty-VS8 and the other 3rdParty-VS9. While running
CMake for OSG, I set the ACTUAL_3RDPARTY_DIR to 3rdParty-VS8, configured,
and went into Visual Studio.
Oddly, the FreeType plugin project was missing - CMake didn't create it, as
if it couldn't find the FreeType library or include dir. I went back into
CMake and verified it had found the FreeType library and include, but for
some reason it refused to create the VS project file.
I resolved the issue by renaming 3rdParty-VS8 to simply 3rdParty.
Any idea why the non-standard name for the 3rdParty dir would cause this
failure?
Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com
+1 303 859 9466
___
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] How to use setSampleRatio on terrain generated with VPB?
Hi David, If there isn't a Terrain node decorating your terrian just add one, then add your paged terrain to this. Also w.r.t distant tiles being rendered at full res, this shouldn't be happening as VPB generates a hierarchical paged database, with PagedLOD being the central bit of glue that makes the paging work - PagedLOD is a LOD. My guess is that everything may well be working just fine, just your expectations are off. Also when doing benchmarking of paged database only do it in meshed mode, as modern drivers render wireframe very slowly compared to meshed ones. Wireframe is good just for double checking what the paging is doing. As a general note I'd also add the VPB by default does build pretty high res databases, you can temper this in the original build or at runtime via the LODScale and SampleRatio, personally I'd recommend the later as it allows you to trade performance for quality on hardware that can't handle the high res datasets, but on high end hardware you can let everything run at full res. Robert. On Thu, Feb 26, 2009 at 9:48 AM, David Karlsson david.karls...@foi.se wrote: Hi, The problem is that I can't find any osgTerrain:Terrain node in the file generated by VPB. The following command always returns NULL: osgTerrain::Terrain* testNode = findTopMostNodeOfTypeosgTerrain::Terrain(terrainNode); /David -Ursprungligt meddelande- Från: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] För J.P. Delport Skickat: den 26 februari 2009 10:20 Till: OpenSceneGraph Users Ämne: Re: [osg-users] How to use setSampleRatio on terrain generated with VPB? Hi, have a look at the osgmultitexturecontrol example. Search for setSampleRatio. jp David Karlsson wrote: Hello, I'm having problem with my terrain generated using Virtual planet builder. Basically, what I want to do is to control the resolution/lod-scale of the rendered terrain. If I simply add the node to the scene graph, the terrain is rendered using the most detailed lod-level very far away from the camera resulting in a lot of unnecessary geometry: http://www.student.itn.liu.se/~davka531/render_wireframe2.jpg I found out that I can control this by using setLODScale(...) on the camera, but this will unfortunately change the behaviour of all lod-nodes in the scene - not only the level of detail of the terrain. Instead I tried to use setSampleRatio(...) on the terrain node. The problem in this case is that I can't find a osgTerrain::Terrain node in the .ive file generated from vpb. All I got are osgTerrain::TerrainTile nodes, and I can't get the osgTerrain::TerrainTile::getTerrain(...) functions to return a valid pointer. What have I missed? Aren't TerrainTiles supposed to be connected to a Terrain node? Some addtional info: The command used to build the terrain: osgdem.exe --geocentric --TERRAIN --PagedLOD --max-visible-distance-of-top-level 20 --layer 0 -t dir1 --layer 1 -t dir2 --layer 2 -t dir3 -d heightDir -l 10 -o terrain.ive OSG version: 2.8.0 VPB version: 0.9.9 (revision 953) Finally, I would like to say thank you to the osg community for helping me out with some of my previous posts. Very appreciated! /David ___ 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 ___ 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] FBO and WGL_ARB_render_texture
hi Robert, I get the same version string: OpenGL version string: 2.1.2 NVIDIA 177.82 Yet I most probably have a less recent Graphics Card than you : I have a NVidia Quadro FX 550 Do you think this is the reason? Why doesn't it occur every time? On Wed, Feb 25, 2009 at 9:20 PM, Robert Osfield robert.osfi...@gmail.comwrote: Hi Loic, I've just done a testing of using --hdr in osgprerender (--fbo is the default where supported) and it works fine. I'm using Kubuntu 8.10 + Geforce 8800GTS. glxinfo outputs lots of stuff including the version info: OpenGL version string: 2.1.2 NVIDIA 177.82 Check which version you are using, as it does sounds like you are encountering a bug. I'd also be worth checking what glxinfo reports as being supported - make sure it support HDR + FBO's. WGL_render_texture isn't required for FBO, and do export OSG_NOTIFY_LEVEL=DEBUG on my system doesn't produce any checks. The fact that your system is reporting this (benign) warning suggest to me that RenderStage::runCameraSetUp() has failed to set up an FBO render target, and is fallback back to using pbuffer. I don't think pbuffer can support HDR. Robert. - Show quoted text - On Wed, Feb 25, 2009 at 6:39 PM, Simon Loic simon1l...@gmail.com wrote: hi all, I have some probelms when using FBO. I have an Nvidia Quadro Fx 550, on an ubuntu 8.10 distribution when doing osgprerender --hdr --fbo cow.osg Sometimes I get the following output: RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd With OSG_NOTIFY_LEVEL=DEBUG i get: WGL_ARB_render_texture is not supported. I find it strange that WGL_render_texture has to be supported as I thought it was a Windows only extension. Does this means that FBO can not be used on linux? I don't know why I get this message sometimes but not every time. BTW In my osg application I am doing FBO based screenshot, and I have the same behaviour: sometimes it works perfectly and dometimes I get this message and I get a black image. Thanks guys -- Loïc Simon ___ 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 -- Loïc Simon ___ 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
Nice to see this kind of results. (I'm just a bit disapointed since I'm an Opera-conviced user ;p ) Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 26 Feb 2009 11:06:51 +0100, Robert Osfield robert.osfi...@gmail.com a écrit: Hi All, At the end of last week I ask Jose-Luis about web stats, and the boy came good, adding awstats to the new virtual server, it's only been running since Sunday, so the logs are only a quick snapshot so far, but still interesting no less. First up the operating systems that people are accessing the site from: Windows 154463 60.7 % Windows XP 116617 45.8 % Windows NT 18640.7 % Windows Me 138 0 % Windows Vista 25972 10.2 % Windows CE 10 0 % Windows 98 122 0 % Windows 95 22 0 % Windows 200374992.9 % Windows 200022120.8 % Windows 3.xx7 0 % BSD 281 0.1 % FreeBSD 281 0.1 % Linux 37600 14.7 % Ubuntu 13965 5.4 % Suse27751 % Red Hat 563 0.2 % Mandriva (or Mandrake) 337 0.1 % Fedora 37321.4 % Debian 35791.4 % Centos 462 0.1 % GNU Linux (Unknown or unspecified distribution) 12187 4.7 % Macintosh 12800 5 % Mac OS X12787 5 % Mac OS 13 0 % Others49212 19.3 % Unknown 48799 19.1 % Sun Solaris 174 0 % Irix162 0 % Symbian OS 74 0 % Unknown Unix system What is pretty stunning is that Window only accounts for 60% of people who visit our website, with only 10% using Vista. Linux comes in at near 15%, while OSX comes in at 5%. The rest of the identifiable platforms are pretty negligible, but the Unknown is massive at 19.1% - which platforms these would map we can only guess. Anyone any ideas about what platforms this Unknown are likely to be? -- Next up the browser stats are pretty revealing too: Firefox No 108762 42.6 % MS Internet ExplorerNo 67805 26.6 % Mozilla No 30931 12.1 % Subversion client No 21572 8.4 % Safari No 14097 5.5 % Opera No 78843 % Konqueror No 21600.8 % CurlYes 508 0.1 % EpiphanyNo 256 0.1 % Unknown ? 253 0 % Others That is a pretty stunning victory for Firefox, adding on Mozilla the total is 54.7%. Also don't forget that svn accounts for 8.4%, so regular browser us is actaully higher than this still. The once dominant browser family of Internet explorer picks up second place, but has less than number of users than the Firefox/Mozilla family. -- Finally the stats for number visitors/hits are: Reported period Month Feb 2009 First visit 22 Feb 2009 - 07:15 Last visit26 Feb 2009 - 10:50 Unique visitors Number of visitsPages HitsBandwidth Viewed traffic * 4786 8060 (1.68 visits/visitor) 72397 (8.98 Pages/Visit)254795 (31.61 Hits/Visit)40.30 GB (5242.26 KB/Visit) -- What is clear from this picture is that the OSG community is very different to average computer user, which is not too surprising, but just how different is to me. Or perhaps we just aren't that different, and that perhaps as we aren't a world away from w3schools stats for Firefox adoption: http://www.w3schools.com/browsers/browsers_stats.asp Perhaps this strong showing of non windows OS's and non IE browsers in the graphics community might be useful in helping win over clients that go demanding MS specific solutions. The tide has turned. 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] How to use setSampleRatio on terrain generated with VPB?
Hi,
from the example:
osgTerrain::Terrain* terrain =
findTopMostNodeOfTypeosgTerrain::Terrain(rootnode);
if (!terrain)
{
terrain = new osgTerrain::Terrain;
terrain-addChild(rootnode);
rootnode = terrain;
}
terrain-setSampleRatio(sampleRatio);
jp
Robert Osfield wrote:
Hi David,
If there isn't a Terrain node decorating your terrian just add one,
then add your paged terrain to this.
Also w.r.t distant tiles being rendered at full res, this shouldn't be
happening as VPB generates a hierarchical paged database, with
PagedLOD being the central bit of glue that makes the paging work -
PagedLOD is a LOD. My guess is that everything may well be working
just fine, just your expectations are off.
Also when doing benchmarking of paged database only do it in meshed
mode, as modern drivers render wireframe very slowly compared to
meshed ones. Wireframe is good just for double checking what the
paging is doing.
As a general note I'd also add the VPB by default does build pretty
high res databases, you can temper this in the original build or at
runtime via the LODScale and SampleRatio, personally I'd recommend the
later as it allows you to trade performance for quality on hardware
that can't handle the high res datasets, but on high end hardware you
can let everything run at full res.
Robert.
On Thu, Feb 26, 2009 at 9:48 AM, David Karlsson david.karls...@foi.se wrote:
Hi,
The problem is that I can't find any osgTerrain:Terrain node in the file
generated by VPB.
The following command always returns NULL:
osgTerrain::Terrain* testNode =
findTopMostNodeOfTypeosgTerrain::Terrain(terrainNode);
/David
-Ursprungligt meddelande-
Från: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] För J.P. Delport
Skickat: den 26 februari 2009 10:20
Till: OpenSceneGraph Users
Ämne: Re: [osg-users] How to use setSampleRatio on terrain generated with VPB?
Hi,
have a look at the osgmultitexturecontrol example. Search for setSampleRatio.
jp
David Karlsson wrote:
Hello,
I'm having problem with my terrain generated using Virtual planet builder.
Basically, what I want to do is to control the resolution/lod-scale of the
rendered terrain. If I simply add the node to the scene graph, the terrain is
rendered using the most detailed lod-level very far away from the camera
resulting in a lot of unnecessary geometry:
http://www.student.itn.liu.se/~davka531/render_wireframe2.jpg
I found out that I can control this by using setLODScale(...) on the camera,
but this will unfortunately change the behaviour of all lod-nodes in the scene
- not only the level of detail of the terrain.
Instead I tried to use setSampleRatio(...) on the terrain node. The problem in
this case is that I can't find a osgTerrain::Terrain node in the .ive file
generated from vpb. All I got are osgTerrain::TerrainTile nodes, and I can't
get the osgTerrain::TerrainTile::getTerrain(...) functions to return a valid
pointer. What have I missed? Aren't TerrainTiles supposed to be connected to a
Terrain node?
Some addtional info:
The command used to build the terrain:
osgdem.exe --geocentric --TERRAIN --PagedLOD
--max-visible-distance-of-top-level 20 --layer 0 -t dir1 --layer 1
-t dir2 --layer 2 -t dir3 -d heightDir -l 10 -o terrain.ive
OSG version: 2.8.0
VPB version: 0.9.9 (revision 953)
Finally, I would like to say thank you to the osg community for helping me out
with some of my previous posts. Very appreciated!
/David
___
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
___
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
Re: [osg-users] FBO and WGL_ARB_render_texture
On Thu, Feb 26, 2009 at 10:53 AM, Simon Loic simon1l...@gmail.com wrote: hi Robert, I get the same version string: OpenGL version string: 2.1.2 NVIDIA 177.82 Yet I most probably have a less recent Graphics Card than you : I have a NVidia Quadro FX 550 Do you think this is the reason? I'm not familiar with the FX 550 so can't comment on it's capabilities. Have a look through what glxinfo reports. Why doesn't it occur every time? I can't answer this. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] New ffmpeg plugin checked into svn/trunk
Hi All, Thanks to the Tanguy Fautre at Aris Technlogies we have a shinny new ffmpeg, which this week I got ported to Linux and checked in to svn/trunk. The code is still under development, including the Cmake support which right now only support a pkg-config path so isn't yet ready for prime-time, but it's certainly ready for early adopters to dive and fixing up the remaining items like Cmake more generalised support. One area that works on Tanguy's original code, but not yet the ffmpeg plugin that I put together is audio, so if you run: osgmovie -e ffmpeg mymovie.mpg You'll only get video up on screen, not audio will play. Tanguy's original code subclassed from osg::ImageStream to provide a mechanism for wiring up a audio sink for the audio streams that ffmpeg reads from the movie file. Our previous movie plugins handled the audio automatically so didn't have to deal with this, but ffmpeg doesn't deal with rendering of video or audio so it's up to us. The OSG itself doesn't have audio built in yet, so we either graft this support into the plugin or add the audio in separately. The later route would be the most flexible route, Tanguy's extensions of ImageStream enable this type of interoperability so my plan is to push these extensions directly into osg:ImageStream. This doesn't solve the problem of providing the audio sink though... only possibility would be to have osgmovie use something like SDL to provide the audio, or we could even provide an option in the plugin to use SDL. SDL on macs plays silly games with Cocoa though so you end up odd dependencies even if you don't use video so I'm not convinced this is a clean solution as it could be. So members of the community, what audio libraries should be on our list of targets? Do we even go as far as integrating osgAL/osgAudio directly into the core just to enable this plugin to gain the option of audio? I'm not expecting 100% solutions right away, and am happy experimenting with interim solutions like SDL just to get the audio side tested, then hopefully with better insight into the possible solutions that the community spots we'll then be able to come up with a good path forwards. Another aspect to this plugin that is a little intriguing is that it's a cross platform solution, and it works fine under 32bit and 64bit as far as aware. This later capability means that under OSX 64bit it will work out of the box unlike the present Quicktime movie plugin, so it could avoid one of the stumbling blocks for doing 64bit build under OSX (the other stumbling block is Apple crappy decision to not port Carbon to 64bit). Personally I'd much prefer to be able to maintain a single cross platform video solution instead of three plugins, two of which are platform specific. It's less code to develop, test, debug and maintain, and it also keeps the user base working on the same consistent tools so those tools get far more testing and refinement than what happens when you have disparate solutions. So... could we even deprecate the xine-lib and Quicktime plugins completely? Thanks in advance for your help in refining the Cmake support, suggestions on audio and general thoughts. Robert. ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Nice to see another way to play videos on differen plattforms, thanks for the contribution! Robert Osfield schrieb: So members of the community, what audio libraries should be on our list of targets? Do we even go as far as integrating osgAL/osgAudio directly into the core just to enable this plugin to gain the option of audio? Don't know what ffmpeg needs, I used RtAudio for crossplattform playback + recording of audio. It's basically one base-class with different backends per platform: http://www.music.mcgill.ca/~gary/rtaudio/ Another aspect to this plugin that is a little intriguing is that it's a cross platform solution, and it works fine under 32bit and 64bit as far as aware. This later capability means that under OSX 64bit it will work out of the box unlike the present Quicktime movie plugin, so it could avoid one of the stumbling blocks for doing 64bit build under OSX (the other stumbling block is Apple crappy decision to not port Carbon to 64bit). Everybody claims that the current quicktime-plugin + carbon window implementation sucks, because it can't handle 64bit, but nobody wants to spend time and/or money fixing this. I am currently in progress developing GraphicsWindowCocoa, so perhaps we have an alpha-quality-implementation by the end of this week. Without a true 64bit version of Quicktime which works on Win+Mac it doesn't make sense to update/replace the plugin by QTKit. (Currently, for 64bit, the 64bit app communicates with a 32bit background process, which provides the video-stream, and it lacks some of features + is not crossplattform) Personally I'd much prefer to be able to maintain a single cross platform video solution instead of three plugins, two of which are platform specific. It's less code to develop, test, debug and maintain, and it also keeps the user base working on the same consistent tools so those tools get far more testing and refinement than what happens when you have disparate solutions. So... could we even deprecate the xine-lib and Quicktime plugins completely? Currently, I am against deprecating the quicktime-lib, because: 1.) it handles images default for OS X 2.) it handles live-video 3.) it handles movies ffmpg can't handle 4.) it has no dependencies on Mac OS X But if you want, go deprecate it, interested users can fork + maintain a copy of it. Just my 2cents. cheers, Stephan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmmhrwACgkQJXw1lkNcI04gowCgr0RajxtZ0TmJMt7+tOhM7/qv AsMAni+HstK5alSoBiEnD8uegcL7Dh4a =2oLs -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] rendered image has overally lower pixel values
Hi all, I have a following question. When I set texture values (manually or from loaded image) and render such a texture on object and grab the final image from screenbuffer its pixel values are lower. For example, when I set value 100 (from 0-255) I get 80. I have already switched of the light using Code: state-setMode(GL_LIGHTING, osg::StateAttribute::OFF); .. to remove standard viewer shadowing. Is there in OSG any default ambient lighting or any attenuation that could cause this behaviour? Do you have any ideas how to get in rendered images the exact color that I set without any modification? Another confusing thing is, that default viewer has some default light positioned in the same direction as camera and performs some kind of Lambertian shading. Is there any way how to switch on/off this light or control its position to have the same functionality? Sorry for silly questions, but this problem drives me mad. Thanks in advance for any suggestions. Jiri -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7456#7456 ___ 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 Stephan, On Thu, Feb 26, 2009 at 12:10 PM, Stephan Maximilian Huber ratzf...@digitalmind.de wrote: Don't know what ffmpeg needs, I used RtAudio for crossplattform playback + recording of audio. It's basically one base-class with different backends per platform: http://www.music.mcgill.ca/~gary/rtaudio/ Thanks for the link. I'll download it and have a look. I am currently in progress developing GraphicsWindowCocoa, so perhaps we have an alpha-quality-implementation by the end of this week. Good news, thanks for your efforts on this. Will it be able to handle multi-threading/multi-context windowing? Without a true 64bit version of Quicktime which works on Win+Mac it doesn't make sense to update/replace the plugin by QTKit. (Currently, for 64bit, the 64bit app communicates with a 32bit background process, which provides the video-stream, and it lacks some of features + is not crossplattform) Sorry but I couldn't quite work out the exact status of 64bit + Quicktime. Will it be possible for use to move our present Quicktime plugin across to work under 64bit, even if means emulation, or do we simply have to disable the build of the Quicktime plugin under OSX. Currently, I am against deprecating the quicktime-lib, because: 1.) it handles images default for OS X Which images does Quicktime support that we don't have other plugins for? Ideally I'd like to see us have cross platform support for all types of imagey that OSG users come across, this way users are locked into a single platform just because of a data type. 2.) it handles live-video A quick search on the web suggest that live-video should be possible under ffmpeg. 3.) it handles movies ffmpg can't handle Which movie formats are these? If we know which formats are potential issue we can look them up to see if they are supported/may be supported in the future. ffmpeg isn't a static target, support for various formats is improving over time so perhaps this issue should becoming less significant. 4.) it has no dependencies on Mac OS X Kinda of true, but being only portable to Windows and OSX doesn't make it a fully portable no strings attached solution. But if you want, go deprecate it, interested users can fork + maintain a copy of it. I'm just suggesting that deprecating the xine-lib and quicktime plugins might make sense. I haven't made any decisions - we need to get this ffmpeg working well across all platforms before we could even consider such a move and even then we need to closely examine what the downside would be on such a move. The benefits are a unified code base that is developed and tested on all platforms, the downside is potential loss for some file formats. If we can enumerate the missing features then we'll be in better place to make an informed decision. As you mention, the quicktime and xine-lib plugins are open source so even if they are deprecated they can still be maintained by those that need them specifically. The first step in this process has to be getting the ffmpeg up and running with video and audio across all platforms, then to start looking at a set of test video/features that we can use a unit tests that we measure the plugin against. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] rendered image has overally lower pixel values
Hi, Jiri Filip wrote: Hi all, I have a following question. When I set texture values (manually or from loaded image) and render such a texture on object and grab the final image from screenbuffer its pixel values are lower. For example, when I set value 100 (from 0-255) I get 80. I have already switched of the light using Code: state-setMode(GL_LIGHTING, osg::StateAttribute::OFF); .. to remove standard viewer shadowing. Is there in OSG any default ambient lighting or any attenuation that could cause this behaviour? Do you have any ideas how to get in rendered images the exact color that I set without any modification? Make sure your object you put the texture on has colours 1,1,1. Also see other texture modes. E.g. OSG defaults to GL_MODULATE, there is also GL_DECAL. See this thread also: http://article.gmane.org/gmane.comp.graphics.openscenegraph.user/36938 jp Another confusing thing is, that default viewer has some default light positioned in the same direction as camera and performs some kind of Lambertian shading. Is there any way how to switch on/off this light or control its position to have the same functionality? Sorry for silly questions, but this problem drives me mad. Thanks in advance for any suggestions. Jiri -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7456#7456 ___ 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
[osg-users] Qt mouse wheel zoom howto
Hi,
I was writing an application using Qt and osg.
I would like to zoom in and out on mouse scroll.
I could not find a good way to do this, so I came up with:
void osgWidget::wheelEvent(QWheelEvent *event) {
const float delta(event-delta() / (8.0f * 15.0f));
const float x(event-x());
const float y(event-y());
const float ydy(y + delta);
const int b(osgGA::GUIEventAdapter::LEFT_MOUSE_BUTTON
| osgGA::GUIEventAdapter::MIDDLE_MOUSE_BUTTON);
_gw-getEventQueue()-mouseButtonPress(x, y, b);
_gw-getEventQueue()-mouseMotion(x, ydy);
_gw-getEventQueue()-mouseButtonRelease(x, ydy, b);
}
which actually works but it's not so elegant.
Is there a obj-zoom(0.9f); to get 10% closer or obj-zoom(1.1f); to get
10% further for example?
thank you.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Qt mouse wheel zoom howto
Hi Paulo,
Possible the easiest way to do this would be modify the
osgGA::TrackballManipulator itself (and see in the changes so we can
all benefit :-), or subclass from it and override the handle method to
add the handling of the mouse wheel events. Once you've done this
you'd need to pass in the mouse wheel events via the
osgGA::EventQueue.
Robert.
On Thu, Feb 26, 2009 at 1:00 PM, Paulo Jnkml paulo.jn...@gmail.com wrote:
Hi,
I was writing an application using Qt and osg.
I would like to zoom in and out on mouse scroll.
I could not find a good way to do this, so I came up with:
void osgWidget::wheelEvent(QWheelEvent *event) {
const float delta(event-delta() / (8.0f * 15.0f));
const float x(event-x());
const float y(event-y());
const float ydy(y + delta);
const int b(osgGA::GUIEventAdapter::LEFT_MOUSE_BUTTON
| osgGA::GUIEventAdapter::MIDDLE_MOUSE_BUTTON);
_gw-getEventQueue()-mouseButtonPress(x, y, b);
_gw-getEventQueue()-mouseMotion(x, ydy);
_gw-getEventQueue()-mouseButtonRelease(x, ydy, b);
}
which actually works but it's not so elegant.
Is there a obj-zoom(0.9f); to get 10% closer or obj-zoom(1.1f); to get 10%
further for example?
thank you.
___
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] Streaming of high resolution images
The bottleneck is still your disk I/O bandwidth and if that isn't fast enough you're still out of luck. Yes, the bottleneck is certainly I/O bandwidth: in fact the application doesn't block until It work totally in ram. When RAM is full the paging file (on the hard disk) begin to grow and the application go slow and crush. Still: the resolution you mentioned (1440x1050) requires ~108 MB/s for 8-bit RGB @ 25 fps (and over 140 MB/s for 10-bit or RGBA). You need a few drives to do that... What do you mean with You need a few drives to do that...? That the majority of hard drives support a flow like that? I think so but probably the problem could be the loading process of images and I hope that it could be resolved using other techniques (probably customizing implementation of osgDB::readImageFile? probably with ramdisk?). Is it possible or am i wrong? What is the path (in terms of memory) that images follow before to be displayed at video? At the moment i'm already trying using quicktime (inserting images in a .mov) while, as regards ive, there could it be a problem of size because i have a lot of images to display. Thanks all for the useful answers Francesco Argese -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7461#7461 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Non-standard name for 3rdParty disables FreeType plugin
Hi Robert,
no it didn't work, but I have recreated the situation here so can
confirm the bug. It seems Find3rdPartyDependincies can't set the
FREETYPE_INCLUDE_DIR_ft2build/freetype2 vars so even if
Find3rdPartyDep...cmake sets FREETYPE_FOUND to YES, FindFreeType
eventually set it to NO.
...
I know why this is now. Posting in osg-submissions soon
Mattias
On 2/26/09, Robert Osfield robert.osfi...@gmail.com wrote:
Hi Guys,
To solve the missing FREETYPE_INCLUDE_DIRS definition I've added a
SET(FREETYPE_INCLUDE_DIRS
${FREETYPE_INCLUDE_DIR_ft2build};${FREETYPE_INCLUDE_DIR_freetype2})
To the appropriate part of Find3rdPartyDependencies.cmake. Changed
file is attached and checked into svn/trunk.
Paul could you try this out, if it works fine I'll merge it with the
OSG-2.8 branch as well.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OFT: Interesting commentary of the future of OpenGL
Hi Robert, hi all, Well, so in that case I agree we should support OpenGL+ES+CL in OSG 3+. About topics/actions you mentioned... 1) Campaign individually and as group publicly support of OpenGL and it's promote its benefits. 2) Publicly put pressure on the hardware vendors to better support OpenGL w.r.t driver quality and features. I suggest we create a Communication/advertising section on the wiki. Here are some ideas to fill in the pages of this section: - Articles on OpenGL and OSG (so that we link our personnal websites/blogs to them). Official OSG blog could have links and/or copies to/of them. - Campains, logo and various advertising materials (ditto) - Copy of letters we would have sent to to vendors + list of vendors to contact. - Presentations - etc. And we may discuss as usual on the mailing list (or on a osg-communication specific list?). 3) Work with hardware vendors on a suite of unit tests that can test the range of OpenGL features. 4) Come up with compelling benchmarking suite that shows off OSG/OpenGL. I have no strong ideas about this. Could we start by using current examples, and creating benchmark-examples? 5) Coordinating between us on best practices to sell OpenGL to skeptical clients. This may go with 1+2 on the advertising section. 6) Investigate the possibility of using OpenGL subset - Direct3D layer. Yes. However, I guess such a layer would have much delay (between new features in APIs, and the reflection of such features in the layer)... Should we start a thread about 1+2+5? May we use a tag (that Art would add to the forum), such as [Com] or [Adv]? Any idea about precise subjects? Any more ideas about things to put on the wiki? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 26 Feb 2009 10:41:37 +0100, Robert Osfield robert.osfi...@gmail.com a écrit: Hi Sukender, On Thu, Feb 26, 2009 at 12:15 AM, Sukender suky0...@free.fr wrote: Okay, so admitting we're dropping D3D... Well it's hard to drop something that you have picked up yet :-) In terms of making a D3D backend a goal, as mentioned in my earlier post this has some pros, and lots of cons/risks for the project. Given we are already talking about taking on a risk API refactoring over the next couple of years I'd suggest we should keep conservative and avoid taking on further extra risks/loads. If the API refactoring targeting API's already close to use goes well then one could consider taking further steps w.r.t rendering alternate back ends. Waiting a year or two more will also see some wider market trends work themselves out, there is a chance that D3D will actually be less compelling even under Windows. If we do a good job on helping the hardware vendors properly support OpenGL with robust and feature rich drivers then this will change the landscape as well. As an interim solution the OpenGL subset - Direct3D is something that could be investigated independent of other OSG efforts in coping with new API's. Such an approach could work with the existing OSG as well as future revs. Such a solution might also buy us more time. Will the problem be similar for OpenGL-ES/OpenCL (I mean raytracing and such for OpenCL)? This is not ironic: I don't know much about these. But I wonder if we would have the same abstraction problem with them. I was thinking that if OSG 3 would support these, then why not others (such as D3D)... However, if they're quite close to OpenGL, then yes, the situation is different. We thus could think about OSG not as API agnostic, but as Khronos API agnostic or such. Thoughts? The Khronos API's are all part of family which means language and concepts as well as API style, and end user culture all fit in well together. This includes similarities in GLSL implementations, method naming, coordinate system conventions (for instance where 0,0 is on a viewport or a texture). This should mark it easier to port/support to OpenGL ES, OpenGL 3.0, and OpenCL in addition to OpenGL 1.x + 2.x. This are the soft targets for us - being Khronos API agnostic would certainly be a smaller step than being abstracting totally from the HAL API. Smaller steps are less risky, and in the case of OpenGL ES and OpenCL the benefits of opening out new platforms and new ways of working are very significant - far more significant than any D3D port would ever provide. Less risk, greater benefits, pretty easy decision really :-) This doesn't mean we should look at trying to resolve some of the pressures to support D3D that some existing OSG are seeing. For this I'd see a three pronged approach as being helpful : 1) Campaign individually and as group publicly support of OpenGL and it's promote its benefits. 2) Publicly put pressure on the hardware vendors to better support OpenGL w.r.t driver quality and features. 3) Work with hardware vendors on a suite of unit
Re: [osg-users] New ffmpeg plugin checked into svn/trunk
Robert Osfield wrote: On Thu, Feb 26, 2009 at 12:10 PM, Stephan Maximilian Huber ratzf...@digitalmind.de wrote: Currently, I am against deprecating the quicktime-lib, because: 1.) it handles images default for OS X Which images does Quicktime support that we don't have other plugins for? Ideally I'd like to see us have cross platform support for all types of imagey that OSG users come across, this way users are locked into a single platform just because of a data type. This problem can also be solved on OSX by integrating Eric Wing's ImageIO plugin to handle static images. I have the code; I just need to find time to integrate the plugin. Unfortunately I haven't had much time to devote to OSG and my OSG-based application lately. As far as using our standard, cross-platform image plugins on OSX, that works too. I used to do that when the Quicktime plugin didn't handle transparency very well. The first step in this process has to be getting the ffmpeg up and running with video and audio across all platforms, then to start looking at a set of test video/features that we can use a unit tests that we measure the plugin against. I think that the ffmpeg plugin, once we determine if it will work well enough for our purposes, combined with the ImageIO plugin, will be able to replace the old Quicktime plugin, providing (at last) a 64-bit path for OSG-based apps on OSX. -Eric ___ 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, Robert Osfield schrieb: Good news, thanks for your efforts on this. Will it be able to handle multi-threading/multi-context windowing? Yes, I hope so, it's a full GraphicsWindow-implementation. I haven't tested multithreaded/multi-context-usage now, I am still struggling with events, and Cocoa. Sorry but I couldn't quite work out the exact status of 64bit + Quicktime. Will it be possible for use to move our present Quicktime plugin across to work under 64bit, even if means emulation, or do we simply have to disable the build of the Quicktime plugin under OSX. Quicktime itself is AFAIK not 64bit, there's a thin abstraction-layer (called QTKit) available for 32bit/64bit which routes the commands to a 32bit background-app playing the video-stream and handling the image back. For windows the SDK is only 32bit. I think disabling the quicktime-plugin for 64bit is the right way to go, without an alternative in place (ImageIO for example). Currently, I am against deprecating the quicktime-lib, because: 1.) it handles images default for OS X Which images does Quicktime support that we don't have other plugins for? Ideally I'd like to see us have cross platform support for all types of imagey that OSG users come across, this way users are locked into a single platform just because of a data type. PSD for example. Sure you can get all these formats with installing other dependencies + compiling some more plugins... 2.) it handles live-video A quick search on the web suggest that live-video should be possible under ffmpeg. Really? I thought you need other libs to capture the video footage like libcap, openCV, and feed the stream into ffmpeg to compress it... 3.) it handles movies ffmpg can't handle Which movie formats are these? If we know which formats are potential issue we can look them up to see if they are supported/may be supported in the future. All quicktime-codecs -- there are several codecs handled by quicktime, Sorensen, MotionJpeg, DV, etc. even some lossless codecs. (a list is available at: http://www.apple.com/quicktime/player/specs.html) ffmpeg isn't a static target, support for various formats is improving over time so perhaps this issue should becoming less significant. 4.) it has no dependencies on Mac OS X Kinda of true, but being only portable to Windows and OSX doesn't make it a fully portable no strings attached solution. yes I know. One of the keyfeatures of the quicktime-plugin is that you don't need to hassle with all the dependencies - compile the plugin and you'll have most of the image-formats and can play videos. Even distributing the app is simple, because quicktime is part of the system. And with some efforts you'll get double-clickable applications, no need to install needed packages / dependencies on the target systems. I am not a big fan of more external dependencies. For other platforms than unix/linux this is a great hassle to get + install the right packages. There are some package-managers available for OS X (DarwinPorts + Fink for example) but I think most Mac users do not use them. This is why I insist in old deprecated XCode projects which can compile frameworks or the quicktime-plugin, because they help to deliver the os-x experience everybody likes: download an app, copy it to the applications, double-click to run. No installer needed, nada. just my 2 cents :) cheers, Stephan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Streaming of high resolution images
Hi Ulrich, Ulrich Hertlein wrote: Why would you read from disk into a RAM disk, then read from RAM disk into, err, RAM again? Instead of reading straight from disk into your RAM cache? ... Set up a read thread that reads the images into RAM buffers and upload the images from the buffers as needed. At least that way you have the I/O wait in another thread and not your draw thread. you mentioned exactly the same what I told by using RAM-disk and external application which will load the data into it. So, you agree that this is the way to go ;) ? But nevertheless, as soon as coping the data from RAM into VRAM is faster than loading from HDD into RAM, you will always stuck after some time. It doesn't matter how much data you deliver into the RAM buffers from the HDD. After some time you will just reach the end of the buffered data and hence your draw thread will have to wait. Maybe you could try out to stream from HDD to RAM compressed files and uncompress them on the CPU (some simple runtime length encoding or so). Hence 3 threads, streaming, uncompressing and drawing threads. Each of them is working on some kind of RAM buffer. cheers -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7467#7467 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OFT: Interesting commentary of the future of OpenGL
Hi Sukender, On Thu, Feb 26, 2009 at 1:34 PM, Sukender suky0...@free.fr wrote: I suggest we create a Communication/advertising section on the wiki. Here are some ideas to fill in the pages of this section: - Articles on OpenGL and OSG (so that we link our personnal websites/blogs to them). Official OSG blog could have links and/or copies to/of them. - Campains, logo and various advertising materials (ditto) - Copy of letters we would have sent to to vendors + list of vendors to contact. - Presentations - etc. Good idea. The Community section of the wiki would be a natural home for this, perhaps Community/OpenGLAdvocacy would be appropriate. And we may discuss as usual on the mailing list (or on a osg-communication specific list?). Keep it all on osg-users, the ancillary lists always tend to go quiet after a while. 3) Work with hardware vendors on a suite of unit tests that can test the range of OpenGL features. 4) Come up with compelling benchmarking suite that shows off OSG/OpenGL. I have no strong ideas about this. Could we start by using current examples, and creating benchmark-examples? The examples are a start. CTest might be another axis to it. Perhaps a testing harness specifically for graphics rendering would be appropriate. A separate thread is the place to disucss this further. 5) Coordinating between us on best practices to sell OpenGL to skeptical clients. This may go with 1+2 on the advertising section. Indeed, it really is under a similar topic. 6) Investigate the possibility of using OpenGL subset - Direct3D layer. Yes. However, I guess such a layer would have much delay (between new features in APIs, and the reflection of such features in the layer)... You'd have to choose the mapping as well as there is no single Direct3D that you could target. So something like an OpenGL 2.x subset - Direct 3D 9.x and a OpenGL 2.x subset - Direct3D 10.x. The existence of shaders should make the task a bit easier as it reduces the API to smaller subset. One might need to do some hand remapping of GLSL shaders that your app uses to HLSL, but this could be done on the mapping layer. Should we start a thread about 1+2+5? May we use a tag (that Art would add to the forum), such as [Com] or [Adv]? Any idea about precise subjects? Any more ideas about things to put on the wiki? Definitely a good time to start a thread on 1,2+5 topics. Whether we need a separate topic branch I can't say, adding [Adv] or [Com] to a subject line might be easier missed. Perhaps others can chip in with their own thoughts. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Non-standard name for 3rdParty disables FreeType plugin
Hi Paul, Any idea why the non-standard name for the 3rdParty dir would cause this failure? This is an issue that has been there for a while but that no one bothered to fix until now because there's an easy workaround. The workaround is to open up CMake, and show the Advanced variables. You will probably see that some freetype-related variables are set to something-NOTFOUND. Set them to the right values and regenerate, and it will be fine. It's possible that other variables will also not be set correctly. So check all the values in the advanced list and make sure they're all set as they should, if not set them manually. I don't know enough about CMake to fix this. I can however give the exact failure mechanism if someone's interested: 1. Delete your CMake cache 2. Open CMake, point it to your source and build directory, and press Configure a first time. This will ask you which compiler to generate for, and some of the variables will appear in the CMake window. 3. Change ACTUAL_3RDPARTY_DIR manually. 4. Press Configure a second time. It would seem that if ACTUAL_3RDPARTY_DIR is manually changed, CMake is not able to detect all of the libs/includes that are needed. I expect there's a bug in our Find3rdPartyDependencies.cmake, but I wouldn't really know where to look and how to debug. Perhaps Mattias or Philip can help here? In the mean time, I hope the workaround above helps you a bit, Paul. 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
Hi Eric, On Thu, Feb 26, 2009 at 1:41 PM, Eric Sokolowsky esok@gmail.com wrote: This problem can also be solved on OSX by integrating Eric Wing's ImageIO plugin to handle static images. I have the code; I just need to find time to integrate the plugin. Unfortunately I haven't had much time to devote to OSG and my OSG-based application lately. Ahh more good news on the OSX front :-) You could always post the code which would allow others to help out with the wrapping up as plugin. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Non-standard name for 3rdParty disables FreeType plugin
Hi guys, I just posted on osg-submissions a fix for this. J-S is right. It's easy to fix so haven't been dealt with. As I now know this bug I know that the quick fix is to delete/remove entry FREETYPE_INCLUDE_DIR_ft2build and FREETPE_INCLUDE_DIR_freetype2 vars from the cmake cache after having set your preferred ACTUAL_3RDPARTY_DIR Mattias On 2/26/09, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Paul, Any idea why the non-standard name for the 3rdParty dir would cause this failure? This is an issue that has been there for a while but that no one bothered to fix until now because there's an easy workaround. The workaround is to open up CMake, and show the Advanced variables. You will probably see that some freetype-related variables are set to something-NOTFOUND. Set them to the right values and regenerate, and it will be fine. It's possible that other variables will also not be set correctly. So check all the values in the advanced list and make sure they're all set as they should, if not set them manually. I don't know enough about CMake to fix this. I can however give the exact failure mechanism if someone's interested: 1. Delete your CMake cache 2. Open CMake, point it to your source and build directory, and press Configure a first time. This will ask you which compiler to generate for, and some of the variables will appear in the CMake window. 3. Change ACTUAL_3RDPARTY_DIR manually. 4. Press Configure a second time. It would seem that if ACTUAL_3RDPARTY_DIR is manually changed, CMake is not able to detect all of the libs/includes that are needed. I expect there's a bug in our Find3rdPartyDependencies.cmake, but I wouldn't really know where to look and how to debug. Perhaps Mattias or Philip can help here? In the mean time, I hope the workaround above helps you a bit, Paul. 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OFT: Interesting commentary of the future of OpenGL
Hi JS, Supporting OpenGL 2 + OpenGL 3 first sounds fine to me. We should however keep in mind future plans when designing :) Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 26 Feb 2009 15:19:57 +0100, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com a écrit: Hi Sukender, I was thinking that if OSG 3 would support these, then why not others (such as D3D)... OpenCL has an analogue API in Direct3D 11 which is called compute shader. OpenCL is made to work with OpenGL (share resources, buffers, etc.) so as I understand it, you couldn't really use it with D3D. It's pretty much the same thing that happened for (graphical) shaders a while back. There were vendor-specific APIs at first (assembly, Cg, ...) and then there were ARB, GLSL and HLSL which are not vendor-specific but are graphics-API-specific (for OpenGL, for Direct3D). For GPGPU it's the same thing, NVIDIA has CUDA and ATI/AMD has Compute Abstraction Layer (CAL), and soon OpenGL will have OpenCL and Direct3D will have Compute Shader. Again an argument for the fact that both APIs are pretty much on the same footing, after all they're just exposing features of the GPUs, sure for some features one API will expose it faster than the other and inversely but by the time a feature is mature both APIs are equivalent in exposing it. About OpenCL: I think it will be (or should be, at least at the start) orthogonal to OpenGL in OSG. So I think our work in the near-to-mid term is mostly supporting OpenGL 2 + OpenGL 3. Later we might think of doing a completely raytracing-based back-end that uses OpenCL, but OpenCL is much more general than just raytracing, and I think exposing its functionality at a low level, for any use, will be more of a priority than building a rendering back-end for it into OSG. Sure, I'd like to try our simulators in a realtime raytracer, but I think that's not a priority and is still a while off... :-) J-S ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Vec3d - Vec3 bug under Linux ?
Hi all, I was thinking about posting in osg submission, but I don't have nothing to submit. I just had a little bug, solved now, but I thing this can be an interessting point for OSG to notice. To make a special geometry, I did a function returning a new vertex Array. In the code, all was based on Vec3d, including the return data (osg::ref_ptrosg::Vec3dArray ) Under windows, no problem for nothing. Under Linux, 2 of the 9 Vec3d of the array were wrong, and not constant (sometinme a wrong value, sometimes an other wrong value). to solve the problem, I just use vertices-push_back(osg::Vec3(ptA + decal - x*2.0 + z*1.5 + x*0.5 ))) instead of vertices-push_back(ptA + decal - x*2.0 + z*1.5 - x*0.5) and now all is good. Is there any unsafe conversion from Vec3d to vec3 ? I solve the problem for my application, but maybe someone have any explanation ... or maybe a bug is here... don't know.. Regards, Vincent. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OFT: Interesting commentary of the future of OpenGL
Everybody is talking like there aren't any high performance cross-API scene graphs nor could one be made. They do exist and they are expensive. I've also seen a bunch of messages dismissing the gamer market to make the argument that OpenGL is big everywhere else and thus D3D doesn't matter. Well, the last statistics I've seen has the gaming industry an order of magnitude larger than everything else; I wouldn't ignore it. I'm not working on a game, but I do recognize that I can write a fast, cheap 3d app because the technology has been pushed so hard by gamers. With more money being spent on D3D hardware, I wouldn't be too quick to write it off. BTW- I know very little of the two API's and I don't particularly want to know any more (I only know what Wikipedia tells me: http://en.wikipedia.org/wiki/Comparison_of_OpenGL_and_Direct3D). OSG is invaluable to me because it takes care of details that I don't want to worry about and lets me work at a higher level. If the layer on top of OpenGL gets too thin and I have to learn a lot about the underlying API, then that layer isn't valuable to someone like me. But I know I'm just one member of a very diverse community. My needs and desires probably aren't the same as yours. This discussion that Gordon triggered has been fantastic though because I'm learning so much about my fellow OSGers. Cory Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC wrote: I agree with what is said here. >From my experience, generalization and high performance end up being mutually exclusive. Eventually you have to surrender to one to obtain the other... -S -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jan Ciger Sent: Wednesday, February 25, 2009 3:04 PM To: OpenSceneGraph Users Subject: Re: [osg-users] OFT: Interesting commentary of the future of OpenGL Hi, Sukender wrote: Hi Robert, Well yes, I forgot about XBox... So yes, the wrapper may be a solution. However, I'd like to insist on the fact that we should "attract" D3D devs by telling them that we're going towards an API agnostic scene graph, and them see with them what we may/should do about D3D support. Honestly, I wouldn't care too much about platforms like XBox - it is here for a year or two more and the next XBox is likely to be very different. However the OSG devs will have invested lot of time into the D3D infrastructure that will be obsolete when the new XBox is out. Then what? Chase the moving target again? What for? To be competing with things like the Source engine or others that do not care about OpenGL and can be tightly optimized for D3D? If you want to develop Windows/XBox games using OSG, be my guest, but we should not try to target every possible rendering API which is there. I prefer a tool that does one thing and does it well to a jack of all trades that does everything but nothing well. I think OSG only stands to lose by fragmentation of the development resources if Direct 3D was to be supported, and for very little gain. Regards, Jan ___ 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] New ffmpeg plugin checked into svn/trunk
Hi Stephan, On Thu, Feb 26, 2009 at 1:46 PM, Stephan Maximilian Huber ratzf...@digitalmind.de wrote: Yes, I hope so, it's a full GraphicsWindow-implementation. I haven't tested multithreaded/multi-context-usage now, I am still struggling with events, and Cocoa. A full implementation would be great, as it would mean no loss of functionality. Good luck with sorting out the events side. Sorry but I couldn't quite work out the exact status of 64bit + Quicktime. Will it be possible for use to move our present Quicktime plugin across to work under 64bit, even if means emulation, or do we simply have to disable the build of the Quicktime plugin under OSX. Quicktime itself is AFAIK not 64bit, there's a thin abstraction-layer (called QTKit) available for 32bit/64bit which routes the commands to a 32bit background-app playing the video-stream and handling the image back. For windows the SDK is only 32bit. I think disabling the quicktime-plugin for 64bit is the right way to go, without an alternative in place (ImageIO for example). An ImageIO plugin would certainly ease some of this issues in proper support for 64bit under OSX. The OSG went 64bit under other unices 7 years ago, so it's a shame that OSX has been held back for so long. A quick search on the web suggest that live-video should be possible under ffmpeg. Really? I thought you need other libs to capture the video footage like libcap, openCV, and feed the stream into ffmpeg to compress it... I've seen quick tutorials that illustrate recording live video streams, I don't recall mention of external tools. Earlier today I tried out one command line that records the X11 desktop to a video, this required recompiling ffmpeg though. I haven't tried tweaking our new plugin to do this yet though, I guess it should be possible. Once I get into this effort more I should know more about the ins and out of it. All quicktime-codecs -- there are several codecs handled by quicktime, Sorensen, MotionJpeg, DV, etc. even some lossless codecs. (a list is available at: http://www.apple.com/quicktime/player/specs.html) Thanks for the link. If we start with a standard source video I presume we can get quicktime to generate these various formats as an output, then use these for testing against the ffmpeg plugin for compatibility. I don't expect we'd see 100% support, but it'd be great if the main formats that are used supportable by ffmpeg. yes I know. One of the keyfeatures of the quicktime-plugin is that you don't need to hassle with all the dependencies - compile the plugin and you'll have most of the image-formats and can play videos. Even distributing the app is simple, because quicktime is part of the system. And with some efforts you'll get double-clickable applications, no need to install needed packages / dependencies on the target systems. I am not a big fan of more external dependencies. For other platforms than unix/linux this is a great hassle to get + install the right packages. There are some package-managers available for OS X (DarwinPorts + Fink for example) but I think most Mac users do not use them. This is why I insist in old deprecated XCode projects which can compile frameworks or the quicktime-plugin, because they help to deliver the os-x experience everybody likes: download an app, copy it to the applications, double-click to run. No installer needed, nada. Perhaps Philip's efforts on his CMakePorts project will help solve part of this issue, give us an relatively painless way to build the various dependencies and package them in a consistent way. -- On a slightly different note, cross platform solutions like ffmpeg do open up for better support for OSX indirectly, as right now 95% of the community can't help out with OSX specific issues. If one adds full cross platform support then suddenly the number of people who can help out an maintain solutions that OSX developers rely upon jumps by 20 fold. So even if a few features aren't available under ffmpeg, there is a good chance that the features that it does expose will be better supported and maintainable than the present situation with the Quicktime plugin. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VS9 3rd party libs link broken on wiki
Hi Robert, Since the there is a table mapping dependency to links to the 3rd party projects there probably isn't a need for linking to specific version - so I've just removed this set of misleading links. Let me know if there is still something amiss. Looks fine, thanks. BTW, I've asked this before but you didn't respond - Now that we have separate user accounts on the Wiki, could the locked pages be opened up to some of us in the community? Downloads and Dependencies would be good candidates. That way we won't have to pester you all the time, at least for that :-) 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] Vec3d - Vec3 bug under Linux ?
Hi Vincent, I can't work out exactly what to bug is in your instance, from the contents of your email it sounds like windows and linux compilers are evaluating the conversion of types in a different order and getting different results, or that their is a compiler bug. The fact that adding an explicit Vec3d() into your code suggests to me that it's not likely to be an OSG issue, rather a compile one. Robert. On Thu, Feb 26, 2009 at 2:25 PM, Vincent Bourdier vincent.bourd...@gmail.com wrote: Hi all, I was thinking about posting in osg submission, but I don't have nothing to submit. I just had a little bug, solved now, but I thing this can be an interessting point for OSG to notice. To make a special geometry, I did a function returning a new vertex Array. In the code, all was based on Vec3d, including the return data (osg::ref_ptrosg::Vec3dArray ) Under windows, no problem for nothing. Under Linux, 2 of the 9 Vec3d of the array were wrong, and not constant (sometinme a wrong value, sometimes an other wrong value). to solve the problem, I just use vertices-push_back(osg::Vec3(ptA + decal - x*2.0 + z*1.5 + x*0.5 ))) instead of vertices-push_back(ptA + decal - x*2.0 + z*1.5 - x*0.5) and now all is good. Is there any unsafe conversion from Vec3d to vec3 ? I solve the problem for my application, but maybe someone have any explanation ... or maybe a bug is here... don't know.. Regards, Vincent. ___ 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] Vec3d - Vec3 bug under Linux ?
Robert Osfield wrote: Hi Vincent, I can't work out exactly what to bug is in your instance, from the contents of your email it sounds like windows and linux compilers are evaluating the conversion of types in a different order and getting different results, or that their is a compiler bug. The fact that adding an explicit Vec3d() into your code suggests to me Isn't that an explicit cast to Vec3f()? As osg::Vec3 defaults to Vec3f... Paul that it's not likely to be an OSG issue, rather a compile one. Robert. On Thu, Feb 26, 2009 at 2:25 PM, Vincent Bourdier vincent.bourd...@gmail.com wrote: Hi all, I was thinking about posting in osg submission, but I don't have nothing to submit. I just had a little bug, solved now, but I thing this can be an interessting point for OSG to notice. To make a special geometry, I did a function returning a new vertex Array. In the code, all was based on Vec3d, including the return data (osg::ref_ptrosg::Vec3dArray ) Under windows, no problem for nothing. Under Linux, 2 of the 9 Vec3d of the array were wrong, and not constant (sometinme a wrong value, sometimes an other wrong value). to solve the problem, I just use vertices-push_back(osg::Vec3(ptA + decal - x*2.0 + z*1.5 + x*0.5 ))) instead of vertices-push_back(ptA + decal - x*2.0 + z*1.5 - x*0.5) and now all is good. Is there any unsafe conversion from Vec3d to vec3 ? I solve the problem for my application, but maybe someone have any explanation ... or maybe a bug is here... don't know.. Regards, Vincent. ___ 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] openscenegraph.org stats
Hi Robert, Anyone any ideas about what platforms this Unknown are likely to be? Well, some people disable the sending of OS information by their browser, so it's possible that a number of those actually would fall into the other categories (Linux, Windows etc.) Perhaps this strong showing of non windows OS's and non IE browsers in the graphics community might be useful in helping win over clients that go demanding MS specific solutions. The tide has turned. I find your wording funny... All dramatic and foreboding. 60% is still huge. And keep in mind that's just visits to the web site... I don't think we can have a direct correlation between website visits and OSG usage. It would be a pretty big extrapolation. And the browser stats mean nothing since Firefox, Opera and others run on Windows, Linux, etc. I know many people who avoid IE like the plague, even though they run Windows. I use Firefox just because I like it more and I try to use Open Source software wherever I can. You're being pretty extremist in this whole thing. You have to understand that people can use Windows for many reasons, not only technical ones, and it's not because someone uses Windows that they're necessarily buying into MS's propaganda. It's not as clear-cut as that. IMHO, Windows is just another tool, it's superior in some respects and inferior in others, and people will choose to use it or not (sometimes for the wrong reasons, but in general you don't know those reasons so you can't make a judgement on them...) and there's nothing you or I can do about that. 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
So... could we even deprecate the xine-lib and Quicktime plugins completely? One question is does the ffmpeg plugin support streaming (from a web site or from a local/remote webcam) for example? I think that's an interesting feature of the QuickTime plugin. 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
[osg-users] Flicker in osgviewer, multiple channels
Hello all, Kind of a newbie question I'm afraid. I hope somebody can push me into the right direction. I am using osgViewer with several attached camera slaves to render multiple overlapping views of the same scenegraph. Now I am trying to hide an object (using a osg::Switch) in one channel and show it in the others. I am doing the switching in each of the cameras predraw function. While this works in a singlethreaded setup (at a huge performance loss), it creates chaotic flickering in any multithreaded dito probably since I am globally altering the scenegraph from one thread. So, am I pushing the limits of osgViewer, do I need to switch to compositeviewer to achive this or is there some other way? (I am using Fedora, OSG 2.8) Thanks in advance, Per Nordqvist ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OFT: Interesting commentary of the future of OpenGL
Hi Cory, On Thu, Feb 26, 2009 at 2:26 PM, Cory Riddell c...@codeware.com wrote: Everybody is talking like there aren't any high performance cross-API scene graphs nor could one be made. They do exist and they are expensive. I haven't personally suggested this, but I have talked about the technical trade-offs involved. I've also seen a bunch of messages dismissing the gamer market to make the argument that OpenGL is big everywhere else and thus D3D doesn't matter. Well, the last statistics I've seen has the gaming industry an order of magnitude larger than everything else; I wouldn't ignore it. Well the gaming market is very big, BUT the gaming market isn't just Windows/D3D, its much bigger than that. The Wii and Playstation2 have been the big consoles of the last ten years, neither of which have anything to do with D3D. MS would like to associate gaming with exclusivie use of D3D but this is just a marketing ploy. One has to ask the question what platforms you want to deliver your products on, and how to efficiently deliver those products to those platforms. D3D is only one way of delivering it under Windows, and the support matrix for different versions of D3D is rather convoluted, such as D3D10 only being available on 10% of the OSG's community machines, while OpenGL2.x+extensions with similar feature set as D3D 10 is available on 100% of the OSG's communities machines. For instance right now an OSG application right now can deliver a more advanced graphics application under WindowsXP than any Direct3D developer can. If you care about gaming then surely this is good thing. The only thing holding the OSG back in this instance is not being tied to OpenGL, but the lack of quality and feature set of OpenGL drivers from some vendors i.e. Intel + ATI. I'm not working on a game, but I do recognize that I can write a fast, cheap 3d app because the technology has been pushed so hard by gamers. With more money being spent on D3D hardware, I wouldn't be too quick to write it off. It's just hardware, it isn't D3D hardware, again we have to be careful not to tricked by the MS marketing. Microsoft has helped control the hardware specs via it's D3D API's, but it hasn't created the hardware, neither has the grame developers. It's ATI and NVidia that have created the solutions for the games market under Windows, D3D was not the catalyst for this push, it was just one of ingredients in the mix. Take D3D out of the mix and place OpenGL more centrally and would have got pretty well the same hardware advances. Take the games market out of the mix and yes, we would have been unlikely to see such advances. In terms of the OSG community, we do need to make sure that we stay good at what we are good at - we are the defacto standard scene graph is vis-sim, VR and GIS markets. Spending too much time courting a difficult market to crack into could easily make us loose focus on existing user bases needs and up failing to crack the new markets and in existing markets where we are strong. BTW- I know very little of the two API's and I don't particularly want to know any more (I only know what Wikipedia tells me: http://en.wikipedia.org/wiki/Comparison_of_OpenGL_and_Direct3D). OSG is invaluable to me because it takes care of details that I don't want to worry about and lets me work at a higher level. If the layer on top of OpenGL gets too thin and I have to learn a lot about the underlying API, then that layer isn't valuable to someone like me. I sounds like the OSG hits quite a good balance for yourself so far - provides enough functionality to do your job without worry about the details such as the thin API abstraction. By contast Paul Martz at the start of thread emphasised that the thinness of the layer above OpenGL that the OSG provides is one of it's main selling points. To be able to satisfy two different types of users needs/desires means that we've been successful. The challenge now is how to retain these qualities whilst moving the paradigm of state management further on into full dynamic shader composition, and handling these disparate API's at the rendering backend. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Non-standard name for 3rdParty disables FreeType plugin
Hi Mattias, I just posted on osg-submissions a fix for this. Excellent, another bug bites the dust (sung to the tune of the Queen song with a similar name :-) ) 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] OFT: Interesting commentary of the future of OpenGL
Hi Sukender, Supporting OpenGL 2 + OpenGL 3 first sounds fine to me. We should however keep in mind future plans when designing :) Of course, but targeting *all* *possible* future plans, even those that have small probability to actually happen, is not useful. Note that I forgot OpenGL ES in my list of what we will probably shoot for in the near-to-mid term. Since OpenGL ES is totally shader-based it's probably pretty close to OpenGL 3 (I'm assuming). 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] VS9 3rd party libs link broken on wiki
On Thu, Feb 26, 2009 at 2:34 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: BTW, I've asked this before but you didn't respond - Now that we have separate user accounts on the Wiki, could the locked pages be opened up to some of us in the community? Downloads and Dependencies would be good candidates. That way we won't have to pester you all the time, at least for that :-) For regular contributors/maintainers granting access to write to these pages would be fine. Opening out to the all subscribers would still be a bit dangerous as it would be open malicious hackers. I believe Jose L. can grant different privileges to different users. If you wish access then just ping Jose L. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Flicker in osgviewer, multiple channels
Hello Per, Now I am trying to hide an object (using a osg::Switch) in one channel and show it in the others. What I normally do to get this effect is add the object directly as a child of the camera(s) where you want to see the object, but not as child of the others. This doesn't solve your problem, but gives you another way of getting the effect you want. I think you were on a bad track trying to change an osg::Switch in a camera's pre-draw callback. 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] Problems with non-resized NPOT textures andtrilinear min filter
Robert, Thanks for confirming that it isn't just me. Well, at least on machines with an Nvidia card. Does anyone with an ATI card experience this same issue with the samples I posted? I'll try digging deeper as you suggest, though like I mentioned in my original post I was able to make it work simply by reverting the location of the _textureObjectBuffer assignment in Texture2D.cpp back to where it was before r8606. -- Dan -Original Message- From: Robert Osfield [mailto:robert.osfi...@gmail.com] Sent: Thursday, February 26, 2009 12:58 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Problems with non-resized NPOT textures andtrilinear min filter Hi Dan, On Wed, Feb 25, 2009 at 10:02 PM, Gilbert, Daniel R. daniel.r.gilb...@saic.com wrote: Are others able to reproduce this same behavior using my attached sample? Just tried the test models on my Kubuntu 8.10/Gefore8800GTS cards and I get: npot_skydome_linear_noresize.osg works. npot_skydome_trilinear_noresize.osg fails. npot_skydome_trilinear_resize.osg works. I also don't get any OpenGL errors when npot_skydome_trilinear_noresize.osg fails. Any thoughts on how to attempt a fix? It could well be a driver issue, but also might be an OSG issue... When you have a model without mipmaps you have to generate them, either by using gluScaleImage or using the one of the two hardware mipmap extension. It'd be worth digging into osg::Texture/Texture2D to see what code paths it's taking to ask for the mipmap generation. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VS9 3rd party libs link broken on wiki
Hi Robert, BTW, I've asked this before but you didn't respond - Now that we have separate user accounts on the Wiki, could the locked pages be opened up to some of us in the community? Downloads and Dependencies would be good candidates. That way we won't have to pester you all the time, at least for that :-) For regular contributors/maintainers granting access to write to these pages would be fine. Opening out to the all subscribers would still be a bit dangerous as it would be open malicious hackers. Of course, hence why I said some of us in the community above. I believe Jose L. can grant different privileges to different users. If you wish access then just ping Jose L. Will do. Thanks. 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] Non-standard name for 3rdParty disables FreeTypeplugin
First: Wow! Thanks for stepping up to look into this. I post a suspicious behavior report late afternoon US mountain time, wake up the next morning, and there's already a submission in response. I love open source, and we have an awesome global community here. Unfortunately, the issue doesn't seem to be resolved. To test, I started from a fresh checkout of Mike 3rdParty deps, and also OSG, as sibling directories. I verified my OSG checkout contains your change, rev 9819, to the file Find3rdPartyDependencies.cmake. Then I did as follows: 1. Rename 3rdParty as 3rdParty-VS8. 2. Open CMakeSetup.exe with OSG/CMakeLists.txt. Specify a build directory. 3. Click Configure and wait for the variables to appear. 4. Set ACTUAL_3RDPARTY_DIR to the full path for my renamed 3rdParty-VS8 directory. 5. Select the show advanced checkbox. 6. Click Configure again. 7. Examining the freetype variables, I see the following: FREETYPE_INCLUDE_DIR is set correctly. FREETYPE_LIBRARY is set correctly. FREETYPE_LIBRARY_DEBUG is set correctly. FREETYPE_INCLUDE_DIR_freetype2 is NOTFOUND. FREETYPE_INCLUDE_DIR_ft2build is NOTFOUND. 8. Click Configure again, then OK. 9. Enter VS IDE and note that there is no freetype plugin project. So, then, I deleted my build directory and started over, but this time I inserted the mentioned workaround after step 7: 7.5 Copy the value of FREETYPE_INCLUDE_DIR into the variables FREETYPE_INCLUDE_DIR_freetype2 and FREETYPE_INCLUDE_DIR_ft2build. With this workaround, I do get the freetype plugin project. So, the issue is still present, and the workaround is still required. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Mattias Helsing Sent: Thursday, February 26, 2009 7:17 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Non-standard name for 3rdParty disables FreeTypeplugin Hi guys, I just posted on osg-submissions a fix for this. J-S is right. It's easy to fix so haven't been dealt with. As I now know this bug I know that the quick fix is to delete/remove entry FREETYPE_INCLUDE_DIR_ft2build and FREETPE_INCLUDE_DIR_freetype2 vars from the cmake cache after having set your preferred ACTUAL_3RDPARTY_DIR Mattias On 2/26/09, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Paul, Any idea why the non-standard name for the 3rdParty dir would cause this failure? This is an issue that has been there for a while but that no one bothered to fix until now because there's an easy workaround. The workaround is to open up CMake, and show the Advanced variables. You will probably see that some freetype-related variables are set to something-NOTFOUND. Set them to the right values and regenerate, and it will be fine. It's possible that other variables will also not be set correctly. So check all the values in the advanced list and make sure they're all set as they should, if not set them manually. I don't know enough about CMake to fix this. I can however give the exact failure mechanism if someone's interested: 1. Delete your CMake cache 2. Open CMake, point it to your source and build directory, and press Configure a first time. This will ask you which compiler to generate for, and some of the variables will appear in the CMake window. 3. Change ACTUAL_3RDPARTY_DIR manually. 4. Press Configure a second time. It would seem that if ACTUAL_3RDPARTY_DIR is manually changed, CMake is not able to detect all of the libs/includes that are needed. I expect there's a bug in our Find3rdPartyDependencies.cmake, but I wouldn't really know where to look and how to debug. Perhaps Mattias or Philip can help here? In the mean time, I hope the workaround above helps you a bit, Paul. 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 ___ 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] New ffmpeg plugin checked into svn/trunk
On Thu, Feb 26, 2009 at 2:51 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: So... could we even deprecate the xine-lib and Quicktime plugins completely? One question is does the ffmpeg plugin support streaming (from a web site or from a local/remote webcam) for example? I think that's an interesting feature of the QuickTime plugin. I think the answer is probably yes, but I haven't tried anything other than streaming he desktop yet. I have a webcam on my Shuttle so I'll boot this up and see if I can follow the online tutorials to test it out. The online tutorials I've read so far discuss the command line ffmpeg utility, but I presume it should be possible to write things up in use the ffmpeg libs so should be exposable from our plugin given the correct additions. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Spam: Re: New ffmpeg plugin checked into svn/trunk
Hi J-S, I'd be very surprised if the ffmpeg plugin supports streaming out of the box (although you never know). We've surely never tested it with streamed videos. FFmpeg decoding streamed videos should not be a problem. The networking/protocol part of streaming is another matter. I think it's useless extrapolating without someone really looking down into the matter. Tanguy -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien Guay Sent: Thursday 26 February 2009 14:52 To: OpenSceneGraph Users Subject: Spam: Re: [osg-users] New ffmpeg plugin checked into svn/trunk So... could we even deprecate the xine-lib and Quicktime plugins completely? One question is does the ffmpeg plugin support streaming (from a web site or from a local/remote webcam) for example? I think that's an interesting feature of the QuickTime plugin. 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Eric Wing's osgdb_ImageIO image plugin for OSX
Here's Eric Wing's ImageIO plugin. It was actually submitted to osg-submissions in October 2007 but nothing was ever done with it. If someone wants to take a stab at integration please go ahead. I want to do it, but have no time... isn't that always the way? -Eric S. ---BeginMessage--- -- Forwarded message -- From: E. Wing ewmail...@gmail.com Date: Fri, 26 Oct 2007 16:43:59 -0700 Subject: New image handling plugin for OS X (osgdb_ImageIO) To: osg-submissi...@lists.openscenegraph.org Yea! The Leopard NDA is finally lifted. This is a submission for a new osg plugin, osgdb_ImageIO. This is the first piece of the puzzle that we need to get 64-bit support on OS X. This plugin is intended to partially replace the current osgdb_qt (classic Quicktime) plugin. There are many issues with the current osgdb_qt, but perhaps the biggest is that there are many APIs used in it that have been marked deprecated for awhile now and will not make it to 64-bit on OS X. ImageIO is Apple's (semi-)new (as of 10.4 Tiger) fundamental image framework that provides access to all image formats handled by the platform. This new osgdb_ImageIO plugin intends to replace all of osgdb_qt's image handling duties as well as introduce support to new image formats as they become available to the platform (e.g. JPEG2000, RAW, HDR, etc). osgdb_ImageIO does not replace osgdb_qt's movie handling capabilities. I envision that to be handled by a planned second plugin using Apple's semi-new (10.4 Tiger) QuickTimeKit framework, tentatively osgdb_QTKit. So this plugin is just the first step. Would you please add this to src/osgPlugins/ImageIO? Improvements over osgdb_qt plugin: - Supports istream and ostream - Supports a lot more image formats - ImageIO framework should be well supported from 10.4 to the future (which should include 64-bit and new/future image formats) - Doesn't require explicit initialization/close-out - (Hopefully) efficient...avoids the manual byte-by-byte manipulation of the old QuickTime plugin. Calls Apple's Accelerate framework when useful. - Seems to fix/avoid AutoreleasePool related leak warnings which I believe the current qt plugin triggers if not using Cocoa (i.e. actually having an autorelease pool created). Missing: - No movie file support (planning/expecting a separate QTKit plugin to handle that). - Need to update osgDB::Registry for new plugin - Need to update build system(s) Additional Notes: - The old Quicktime plugin will need to remain for both Windows users (who happen to use it) and pre-10.4 OS X versions. It will also need to remain for movies until we get a QTKit plugin written. - This plugin probably could use additional testing for 16-bit/LUMINANCE/ALPHA stuff. I'm not terribly confident I understood what needs to happen in these cases so behavior could be different/broken compared to osgdb_qt. Once I figure out all the build system details, I'm proposing that for the next release of OSG, if building for OS X 10.4 or 10.5, the ImageIO plugin gets built and set as the default image handling plugin. For legacy 10.3 and Quicktime for Windows users, the existing osgdb_qt plugin should remain available. For now though, I wanted to make this piece of code available in case anybody has a pressing need to get 64-bit going soon. Thanks, Eric osgdb_ImageIO.cpp Description: Binary data ---End Message--- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OFT: Interesting commentary of the future of OpenGL
On Thu, Feb 26, 2009 at 3:05 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Note that I forgot OpenGL ES in my list of what we will probably shoot for in the near-to-mid term. Since OpenGL ES is totally shader-based it's probably pretty close to OpenGL 3 (I'm assuming). Just for clarification, OpenGL ES 1.x has fixed function pipeline which is essentially a subset of OpenGL 1.x, while OpenGL ES 2.x is completely shader based. I believe the existing OpenGL ES port of the OSG was done with OpenGL ES 1.x. I think the Iphone and is OpenGL ES 1.x as well. I think if we can do an OpenGL 2.x + OpenGL 3.x rendering backends, then both OpenGL ES 1.x and OpenGL ES 2.x will also be relatively straight forward to do. Robert. ___ 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, as to the Firefox there exists a joke: Why do you have MS Internet Explorer bundled with Windows? In order to download Mozilla Firefox! OK, I know I am getting off topic here, but I couldn't stop thinking on that joke when reading your post ;) cheers -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7501#7501 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Flicker in osgviewer, multiple channels
Hi Per, This might be too simple a solution, but have you tried assigning nodemasks to the objects in question along with the appropriate nodemask for the various cameras? The osgstereoimage example shows how this works. Hope this helps, -- Dan -Original Message- From: Jean-Sébastien Guay [mailto:jean-sebastien.g...@cm-labs.com] Sent: Thursday, February 26, 2009 7:13 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Flicker in osgviewer, multiple channels Hello Per, Now I am trying to hide an object (using a osg::Switch) in one channel and show it in the others. What I normally do to get this effect is add the object directly as a child of the camera(s) where you want to see the object, but not as child of the others. This doesn't solve your problem, but gives you another way of getting the effect you want. I think you were on a bad track trying to change an osg::Switch in a camera's pre-draw callback. 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] GraphicsWindowCocoa : Cocoa backend for osgViewer
I would download one of the cocoa-samples from apple which demonstrates the creation of window + opengl context, download the current svn from SDL and look at its cocoa-implementation and then fill the missing pieces of a newly created GraphicsWindowCocoa class. I'm now reading tons of docs: the SDL Cocoa implementation, the Apple samples, and the osgViewer code. As osgViewer and Cocoa are quite new to me I might need some time to swallow it all :-/ Sure you can borrow bits of code from osgViewerCocoa but they use different design approaches: osgViewerCocoa embeds an osgViewer into a NSApplication with their classes, what you want is to embed a NSWindow / NSOpenGlContext into a GraphicsWindowCocoa class. Understood. Will stick to the SDL-Cocoa integration model then. I started one [implementation], but stopped it, because there was no really need on my side, and it's still bare bone without much functionality. Unfortunately there's some more work to do, some functionality could be refactored and used by both implementations (the automatic hiding of the menubar etc) Great! Would you mind sharing your initial work? Anything speeding up the osgViewer/Cocoa is welcome. And I can definitely live with some limited implementation for a start :-) We could add the shared contexts, fullscreen mode, etc. later, right? If you want we can tackle this task together, I have some sparetime available and know Objective C a bit. I'm _not_ going to refuse any help! :-) OK I'm back to my lectures, hoping to be able to attack/enhance the osgViewer/Cocoa backend ASAP Thanks Sylvain ___ 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, A big extrapolation, but typically people will develop and browse under the same platform. But are people who go to the OSG site necessarily people who use OSG? That's the extrapolation I was referring to. Actually I think you're being a little tetchy. How is pointing aspects browser stats extremist? I wasn't referring to browser stats when saying you're extremist, but more to your general comments on Windows, and how (most) people who use Windows are buying into MS and being blinded by their PR, and so on. In the past few weeks I had the impression that you were making some blanket statements, not necessarily including the Windows users on this list (I didn't feel directly pointed out, at least) but most of the Windows users. It's a tool for a job, making it into a war is useless. For me a real eye opener is that Firefox has risen so rapidly, the mind share that MS once had over Windows developers clearly has ebbed dramatically in the case of browsers. Clearly MS's OS have faired better than their browser, and kept more market share, but OS's are far more of a bed rock of daily work than a single replaceable application, replacing it is not far from easy or desirable in many cases. OK, so you're making the assumption that if 60% of visitors on the site are using Windows, but only 25% use IE, then people seem to not be buying into MS's PR anymore? I would say that the advances of Open Source software (in terms of visibility, quality, etc.) have had a large hand in that. And I agree, being in the same boat myself (Windows user but open source software user wherever I can). So that's good news right? Given the context for Gordon Tomlison's recent email about Direct3D an assertions that some clients ask for Direct3D simply because they think it's better, I think it's important to point out stats, as it's one of the tools that we have available. Times have certainly changed dramatically in the browser market, extrapolating this to a suggestion that other parts of the software eco-system might be also ripe for change as well I don't think is too unreasonable. I agree. And BTW I've been silent about your list of concrete actions, but I'll help there as much as I can of course. Just because I'm a Windows user doesn't make me self-centered :-) 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] OFT: Interesting commentary of the future of OpenGL
Robert- Robert Osfield wrote: Well the gaming market is very big, BUT the gaming market isn't just Windows/D3D, its much bigger than that. The Wii and Playstation2 have been the big consoles of the last ten years, neither of which have anything to do with D3D. MS would like to associate gaming with exclusivie use of D3D but this is just a marketing ploy. Ah- very good point. For some reason I wasn't thinking of consoles. It's just hardware, it isn't D3D hardware, again we have to be careful not to tricked by the MS marketing. Unfortunately all too often it is very closed hardware and proprietary drivers. If the hardware works significantly better with the D3D API, then I call it a D3D card. How about a bad analogy (sorry, I couldn't think of a car analogy): a Macintosh is just a PC, but the software makes it a Mac. I sounds like the OSG hits quite a good balance for yourself so far - provides enough functionality to do your job without worry about the details such as the thin API abstraction. By contast Paul Martz at the start of thread emphasised that the thinness of the layer above OpenGL that the OSG provides is one of it's main selling points. To be able to satisfy two different types of users needs/desires means that we've been successful. Absolutely. This is the diverse community I talked about. This seems mostly to be a pretty pragmatic bunch of people, so I'm fairly confident that if D3D support doesn't materialize, it is for technical rather than religious reasons. Thanks, Cory ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Flicker in osgviewer, multiple channels
Hi Daniel, This might be too simple a solution, but have you tried assigning nodemasks to the objects in question along with the appropriate nodemask for the various cameras? The osgstereoimage example shows how this works. That would work too, but you run out of bits in the nodemask pretty quickly if you start using the node mask for such simple things. I find adding the objects as children of only the required cameras works well. 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
Robert Osfield wrote: Hi Eric, On Thu, Feb 26, 2009 at 1:41 PM, Eric Sokolowsky esok@gmail.com wrote: This problem can also be solved on OSX by integrating Eric Wing's ImageIO plugin to handle static images. I have the code; I just need to find time to integrate the plugin. Unfortunately I haven't had much time to devote to OSG and my OSG-based application lately. Ahh more good news on the OSX front :-) You could always post the code which would allow others to help out with the wrapping up as plugin. This is my second attempt to send Eric Wing's plugin. This was actually originally submitted to osg-submissions in October 2007, but nothing was done with it. If anyone wants to work on integrating it, please go ahead. My plate seems to always be full with other tasks... -Eric S. -- Forwarded message -- From: E. Wing Date: Fri, 26 Oct 2007 16:43:59 -0700 Subject: New image handling plugin for OS X (osgdb_ImageIO) To: osg-submissi...@lists.openscenegraph.org Yea! The Leopard NDA is finally lifted. This is a submission for a new osg plugin, osgdb_ImageIO. This is the first piece of the puzzle that we need to get 64-bit support on OS X. This plugin is intended to partially replace the current osgdb_qt (classic Quicktime) plugin. There are many issues with the current osgdb_qt, but perhaps the biggest is that there are many APIs used in it that have been marked deprecated for awhile now and will not make it to 64-bit on OS X. ImageIO is Apple's (semi-)new (as of 10.4 Tiger) fundamental image framework that provides access to all image formats handled by the platform. This new osgdb_ImageIO plugin intends to replace all of osgdb_qt's image handling duties as well as introduce support to new image formats as they become available to the platform (e.g. JPEG2000, RAW, HDR, etc). osgdb_ImageIO does not replace osgdb_qt's movie handling capabilities. I envision that to be handled by a planned second plugin using Apple's semi-new (10.4 Tiger) QuickTimeKit framework, tentatively osgdb_QTKit. So this plugin is just the first step. Would you please add this to src/osgPlugins/ImageIO? Improvements over osgdb_qt plugin: - Supports istream and ostream - Supports a lot more image formats - ImageIO framework should be well supported from 10.4 to the future (which should include 64-bit and new/future image formats) - Doesn't require explicit initialization/close-out - (Hopefully) efficient...avoids the manual byte-by-byte manipulation of the old QuickTime plugin. Calls Apple's Accelerate framework when useful. - Seems to fix/avoid AutoreleasePool related leak warnings which I believe the current qt plugin triggers if not using Cocoa (i.e. actually having an autorelease pool created). Missing: - No movie file support (planning/expecting a separate QTKit plugin to handle that). - Need to update osgDB::Registry for new plugin - Need to update build system(s) Additional Notes: - The old Quicktime plugin will need to remain for both Windows users (who happen to use it) and pre-10.4 OS X versions. It will also need to remain for movies until we get a QTKit plugin written. - This plugin probably could use additional testing for 16-bit/LUMINANCE/ALPHA stuff. I'm not terribly confident I understood what needs to happen in these cases so behavior could be different/broken compared to osgdb_qt. Once I figure out all the build system details, I'm proposing that for the next release of OSG, if building for OS X 10.4 or 10.5, the ImageIO plugin gets built and set as the default image handling plugin. For legacy 10.3 and Quicktime for Windows users, the existing osgdb_qt plugin should remain available. For now though, I wanted to make this piece of code available in case anybody has a pressing need to get 64-bit going soon. Thanks, Eric // Copyright Eric Wing // This plugin is the bridge to OS X's ImageIO framework // which provides access to all of Apple's supported image types. // This plugin plus the QTKit plugin obsoletes the old QuickTime plugin. // This requires 10.4+. (The old QuickTime plugin will not support 64-bit.) // Needs testing, especially in: // 8-bits per pixel (256 color vs GL_ALPHA, and what about GL_LUMINANCE)? // 16-bits per pixel (is GL_LUMINANCE_ALPHA a safe assumption?) // Non-power-of-two textures (especially odd sizes) // istream code path // ostream code path // write image, especially GL_LUMINANCE and GL_ALPHA paths and image formats other than PNG/JPEG // Enhancements needed: // Way to provide image type hint to ImageIO calls (via CFDictionary), // probably especially important for istream which lacks extension information. // Is there information we can use in the OSG options parameter? // For ImageIO framework and also LaunchServices framework (for UTIs) #include ApplicationServices/ApplicationServices.h // For the vImage framework (part of the Accerlate framework) #include Accelerate/Accelerate.h // Used because CGDataProviderCreate became deprecated in
Re: [osg-users] New ffmpeg plugin checked into svn/trunk
Hi Eric, This is my second attempt to send Eric Wing's plugin. The first one came through as far as I can see. 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
[osg-users] Wash DC OSG Users Group meeting?
Hi all -- Many of you have asked if there would be a UG meeting in conjunction with the upcoming OSG training in Washington DC, March 9-12 (see http://www.skew-matrix.com/training.html). The best evening for me would be the last day of the course, Thursday March 12. Unfortunately, the hotel I'm staying at does not have a meeting room available. Can anyone suggest an alternate location? (My hotel is just a few blocks away from the White House; perhaps President Obama would rent us a room? Ha ha.) Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Non-standard name for 3rdParty disables FreeTypeplugin
Oops, my mistake -- Your fix was not yet checked into svn. I took your change to the Find3rdPartyDecmake file from osg-submissions, and when I use that ALL WORKS CORRECTLY. So, we just need Robert to fold this into svn. Thanks for the quick fix, this is an excellent change. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Mattias Helsing Sent: Thursday, February 26, 2009 7:17 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Non-standard name for 3rdParty disables FreeTypeplugin Hi guys, I just posted on osg-submissions a fix for this. J-S is right. It's easy to fix so haven't been dealt with. As I now know this bug I know that the quick fix is to delete/remove entry FREETYPE_INCLUDE_DIR_ft2build and FREETPE_INCLUDE_DIR_freetype2 vars from the cmake cache after having set your preferred ACTUAL_3RDPARTY_DIR Mattias On 2/26/09, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Paul, Any idea why the non-standard name for the 3rdParty dir would cause this failure? This is an issue that has been there for a while but that no one bothered to fix until now because there's an easy workaround. The workaround is to open up CMake, and show the Advanced variables. You will probably see that some freetype-related variables are set to something-NOTFOUND. Set them to the right values and regenerate, and it will be fine. It's possible that other variables will also not be set correctly. So check all the values in the advanced list and make sure they're all set as they should, if not set them manually. I don't know enough about CMake to fix this. I can however give the exact failure mechanism if someone's interested: 1. Delete your CMake cache 2. Open CMake, point it to your source and build directory, and press Configure a first time. This will ask you which compiler to generate for, and some of the variables will appear in the CMake window. 3. Change ACTUAL_3RDPARTY_DIR manually. 4. Press Configure a second time. It would seem that if ACTUAL_3RDPARTY_DIR is manually changed, CMake is not able to detect all of the libs/includes that are needed. I expect there's a bug in our Find3rdPartyDependencies.cmake, but I wouldn't really know where to look and how to debug. Perhaps Mattias or Philip can help here? In the mean time, I hope the workaround above helps you a bit, Paul. 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 ___ 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] Vec3d - Vec3 bug under Linux ?
Hi, Robert you were right (what as surprise ;-) ) A \ at the end of a line was making a line being commented, but the IDE do not show it as commented... (each compiler do not consider the same syntax) Sorry for the inconvenience. Thanks, Regards, Vincent. 2009/2/26 Paul Melis p...@science.uva.nl: Robert Osfield wrote: Hi Vincent, I can't work out exactly what to bug is in your instance, from the contents of your email it sounds like windows and linux compilers are evaluating the conversion of types in a different order and getting different results, or that their is a compiler bug. The fact that adding an explicit Vec3d() into your code suggests to me Isn't that an explicit cast to Vec3f()? As osg::Vec3 defaults to Vec3f... Paul that it's not likely to be an OSG issue, rather a compile one. Robert. On Thu, Feb 26, 2009 at 2:25 PM, Vincent Bourdier vincent.bourd...@gmail.com wrote: Hi all, I was thinking about posting in osg submission, but I don't have nothing to submit. I just had a little bug, solved now, but I thing this can be an interessting point for OSG to notice. To make a special geometry, I did a function returning a new vertex Array. In the code, all was based on Vec3d, including the return data (osg::ref_ptrosg::Vec3dArray ) Under windows, no problem for nothing. Under Linux, 2 of the 9 Vec3d of the array were wrong, and not constant (sometinme a wrong value, sometimes an other wrong value). to solve the problem, I just use vertices-push_back(osg::Vec3(ptA + decal - x*2.0 + z*1.5 + x*0.5 ))) instead of vertices-push_back(ptA + decal - x*2.0 + z*1.5 - x*0.5) and now all is good. Is there any unsafe conversion from Vec3d to vec3 ? I solve the problem for my application, but maybe someone have any explanation ... or maybe a bug is here... don't know.. Regards, Vincent. ___ 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] New ffmpeg plugin checked into svn/trunk
Jean-Sébastien Guay wrote: Hi Eric, This is my second attempt to send Eric Wing's plugin. The first one came through as far as I can see. J-S Thanks for the feedback. The first time I sent it, I got back a couple of error email messages, and I didn't check them carefully to see where they had come from, so I sent it again, without attaching the original email. It looks like a couple of users work at places that prohibit .eml attachments. Hopefully the plugin won't get lost again, though. -Eric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Streaming of high resolution images
J.P. Delport wrote: Hi, are you creating a new image every time using osgDB::readImageFile? If so, then you might be just plain running out of memory if you are not destroying old images. Yes, I load a certain number of images (a lot of images, for example 20.000 at 1400x1050 resolution-jpg or tga) with readImageFile at the initialization of the application and I load them in memory (inside std::vectorosg::Image*) at startup. To visualize all the images in a smoothing way (like a movie) with play, forward, rewind, skipToNextFrame, skipToPreviousFrame command I iterate the array elements. My problem is that I can load inside the vector a little number of images (about one hundred). Then I have not enough memory error. I suppose that this error is normal because I load all the uncompressed images in memory (also with .jpg) and I'm looking for a method to solve this problem. I have already tried to destroy old images but in that case there is the following problem: the process of loading images from my hard disk to ram require about two times the time required for visualization at 30 fps so it arrives a moment where the buffer is full. As regards ramdisk probably it could be a solution (implementing parallel threads) but on Windows it has portability problems due to the installation of a driver that probably I cannot install on target PC of my application. Thanks all for the useful answers (you are giving me new roads to follow) Francesco Argese -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7514#7514 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Wash DC OSG Users Group meeting?
Paul Martz wrote: Hi all -- Many of you have asked if there would be a UG meeting in conjunction with the upcoming OSG training in Washington DC, March 9-12 (see http://www.skew-matrix.com/training.html). The best evening for me would be the last day of the course, Thursday March 12. Unfortunately, the hotel I'm staying at does not have a meeting room available. Can anyone suggest an alternate location? (My hotel is just a few blocks away from the White House; perhaps President Obama would rent us a room? Ha ha.) I'm not very familiar with what's open in the area late. I would suggest the Corner Bakery on 14th (about a block east of the White House), but they close at 6. Perhaps a nearby hotel would have a small room available? Union Station has several less expensive eating options and they close at 9, but it's not very close to the White House. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] CMake 2.6a build system and OpenSceneGraph - problems with long paths?
Hi, I've been trying to build OpenSceneGraph 2.8.0 from source, using Visual C++ 2008. I noticed a strange effect with the CMake 2.6a build system that results in some examples not getting built. I've placed OpenScenegraph in a subdirectory of the default Visual Studio 2008 projects folder and selected the a build subdirectory for generating the binaries (and project files) separately from source. D:\Documents and Settings\Christian Buchner\My Documents\Visual Studio 2008\Projects\SON\dependencies\openscenegraph-2.8.0\OpenSceneGraph Some examples with the longest filenames are not getting built. The EXE files are missing, yet the .obj files are being created. Visual C++ reports a Compiling... phase, but omits the Linking... phase. So I would expect th .EXE files to be generated in the following folder D:\Documents and Settings\Christian Buchner\My Documents\Visual Studio 2008\Projects\SON\dependencies\openscenegraph-2.8.0\OpenSceneGraph\build\bin But in my case the following examples have not been built (naturally leading to a failure to build the INSTALL project) osganimationskinning osganimationtimeline osgmultiplerendertargets osgmultitexturecontrol osgpackeddepthstencil osgwidgetperformance Now the questions are - who is to blame and how can we fix it? - myself for making too long paths? - CMake ? - Visual Studio 2008 (Standard) ? - Windows ? If anyone has run into similar problems and/or knows a remedy, please let me know. In the mean time I will such things as shortening the path, for example by renaming dependencies to deps and build to bld. I would definitely like to stay in the default location for Visual Studio projects - and I also want to keep my Windows user name ;-) Christian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Streaming of high resolution images
Hi, maybe you can exercise the new ffmpeg plugin that Robert just comitted :) Take your images and stick them into an avi file with mencoder, e.g.: mencoder mf://*.jpg -ovc lavc -lavcopts vcodec=ljpeg:keyint=1 -mf fps=30 -o mynewavi.avi you can select other codec if you want. If you can tolerate compression, try mjpeg instead of lossless (ljpeg). You will have to balance disk speed vs uncompress time on cpu. If the ffmpeg plugin or ffplay or mplayer can play your avi at 30fps then at least you know your hardware can handle the rate. Playing in reverse at full rate might be more difficult. Not sure if the plugin supports single frame step either. jp Francesco Argese wrote: J.P. Delport wrote: Hi, are you creating a new image every time using osgDB::readImageFile? If so, then you might be just plain running out of memory if you are not destroying old images. Yes, I load a certain number of images (a lot of images, for example 20.000 at 1400x1050 resolution-jpg or tga) with readImageFile at the initialization of the application and I load them in memory (inside std::vectorosg::Image*) at startup. To visualize all the images in a smoothing way (like a movie) with play, forward, rewind, skipToNextFrame, skipToPreviousFrame command I iterate the array elements. My problem is that I can load inside the vector a little number of images (about one hundred). Then I have not enough memory error. I suppose that this error is normal because I load all the uncompressed images in memory (also with .jpg) and I'm looking for a method to solve this problem. I have already tried to destroy old images but in that case there is the following problem: the process of loading images from my hard disk to ram require about two times the time required for visualization at 30 fps so it arrives a moment where the buffer is full. As regards ramdisk probably it could be a solution (implementing parallel threads) but on Windows it has portability problems due to the installation of a driver that probably I cannot install on target PC of my application. Thanks all for the useful answers (you are giving me new roads to follow) Francesco Argese -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7514#7514 ___ 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] Problems with non-resized NPOT texturesandtrilinear min filter
Robert,
I tracked the problem down to where it is failing down in
Texture::mipmapAfterTexImage(), which ultimately gets called from the
call to applyTexImage2D_load() in Texure2D::apply().
void Texture::mipmapAfterTexImage(State state, GenerateMipmapMode
beforeResult) const
{
switch (beforeResult)
{
case GENERATE_MIPMAP:
{
unsigned int contextID = state.getContextID();
TextureObject* textureObject = getTextureObject(contextID);
if (textureObject) === IS NULL
{
osg::FBOExtensions* fbo_ext =
osg::FBOExtensions::instance(contextID, true);
fbo_ext-glGenerateMipmapEXT(textureObject-_target);
}
}
break;
o
o
o
}
The passed in value of beforeResult is GENERATE_MIPMAP. The call to
getTextureObject(contextID) simply returns:
/** Returns a pointer to the texture object for the current
context. */
inline TextureObject* getTextureObject(unsigned int contextID)
const
{
return _textureObjectBuffer[contextID].get();
}
Since r8606 moved the assignment of _textureObjectBuffer[contextID] to
*after* the call to applyTexImage2D_load() it's returning a NULL pointer
so the call to glGenerateMipmapEXT never occurs. No error message is
displayed so we're none the wiser.
Considering that the assignment to _textureObjectBuffer[contextID] was
moved in order to avoid a crash, where should the assignment occur in
order to avoid crashes while still properly generating MipMaps?
-- Dan
-Original Message-
From: Gilbert, Daniel R.
Sent: Thursday, February 26, 2009 7:17 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Problems with non-resized NPOT
texturesandtrilinear min filter
Robert,
Thanks for confirming that it isn't just me. Well, at least
on machines
with an Nvidia card. Does anyone with an ATI card experience
this same
issue with the samples I posted?
I'll try digging deeper as you suggest, though like I mentioned in my
original post I was able to make it work simply by reverting the
location of the _textureObjectBuffer assignment in
Texture2D.cpp back to
where it was before r8606.
-- Dan
-Original Message-
From: Robert Osfield [mailto:robert.osfi...@gmail.com]
Sent: Thursday, February 26, 2009 12:58 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Problems with non-resized NPOT
textures andtrilinear min filter
Hi Dan,
On Wed, Feb 25, 2009 at 10:02 PM, Gilbert, Daniel R.
daniel.r.gilb...@saic.com wrote:
Are others able to reproduce this same behavior using my
attached sample?
Just tried the test models on my Kubuntu 8.10/Gefore8800GTS
cards and I get:
npot_skydome_linear_noresize.osg works.
npot_skydome_trilinear_noresize.osg fails.
npot_skydome_trilinear_resize.osg works.
I also don't get any OpenGL errors when
npot_skydome_trilinear_noresize.osg fails.
Any thoughts on how to attempt a fix?
It could well be a driver issue, but also might be an OSG issue...
When you have a model without mipmaps you have to generate them,
either by using gluScaleImage or using the one of the two hardware
mipmap extension. It'd be worth digging into osg::Texture/Texture2D
to see what code paths it's taking to ask for the mipmap generation.
Robert.
___
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 J-S, On Thu, Feb 26, 2009 at 4:07 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: But are people who go to the OSG site necessarily people who use OSG? That's the extrapolation I was referring to. I would have thought there would be a reasonable correlation between visitors to openscenegraph.org and users. For existing users there is obviously a very good correlation. For the rest of the visitors it's case of either accidentally coming across the OSG, in which I would more normal spread of OS/browser usage, or vistors that are genuinely looking at the OSG as possible candidate for use, for this set of visitors the conversion from evaluator to final users I would expect on less conversions of Windows users than users of other OS's given allure of D3D under Windows and the OSG's lack of support for it. Actually I think you're being a little tetchy. How is pointing aspects browser stats extremist? I wasn't referring to browser stats when saying you're extremist, but more to your general comments on Windows, and how (most) people who use Windows are buying into MS and being blinded by their PR, and so on. In the past few weeks I had the impression that you were making some blanket statements, not necessarily including the Windows users on this list (I didn't feel directly pointed out, at least) but most of the Windows users. My guess is that the Windows users/developers in the OSG community are likely to be less MS centric than the the majority of Windows developers/end users/purchasers. So if I do sweep a broad brush about being overly swayed by MS PR, it's the later category that I feel is where the problem lies. The problem lies in that non MS solutions don't get a fair shout even if they are as good or better solutions. Clients of OSG app developers asking for a D3D port is a case where less tech savy end users are being swayed by the MS PR machine. Seeing signs of movement away from previously entrenched MS products is encouraging, as it gives more oxygen to the argument that solutions like OpenGL are a positive attribute, for those struggling to convince end users about it's value can point to MS not necessarily producing the best technology, and that open solutions are viable and making headway. As a non Windows users I'm pretty aware of lots of places where lack of standards and portability restricts computing life unnecessary, it's not technical issues, it's issues of monopoly and a strangle hold over software and hardware vendors. If you are a Windows users then you'll probably be less aware of places where your computing life might otherwise be impinged upon as your in the MS blessed eco-system. It's a tool for a job, making it into a war is useless. I'm not trying to make war. I'm try to give perspective on what seems to be happening in the OSG community and what that might mean more widely. OK, so you're making the assumption that if 60% of visitors on the site are using Windows, but only 25% use IE, then people seem to not be buying into MS's PR anymore? I would say that the advances of Open Source software (in terms of visibility, quality, etc.) have had a large hand in that. And I agree, being in the same boat myself (Windows user but open source software user wherever I can). There has been in the past a noticeable entrenchment of the view that MS products are best, or that no alternative exists. I see it particularly in on tech communities, such as family and non tech friends where IE == internet, Word == word processor, rather than these just being products. The idea that their are alternatives to IE, let along Windows takes a bit of time to get over. Even in non tech circles we see people claiming the demise of OpenGL, and that gaming == Direct3D, both of which are demonstrably wrong, and it's MS's PR machine that has successfully engineering this. So that's good news right? It is indeed good news, it's one of key points of me posting the stats. To highlight that fact that for our community at least things aren't as MS centric as they were previously. Given the context for Gordon Tomlison's recent email about Direct3D an assertions that some clients ask for Direct3D simply because they think it's better, I think it's important to point out stats, as it's one of the tools that we have available. Times have certainly changed dramatically in the browser market, extrapolating this to a suggestion that other parts of the software eco-system might be also ripe for change as well I don't think is too unreasonable. I agree. And BTW I've been silent about your list of concrete actions, but I'll help there as much as I can of course. Just because I'm a Windows user doesn't make me self-centered :-) Having a viable choice is a good thing, having competitors to IE and even Windows starting to get on to a more level footing will mean that you'll have the choice of which platforms suits you best, and MS will be forced to start
Re: [osg-users] Non-standard name for 3rdParty disables FreeTypeplugin
phieuu, you had me worried in your previous post :-) Nice to hear that it's working now. Thanks for testing Mattias On Thu, Feb 26, 2009 at 4:51 PM, Paul Martz pma...@skew-matrix.com wrote: Oops, my mistake -- Your fix was not yet checked into svn. I took your change to the Find3rdPartyDecmake file from osg-submissions, and when I use that ALL WORKS CORRECTLY. So, we just need Robert to fold this into svn. Thanks for the quick fix, this is an excellent change. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Mattias Helsing Sent: Thursday, February 26, 2009 7:17 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Non-standard name for 3rdParty disables FreeTypeplugin Hi guys, I just posted on osg-submissions a fix for this. J-S is right. It's easy to fix so haven't been dealt with. As I now know this bug I know that the quick fix is to delete/remove entry FREETYPE_INCLUDE_DIR_ft2build and FREETPE_INCLUDE_DIR_freetype2 vars from the cmake cache after having set your preferred ACTUAL_3RDPARTY_DIR Mattias On 2/26/09, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Paul, Any idea why the non-standard name for the 3rdParty dir would cause this failure? This is an issue that has been there for a while but that no one bothered to fix until now because there's an easy workaround. The workaround is to open up CMake, and show the Advanced variables. You will probably see that some freetype-related variables are set to something-NOTFOUND. Set them to the right values and regenerate, and it will be fine. It's possible that other variables will also not be set correctly. So check all the values in the advanced list and make sure they're all set as they should, if not set them manually. I don't know enough about CMake to fix this. I can however give the exact failure mechanism if someone's interested: 1. Delete your CMake cache 2. Open CMake, point it to your source and build directory, and press Configure a first time. This will ask you which compiler to generate for, and some of the variables will appear in the CMake window. 3. Change ACTUAL_3RDPARTY_DIR manually. 4. Press Configure a second time. It would seem that if ACTUAL_3RDPARTY_DIR is manually changed, CMake is not able to detect all of the libs/includes that are needed. I expect there's a bug in our Find3rdPartyDependencies.cmake, but I wouldn't really know where to look and how to debug. Perhaps Mattias or Philip can help here? In the mean time, I hope the workaround above helps you a bit, Paul. J-S -- __ Jean-Sebastien Guay jean-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 ___ 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] openscenegraph.org stats
Hi Robert, It's a tool for a job, making it into a war is useless. I'm not trying to make war. I'm try to give perspective on what seems to be happening in the OSG community and what that might mean more widely. But you have to realize that even you aren't 100% objective, no one is. Your views are skewed by your background just as much as anyone else's. IMHO the situation with Windows users at large is less bleak than what you make out, the recent situation with Vista coming in far below expectations helped on that front. Non-tech people are starting to see that there are alternatives, and that (other than MacOS) a choice of hardware doesn't lock you onto a single OS. But that's a matter of opinion and we don't have any cold facts (other than perhaps the actual market share of Windows vs other OSes, but that won't be reflected by web server stats). We can just hope that people making products are choosing their APIs based on merit instead of based on a misguided idea of which API will sell more products... In the end I don't think a user cares whether DirectX or OpenGL is under the hood, the results are what counts, but the people managing projects are choosing one or the other sometimes for the wrong reasons I agree. It is indeed good news, it's one of key points of me posting the stats. To highlight that fact that for our community at least things aren't as MS centric as they were previously. And perhaps that's a trend that's larger than our community only? (I hope so) Having a viable choice is a good thing, having competitors to IE and even Windows starting to get on to a more level footing will mean that you'll have the choice of which platforms suits you best, and MS will be forced to start competing with better products rather than abusing it's monopoly position (like it's done so far with OpenGL/D3D). Yes, which is why I don't agree with those who say D3D should die. 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] Qt mouse wheel zoom howto
Hi Martin,
I had a try at doing this through TrackBallManipulator
This seems to work, tested on Windows with viewerQT and viewer.Each mouseWheel
click zooms in/out by 10%
I'm not an expert and would welcome any suggestions about better ways to do
this.
That looks a bit like how we did it in our local codebase, except that
instead of acting directly on _distance, in our case we set dy to 0.1 or
-0.1 (depending on scroll up or down) and then let the normal mouse
zooming functionality do the zooming calculations:
if (_ga_t0-getEventType() == osgGA::GUIEventAdapter::SCROLL)
{
dy = _ga_t0-getScrollingMotion() ==
osgGA::GUIEventAdapter::SCROLL_DOWN ? 0.1 : -0.1;
}
It works well too, perhaps you can compare the two and see which one you
like best in terms of behavior. I don't know if zooming in/out by 10%
per mouse wheel click is too much or too little, I haven't tested your
code directly...
And in our case, we didn't add a completely separate case for SCROLL in
the handle() method, just piggybacked on top of the DRAG case:
case (osgGA::GUIEventAdapter::SCROLL):
case (osgGA::GUIEventAdapter::DRAG):
{
// ...
}
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] Problems with non-resized NPOT texturesandtrilinear min filter
HI Dan,
I don't know the answer to this off the top of my head. These changes
are party of a 3rd party submission that I reviewed but now can't
remember the details. I'm afraid I'm juggling a couple of tasks right
now so can't dive into look into debugging this issue right away.
Perhaps others who've tinkered with this code will be able to spot the
problem/and a solution, if not then I'll come back to this once I've
cleared my intray a bit more.
Robert.
On Thu, Feb 26, 2009 at 5:45 PM, Gilbert, Daniel R.
daniel.r.gilb...@saic.com wrote:
Robert,
I tracked the problem down to where it is failing down in
Texture::mipmapAfterTexImage(), which ultimately gets called from the
call to applyTexImage2D_load() in Texure2D::apply().
void Texture::mipmapAfterTexImage(State state, GenerateMipmapMode
beforeResult) const
{
switch (beforeResult)
{
case GENERATE_MIPMAP:
{
unsigned int contextID = state.getContextID();
TextureObject* textureObject = getTextureObject(contextID);
if (textureObject) === IS NULL
{
osg::FBOExtensions* fbo_ext =
osg::FBOExtensions::instance(contextID, true);
fbo_ext-glGenerateMipmapEXT(textureObject-_target);
}
}
break;
o
o
o
}
The passed in value of beforeResult is GENERATE_MIPMAP. The call to
getTextureObject(contextID) simply returns:
/** Returns a pointer to the texture object for the current
context. */
inline TextureObject* getTextureObject(unsigned int contextID)
const
{
return _textureObjectBuffer[contextID].get();
}
Since r8606 moved the assignment of _textureObjectBuffer[contextID] to
*after* the call to applyTexImage2D_load() it's returning a NULL pointer
so the call to glGenerateMipmapEXT never occurs. No error message is
displayed so we're none the wiser.
Considering that the assignment to _textureObjectBuffer[contextID] was
moved in order to avoid a crash, where should the assignment occur in
order to avoid crashes while still properly generating MipMaps?
-- Dan
-Original Message-
From: Gilbert, Daniel R.
Sent: Thursday, February 26, 2009 7:17 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Problems with non-resized NPOT
texturesandtrilinear min filter
Robert,
Thanks for confirming that it isn't just me. Well, at least
on machines
with an Nvidia card. Does anyone with an ATI card experience
this same
issue with the samples I posted?
I'll try digging deeper as you suggest, though like I mentioned in my
original post I was able to make it work simply by reverting the
location of the _textureObjectBuffer assignment in
Texture2D.cpp back to
where it was before r8606.
-- Dan
-Original Message-
From: Robert Osfield [mailto:robert.osfi...@gmail.com]
Sent: Thursday, February 26, 2009 12:58 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Problems with non-resized NPOT
textures andtrilinear min filter
Hi Dan,
On Wed, Feb 25, 2009 at 10:02 PM, Gilbert, Daniel R.
daniel.r.gilb...@saic.com wrote:
Are others able to reproduce this same behavior using my
attached sample?
Just tried the test models on my Kubuntu 8.10/Gefore8800GTS
cards and I get:
npot_skydome_linear_noresize.osg works.
npot_skydome_trilinear_noresize.osg fails.
npot_skydome_trilinear_resize.osg works.
I also don't get any OpenGL errors when
npot_skydome_trilinear_noresize.osg fails.
Any thoughts on how to attempt a fix?
It could well be a driver issue, but also might be an OSG issue...
When you have a model without mipmaps you have to generate them,
either by using gluScaleImage or using the one of the two hardware
mipmap extension. It'd be worth digging into osg::Texture/Texture2D
to see what code paths it's taking to ask for the mipmap generation.
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] Qt mouse wheel zoom howto
I had a try at doing this through TrackBallManipulator This seems to work, tested on Windows with viewerQT and viewer.Each mouseWheel click zooms in/out by 10% I'm not an expert and would welcome any suggestions about better ways to do this. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7522#7522 TrackballManipulator.cpp Description: Binary data ___ 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 J-S, On Thu, Feb 26, 2009 at 6:11 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: IMHO the situation with Windows users at large is less bleak than what you make out, the recent situation with Vista coming in far below expectations helped on that front. Non-tech people are starting to see that there are alternatives, and that (other than MacOS) a choice of hardware doesn't lock you onto a single OS. Things are certainly get better than they were a couple of years ago. Netbooks and cloud computing are two factors. Vista being harder to use than XP, breaking people applications/dropping support for hardware is something that even my parents complained about vigorously when they were forced to purchase Vista on new hardware. We are still a long way from having genuine choice about hardware and software though. MS has a tremendously right grip on almost every PC manufacturer save for Apple and the specialist Linux firms. The only easy way of matching the hardware your want with the OS you want is build it yourself, this obviously isn't what the average users wants to do. But that's a matter of opinion and we don't have any cold facts (other than perhaps the actual market share of Windows vs other OSes, but that won't be reflected by web server stats). We can just hope that people making products are choosing their APIs based on merit instead of based on a misguided idea of which API will sell more products... In the end I don't think a user cares whether DirectX or OpenGL is under the hood, the results are what counts, but the people managing projects are choosing one or the other sometimes for the wrong reasons I agree. This will still be an uphill struggle when you see death of OpenGL articles being published, it requires one to see beyond this FUD. OSG users obviously already have, but I would guess to do loose potential users purely because of the year in year out FUD against OpenGL. This are certainly getting better, but there is still a massive way to go in getting the playing field levelled. It is indeed good news, it's one of key points of me posting the stats. To highlight that fact that for our community at least things aren't as MS centric as they were previously. And perhaps that's a trend that's larger than our community only? I think the trend for browsers is a wider one. None Windows OS's are certainly on the rise too, but no where near the penetration of non Windows OS's we see in our browser stats. This probably reflects that nature of the applications that OSG users develop, and perhaps the fact that tech savy users are more able to understand and act upon their preferred choice of OS. Having a viable choice is a good thing, having competitors to IE and even Windows starting to get on to a more level footing will mean that you'll have the choice of which platforms suits you best, and MS will be forced to start competing with better products rather than abusing it's monopoly position (like it's done so far with OpenGL/D3D). Yes, which is why I don't agree with those who say D3D should die. Some places competition is good, but not typically in the area of standards. OpenGL is an open standard, Direct3D is a close standard that is pushed my a monopoly with the explicit intent of destroying its competing open standard. If Direct3D hadn't existing we'd have vendors competing between quality of their OpenGL drivers, instead we have them competing primarily in Direct3D performance/quality, and OpenGL drivers from most vendors have sadly seemed to play a very distant second in priority. It really isn't a huge waste of hardware vendors time having to work on two separate HAL's for their hardware, it's a idotic situation and an extremely bad engineering solution to a problem in hand. The find it very hard to reconcile the view that competition between OpenGL and Direct3D is beneficial. One only has to point to Intel and ATI OpenGL as clear proof of the damage that is has done. Robert. ___ 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 All, I have just upload Tanguy's Windows LGPL build of ffmpeg at the last stable svn rev (ffmpeg doesn't do official stable releases I'm afraid). You can grab the .zip file containing headers and libs at: http://www.openscenegraph.org/downloads/dependencies/FFmpeg/Windows/ffmpeg-r15261.zip The current CMakeModules/FindFFmpeg.cmake won't pick on this package yet as I've just coded pkg-config path for it, so you'll need to tweak the .cmake find script to find it. Once you have you should hopefully be able to get a running ffmpeg soon after. To use it do: osgmovie -e ffmpeg mymovie.mpg No audio yet, but the video should work. Robert. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Positioning PrecipitationEffect
Hi Robert, I'm playing around with the osgprecipitation example and noticed that it doesn't work as I would expect for large models. For example, osgprecipitation lz.osg works fine, but osgprecipitation lz.osg.100,100,100.scale doesn't show any rain unless you zoom in closely to 0,0,0. Is there a way to make the precipitation effect follow the camera so that is always appears to be raining? I attempted to use the setPosition method of particle effect on each frame to the eye point of the camera, but that didn't seem to do anything. I also tried sticking the PrecipitationEffect under a MatrixTransform and translating the MatrixTransform to the eye point of the camera each frame and it didn't seem to work correctly either. It seemed like it only respected the initial positioning and ignored all subsequent transforms. Thanks! Jason ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgswig: iterating over a vertex array
The following code appears to work:
def apply_Geode(self,ge):
for i in range(ge.getNumDrawables()):
geom = ge.getDrawable(i).asGeometry()
if geom:
arr = geom.getVertexArray()
if arr.getType() != osg.Array.Vec3ArrayType:
raise LumError, 'Type of vertex array not
three-element vectors'
# aagh!
sz = arr.getDataSize()
pvec =
ctypes.pointer(c_float.from_address(int(arr.getDataPointer(
o = 0
for i in range(arr.getNumElements()):
self.file.write(' %f %f %f\n' % (pvec[o],
pvec[o+1], pvec[o+2]))
o += sz
I do not recommend this as a coding style, but it seems to be the only
way to do this at the moment.
Randolph
Gerwin de Haan wrote:
Hi Randolph,
this is a typical problem of (python) wrappers; the getVertexArray
returns a general Array, which is currently not wrapped. The trick
would be to somewhere cast the general Array back to its specific
type in Python, e.g. a Vec3Array. We've used some of these tricks in
the wrappings themselves by a dynamic_cast through C++ run-time type
information (not accessible to users), and some you can access
yourself, e.g. osg.Node.asLOD .
To fix your particular problem we might introduce extensions to Array
such as osg.Array.asVec3Array etc, or better would be to automatically
let SWIG convert all returning values of Array to its real type. In
any case this means diving into SWIG specifics. I'll post this as an
issue on the list
(http://code.google.com/p/osgswig/issues/detail?id=27), but I cannot
give guarantees when it will be picked up.
Gerwin
On Thu, Feb 26, 2009 at 5:19 AM, Randolph Fritz rfr...@u.washington.edu wrote:
I'm writing a prototype OSG to Radiance exporter in Python. I've got to the
point of code that iterates over all geodes in the scene graph. Problem
is--then what? Is the only way to read the elements of the arrays ctype and
pointers? Or is there something a bit simpler and safer?
Perhaps-relevant bit of code:
def apply_Geode(self,ge):
for i in range(ge.getNumDrawables()):
geom = ge.getDrawable(i).asGeometry()
if geom:
arr = geom.getVertexArray()
for i in range(arr.getNumElements()):
# This doesn't seem to work--what does?
arr.accept(i,self.val)
--
Randolph Fritz
design machine group
architecture department
university of washington
rfr...@u.washington.edu
___
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
--
Randolph Fritz
design machine group
architecture department
university of washington
rfr...@u.washington.edu
___
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, We are still a long way from having genuine choice about hardware and software though. MS has a tremendously right grip on almost every PC manufacturer save for Apple and the specialist Linux firms. The only easy way of matching the hardware your want with the OS you want is build it yourself, this obviously isn't what the average users wants to do. You would want manufacturers to offer a choice of OS when buying a PC? Non tech-savvy people won't know what to choose between Linux, Windows, etc. when they buy a PC, so pushing the choice all the way down to them doesn't make sense. They'll just go with whatever has the most publicity on TV or something, and we'll be right where we started. This are certainly getting better, but there is still a massive way to go in getting the playing field levelled. Massive I don't know. It's much better than it was, and I think we only need a bit more of a push to get to where competition is healthy and everyone has an equal chance. I think the trend for browsers is a wider one. None Windows OS's are certainly on the rise too, but no where near the penetration of non Windows OS's we see in our browser stats. This probably reflects that nature of the applications that OSG users develop, and perhaps the fact that tech savy users are more able to understand and act upon their preferred choice of OS. Agreed. Some places competition is good, but not typically in the area of standards. OpenGL is an open standard, Direct3D is a close standard that is pushed my a monopoly with the explicit intent of destroying its competing open standard. If Direct3D hadn't existing we'd have vendors competing between quality of their OpenGL drivers, instead we have them competing primarily in Direct3D performance/quality, and OpenGL drivers from most vendors have sadly seemed to play a very distant second in priority. It really isn't a huge waste of hardware vendors time having to work on two separate HAL's for their hardware, it's a idotic situation and an extremely bad engineering solution to a problem in hand. The find it very hard to reconcile the view that competition between OpenGL and Direct3D is beneficial. One only has to point to Intel and ATI OpenGL as clear proof of the damage that is has done. I don't agree with you on that. OpenGL is an API. Direct3D is an API. They're not standards... If a video card manufacturer wants a good market share in most areas, they'll support both and support them well. If they focus on whatever market D3D caters to, they'll focus on D3D support. Now, if one graphics API were really standard, kind of like x86 assembly, then we could have one that all video cards talk and have compilers that would compile OpenGL and D3D programs for that assembly language. As far as I know that's what the video card drivers do anyways, so having competition between OpenGL and D3D is kind of like competition between C and Pascal (say) and I see nothing bad with that. Pick what you want to pick and makes sense for your projects. It's how to determine what makes sense for your projects that's hard, but I expect there were similar discussions back when C++ was a young language. ATI OpenGL is a specific case, their D3D drivers were very bad at one point too (heck, even their 2D Windows drivers would crash the machine at one point!), and I guess they wanted to improve D3D before working on OpenGL. Which they are apparently doing - I saw FlightGear running on a multi-display ATI-based set up running Linux (therefore OpenGL) at Siggraph 2008 and it ran very well. It was on public display at ATI's booth, so presumably they want to publicize that they're working on their OpenGL/Linux drivers. Sure it's just one example, but I think it's getting better. Intel is another special case: most of their integrated display hardware has no accelerated 3D support, period! So I don't think you can say they have bad OpenGL support... Hopefully Larrabee changes that. Anyways... Opinions, opinions... :-) 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
Hi Robert, Tanguy, I have just upload Tanguy's Windows LGPL build of ffmpeg at the last stable svn rev (ffmpeg doesn't do official stable releases I'm afraid). What compiler are those for? VC8 SP1 I assume? Might be nice to make a directory with the compiler like for the OSG binaries, so someone else can contribute a build for VC9 SP1 and VC7.1, etc. 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] OFT: Interesting commentary of the future of OpenGL
I can think of a least two ways to support multiple backends without sacrificing performance. 1) We generally acknowledge that a system of wrappers will provide portability (to different backends) at the expense of performance. However, a scene graph could be designed in such a way that it supports one backend close to the metal and other backends using wrappers. Consider the existing Drawable draw callback; if no callback is attached, we use the native draw mechanism, otherwise the callback (jump through function pointer) handles the drawing. Such a mechanism could be used to support OpenGL natively and other backends through the callback. 2) Use a factory pattern. On an unrelated note, I've heard many people assert that gaming has driven the creation of high-performance rendering hardware. This is an incomplete picture. In the mid-90s when commercial (non-workstation) graphics hardware first became available, getting gamers to use hardware acceleration was a hard sell. They mostly snubbed their noses at PC graphics cards, preferring to code software renderers in assembly to get the performance they needed. Up until the late-90s, it was high-end CAD, molecular modeling, etc., that was solely responsible for the growth of accelerated 3D graphics and eventual emergence of commercial graphics hardware. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problems with non-resized NPOT texturesandtrilinearmin filter
Robert,
Sounds good. Thanks for taking the time to verify that you were able to
reproduce the problem on your end.
-- Dan
-Original Message-
From: Robert Osfield [mailto:robert.osfi...@gmail.com]
Sent: Thursday, February 26, 2009 10:47 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Problems with non-resized NPOT
texturesandtrilinearmin filter
HI Dan,
I don't know the answer to this off the top of my head. These changes
are party of a 3rd party submission that I reviewed but now can't
remember the details. I'm afraid I'm juggling a couple of tasks right
now so can't dive into look into debugging this issue right away.
Perhaps others who've tinkered with this code will be able to spot the
problem/and a solution, if not then I'll come back to this once I've
cleared my intray a bit more.
Robert.
On Thu, Feb 26, 2009 at 5:45 PM, Gilbert, Daniel R.
daniel.r.gilb...@saic.com wrote:
Robert,
I tracked the problem down to where it is failing down in
Texture::mipmapAfterTexImage(), which ultimately gets
called from the
call to applyTexImage2D_load() in Texure2D::apply().
void Texture::mipmapAfterTexImage(State state, GenerateMipmapMode
beforeResult) const
{
switch (beforeResult)
{
case GENERATE_MIPMAP:
{
unsigned int contextID = state.getContextID();
TextureObject* textureObject =
getTextureObject(contextID);
if (textureObject) === IS NULL
{
osg::FBOExtensions* fbo_ext =
osg::FBOExtensions::instance(contextID, true);
fbo_ext-glGenerateMipmapEXT(textureObject-_target);
}
}
break;
o
o
o
}
The passed in value of beforeResult is GENERATE_MIPMAP. The call to
getTextureObject(contextID) simply returns:
/** Returns a pointer to the texture object for the current
context. */
inline TextureObject* getTextureObject(unsigned int
contextID)
const
{
return _textureObjectBuffer[contextID].get();
}
Since r8606 moved the assignment of
_textureObjectBuffer[contextID] to
*after* the call to applyTexImage2D_load() it's returning a
NULL pointer
so the call to glGenerateMipmapEXT never occurs. No error
message is
displayed so we're none the wiser.
Considering that the assignment to
_textureObjectBuffer[contextID] was
moved in order to avoid a crash, where should the
assignment occur in
order to avoid crashes while still properly generating MipMaps?
-- Dan
-Original Message-
From: Gilbert, Daniel R.
Sent: Thursday, February 26, 2009 7:17 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Problems with non-resized NPOT
texturesandtrilinear min filter
Robert,
Thanks for confirming that it isn't just me. Well, at least
on machines
with an Nvidia card. Does anyone with an ATI card experience
this same
issue with the samples I posted?
I'll try digging deeper as you suggest, though like I
mentioned in my
original post I was able to make it work simply by reverting the
location of the _textureObjectBuffer assignment in
Texture2D.cpp back to
where it was before r8606.
-- Dan
-Original Message-
From: Robert Osfield [mailto:robert.osfi...@gmail.com]
Sent: Thursday, February 26, 2009 12:58 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Problems with non-resized NPOT
textures andtrilinear min filter
Hi Dan,
On Wed, Feb 25, 2009 at 10:02 PM, Gilbert, Daniel R.
daniel.r.gilb...@saic.com wrote:
Are others able to reproduce this same behavior using my
attached sample?
Just tried the test models on my Kubuntu 8.10/Gefore8800GTS
cards and I get:
npot_skydome_linear_noresize.osg works.
npot_skydome_trilinear_noresize.osg fails.
npot_skydome_trilinear_resize.osg works.
I also don't get any OpenGL errors when
npot_skydome_trilinear_noresize.osg fails.
Any thoughts on how to attempt a fix?
It could well be a driver issue, but also might be an
OSG issue...
When you have a model without mipmaps you have to generate them,
either by using gluScaleImage or using the one of the
two hardware
mipmap extension. It'd be worth digging into
osg::Texture/Texture2D
to see what code paths it's taking to ask for the mipmap
generation.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce
negraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Qt mouse wheel zoom howto
Thanks Jean-Sébastien, You can't reuse (osgGA::GUIEventAdapter::DRAG) case in handle() because the scroll event needs to be cleared. I like the idea of reusing the drag and 'dy' - I have rewritten it with that approach. It does lead to having to declare a couple of variables before they can be set which seems to be against OSG house style (and is generally a bad idea) I can only test on windows, but so long as the other windows toolkits add mouse wheel events to the GUIEventAdapter it should just work. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7534#7534 TrackballManipulator.cpp Description: Binary data ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OFT: Interesting commentary of the future of OpenGL
OpenGL was a major concern in me choosing OSG for a commercial product. I have issues with our current product where there are drawing bugs due to OpenGL drivers (Dell laptops !) and I have to tell customers to update. It's also not beyond belief that MSFT could simply decide to lock OpenGL out of a future version of windows (or cripple it) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7535#7535 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Qt mouse wheel zoom howto
Hi Martin,
You can't reuse (osgGA::GUIEventAdapter::DRAG) case in handle() because the scroll event needs to be cleared.
That's how we do it, and I didn't see any problems... Our code is quite
close to:
case (osgGA::GUIEventAdapter::SCROLL):
case (osgGA::GUIEventAdapter::DRAG):
{
addMouseEvent(ea);
if (calcMovement()) aa.requestRedraw();
aa.requestContinuousUpdate(false);
_thrown = false;
return true;
}
and it works great. Perhaps there's something else that is different.
We've subclassed TrackballManipulator and replaced most of its
functionality with similar (but not quite identical) code...
I like the idea of reusing the drag and 'dy' - I have rewritten it with that
approach. It does lead to having to declare a couple of variables before they
can be set which seems to be against OSG house style (and is generally a bad
idea)
It's not that bad, since you only have an if and an else it can't really
fall through the cracks. As with any programming convention I tend to be
pragmatic...
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] Positioning PrecipitationEffect
Hi Jason, osgParticle::PrecipitationEffect is design to be effectively infinite, no matter how far you move it should repeat endlessly. I've done lots of testing on town sized models and it certainly works in this context fine. My guess is that your scaling of the scene has introduced issues that the shader isn't able to cope with for some reason. Try loaded a model that is of a 1:1 scale to see if it works fine. Robert. On Thu, Feb 26, 2009 at 7:29 PM, Jason Beverage jasonbever...@gmail.com wrote: Hi Robert, I'm playing around with the osgprecipitation example and noticed that it doesn't work as I would expect for large models. For example, osgprecipitation lz.osg works fine, but osgprecipitation lz.osg.100,100,100.scale doesn't show any rain unless you zoom in closely to 0,0,0. Is there a way to make the precipitation effect follow the camera so that is always appears to be raining? I attempted to use the setPosition method of particle effect on each frame to the eye point of the camera, but that didn't seem to do anything. I also tried sticking the PrecipitationEffect under a MatrixTransform and translating the MatrixTransform to the eye point of the camera each frame and it didn't seem to work correctly either. It seemed like it only respected the initial positioning and ignored all subsequent transforms. Thanks! 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
Re: [osg-users] [osgPPU] Multisampling/RenderBuffer Support
Art, I'm glad you were able to get the fbo to work in osgPPU. Now you appear to be at the point I'm at with my application where the resultant texture is no longer HDR and appears to be clamped at 1.0. This is not the case with the Nvidia SDK sample (hdr) and I've tried to figure out what OSG is doing differently, but so far have not found anything. Ken -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7538#7538 ___ 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
Robert Osfield wrote: This doesn't solve the problem of providing the audio sink though... only possibility would be to have osgmovie use something like SDL to provide the audio, or we could even provide an option in the plugin to use SDL. SDL on macs plays silly games with Cocoa though so you end up odd dependencies even if you don't use video so I'm not convinced this is a clean solution as it could be. So members of the community, what audio libraries should be on our list of targets? Do we even go as far as integrating osgAL/osgAudio directly into the core just to enable this plugin to gain the option of audio? OpenAL is an obvious possibility for this. The OpenAL-Soft implementation at http://kcat.strangesoft.net/openal.html supports almost all of the platforms that OSG supports, and there are also hardware implementations of OpenAL for some sound cards (mostly Creative Labs). There is also a dedicated OSX implementation. You wouldn't necessarily need to go so far as to integrate osgAudio yet. Simple streaming from ffmpeg could probably be implemented with just a few lines of OpenAL code. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Qt mouse wheel zoom howto
Skylark wrote:
case (osgGA::GUIEventAdapter::SCROLL):
case (osgGA::GUIEventAdapter::DRAG):
{
addMouseEvent(ea);
if (calcMovement()) aa.requestRedraw();
aa.requestContinuousUpdate(false);
_thrown = false;
return true;
}
On Windows at least with viewer/viewerQT if you don't call
flushMouseEventStack() the handle() gets called repeatedly.
I suppose because there isn't really an end event for a mouse scroll.
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=7541#7541
___
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 J-S, On Thu, Feb 26, 2009 at 7:35 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: I don't agree with you on that. OpenGL is an API. Direct3D is an API. They're not standards... If a video card manufacturer wants a good market share in most areas, they'll support both and support them well. If they focus on whatever market D3D caters to, they'll focus on D3D support. Please go check out the the specs on OpenGL. It is a open standard. It's up to vendors to create OpenGL drivers to this standard. It's not an API like the OSG is an API, OpenGL is a standard with an standardised API. It's a standard that is derived from a standards body - this is what Khronos is all about. Now, if one graphics API were really standard, kind of like x86 assembly, then we could have one that all video cards talk and have compilers that would compile OpenGL and D3D programs for that assembly language. As far as I know that's what the video card drivers do anyways, so having competition between OpenGL and D3D is kind of like competition between C and Pascal (say) and I see nothing bad with that. Pick what you want to pick and makes sense for your projects. It's how to determine what makes sense for your projects that's hard, but I expect there were similar discussions back when C++ was a young language. I'm afraid you have not grasped what OpenGL is about. It's a standardised hardware abstraction layer. It's meant to solve the problem of targeting multiple hardware types across multiple platforms so application developers don't have to worry about the platform specifics, they just write to the standard and it works. Having two competing standards that address the same job is very rarely a healthy phenomenon. It just fragments and breaks down interoperability. It also spreads drivers writing too thinly. It's been a case of divide an conquer, MS have used their monopoly clout to marginalize OpenGL as much as they could. The quality of OpenGL drivers has very clearly been harmed by this. ATI OpenGL is a specific case, their D3D drivers were very bad at one point too (heck, even their 2D Windows drivers would crash the machine at one point!), and I guess they wanted to improve D3D before working on OpenGL. Which they are apparently doing - I saw FlightGear running on a multi-display ATI-based set up running Linux (therefore OpenGL) at Siggraph 2008 and it ran very well. It was on public display at ATI's booth, so presumably they want to publicize that they're working on their OpenGL/Linux drivers. Sure it's just one example, but I think it's getting better. Intel is another special case: most of their integrated display hardware has no accelerated 3D support, period! So I don't think you can say they have bad OpenGL support... Hopefully Larrabee changes that. ATI and Intel two special cases of poor OpenGL support? We'll that only leaves one mainstream vendor that provides acceptable OpenGL drives, and it make it the exception to the rule - so surely NVidia is the special case here, not ATI and Intel. Anyways... Opinions, opinions... :-) The fact is that the majority of our graphics vendors produce OpenGL drivers that we as community universally regard as being not good enough. This is not good for us, it's not good for our end users it's not good for the hardware vendors. It become speculation/opinion and the exact cause of this situation. From my perspective the only beneficiary of this situation is MS, something that it engineered by using is monopoly position to push Direct3D and sideline OpenGL. Knowing how we got to just point can certainly help to refine how we go about trying to redress it, which is why I think it's important to look at this recently history with unclouded vision. What I really really want is for use to have high quality OpenGL drivers, in a perfect world open sourced ones so we can fix them and support them directly. Once we get this, then we have level playing field, and there on whole topic of Direct3D will be an irrelevance. We still have to struggle to get to this point though, and unfortunately it's us that can directly make it happen. The best we can do is try to influence the commitment to OpenGL from hardware vendors, either directly or through wider support for OpenGL. Robert. ___ 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 J-S, On Thu, Feb 26, 2009 at 7:38 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: What compiler are those for? VC8 SP1 I assume? Might be nice to make a directory with the compiler like for the OSG binaries, so someone else can contribute a build for VC9 SP1 and VC7.1, etc. Tanguy said that the libs were built using MSYS+MinWG+GCC, but should be compatible with various VS version thanks to it being C library. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Qt mouse wheel zoom howto
Hi Martin, On Windows at least with viewer/viewerQT if you don't call flushMouseEventStack() the handle() gets called repeatedly. I suppose because there isn't really an end event for a mouse scroll. We're on Windows, and we have a Qt-based application running this (among others)... But we don't need to call flushMouseEventStack()... I don't know what to say. :-) 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] OFT: Interesting commentary of the future of OpenGL
Hi Martin, On Thu, Feb 26, 2009 at 8:16 PM, Martin Beckett osgfo...@tevs.eu wrote: OpenGL was a major concern in me choosing OSG for a commercial product. I have issues with our current product where there are drawing bugs due to OpenGL drivers (Dell laptops !) and I have to tell customers to update. I feel your anguish on this. We have to get better OpenGL drivers out there. It's also not beyond belief that MSFT could simply decide to lock OpenGL out of a future version of windows (or cripple it) Well this was the case originally for Vista, but it was lobbying by big companies that used OpenGL turned it around. Amongst these some OSG users were very active and uncompromising in the push for allowing OpenGL driver to function fully. Potentially if the OSG had a Direct3D path then this lobbying wouldn't have been so direct, and there that it might not have swung the right way for us. If proper OpenGL drivers hadn't been on Vista then many many software vendors would have been in big trouble, having to accept huge engineering costs refactoring or loss of market share. The stakes were pretty high. When stakes are high sometime you have to hold your nerve. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OFT: Interesting commentary of the future of OpenGL
Thanks Nintendo and Sony for their usage of OpenGL! ;) Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 26 Feb 2009 17:10:19 +0100, Cory Riddell c...@codeware.com a écrit: Robert- Robert Osfield wrote: Well the gaming market is very big, BUT the gaming market isn't just Windows/D3D, its much bigger than that. The Wii and Playstation2 have been the big consoles of the last ten years, neither of which have anything to do with D3D. MS would like to associate gaming with exclusivie use of D3D but this is just a marketing ploy. Ah- very good point. For some reason I wasn't thinking of consoles. It's just hardware, it isn't D3D hardware, again we have to be careful not to tricked by the MS marketing. Unfortunately all too often it is very closed hardware and proprietary drivers. If the hardware works significantly better with the D3D API, then I call it a D3D card. How about a bad analogy (sorry, I couldn't think of a car analogy): a Macintosh is just a PC, but the software makes it a Mac. I sounds like the OSG hits quite a good balance for yourself so far - provides enough functionality to do your job without worry about the details such as the thin API abstraction. By contast Paul Martz at the start of thread emphasised that the thinness of the layer above OpenGL that the OSG provides is one of it's main selling points. To be able to satisfy two different types of users needs/desires means that we've been successful. Absolutely. This is the diverse community I talked about. This seems mostly to be a pretty pragmatic bunch of people, so I'm fairly confident that if D3D support doesn't materialize, it is for technical rather than religious reasons. Thanks, Cory ___ 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 Robert, Please go check out the the specs on OpenGL. It is a open standard. It's up to vendors to create OpenGL drivers to this standard. It's not an API like the OSG is an API, OpenGL is a standard with an standardised API. It's a standard that is derived from a standards body - this is what Khronos is all about. Is OpenGL ratified by the ISO? No. So it's not a standard. The fact that it's a spec made by a consortium doesn't mean it's a standard, because not all companies are on that consortium and there's no way to force other companies to follow the standard (which is why we're having this whole discussion - perhaps it should become a real standard). I'm afraid you have not grasped what OpenGL is about. It's a standardised hardware abstraction layer. It's meant to solve the problem of targeting multiple hardware types across multiple platforms so application developers don't have to worry about the platform specifics, they just write to the standard and it works. In practice that's not what happens... That's the ideal case but it doesn't exist. In fact, we're lucky we only have OpenGL and Direct3D to argue about. Back in 1995-1998, on the PC side (commodity graphics hardware), each vendor had their API (look up Glide from 3Dfx, RRedline from Rendition, etc.) and games would support a list of 3D accelerators but certainly not all of them. I remember having to replace the executable for Tomb Raider 1 for another one when I changed from a Matrox Mystique to a 3Dfx Voodoo2 card. :-) Having two competing standards that address the same job is very rarely a healthy phenomenon. I have a different view. Competition is always good. I doubt we'd have OpenGL 3.0 drivers right now (let alone a final OpenGL 3.0 spec) if it wasn't for the ongoing Direct3D vs OpenGL debate (and the OpenGL is dead articles). Yes it spreads FUD that some buy into, but the APIs themselves progress faster when there's competition. ATI and Intel two special cases of poor OpenGL support? We'll that only leaves one mainstream vendor that provides acceptable OpenGL drives, and it make it the exception to the rule - so surely NVidia is the special case here, not ATI and Intel. Please actually read my arguments instead of just focusing on the wording. You can't refute the fact that Intel's hardware is not really 3D accelerators, rather decelerators and that is in both Direct3D and OpenGL. So that dismisses one case right there, we're left with NVidia and ATI. As for ATI's driver quality, as I said it was a generalized problem, not specific to OpenGL drivers, not that long ago. That may be a part of the picture that you missed, but which gamers are all too familiar with. Up until a few years ago, ATI was behind not because of the speed of its chips, but because of the quality of its drivers. Anyways, I'll let you get back to your work. I don't think we're getting anywhere. Thanks for the server stats in any case, it's interesting. 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
[osg-users] Understanding message handling
Can anyone give me the scoop on how gui event messages are handled with osgViewer? I'm trying to get the viewer running inside a GUI toolkit (in this case MFC). It's mostly working for me except for event propagation. Basically I've noticed that if you do osg::GraphicsContext::createGraphicsContext and pass it an hwnd then a couple of things happen: One the osgViewer::GraphicsWindowWin32 registers a WindowProc function with windows. This causes the function to be called back by default and respond to messages. HOWEVER since we provided an hWnd to it then GraphicsWindowWin32 has _ownsWindow marked false. As a result it registers for messages, reacts to them, but never returns a value saying it handled the message. This doesn't seem like a great way to do it to me. I have no way to know if OSG handled the event (such as a key press). If I assume it did handle it, I get in trouble. If I assume it didn't handle it, I get in trouble. To granularly figure this out would be a major pain. Maybe there is another way I should be setting this up. Can anyone shed some light? Thanks -Brad ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Qt mouse wheel zoom howto
Aha - I had _thrown=true in my scroll case ! For simplicity I will have SCROLL and DRAG together as you do. If somebody needs scroll to do more/different it is easy to add as a special case. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7549#7549 TrackballManipulator.cpp Description: Binary data ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OFT: Interesting commentary of the future of OpenGL
Hi Paul, On Thu, Feb 26, 2009 at 7:53 PM, Paul Martz pma...@skew-matrix.com wrote: I can think of a least two ways to support multiple backends without sacrificing performance. 1) We generally acknowledge that a system of wrappers will provide portability (to different backends) at the expense of performance. However, a scene graph could be designed in such a way that it supports one backend close to the metal and other backends using wrappers 2) Use a factory pattern. With my own considerations of moving to an API agnostic scene graph the issue of performance is one that has loomed large in my mind. We absolutely want to avoid any performance degradation in this move for any of the targets - that's the gold standard which we should strive for. There are couple of elements to the performance side, first up is the cost of abstraction. Right now we have StateSttributes with a virtual function that calls OpenGL C functions to pass state to OpenGL. A refactor method system could in theory create the concrete classes for us that do the subclassing of the the interface and thereby work with just the exiting virtual function. To do this we have to change the way we construct scene graphs. Such an approach would also limit us to only use one type of GraphicsContext in an application, which isn't too much of a limit. A second element to performance is that of multi-threading. Right now we don't buffer the scene graph so the current DrawThreadPerContext/CullThreadPerCameraDrawThreadPerContext has to hold back the next frame till all dynamic state + drawables are dispatched. This means we are limiting the opportunity for parallelism. So.. how do we solve this one... buffer dynamic parts of the scene graph? How do we do this without really complicating the OSG? One of my thoughts was perhaps the graphics context rendering back end could create it's own own objects to cache the data locally, rather than read from the the scene graph in the draw thread. Such caching of graphics objects could possibly be done by attaching this rendering API specific objects to the scene graph objects, and then updating these cached objects when the scene graph objects are updated. This approach is a bit similar to the factory approach, but pushes the factory into the rendering backend rather than the scene graph interface. There will be other approaches as well.. Need to spend more time pontificating about it... Robert. ___ 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
Indeed. I have heard of Linux users configuring browsers to act report being other browsers, I presume other platform/browsers do the same. I'm curious where this practice would be most common. Using Opera, you can switch your browser identification in one or two clicks. And you even can set (and save) identification for a particular site that is not browser-firendly... And I know many users that let Opera to be masked as IE (this is different from identify as ... because the Opera string simply diseapear when using Mask as ...). That way, ill-designed sites can be viewed normally. I don't really know about Firefox, but I guess this is the same thing (Firefox is a cool browser too, IMO, and I as far as I know it provides a set of features comparable to Opera). Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 26 Feb 2009 16:42:04 +0100, Robert Osfield robert.osfi...@gmail.com a écrit: Hi J-S, On Thu, Feb 26, 2009 at 2:46 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Well, some people disable the sending of OS information by their browser, so it's possible that a number of those actually would fall into the other categories (Linux, Windows etc.) Indeed. I have heard of Linux users configuring browsers to act report being other browsers, I presume other platform/browsers do the same. I'm curious where this practice would be most common. I'd doubt that IE users would try and mimic something other than Windows/IE as the issue in compatibility tends to be websites excluded non IE or non Windows platforms. Perhaps this strong showing of non windows OS's and non IE browsers in the graphics community might be useful in helping win over clients that go demanding MS specific solutions. The tide has turned. I find your wording funny... All dramatic and foreboding. 60% is still huge. 60% is the majority so indeed huge. But... it's very different than the 90 or 95% figure that you see often claimed about for desktop client usage, something that is certainly worthy of mention. We are very different in terms of make up, with around four times as many non Windows users as we might expect given other published figures. While the majority are working under Windows, 40% is not a small minority of non windows machines. And keep in mind that's just visits to the web site... I don't think we can have a direct correlation between website visits and OSG usage. It would be a pretty big extrapolation. A big extrapolation, but typically people will develop and browse under the same platform. A few years back Don Burns did a poll of platform usage and the percentages were around 45% developed for Windows, and 40% developed for Linux, with a large number developing for both. So the figures I've published today probably aren't too surprising from our own community perspective. It's how different we are from wider averages than it surprising for me. The most surprising thing to me was just how dominant Firefox has come. I'm pretty sure a few years back it would have been IE totally dominating. And the browser stats mean nothing since Firefox, Opera and others run on Windows, Linux, etc. I know many people who avoid IE like the plague, even though they run Windows. I use Firefox just because I like it more and I try to use Open Source software wherever I can. You're being pretty extremist in this whole thing. You have to understand that people can use Windows for many reasons, not only technical ones, and it's not because someone uses Windows that they're necessarily buying into MS's propaganda. It's not as clear-cut as that. IMHO, Windows is just another tool, it's superior in some respects and inferior in others, and people will choose to use it or not (sometimes for the wrong reasons, but in general you don't know those reasons so you can't make a judgement on them...) and there's nothing you or I can do about that. Actually I think you're being a little tetchy. How is pointing aspects browser stats extremist? Never did I map Firefox usage to non Windows usage, the figures don't support this and I didn't suggest this. I put the two sets of stats in two separate blocks each with own quick thoughts on what this meant each individually. What is clear from the stats is that our community contains many more non windows users that the average populace. We provide a cross platform toolkit so this isn't too surprising, it's a self selective set of people visiting our website. For me a real eye opener is that Firefox has risen so rapidly, the mind share that MS once had over Windows developers clearly has ebbed dramatically in the case of browsers. Clearly MS's OS have faired better than their browser, and kept more market share, but OS's are far more of a bed rock of daily work than a single replaceable application, replacing it is not far from easy or desirable in many
