ify 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
> > fe
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 (sa
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.
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
g 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 wro
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 't
; 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
>
>
>
&
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
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, offsetToNorma
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.
Toml
ed 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/RY
put my results in context, the database I'm testing with is a
whole earth model with SRTM and DTED(1&2) 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 A
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.
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 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 f
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
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 lay
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 o
17 matches
Mail list logo
