Re: [osg-users] Problems with VPB and DTED data.
what OS are you using? What version of GDAL? On Linux I've not had a problem reading .dt? files. OpenSuSE Linux 11.0, VPB rev 953, OSG 2.8.0 and GDAL 1.6.0. I'm not sure how it's working for you if you're using the version of VPB that checks extensions. Did you modify GDAL to report the .dt? file extensions? Ken Sewell, Kenneth R Civ USAF AFMC AFRL/RYZW wrote: It seems that VPB (SVN revision 953) won't accept DTED data. Looking at the VPB code, VPB gets a list of GDAL supported extensions (and adds a few that GDAL doesn't report). Looking at GDAL, it fails to report the DTED extensions (.dt0, .dt1, .dt2) via the GetMetadataItem(DMD_EXTENSIONS) method. The result is VPB reports that DTED files are not supported. I don't know if the fix belongs in GDAL or VPB, but as a quick work-around add the following lines to the end of the VPB System constructor (src/vpb/System.cpp): addSupportedExtension(dt0, Source::IMAGE | Source::HEIGHT_FIELD, DTED Level 0); addSupportedExtension(dt1, Source::IMAGE | Source::HEIGHT_FIELD, DTED Level 1); addSupportedExtension(dt2, Source::IMAGE | Source::HEIGHT_FIELD, DTED Level 2); Ken. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users- openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users- openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Problems with VPB and DTED data.
It seems that VPB (SVN revision 953) won't accept DTED data. Looking at the VPB code, VPB gets a list of GDAL supported extensions (and adds a few that GDAL doesn't report). Looking at GDAL, it fails to report the DTED extensions (.dt0, .dt1, .dt2) via the GetMetadataItem(DMD_EXTENSIONS) method. The result is VPB reports that DTED files are not supported. I don't know if the fix belongs in GDAL or VPB, but as a quick work-around add the following lines to the end of the VPB System constructor (src/vpb/System.cpp): addSupportedExtension(dt0, Source::IMAGE | Source::HEIGHT_FIELD, DTED Level 0); addSupportedExtension(dt1, Source::IMAGE | Source::HEIGHT_FIELD, DTED Level 1); addSupportedExtension(dt2, Source::IMAGE | Source::HEIGHT_FIELD, DTED Level 2); Ken. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] VPB and imagery without filename extensions.
A lot of the imagery data we use is in ENVI's native format. GDAL does support it and it has worked in previous versions of Virtual Planet Builder. It now fails with the current SVN head (953) because the data doesn't use a filename extension. Typically the ENVI format is composed of two files (sample.hdr and sample, for example). One file has the projection and image info, the other is just the raw data. All the gdal commands want the file without the extension as the argument. Previously, this was not an issue with VPB, but the new method of checking filename extensions on input files is causing problems. Since there is no extension to add to VPB's list, may I suggest a flag for VPB to tell it not to do the filename extensions checking? Ken. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple GPU
Just to offer an alternative setup... We have OSG running a system of 6 screens representing a single view. The solution we chose was to use a single 8800 GTX and two of the matrox triple-head-to-go devices. Nvidia's twinview lets us treat it as one big screen of resolution 3840x2048, which makes for a very simple setup in OSG. By adding another card you could easily get the number of screens you require. - Ken. I have to do a simulation project which needs 8 screens. This system likes a dome. so i want to ask few questions about this: 1) i want to use multiple gpu's. So is there a limit on number of gpu's on a pc? i saw 4 gpu's on a pc and every gpu has 2 outputs. can i render 8 screen with viewer? 2) how can i set which gpu render which screen. is there an auto management system in viewer? if i have screens which have resolutions like 8x1280x1024 or 4x2560x1024 or any other combination of this, should i do an extra thing for this? 3) do you think i will have a critical frame rate problem if i render 8 screens. ___ 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] OT: Access to OSG website.
Over the past couple weeks, accessing the OSG website/SVN has become near impossible for me from home (connection timeouts). While at work, the website is quite fast and responsive. I've taken the issue up with my ISP, but at least one co-worker on a different ISP has the same issue. My ISP's 'tier 2' networking people are blaming it on the OSG server; they claim they can access it in the morning but not the rest of the day. Since I have no problems accessing it from work, I have to believe that it's either my ISP (or one of their providers) or the OSG website tracks my work habits and shuts down when I go home in the evening. So far I've seen the trouble going across both (ATT and Time Warner networks in Ohio, USA). Has any other OSG users had a similar experience recently? Has the server had any issues in the past week or two? Any information I can use to get my ISP to fix this would help. Thanks. Ken. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OT: Access to OSG website.
Thanks for the answer Robert. The last message I found in the archives regarding the server was from a few months ago, since I hadn't seen anything lately, I assumed the server was back on its feet. I still have my doubts regarding my ISP, but I guess I can't lay all the blame on them now :) Ken -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users- boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Friday, January 30, 2009 10:20 AM To: OpenSceneGraph Users Subject: Re: [osg-users] OT: Access to OSG website. Hi Ken, We've had lots of problems with the present server over the last few months, Jose's made a few changes to try and keep things more stable, but in the end the server software needs an complete update to fix the problems. To this end Jose is helping get us migrated to a virtual server which will give us much more control over our server and the ability to update the various components of the server to make it handle the throughput better. Fingers crossed we'll have this new server up and running next week. So.. my guess at your end the stability at home vs work is just a coincides with when the server is most likely to be overloaded and to grind to a halt. Robert. On Fri, Jan 30, 2009 at 3:09 PM, Sewell, Kenneth R Civ USAF AFMC AFRL/RYZW kenneth.sew...@wpafb.af.mil wrote: Over the past couple weeks, accessing the OSG website/SVN has become near impossible for me from home (connection timeouts). While at work, the website is quite fast and responsive. I've taken the issue up with my ISP, but at least one co-worker on a different ISP has the same issue. My ISP's 'tier 2' networking people are blaming it on the OSG server; they claim they can access it in the morning but not the rest of the day. Since I have no problems accessing it from work, I have to believe that it's either my ISP (or one of their providers) or the OSG website tracks my work habits and shuts down when I go home in the evening. So far I've seen the trouble going across both (ATT and Time Warner networks in Ohio, USA). Has any other OSG users had a similar experience recently? Has the server had any issues in the past week or two? Any information I can use to get my ISP to fix this would help. Thanks. Ken. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users- openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users- openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Vertex list indexing into another vertex list?
This would be a simplified (although not useful) example of the data:
Primary_vertex[0] = { 1.0, 1.0, 1.0 };
Secondary_vertex[0] = 0; // Index into primary_vertex list
Secondary_vertex[1] = 0; // Index into primary_vertex list
TexCoord[0] = { 0.0, 0.0 }; // Texture coord for Secondary_vertex[0]
TexCoord[1] = { 1.0, 1.0 }; // Texture coord for Secondary_vertex[1]
If I understand your suggestion, then the draw elements list would just
be {0, 0}, in which case the geometry would work, but it would also
apply TexCoord[0] to both vertices, which is not what was intended.
- Ken
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-
boun...@lists.openscenegraph.org] On Behalf Of Vincent Bourdier
Sent: Thursday, January 15, 2009 5:14 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Vertex list indexing into another vertex
list?
Hi,
Maybe just use setVertexArray with the primary vertex list, and you
use
the second list in a osg::DrawElementsUInt (or similar).
In the DrawElementsUInt, you push your vertices indexes. So when the
vertices data are modified, if they keep the same position in the list
the geometry will update. (do not forget setUserData(DYNAMIC) )
There is a setVertexIndice() method but it is now deprecated... maybe
something can replace it.
Same thing for the texture (if I understand well)
Hope this help.
PS : have a look on documentation
http://www.openscenegraph.org/documentation/OpenSceneGraphReferenceDocs
/a01369.html#4596d0e18fb5217a1306c324a2eaba72
Regards,
Vincent.
2009/1/14 Sewell, Kenneth R Civ USAF AFMC AFRL/RYZW
kenneth.sew...@wpafb.af.mil
Is it possible to specify a vertex list by indexing into a
different
vertex list? Sorry if that's confusing, I'll try to explain a
bit more.
I've got some data that is organized in the following way:
- A primary vertex list that is the regular xyz values you'd
expect.
- A secondary vertex list that is composed by indexing into the
primary
vertex list.
- A texture coordinate list that has a value for each 'vertex'
in
the
secondary list.
- Lastly, a list of indices into the secondary vertex list to
define
some primitives.
It looks like the data was set up this way so a vertex that
exists in
multiple primitives can have a unique texture coordinate per
primitive,
yet still only be transformed once.
My initial approach was just to construct the secondary list by
replacing the index with a copy of the vertex it was
referencing.
This
works except for one thing, the primary vertex list is not
static. By
that, I mean the values of the vertices themselves, the list
size
itself
will not change. So, the only approach I see is to basically
reconstruct the secondary vertex list every time the primary is
updated.
This could be kind of rough, since I could potentially have many
secondary lists. From what I've seen looking through OSG
headers
and
mailing list postings it doesn't seem possible to do this
'vertex
list
by indexing another', but I thought I'd ask just in case.
Thanks.
- Ken.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-
openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Vertex list indexing into another vertex list?
Is it possible to specify a vertex list by indexing into a different vertex list? Sorry if that's confusing, I'll try to explain a bit more. I've got some data that is organized in the following way: - A primary vertex list that is the regular xyz values you'd expect. - A secondary vertex list that is composed by indexing into the primary vertex list. - A texture coordinate list that has a value for each 'vertex' in the secondary list. - Lastly, a list of indices into the secondary vertex list to define some primitives. It looks like the data was set up this way so a vertex that exists in multiple primitives can have a unique texture coordinate per primitive, yet still only be transformed once. My initial approach was just to construct the secondary list by replacing the index with a copy of the vertex it was referencing. This works except for one thing, the primary vertex list is not static. By that, I mean the values of the vertices themselves, the list size itself will not change. So, the only approach I see is to basically reconstruct the secondary vertex list every time the primary is updated. This could be kind of rough, since I could potentially have many secondary lists. From what I've seen looking through OSG headers and mailing list postings it doesn't seem possible to do this 'vertex list by indexing another', but I thought I'd ask just in case. Thanks. - Ken. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Interleaved vertex data and VBOs.
I'm porting some OpenGL code that has the vertex position, normal, tex coord, ... interleaved in one large array. In OpenGL I could use one buffer: glBindBuffer( GL_ARRAY_BUFFER, bufferObject ); glVertexPointer( 3, GL_FLOAT, sizeOfVertex, 0 ); glNormalPointer( GL_FLOAT, sizeOfVertex, offsetToNormal ); I'm struggling to figure out how to do it in OSG. The only OSG examples I can find have the position data in one array, the normal data in another, ... I've been looking through the source code, but I'm not having much luck. Any pointers? Thanks. Ken. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Slightly of Topic: Access OSG SVN thru Autoproxy.
Have you tried adding the following lines to your svn servers file? http-proxy-host = your.proxy.server.here http-proxy-port = yourproxyportnumber If your proxy requires name/password you also set the lines: http-proxy-username = defaultusername http-proxy-password = defaultpassword -Ken. Tomlinson, Gordon wrote: We have recently been moved in to the corporate network and thus thrown behind a gaggle of walls/issues etc including an Autoproxy and I cannot seem to figure out how to get to the OSG SVN repositories thru this autoproxy The errors we are getting are ( all was fine before the moved to the corporate net) Error: OPTIONS of 'http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk': Could Error: not resolve hostname `http://autoproxy.textron.com': The requested name is Error: valid and was found in the database, but it does not have the correct Error: associated data being resolved for. Error: (http://www.openscenegraph.org http://www.openscenegraph.org/) If we don't use the http:// the error becomes Error: The path was not part of a repository Error: '/' path not found Any one come across this and found a way to get this SVN to work thru a autoproxy, is there something that need to be changed on the proxy ? ( which will be fun trying to get to happen) I'm at a loss as I'm no SVN guy, I can use TortoiseSVN and cmdline to grab data that's it etc. I have tried most of the SVN clients and they all exhibit the same issues I don't know much about the use of proxies, but can you at least access the repository in a web browser using the repo URL? Paul TIA for any hints or pointers /Gordon/ __ /Gordon Tomlinson //Email / : gtomlinson @ overwatch.textron.com/ / __ //(C)//:/ (+1) 571-265-2612* *(W)//:/ //(+1) 703-437-7651// Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival - */Master Tambo Tetsura/* ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgdem performance...
One last question, your client that got a solid 60Hz, what kind of CPU usage did they see? -Ken. I can't really add much as I've explained about the osgTerrain database sampling already - you just need to try it. As for the hardware, yep this should be able to cope, the client I worked with in the VPB work is using similar hardware and OS and getting solid 60Hz so I would expect you to be able to achieve similar. W.r.t checking for VBO issue, go read the recent thread on this Intel VBO crash. Robert. On Fri, Aug 15, 2008 at 3:25 PM, Sewell, Kenneth R Civ USAF AFMC AFRL/RYZW [EMAIL PROTECTED] wrote: Hi Robert, I can't speak for the hardware on the windows machine, but the linux box I tested with was a Quad core 2.6Ghz machine with 4GB memory and a GeForce 8800 GTX 768MB with the latest Nvidia drivers(with Sync to VBlank set). I'm pretty sure the hardware specs are not the problem, so what's to best way to check for VBO issues? I've never had to down sample any of the OSG databases before, so I was surprised when I tried the --terrain option. I'm not sure I understand all the benefits of --terrain over the default. The --terrain option doesn't do any simplification of the terrain during build time, it just produces a regular triangulated grid and expects you to use it or sample it in some way at runtime, correct? But the default does do terrain simplification, so you get longer build times but much less polygons at runtime. Assuming I'm not way off base there, --terrain would only seem to be recommended if you plan on doing some custom sampling or other manipulation at runtime. I apologize if this has been addressed before, but I haven't had much luck finding a clear explanation on the wiki or mailing list archives. To put my results in context, the database I'm testing with is a whole earth model with SRTM and DTED(12) elevation, and 2 texture layers consisting of Bluemarble NG, Landsat7, Quickbird and CADRG imagery. - Ken. Hi Ken et. al, On Thu, Aug 14, 2008 at 7:01 PM, Sewell, Kenneth R Civ USAF AFMC AFRL/RYZW [EMAIL PROTECTED] wrote: We had similar issues with terrain recently. On windows it was single digit framerates and the same database on Linux was 30 fps but %100 on 2 cores. Rebuilding our terrain without the -terrain flag solved the issue. Framerates on windows jumped up to 30 fps, Linux to 60 fps with %30 on 1 core. We tried this with several databases and the ones without -terrain always performed better. Performance problems when using --terrain (i.e. an osgTerrain::TerrainTile based database) suggests either problems with VBO's or that your graphics hardware simply isn't up to the amount of geometry being pushed to the graphics hardware. The osgTerrain based databases deliberately use high resolution (64x64 by default) tiles, and the default GeometryTechnique used doesn't do any simplification in its default settings. What you get is very high fidelity databases but... lots and lots of polygons. The solution is very simple - as osgTerrain tessellates the TerrainTile on loading its able to down sample the tiles to a user defined level, so on hardware that is less capable you can use a lower sample ration, and better hardware use a sample ration of 1.0. To control this you simply decorate your paged database with an osgTerrain::Terrain and set the SampleRatio here. The osgmultitexturecontrol example provides code to do this, as well as an event handle to vary the sample density. The osgmultitexturecontrol example has an -r sampleratio command line option so try: osgmultitexturecontrol -r 0.25 mydatabase.ive Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgdem performance...
We had similar issues with terrain recently. On windows it was single digit framerates and the same database on Linux was 30 fps but %100 on 2 cores. Rebuilding our terrain without the -terrain flag solved the issue. Framerates on windows jumped up to 30 fps, Linux to 60 fps with %30 on 1 core. We tried this with several databases and the ones without -terrain always performed better. Ken From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC Sent: Thursday, August 14, 2008 1:07 PM To: osg-users@lists.openscenegraph.org Subject: [osg-users] osgdem performance... I would like to get some feedback from users that might be rendering OSG terrain built with osgdem on Windows XP. Based on previous discussions, I understand that the terrain rendering on Windows does not have as good of performance as on Linux, however, I'm seeing abysmal frame rates when I'm rendering terrain on Windows. The paging performance is horrible. Perhaps it's the way I'm constructing my terrain or the setup in my OSG app...I'm not sure. While I don't understand the algorithm that is being used for OSG terrain, I would expect it to perform as good or somewhat close to other Windows based earth viewers such as NASA's WorldWind which seems to run just fine on Windows with large databases. For the record, here's the osgdem command I'm using to build the terrain... osgdem -TERRAIN -PagedLOD -geocentric -t dted -d texture -l 10 -o terrain/wasatch_utm.ive Any input on the matter would be appreciated... -Shayne ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenScenGraph-2.6.0-rc2 tagged
OSG 2.6.0-3c2 compiles and runs on 32-bit openSUSE 11.0. I did stumble upon one small issue with Virtual Planet Builder though. GCC 4.3.1 requires cstring to be included to support the calls made to memcmp and strchr in the file src/vpb/PropertyFile.cpp. After adding that include, VPB compiled and ran fine with 2.6.0-rc2. Ken ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] vpb/osgdem textures in different layers blending.
When using vpb or osgdem and using the --layer options, I expected the layers to be assigned to different texture units. However when I generate the terrain the layers seem to be blended 50/50 and stored as one texture. Is this a bug or am I not understanding what osgdem is referring to as a layer? I'm using OSG 2.4 and VPB svn rev 911. A simple test case using the OSG-Data: osgdem --geocentric -o testLayer.ive -l 5 --layer 0 --whole-globe land_shallow_topo_2048.jpg --layer 1 --whole-globe whitemetal_diffuse.jpg ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] vpb/osgdem textures in different layers blending.
Oops. My shader wasn't being loaded properly, fixed that and now the layers are behaving as expected. Ken. -Original Message- When using vpb or osgdem and using the --layer options, I expected the layers to be assigned to different texture units. However when I generate the terrain the layers seem to be blended 50/50 and stored as one texture. Is this a bug or am I not understanding what osgdem is referring to as a layer? I'm using OSG 2.4 and VPB svn rev 911. A simple test case using the OSG-Data: osgdem --geocentric -o testLayer.ive -l 5 --layer 0 --whole-globe land_shallow_topo_2048.jpg --layer 1 --whole-globe whitemetal_diffuse.jpg ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgdem/vpb ignore alpha channel
I have several hundred images I'm using in my terrain generation. Each image contains 4 bands of data, 3 are the standard RGB, but the 4th is another visual band. Osgdem/VPB is using the 4th band as an alpha channel, which is causing some visual artifacts. Is there an undocumented command line option or other work-around to tell osgdem to ignore the alpha channel for an image or do I need to strip the 4th band from all my images? Thanks. Ken. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
