Re: [osg-users] Colors and Lighting

[Robert Osfield]

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

[Robert Osfield]

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

[Robert Osfield]

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  to something like 16 and then limit the
number of levels provide using -l .

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

[Robert Osfield]

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)

[Maciej Krol]

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)

[Robert Osfield]

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

[Glenn Waldron]

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

Re: [osg-users] [VPB] Overriding source reprojection requirement in vpbmaster

[Robert Osfield]

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

[Glenn Waldron]

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.openscenegr

[osg-users] Annexing the old OpenSceneGraph/XCode directory, moving to using just CMake

[Robert Osfield]

Hi All,

This time last year CMake's support for XCode wasn't up to OSX users
requirements, so reluctantly I agreed to temporarily allow the old
XCode directory to be maintained while CMake gained full XCode
support.   With OSG-2.4 on the near horizon I'd now like to review the
situation but since I'm not an OSX users I need feedback from OSX
users.

Personally I think its about time we annexed the old hand maintained
XCode directory to touch and moved across entirely to using CMake's
Xcode support,
my reasons are:

  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.

  o The hand maintained XCode projects don't have any support for
automatically detecting dependencies and enable/disable modules
accordingly like
 the rest of the platforms that the OSG supports.  This situation
means that key OSG features aren't supported, and OSX users are tied
to a fixed
 set of dependencies.

  o The hand maintianed XCode projects are very easily broken by new
additions/name changes/file removals breaks the build for as long as
it takes
 the XCode projects maintainers (Stephen and Eric) to update the
XCode projects.  I don't often see updates being checked in so I can
only presume
 that alot of the time the OSX build is broken if you use the SVN
or dev versions of the OSG.  It's also just creates work for the
maintainers of
 the old Xcode projects.  Personally I'd rather people spend time
coding better software than maintaining cranky build systems.

  o The lack of consistency in build with the hand maintained XCode
projects means that more OSX will shy away from testing SVN and dev
versions than
 on other platforms, so less testing will be done and as a
consequences less problems caught and fixed before stable release go
out - the upshot is
 stability and quality of OSG under OSX will be worse than it
could and should be.

  o Having multiple XCode project build paths is confusing for end
users and maintainers like myself  - consider when someone reports OSX
build fails
 but don't mention which build path they are using it leaves us
with three possible paths to guess what they are using - gmake/Cmake
built XCode or
 the hand built XCode).

  o Having multiple XCode project build paths creates a larger testing
matrix that must be ran through to make sure OSX works fine - note
this is
 currently three different build paths that need testing.

  o Having multiple XCode project build paths means that you need more
documentation to cover all the options.

  o Hand maintained XCode projects doesn't introduce you to the CMake
build system, and creates a discontinuity in build when you move to a
new
 platform.  If you use CMake on all platforms then transition
learning curve is minimized as at least one part of the build system
is familiar.

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.

My suggest right now is that we move the hand maintained XCode
projects out of the core OpenSceneGraph distribution and in to its own
deprecated directory.

Thoughts?

Robert.
___
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

[Stephan Huber]

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

[hesicong2006]

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

[Markus Hein]

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

[Robert Osfield]

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

[Robert Osfield]

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

[Paul Martz]

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

[Robert Osfield]

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

[Robert Osfield]

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

[Norman Vine]

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 

Re: [osg-users] [VPB] Overriding source reprojection requirement invpbmaster

[Glenn Waldron]

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
> 

Re: [osg-users] Annexing the old OpenSceneGraph/XCode directory, moving to using just CMake

[Stephan Huber]

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

[Stephan Huber]

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

[Glenn Waldron]

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

[David Callu]

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

[E. Wing]

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

[Paul Martz]

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

[Markus Hein]

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

[Robert Osfield]

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

[Robert Osfield]

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

[Markus Hein]

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

[nicolas peña]

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

Re: [osg-users] ANN: FLT export

[Brede Johansen]

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-openscenegraph.org

[osg-users] Stop testing FLT export temporarily

[Paul Martz]

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  
+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

[Paul Martz]

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