Re: [osg-users] Colors and Lighting
Hi Renan, On Fri, Mar 28, 2008 at 4:39 PM, Renan Mendes [EMAIL PROTECTED] wrote: I'm new at OSG and computer graphics in general, so I'd like to ask a few very simple questions: 1) When I use an osg::Vec4 for setting the clear color, I have, of course, 4 parameters. The first three are the proportion of red, green and blue. But what does the last one do? red, green, blue, alpha alpha controls how transparent it is. 2) This question is linked to the last one, I think: how do I change the intensity of the light in my scene? With an osg::LightSource, see the osglight example. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgText + NVidia driver bug fix checked in
Hi All, Thanks to Sherman Wilcox the cause of the crash in osgText looks to have been tracked down to a problem with some NVidia drivers handling subloading of 0 sized data that was triggered by spaces in text. While this actually is a legal size but it causes the NVidia driver to crash no less - so very much looks to be an Nvidia driver bug hence why most users don't see it. However, it doesn't actually make much sense to call OpenGL with a 0 sized subload so we can easily work around but not calling OpenGL in this instance. I've checked in Sherman's fix, could users who've seen this problem do an svn update and let me know how you get on. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] (VPB) osgdem not providing terrain heights with --tile-terrain-size --tile-image-size options
Hi Scott, The tile dimensions aren't controlled in size, it's purely done in post dimensions. If you don't need high res heights then just set the --tile-terrain-size size to something like 16 and then limit the number of levels provide using -l numlevels. Robert. On Fri, Mar 28, 2008 at 10:36 PM, Hulet, Scott S [EMAIL PROTECTED] wrote: Robert, So then, is there a way to control the terrain tile size? For instance, how would I set the coarsest terrain tile to be a single tile per geocell (20 meters on a side), an then have it sub-divide from there? With the default settings and the dataset that I am using, osgdem creates 11 levels and creates ~40m triangles at the finest resolution. I am building a DB for an application that does not require this type of resolution/fidelity. I'd like to generate an OSG DB that targets a 400m traingle at the finest resolution. HI Scott, The max tile sizes is in number of pixels/height field cells, neither are in meters. Robert. Scott S. Hulet * Simulation Training and Support They never forget who they're dying for... We can never forget who we're working for... Lockheed Martin Corp - STS Akron 1210 Massillon Road Mailpoint C2E, AB-33 Akron, OH 44315-0001 ( Phone Numbers: 330.796.6616 (Desk) 330.796.1059 (Lab) 330.242.2385 (Cell) 6 Fax: 330.796.4050 ___ 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] [VPB] Overriding source reprojection requirement in vpbmaster
Hi Glenn, It's correct vpbmaster refuses to do a build if the sources aren't all the same coordinate system as otherwise running osgdem on multiple processes at the same time would cause multiple reprojections on the same data at the same time and an unholy mess. The way to manage the reprojection is do it as a preprocessing step, creating a cache of reprojected data. For this you use another tool vpbcache. I'm looking after my little 4 year old right now so can't answer any further right now - we're going out for walk!! Robert. On Sat, Mar 29, 2008 at 12:50 AM, Glenn Waldron [EMAIL PROTECTED] wrote: Robert, I've noticed that vpbmaster refuses to continue if it detects that all sources are not in the same coordinate system. I can certainly understand why. That said, is there a way to override this decision and tell vpbmaster to trust me that all sources are in a common projection? Case in point: GDAL's ECW (ER Mapper compressed wavelet raster) plugin is sometimes not able to correctly parse the coordinate system information in the file. (This is a known issue -- http://www.gdal.org/frmt_ecw.html). So vpbmaster won't run since it thinks the ECW is in a different projection than other input layers. I tried using the --cs option to manually specify the CS; also --ReprojectSources False; no luck in either case. I'm running on Win32 with the latest SVN head of OSG and VPB. Glenn -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : 703-652-4791 ___ 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] Rewrite of DatabasePager::removeExpiredSubgraphs(double)
Hi Robert,
Great improvement! Memory usage dropped almost 6 fold for our paged scenes,
from oscillating around 350MB to rock solid 60MB (WinXP).
Many thanks,
Maciej
2008/3/28, Robert Osfield [EMAIL PROTECTED]:
Hi All,
Testing that I've been carrying out on some new big terrain databases
has shown some real weaknesses in the DatabasePager ability to load
balance - with memory footprint growing significantly when the camera
moves fast over wide areas of high res data. Memory usage was growing
to over 4GB and blowing our test computers, hardly something that is
desired for a database paging system that is supposed to maintain a
modest memory footprint.
After much investigation the cause of the rather unconstrained memory
usage has been traced to the slow speed that the DatabasePager was
expiring (removing) no longer visible subgraphs - subgraphs were
correctly ear marked for removal but idsyncrosies in the threading and
original DatabasePager::removeExpiredSubgraphs(..) method meant that
it would take many frames to finally let go expired subgraphs. It in
fact was taking long enough that new data was coming in at a far
faster rate than it was been removed at hence the dramatic growth in
memory footprint.
The solution has been to rewrite
theDatabasePager::removeExpiredSubgraphs(..) method that is
responsible for expiring subgraph and setting them aside for deletion.
I've now got this new implementation working and sees a memory
footprint halved which not affecting the visual quality on screen.
Performance is now much more stable and crashes due to excessive
memory consumption are gone on my test machine. With this rewrite a
couple member variables and their associated set/getters are no longer
required, and rather leave them around for potential confusion I've
removed them completely so an svn update if you get an compile error
just remove the below methods and recompile.
-/** Set the maximum number of PagedLOD child to remove per frame
*/
-void setMaximumNumOfRemovedChildPagedLODs(unsigned int
number) { _maximumNumOfRemovedChildPagedLODs = number; }
-
-/** Get the maximum number of PagedLOD child to remove per frame
*/
-unsigned int getMaximumNumOfRemovedChildPagedLODs() const {
return _maximumNumOfRemovedChildPagedLODs; }
-
-/** Set the minimum number of inactive PagedLOD child to keep */
-void setMinimumNumOfInactivePagedLODs(unsigned int number) {
_minimumNumOfInactivePagedLODs = number; }
-
-/** Get the minimum number of inactive PagedLOD child to keep */
-unsigned int getMinimumNumOfInactivePagedLODs() const {
return _minimumNumOfInactivePagedLODs; }
I would like to improve this method further still as I've already come
up with a better load balancing algorithm to implement in this method,
however, it'll take a while longer to implement, so rather than wait
for this polished implementation I'm checking in what is working
effectively, albeit not perfect it is far better than what was there
before.
There are other aspects of the DatabasePager that need attention too,
such as the high cost of DatabasePager::requestNodeFile() method
during cull traversal when many file requested are queued up. This is
something that has been raised on the list before by others, so it's a
bit of common theme when we really start to push the size of paged
databases we are dealing with. I will be spending more time on this
code over the coming month, so feel free to chip in with your own
experiences.
Cheers,
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rewrite of DatabasePager::removeExpiredSubgraphs(double)
Hi Maciej, On Sat, Mar 29, 2008 at 10:41 AM, Maciej Krol [EMAIL PROTECTED] wrote: Great improvement! Memory usage dropped almost 6 fold for our paged scenes, from oscillating around 350MB to rock solid 60MB (WinXP). Wow, far better than I was even expecting, great to hear that thing a now load balancing far better - this is one of the key points of doing paging. Thanks for the feedback, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [VPB] Overriding source reprojection requirement in vpbmaster
Hi Glenn, If VPB is reading the coordinate systems for the source and the required target coordinate system and not matching them it'll reproject, this matching does rely upon the WTK strings to be equal, so perhaps this is where the divergance is occurring. I don't have any ECW data or plugin available under Linux so I can test this route personally. Try using gdal to convert from ECW to GeoTiff and pass the GeoTiff's into VPB. Robert. On Sat, Mar 29, 2008 at 12:28 PM, Glenn Waldron [EMAIL PROTECTED] wrote: Robert, I didn't explain myself properly. All my data is indeed reprojected in advance. The issue is that vpbmaster just *thinks* the data needs reprojection -- I suspect the fault lies with the ECW plugin -- and so I'd like to override the check and tell vpbmaster to forge ahead anyway and treat the data as if it needs no reprojection. Which it doesn't. :) Does that make sense? I hope you enjoyed your walk! Glenn On Sat, Mar 29, 2008 at 5:20 AM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Glenn, It's correct vpbmaster refuses to do a build if the sources aren't all the same coordinate system as otherwise running osgdem on multiple processes at the same time would cause multiple reprojections on the same data at the same time and an unholy mess. The way to manage the reprojection is do it as a preprocessing step, creating a cache of reprojected data. For this you use another tool vpbcache. I'm looking after my little 4 year old right now so can't answer any further right now - we're going out for walk!! Robert. On Sat, Mar 29, 2008 at 12:50 AM, Glenn Waldron [EMAIL PROTECTED] wrote: Robert, I've noticed that vpbmaster refuses to continue if it detects that all sources are not in the same coordinate system. I can certainly understand why. That said, is there a way to override this decision and tell vpbmaster to trust me that all sources are in a common projection? Case in point: GDAL's ECW (ER Mapper compressed wavelet raster) plugin is sometimes not able to correctly parse the coordinate system information in the file. (This is a known issue -- http://www.gdal.org/frmt_ecw.html). So vpbmaster won't run since it thinks the ECW is in a different projection than other input layers. I tried using the --cs option to manually specify the CS; also --ReprojectSources False; no luck in either case. I'm running on Win32 with the latest SVN head of OSG and VPB. Glenn -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : 703-652-4791 ___ 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 -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : 703-652-4791 ___ 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] [VPB] Overriding source reprojection requirement in vpbmaster
Robert, Exactly: it is quite possible for different WKT strings to represent the same CS -- I don't think there is a canonical WKT representation per se. I have the same challenge in osgGIS. ECW=GeoTIFF would work but ... unfortunately most of my ECW's are just plain large -- in one case I have 0.15m imagery covering 4000 sq kms. If you do have the time, I have uploaded a sample dataset that demonstrates the issue. There is a small ECW and a corresponding DEM (GeoTIFF). They are both WGS84. The build command line is included: http://pelicanmapping.com/downloads/ecw-sample.zip FWTools contains a pre-built GDAL library with ECW support included: http://fwtools.maptools.org/ Thanks again for your continued great work! I am especially appreciative of the upgrades to DatabasePager and look forward to test-driving this soon. Glenn On Sat, Mar 29, 2008 at 8:36 AM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Glenn, If VPB is reading the coordinate systems for the source and the required target coordinate system and not matching them it'll reproject, this matching does rely upon the WTK strings to be equal, so perhaps this is where the divergance is occurring. I don't have any ECW data or plugin available under Linux so I can test this route personally. Try using gdal to convert from ECW to GeoTiff and pass the GeoTiff's into VPB. Robert. On Sat, Mar 29, 2008 at 12:28 PM, Glenn Waldron [EMAIL PROTECTED] wrote: Robert, I didn't explain myself properly. All my data is indeed reprojected in advance. The issue is that vpbmaster just *thinks* the data needs reprojection -- I suspect the fault lies with the ECW plugin -- and so I'd like to override the check and tell vpbmaster to forge ahead anyway and treat the data as if it needs no reprojection. Which it doesn't. :) Does that make sense? I hope you enjoyed your walk! Glenn On Sat, Mar 29, 2008 at 5:20 AM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Glenn, It's correct vpbmaster refuses to do a build if the sources aren't all the same coordinate system as otherwise running osgdem on multiple processes at the same time would cause multiple reprojections on the same data at the same time and an unholy mess. The way to manage the reprojection is do it as a preprocessing step, creating a cache of reprojected data. For this you use another tool vpbcache. I'm looking after my little 4 year old right now so can't answer any further right now - we're going out for walk!! Robert. On Sat, Mar 29, 2008 at 12:50 AM, Glenn Waldron [EMAIL PROTECTED] wrote: Robert, I've noticed that vpbmaster refuses to continue if it detects that all sources are not in the same coordinate system. I can certainly understand why. That said, is there a way to override this decision and tell vpbmaster to trust me that all sources are in a common projection? Case in point: GDAL's ECW (ER Mapper compressed wavelet raster) plugin is sometimes not able to correctly parse the coordinate system information in the file. (This is a known issue -- http://www.gdal.org/frmt_ecw.html). So vpbmaster won't run since it thinks the ECW is in a different projection than other input layers. I tried using the --cs option to manually specify the CS; also --ReprojectSources False; no luck in either case. I'm running on Win32 with the latest SVN head of OSG and VPB. Glenn -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : 703-652-4791 ___ 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 -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : 703-652-4791 ___ 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 -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : 703-652-4791 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Annexing the old OpenSceneGraph/XCode directory, moving to using just CMake
Robert Osfield schrieb: Put this all together and I think we'd have to have really good reason not to migrate to entirely CMake build system. CMake does support XCode, and I presume that it has moved forward in its XCode support since this time last year so we should now be in a better position. Does CMake support building frameworks on OS X now? IMHO this was the missing key feature, stopping us using CMake on OS X. I'd like to get rid of the hand crafted XCode-files as soon as possible, but I have to stick with them as long Cmake can't build frameworks. I can live with an extra xcode-subversion repository holding all necessary files which is in control of Eric and/or me, so people can use the old xcode files, if they need to. just my 2 cents, Stephan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] 3D Texture mipmap
Hi, I'm encounter a problem with 3D texture mipmap. I try to setup my 3D texture with mipmaps enable by: volumeTexture-setFilter(osg::Texture3D::MIN_FILTER, osg::Texture3D::LINEAR_MIPMAP_LINEAR); volumeTexture-setFilter(osg::Texture3D::MAG_FILTER, osg::Texture3D::LINEAR_MIPMAP_LINEAR); And OSG gives me a runtime error: Error: gluBuild3DMipmaps not supported by OpenGL driver. I'm now using 8800GTS 320M with 174.74 under Windows Server 2008 system. I have found that gluBuild3DMipmaps function have not defined in glu.h. Google search result tells me that the gluBuild3DMipmaps only supported in GLU 1.3. I've found the GLU 1.3 here(http://www.geocities.com/vmelkon/glu.html), not official release. I replaced glu.h, glu32.lib, glu32.dll with GLU 1.3. But OSG always gives me the error. I also found nvidia OpenGL 2.0 document have this function description. My question is there any way to workaround the problem or can I manually create and use mipmap for 3D texture in OSG? Thanks guys! ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgText + NVidia driver bug fix checked in
Hi all, I've checked in Sherman's fix, could users who've seen this problem do an svn update and let me know how you get on. after svn-update and a complete rebuild I still have some issues . The behavior of the app is more stable now (when switching threading model modes), but it still crashes. Sometimes, the whole system is frozen. It is unpredictable behavior, sometimes it just crashes, wasn't able to repeat it. Ok, best to wait for the reports from other users. regards, Markus Testsystem: NVidia Drivers 169.12, Ubuntu Hardy Beta ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Annexing the old OpenSceneGraph/XCode directory, moving to using just CMake
HI Stephan, On Sat, Mar 29, 2008 at 1:44 PM, Stephan Huber [EMAIL PROTECTED] wrote: Does CMake support building frameworks on OS X now? IMHO this was the missing key feature, stopping us using CMake on OS X. I don't know the answer to this, I was hoping that OSX users might know. If it doesn't then moving the OSG across to only using CMake will be motivating factor to getting this sorted as if it hasn't been sorted in the past year then clearly there hasn't been enough attention placed on it. Even if frameworks aren't yet support I'd still suggest moving away from hand maintained XCode projects as one positive reason to keep hardly seems to compensate for the eight negatives. I'd like to get rid of the hand crafted XCode-files as soon as possible, but I have to stick with them as long Cmake can't build frameworks. Can CMake generated XCode projects not support frameworks with just some settings being changed via the Xcode app? I've always been perplexed at why this shouldn't be straight forward. I can live with an extra xcode-subversion repository holding all necessary files which is in control of Eric and/or me, so people can use the old xcode files, if they need to. You can check out other subversion branches within another - OpenThreads is already proves this, in the case of an optional external include the user would have to check it out, but I wouldn't have thought it too awkward - its just another svn checkout. Creating this extra hurdle is no bad thing, what I want is for CMake XCode path being the one that everyone users, just like CMake is used on other platforms so everyone tests this paths and makes sure its perfected. What I'm after is better support for OSX for as wide a range of users as possible, rather than good support for specific OSX and XCode versions with a specific set of dependencies that the two maintainers of the XCode projects just happen to use. I'll have a look at practicality of creating a copy of the XCode directory on the deprecated branch of the OSG's svn repository. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgText + NVidia driver bug fix checked in
Hi Markus, On Sat, Mar 29, 2008 at 2:41 PM, Markus Hein [EMAIL PROTECTED] wrote: I've checked in Sherman's fix, could users who've seen this problem do an svn update and let me know how you get on. after svn-update and a complete rebuild I still have some issues . The behavior of the app is more stable now (when switching threading model modes), but it still crashes. Sometimes, the whole system is frozen. It is unpredictable behavior, sometimes it just crashes, wasn't able to repeat it. Ok, best to wait for the reports from other users. I think we need to be careful about clumping different issues together, the fix from Sherman was a very specific workaround for a bug in the NVidia driver coping with zero sized texture subloads that was causing a crash (the stack trace would lead from the OSG into the NVidia driver via the osgText::Font's subloading code. Did you see this crash previously, if so is this now fixed? As for the other issues, are they text related? Do any OSG example exhibit this behaviour? When I run glxinfo | grep version I get: server glx version string: 1.4 client glx version string: 1.4 GLX version: 1.3 OpenGL version string: 2.1.1 NVIDIA 100.14.19 I'm using Kubuntu 7.10. As yet I haven't been able to recreate the problems with the divide by zero/NVidia bug. Robert. OpenGL version string: 2.1.1 NVIDIA 100.14.19 Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ANN: FLT export
Hi Jason -- Thanks for taking this code for a test drive. FLT doesn't support POINTS primitives, so those warnings are just FYI that you're exporting a scene graph that is ill-suited for export to FLT. The only comparable FLT entity would be a light point, but if you want light points, then you should use osgSim::LightPoint instead of GL_POINTS, so I think the FLT export code is doing the right thing here. Not sure where the NAN is coming from on re-import. If you osgconv your .ive file to .osg, do the tex coords look OK in the .osg file? The missing chunks of geometry are odd; clearly you have the latest FLT OSG plugin so you have support for continuation records. That's a stumper. Post a small reproducer scene graph if you can. Otherwise, my ability to assist is quite limited. Perhaps a good use of a couple hours of my time would be going in and adding more verbose output to the exporter. -Paul _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Daly Sent: Friday, March 28, 2008 2:36 PM To: OpenSceneGraph Users Subject: Re: [osg-users] ANN: FLT export Paul Martz wrote: Hi All -- I recently posted a change to osg-submissions that adds FLT export capability to OSG. Assuming it doesn't break the build, I expect Robert will have this available on current SVN soon. Hi, Paul, Great work! I tested with a fairly complex .ive. Originally this was an OpenFlight database. During export, I got a lot of these errors: fltexp: GL_POINTS not supported in FLT export. I'm not worried about actually exporting the points, as they weren't important anyway. I'm just mentioning them in case it's relevant for the real problem. This happened when I went to view the exported .flt file in osgviewer. During load, I got several groups of these two warnings: Warning: data error detected in VertexCNT::readRecord uv=nan nan Warning: data error detected in LocalVertexPool::readRecord uv=nan nan The file does eventually finish loading, and it looks fine for the most part. However, there are several objects in the scene that are missing large groups of faces. In each case, the bulk of the object is there, but there are large holes in it. Many of these objects used to be external references that were duplicated multiple times, and each copy looks the same. I really wish I could send you the file, but alas, I cannot. I'm sure this isn't enough information for you to go on. Let me know what else I can do to help. -- --J I'm a castaway stranded in a desolate land, I can see the footprints in the virtual sand. --Neil Peart ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Annexing the old OpenSceneGraph/XCode directory, moving to using just CMake
HI Stephan et. al, On Sat, Mar 29, 2008 at 3:08 PM, Robert Osfield [EMAIL PROTECTED] wrote: I'll have a look at practicality of creating a copy of the XCode directory on the deprecated branch of the OSG's svn repository. I have just done a : cd OpenSceneGraph svn update svn cp Xcode http://www.openscenegraph.org/svn/osg/OpenSceneGraph/deprecated/ You can browse via Tracs at: http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/deprecated Note the src/osgPlugins/flt plugin is already there, placed there last year. Thanks to svn all the history should be copied across as well. Stephan could you check this directory in a place sparate from the OSG and then see if you have permission to modify it? Another test would be to remove the local XCode directory and checkout the dprecated one instead. If things work out I could remove the OpenSceneGraph/XCode version. Thanks, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ANN: FLT export
Hi Paul, The case when the new flt load was complaining about GL_POINTS was on a dataset that I first loaded from .flt then converted to .ive and then from .ive to .flt. I don't know if it was light points in the original .flt file, or how the point got in there, but somehow they did. Robert. On Sat, Mar 29, 2008 at 3:23 PM, Paul Martz [EMAIL PROTECTED] wrote: Hi Jason -- Thanks for taking this code for a test drive. FLT doesn't support POINTS primitives, so those warnings are just FYI that you're exporting a scene graph that is ill-suited for export to FLT. The only comparable FLT entity would be a light point, but if you want light points, then you should use osgSim::LightPoint instead of GL_POINTS, so I think the FLT export code is doing the right thing here. Not sure where the NAN is coming from on re-import. If you osgconv your .ive file to .osg, do the tex coords look OK in the .osg file? The missing chunks of geometry are odd; clearly you have the latest FLT OSG plugin so you have support for continuation records. That's a stumper. Post a small reproducer scene graph if you can. Otherwise, my ability to assist is quite limited. Perhaps a good use of a couple hours of my time would be going in and adding more verbose output to the exporter. -Paul From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Daly Sent: Friday, March 28, 2008 2:36 PM To: OpenSceneGraph Users Subject: Re: [osg-users] ANN: FLT export Paul Martz wrote: Hi All -- I recently posted a change to osg-submissions that adds FLT export capability to OSG. Assuming it doesn't break the build, I expect Robert will have this available on current SVN soon. Hi, Paul, Great work! I tested with a fairly complex .ive. Originally this was an OpenFlight database. During export, I got a lot of these errors: fltexp: GL_POINTS not supported in FLT export. I'm not worried about actually exporting the points, as they weren't important anyway. I'm just mentioning them in case it's relevant for the real problem. This happened when I went to view the exported .flt file in osgviewer. During load, I got several groups of these two warnings: Warning: data error detected in VertexCNT::readRecord uv=nan nan Warning: data error detected in LocalVertexPool::readRecord uv=nan nan The file does eventually finish loading, and it looks fine for the most part. However, there are several objects in the scene that are missing large groups of faces. In each case, the bulk of the object is there, but there are large holes in it. Many of these objects used to be external references that were duplicated multiple times, and each copy looks the same. I really wish I could send you the file, but alas, I cannot. I'm sure this isn't enough information for you to go on. Let me know what else I can do to help. -- --J I'm a castaway stranded in a desolate land, I can see the footprints in the virtual sand. --Neil Peart ___ 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] [VPB] Overriding source reprojection requirement invpbmaster
Glenn Waldron writes: Robert, Exactly: it is quite possible for different WKT strings to represent the same CS -- I don't think there is a canonical WKT representation per se. I have the same challenge in osgGIS. ECW=GeoTIFF would work but ... unfortunately most of my ECW's are just plain large -- in one case I have 0.15m imagery covering 4000 sq kms. Glenn, Have you tried using GDAL's VRT format to pass the projection info http://www.gdal.org/gdal_vrttut.html In a nutshell create a .vrt file with the correct projection gdal_translate -of vrt -a_srs $YOUR_SRS $IN_FILE.ecw $OUT_FILE.vrt You may need to tweak the resultant .vrt file Then pass VPB the .vrt files instead of the ecw files Of course this assumes you know your desired SRS http://spatialreference.org/ is a handy site HTH Norman If you do have the time, I have uploaded a sample dataset that demonstrates the issue. There is a small ECW and a corresponding DEM (GeoTIFF). They are both WGS84. The build command line is included: http://pelicanmapping.com/downloads/ecw-sample.zip FWTools contains a pre-built GDAL library with ECW support included: http://fwtools.maptools.org/ Thanks again for your continued great work! I am especially appreciative of the upgrades to DatabasePager and look forward to test-driving this soon. Glenn On Sat, Mar 29, 2008 at 8:36 AM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Glenn, If VPB is reading the coordinate systems for the source and the required target coordinate system and not matching them it'll reproject, this matching does rely upon the WTK strings to be equal, so perhaps this is where the divergance is occurring. I don't have any ECW data or plugin available under Linux so I can test this route personally. Try using gdal to convert from ECW to GeoTiff and pass the GeoTiff's into VPB. Robert. On Sat, Mar 29, 2008 at 12:28 PM, Glenn Waldron [EMAIL PROTECTED] wrote: Robert, I didn't explain myself properly. All my data is indeed reprojected in advance. The issue is that vpbmaster just *thinks* the data needs reprojection -- I suspect the fault lies with the ECW plugin -- and so I'd like to override the check and tell vpbmaster to forge ahead anyway and treat the data as if it needs no reprojection. Which it doesn't. :) Does that make sense? I hope you enjoyed your walk! Glenn On Sat, Mar 29, 2008 at 5:20 AM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Glenn, It's correct vpbmaster refuses to do a build if the sources aren't all the same coordinate system as otherwise running osgdem on multiple processes at the same time would cause multiple reprojections on the same data at the same time and an unholy mess. The way to manage the reprojection is do it as a preprocessing step, creating a cache of reprojected data. For this you use another tool vpbcache. I'm looking after my little 4 year old right now so can't answer any further right now - we're going out for walk!! Robert. On Sat, Mar 29, 2008 at 12:50 AM, Glenn Waldron [EMAIL PROTECTED] wrote: Robert, I've noticed that vpbmaster refuses to continue if it detects that all sources are not in the same coordinate system. I can certainly understand why. That said, is there a way to override this decision and tell vpbmaster to trust me that all sources are in a common projection? Case in point: GDAL's ECW (ER Mapper compressed wavelet raster) plugin is sometimes not able to correctly parse the coordinate system information in the file. (This is a known issue -- http://www.gdal.org/frmt_ecw.html). So vpbmaster won't run since it thinks the ECW is in a different projection than other input layers. I tried using the --cs option to manually specify the CS; also --ReprojectSources False; no luck in either case. I'm running on Win32 with the latest SVN head of OSG and VPB. Glenn -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : 703-652-4791 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org ___ osg-users mailing list
Re: [osg-users] [VPB] Overriding source reprojection requirement invpbmaster
Norman, Your solution works perfectly! Thanks a lot. For the benefit of others, here is my Win32 build batch file. (That odd-looking first line just reads the contents of a WKT .prj file into a variable.) for /F delims= %%p in (boston-image.prj) do set prj=%%p gdal_translate -of vrt -a_srs %prj% boston-image.ecw boston-image.vrt gdal_translate -of vrt -a_srs %prj% boston-dem.tif boston-dem.vrt vpbmaster --terrain -d boston-dem.vrt -t boston-image.vrt -o out.ive On Sat, Mar 29, 2008 at 11:48 AM, Norman Vine [EMAIL PROTECTED] wrote Glenn Waldron writes: Robert, Exactly: it is quite possible for different WKT strings to represent the same CS -- I don't think there is a canonical WKT representation per se. I have the same challenge in osgGIS. ECW=GeoTIFF would work but ... unfortunately most of my ECW's are just plain large -- in one case I have 0.15m imagery covering 4000 sq kms. Glenn, Have you tried using GDAL's VRT format to pass the projection info http://www.gdal.org/gdal_vrttut.html In a nutshell create a .vrt file with the correct projection gdal_translate -of vrt -a_srs $YOUR_SRS $IN_FILE.ecw $OUT_FILE.vrt You may need to tweak the resultant .vrt file Then pass VPB the .vrt files instead of the ecw files Of course this assumes you know your desired SRS http://spatialreference.org/ is a handy site HTH Norman If you do have the time, I have uploaded a sample dataset that demonstrates the issue. There is a small ECW and a corresponding DEM (GeoTIFF). They are both WGS84. The build command line is included: http://pelicanmapping.com/downloads/ecw-sample.zip FWTools contains a pre-built GDAL library with ECW support included: http://fwtools.maptools.org/ Thanks again for your continued great work! I am especially appreciative of the upgrades to DatabasePager and look forward to test-driving this soon. Glenn On Sat, Mar 29, 2008 at 8:36 AM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Glenn, If VPB is reading the coordinate systems for the source and the required target coordinate system and not matching them it'll reproject, this matching does rely upon the WTK strings to be equal, so perhaps this is where the divergance is occurring. I don't have any ECW data or plugin available under Linux so I can test this route personally. Try using gdal to convert from ECW to GeoTiff and pass the GeoTiff's into VPB. Robert. On Sat, Mar 29, 2008 at 12:28 PM, Glenn Waldron [EMAIL PROTECTED] wrote: Robert, I didn't explain myself properly. All my data is indeed reprojected in advance. The issue is that vpbmaster just *thinks* the data needs reprojection -- I suspect the fault lies with the ECW plugin -- and so I'd like to override the check and tell vpbmaster to forge ahead anyway and treat the data as if it needs no reprojection. Which it doesn't. :) Does that make sense? I hope you enjoyed your walk! Glenn On Sat, Mar 29, 2008 at 5:20 AM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Glenn, It's correct vpbmaster refuses to do a build if the sources aren't all the same coordinate system as otherwise running osgdem on multiple processes at the same time would cause multiple reprojections on the same data at the same time and an unholy mess. The way to manage the reprojection is do it as a preprocessing step, creating a cache of reprojected data. For this you use another tool vpbcache. I'm looking after my little 4 year old right now so can't answer any further right now - we're going out for walk!! Robert. On Sat, Mar 29, 2008 at 12:50 AM, Glenn Waldron [EMAIL PROTECTED] wrote: Robert, I've noticed that vpbmaster refuses to continue if it detects that all sources are not in the same coordinate system. I can certainly understand why. That said, is there a way to override this decision and tell vpbmaster to trust me that all sources are in a common projection? Case in point: GDAL's ECW (ER Mapper compressed wavelet raster) plugin is sometimes not able to correctly parse the coordinate system information in the file. (This is a known issue -- http://www.gdal.org/frmt_ecw.html). So vpbmaster won't run since it thinks the ECW is in a different projection than other input layers. I tried using the --cs option to manually specify the CS; also --ReprojectSources
Re: [osg-users] Annexing the old OpenSceneGraph/XCode directory, moving to using just CMake
Robert Osfield schrieb: o The hand maintained XCode projects only work for specific version of XCode as XCode's project forward/backwards compatibility is nothing short of atrocious. I've recently heard from a long time OSX users that the lastest XCode project files have broken the build on old OSX/XCode versions so they can't upgrade. I consider this really bad situation to be in for those users and the OSG project as whole. Do you have some more informations? To my knowledge you'll need XCode 2.4 to get OpenSceneGraph compiled. It's no problem to open old project files with newer Xcode-versions. just curious, Stephan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Annexing the old OpenSceneGraph/XCode directory, moving to using just CMake
Hi Robert, Robert Osfield schrieb: Stephan could you check this directory in a place sparate from the OSG and then see if you have permission to modify it? Another test would be to remove the local XCode directory and checkout the dprecated one instead. If things work out I could remove the OpenSceneGraph/XCode version. No, I have no write permission to the project file. The permission-management of subversion is path-based not file-/folder-based. cheers, Stephan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [VPB] vpbmaster doesn't exit on Win32
Not sure whether this has been reported, but vpbmaster does not exit under Win32. Once the build completes you have to kill it from the Windows task manager. I have not had time to look into it yet - just wanted to throw it out there for now.. Glenn -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : 703-652-4791 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Testing of OSG and VPB SVN in prep for nex dev releases and 2.4 stable release
Hi Robert, OSG and VPB build fine on Fedora 8, gcc 4.2 Cheers David Callu 2008/3/28, Robert Osfield [EMAIL PROTECTED]: Hi All, There has been a number of changes and new introduction this week so I'd very much appreciate another round of build and run tests across various platforms. if all goes well I'll make a OSG-2.3.7 and VPB-0.9.8 dev releases on Monday. Feature wise OSG is now ready for 2.4, so its just build and run testing now. If things looks really good OSG wise then perhaps we could even think about tagging 2.4 in the second half of next week. If not next week then we'll need to wait till mid April as I have on-site training booked in for the 2nd week of April. It'd be kinda nice to have 2.4 done and dusted before I go, but not great sweat if it doesn't happen. VPB-1.0 won't be till the end of April though as I still have a couple more items to complete first, OSG-2.4 also needs to be out first as VPB-1.0 won't compile with OSG-2.2. Thanks in advance for you efforts, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Annexing the old OpenSceneGraph/XCode directory, moving to using just CMake
On 3/29/08, Robert Osfield [EMAIL PROTECTED] wrote: HI Stephan, On Sat, Mar 29, 2008 at 1:44 PM, Stephan Huber [EMAIL PROTECTED] wrote: Does CMake support building frameworks on OS X now? IMHO this was the missing key feature, stopping us using CMake on OS X. I don't know the answer to this, I was hoping that OSX users might know. The answer is maybe. It is in CMake's CVS. There are still some critical bugs, but the infrastructure is at least there now. (OSG's CMake code must be updated to handle this though.) CMake entered its 2.6.0 beta phase two days ago. I'm hoping to press the issue to finalize the support for the final 2.6 release. Can CMake generated XCode projects not support frameworks with just some settings being changed via the Xcode app? I've always been perplexed at why this shouldn't be straight forward. No, unfortunately, it doesn't work like that. Frameworks, libraries, applications, command-line tools, bundles, etc. targets in Xcode. Targets in Xcode are non-toggleable. You have to construct targets from the ground up. -Eric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ANN: FLT export
Looks like the importer interprets DrawMode OMNIDIRECTIONAL_LIGHT as a POINTS primitive. I can support the inverse mapping in my exporter to stifle the GL_POINTS not supported warning. I'll add this to my to-do list. -Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Saturday, March 29, 2008 9:32 AM To: OpenSceneGraph Users Subject: Re: [osg-users] ANN: FLT export Hi Paul, The case when the new flt load was complaining about GL_POINTS was on a dataset that I first loaded from .flt then converted to .ive and then from .ive to .flt. I don't know if it was light points in the original .flt file, or how the point got in there, but somehow they did. Robert. On Sat, Mar 29, 2008 at 3:23 PM, Paul Martz [EMAIL PROTECTED] wrote: Hi Jason -- Thanks for taking this code for a test drive. FLT doesn't support POINTS primitives, so those warnings are just FYI that you're exporting a scene graph that is ill-suited for export to FLT. The only comparable FLT entity would be a light point, but if you want light points, then you should use osgSim::LightPoint instead of GL_POINTS, so I think the FLT export code is doing the right thing here. Not sure where the NAN is coming from on re-import. If you osgconv your .ive file to .osg, do the tex coords look OK in the .osg file? The missing chunks of geometry are odd; clearly you have the latest FLT OSG plugin so you have support for continuation records. That's a stumper. Post a small reproducer scene graph if you can. Otherwise, my ability to assist is quite limited. Perhaps a good use of a couple hours of my time would be going in and adding more verbose output to the exporter. -Paul From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Daly Sent: Friday, March 28, 2008 2:36 PM To: OpenSceneGraph Users Subject: Re: [osg-users] ANN: FLT export Paul Martz wrote: Hi All -- I recently posted a change to osg-submissions that adds FLT export capability to OSG. Assuming it doesn't break the build, I expect Robert will have this available on current SVN soon. Hi, Paul, Great work! I tested with a fairly complex .ive. Originally this was an OpenFlight database. During export, I got a lot of these errors: fltexp: GL_POINTS not supported in FLT export. I'm not worried about actually exporting the points, as they weren't important anyway. I'm just mentioning them in case it's relevant for the real problem. This happened when I went to view the exported .flt file in osgviewer. During load, I got several groups of these two warnings: Warning: data error detected in VertexCNT::readRecord uv=nan nan Warning: data error detected in LocalVertexPool::readRecord uv=nan nan The file does eventually finish loading, and it looks fine for the most part. However, there are several objects in the scene that are missing large groups of faces. In each case, the bulk of the object is there, but there are large holes in it. Many of these objects used to be external references that were duplicated multiple times, and each copy looks the same. I really wish I could send you the file, but alas, I cannot. I'm sure this isn't enough information for you to go on. Let me know what else I can do to help. -- --J I'm a castaway stranded in a desolate land, I can see the footprints in the virtual sand. --Neil Peart ___ 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-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] osgText + NVidia driver bug fix checked in
Robert Osfield schrieb: the fix from Sherman was a very specific workaround for a bug in the NVidia driver coping with zero sized texture subloads that was causing a crash (the stack trace would lead from the OSG into the NVidia driver via the osgText::Font's subloading code. Did you see this crash previously, if so is this now fixed? As for the other issues, are they text related? Do any OSG example exhibit this behaviour? Hi Robert, ok, my application crashed with the combination of setText() called from UpdateCallback per frame and switching the threading modes at runtime. The debug FameStack shows me a crash is caused by : osgText::Text::computeGlyphRepresentation osgText::TextBase::setText I'm not sure if it has to do with Sherman's bugfix or not. I try to reproduce the problem with a modified osgPick example. Standard osgviewer app will not crash but I try to reproduce with a modified osgPick example regards, markus ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Annexing the old OpenSceneGraph/XCode directory, moving to using just CMake
Hi Eric, On Sat, Mar 29, 2008 at 5:28 PM, E. Wing [EMAIL PROTECTED] wrote: The answer is maybe. It is in CMake's CVS. There are still some critical bugs, but the infrastructure is at least there now. (OSG's CMake code must be updated to handle this though.) CMake entered its 2.6.0 beta phase two days ago. I'm hoping to press the issue to finalize the support for the final 2.6 release. Good to hear there is light at the end of the tunnel. Would it be possible for you to make the necessary amendments to the OSG CMake projects, it'd be great to have OSG-2.4 CMake build support XCode fully as this neatly does away of hassle alround and finally we'll be able to say that we have a truly unified build system. Once changes are checked in to the OSG CMake build we can make a call for testing of CMake 2.6.0 beta on all platforms, and in particular OSX as this could well help shake out final bugs in CMake 2.6.0 in time for OSG-2.4 to roll out. Robert. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgText + NVidia driver bug fix checked in
Hi Markus, On Sat, Mar 29, 2008 at 6:38 PM, Markus Hein [EMAIL PROTECTED] wrote: ok, my application crashed with the combination of setText() called from UpdateCallback per frame and switching the threading modes at runtime. Have you set the DataVariance on the Text drawable to DYNAMIC? This is required if you are updating it dynamically and use DrawThreadPerContext or CullPerCameraDrawPerContext threading models. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgText + NVidia driver bug fix checked in
Hi Robert, Have you set the DataVariance on the Text drawable to DYNAMIC? This is required if you are updating it dynamically and use DrawThreadPerContext or CullPerCameraDrawPerContext threading models. hmm...no, it wasn't . DataVariance is set to DYNAMIC now and is working fine :-) Thanks for the info. Markus ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Testing of OSG and VPB SVN in prep for nex dev releases and 2.4 stable release
OSG SVN builds OK and my applications work as expected. VPN SVN also builds well but I have not tested it. My machine runs Linux 2.6.22 (x86_64) and all was built with gcc 4.1.3 targeting x86_64. Cheers, Nicolas. 2008/3/29, David Callu [EMAIL PROTECTED]: Hi Robert, OSG and VPB build fine on Fedora 8, gcc 4.2 Cheers David Callu 2008/3/28, Robert Osfield [EMAIL PROTECTED]: Hi All, There has been a number of changes and new introduction this week so I'd very much appreciate another round of build and run tests across various platforms. if all goes well I'll make a OSG-2.3.7 and VPB-0.9.8 dev releases on Monday. Feature wise OSG is now ready for 2.4, so its just build and run testing now. If things looks really good OSG wise then perhaps we could even think about tagging 2.4 in the second half of next week. If not next week then we'll need to wait till mid April as I have on-site training booked in for the 2nd week of April. It'd be kinda nice to have 2.4 done and dusted before I go, but not great sweat if it doesn't happen. VPB-1.0 won't be till the end of April though as I still have a couple more items to complete first, OSG-2.4 also needs to be out first as VPB-1.0 won't compile with OSG-2.2. Thanks in advance for you efforts, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.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] Stop testing FLT export temporarily
Hi folks -- I just encountered a remarkable inefficiency in how the exporter handles Mesh and Face records. Let me do some redesign and rewriting, and once I've fixed it it'll be fair game for testing again. 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] ANN: FLT export
Whew! I'm glad someone found that it worked well! -Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brede Johansen Sent: Saturday, March 29, 2008 4:55 PM To: OpenSceneGraph Users Subject: Re: [osg-users] ANN: FLT export Hi Paul, I took the Flight exporter out for a quick spin and it worked remarkably well. Another nice feature available to OSG users. Grats! Regards, Brede On Fri, Mar 28, 2008 at 12:01 AM, Paul Martz [EMAIL PROTECTED] wrote: Hi All -- I recently posted a change to osg-submissions that adds FLT export capability to OSG. Assuming it doesn't break the build, I expect Robert will have this available on current SVN soon. Thanks to Dave Wolfe and Bob Kuehne for their assistance. Thanks to my client, who wishes to remain anonymous, for funding the development. See the KnowledgeBase page on the wiki for export Options., or see ExportOptions.cpp in my recent submission. I've focused on this project for the past month and I really like what I see. I'm now loading in fairly complex FLT models to OSG, writing them back out as FLT, and reloading them. I see little visual difference. I am also writing the OSG scene graphs out as .osg files and diffing them. Again, I see little significant difference between the .osg from the original versus our written FLT files. There are currently some outstanding issues I'm aware of that I need to address, which I've summarized below. * Should support BIND_PER_PRIMITIVE color binding better, use the Face/Mesh record colors instead of (what we currently do) per vertex colors. * Need to add support for Shader Palettes, Instance Definition, Instance reference, and Extension records. * I'd like to support osg::PagedLOD nodes as an LOD record and an External Reference record. This is on my to do list. * Billboards are not yet supported. This is on my to-do list as well. I still have funding for these and other mods, and appreciate the community diving in and testing. The bulk of my focus has been on exporting scene graphs that were created by loading FLT files, so I'm sure there are many ways to break this code. Let's see what's broke, and get s list of needed mods together and prioritize them. We developed a regression test suite that I'm working on making available to the community. I'll post here when I have more info. It has a dependency on Python so is not suitable for inclusion in core OSG. Thanks in advance for testing and feedback, Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com 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-opensce negraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
