Hi J-S,
On Jan 16, 2008 12:11 AM, Jean-Sebastien Guay
[EMAIL PROTECTED] wrote:
Yes, the gaps between tiles of different levels is usual right now.
The --terrain feature is very new to VPB, its not yet productive ready
so one would expect little items to not work 100%. It'll be working
Hi,
I have exactly the same black tile border problem on windows side with
my own data set.
On linux side it seems ok.
jcl
This footnote confirms that this email message has been scanned by
PineApp
On Jan 16, 2008 1:12 PM, Jean-Christophe Lombardo
[EMAIL PROTECTED] wrote:
Just to go a little further on this black contour problem:
I've transfered my scene generated on linux side to windows, and the
black contour appears...
Is there any difference in the default texture parameters between
Hello Robert,
I've been comparing the texture setup up code in both VPB and
osgTerrain and found that VPB uses CLAMP_TO_EDGE while
osgTerrain::GeometryTechnique itself just used defaults. I've changed
osgTerrain::GeometryTechnqiue to use CLAMP_TO_EDGE, testing under
linux doesn't show any
On Jan 16, 2008 2:51 PM, Jean-Sebastien Guay
[EMAIL PROTECTED] wrote:
Just updated OSG from SVN to get the changes to osgTerrain::GeometryTechnique,
recompiled, and regenerated the terrain, and it's fixed. No more black lines.
Thanks Robert.
Good to hear.
I don't think there are any other
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Jean-Christophe Lombardo
Sent: Wednesday, January 16, 2008 6:13 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] VPB in SVN
Just to go a little further on this black contour problem:
I've transfered my
Hi Paul,
NVIDIA drivers have a control for default texture clamping. I know this used
to default to the CLAMP_TO_EDGE, and if you wanted OpenGL spec-compliant
behavior, you had to manually change it to CLAMP_TO_BORDER.
Thanks for the details! I'm always impressed at how difficult it seems to
Hello Robert,
Still investigating. I'll continue on Monday.
OK, now with OSG and VPB updated to today's SVN, and clean builds of both, I am
getting predictable results from this command line:
osgdem -d NED_59396523.tif -t NED_59396523.tif --terrain -o output/test.ive -v
0.08
Whether it was
Hello Robert,
Good to hear things working better, although the not knowing exactly
what was amiss is a little unsettling.
Agreed. I assure you I'm on the lookout for any further signs that things are
wonky on my side... :-)
The lines on the terrain are most likely down to
On Jan 15, 2008 8:55 PM, Jean-Sebastien Guay
[EMAIL PROTECTED] wrote:
OK. Do you get the same behaviour on your end?
Yes, the gaps between tiles of different levels is usual right now.
The --terrain feature is very new to VPB, its not yet productive ready
so one would expect little items to not
Hello Robert,
Yes, the gaps between tiles of different levels is usual right now.
The --terrain feature is very new to VPB, its not yet productive ready
so one would expect little items to not work 100%. It'll be working
fully pretty soon though ;-)
It's not just different levels though -
I haven't had time to read this entire thread from you two yet, so I
apologize if you've already discussed and resolved this...
'vsnprintf' doesn't appear to be available under VS7.1. I can't locate it in
the VS7.1 help or determine what header file should define it in VS7.1.
It builds fine with
Paul Martz
'vsnprintf' doesn't appear to be available under VS7.1. I
can't locate it in
the VS7.1 help or determine what header file should define it
in VS7.1.
Any ideas?
Hey this is Microsoft :-)
try _vsnprintf
http://msdn2.microsoft.com/en-us/library/1kt27hek(VS.71).aspx
HTH
Hi J-S,
Thanks for doing the tests. Loading your test.osga into osgviewer on
its own it looks OK.
However, when loading your test.osga and my original test.osga into
osgviewer at the same time results the two models being loaded a long
way apart... suggesting a problem with position of the
site. I don't understand very well what is your problem in creating
terrain but it will probably help you! Ümit UZUN Date: Fri, 11 Jan 2008
11:03:50 + From: [EMAIL PROTECTED] To:
osg-users@lists.openscenegraph.org Subject: Re: [osg-users] VPB in SVN HI
JS, Thanks for the data
On Jan 11, 2008 5:40 PM, Jean-Sébastien Guay
[EMAIL PROTECTED] wrote:
Hello Robert,
The issue you have with all the terrain overlapping is suggest
problems with positioning of the tiles as well. I'm currently waiting
on output.zip to download so can't say any more at this stage.
Ok, let
Hello Robert,
The issue you have with all the terrain overlapping is suggest
problems with positioning of the tiles as well. I'm currently waiting
on output.zip to download so can't say any more at this stage.
Ok, let me know.
BTW, just how long did your full osgdem run take? What
Hello Robert,
This is almost certainly the root of the problem with the
visualization. I'll add some debugging into the .ive plugin to see if
the Locator exists in the file or whether it exists but with just
default settings.
Any ideas as to why I didn't get the right settings? I just tried
Hello Robert,
I'm stumped, I've reviewed both the DestinationTile and .ive code and
it looks fine. Could you put a break point in createTerrainTile() and
step through the code that sets up the Locator to see if its setting
up.
Sure, no problem. I'll get back to you.
Another long shot
Robert Osfield writes:
On Jan 11, 2008 6:25 PM, Jean-Sébastien Guay wrote:
Perhaps outputting the data as .osg will reveal exactly
what is going amiss.
OK, getting closer.
I've done a
osgconv test.ive test.osg
On your root .ive file and found the osgTerrain::Locator has
Hi JS,
On Jan 11, 2008 6:25 PM, Jean-Sébastien Guay
[EMAIL PROTECTED] wrote:
Perhaps outputting the data as .osg will reveal exactly what is going amiss.
OK, getting closer.
I've done a
osgconv test.ive test.osg
On your root .ive file and found the osgTerrain::Locator has default
Hi JS,
On Jan 11, 2008 7:36 PM, Robert Osfield [EMAIL PROTECTED] wrote:
This is almost certainly the root of the problem with the
visualization. I'll add some debugging into the .ive plugin to see if
the Locator exists in the file or whether it exists but with just
default settings.
Now
Hello Norman,
My guess is that the GDAL data files aren't being picked up
I don't think this is the problem, because the same command, without
--terrain, produces correct output. With --terrain, it gives a Locator
with default settings.
Still investigating. I'll continue on Monday.
J-S
--
Hello Robert,
I get the same problem as you - once the lower levels start paging in
they all overlap each other. This shows us at least that the problem
is in database creation rather than rendering.
Perhaps outputting the data as .osg will reveal exactly what is going amiss.
OK, getting
Hi
I have a msvc8 version of vpb 0.9.3.
I found some straight forward equivalents for most of the posix
functions, but I had to make rather rude stuff for others.
I did not test this part (tasks and machines), but the project compiles
and run fine on one single computer.
I don't know whether
Hi JCL,
I am just merging changes than JS submitted yesterday evening, I'm not
merging all the suggested changes, rather merging the uncontroversial
ones first, making other alternative ammendments for others. These
changes are now checked in.
A number of items are outstanding, such as the
ok, fine for me.
jcl
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals computer
viruses.
On Jan 10, 2008 11:13 AM, Jean-Christophe Lombardo
[EMAIL PROTECTED] wrote:
ok, fine for me.
The changes are now all checked in. Could you do an svn update on OSG
and VPB and let me know how you get on.
Also could you review the src/vpb/FileUtils.cpp file to see if the
windows equivalents of
Bonjour Jean-Christophe,
I don't know whether this can be useful or not, nor how I can
contribute. Let me know.
Hehe, I would have liked to know this yesterday :-)
I sent to osg-submissions the changed files to make VPB from SVN
compile cleanly on Windows yesterday. We'll see if they make
Hi Robert,
A number of items are outstanding, such as the Windows versions of
posix functions. JS has created a Utils file for these, I'm about to
just start reviewing these. I'll follow JS's lead in collecting all
these functions into one place, but I'll probably not follow the
naming
I still have 2 slight modifications to suggest on windows side:
* in vpb/FileUtils I had to add a #include fcntl.h to define the
O_RDWR flag with no leading _
* in vpb/FileUtils.cpp I think that vpb::sync() could be defined as
void vpb::sync() { (void) _flushall(); }
Jean-Sébastien, I'm
Hello Robert,
Fingers crossed this should now mean VPB is
ported back to windows, at least for basic osgdem functionality.
Yep, seems so. osgdem still running... I probably should have chosen a
smaller dataset as a first test. :-)
Once I've completed some more work on
VPB I'll do a write
Hello jcl,
* in vpb/FileUtils I had to add a #include fcntl.h to define the
O_RDWR flag with no leading _
Already done in the second batch of modifications (it was already in
the #else, so we just moved it out of the #ifdef).
* in vpb/FileUtils.cpp I think that vpb::sync() could be
On Jan 10, 2008 1:45 PM, Robert Osfield [EMAIL PROTECTED] wrote:
The changes are now all checked in. Could you do an svn update on OSG
and VPB and let me know how you get on.
I've just received, merged and submitted to SVN further update from
J-S that tweak the changes I checked in earlier, so
On Jan 10, 2008 3:16 PM, Jean-Sébastien Guay
[EMAIL PROTECTED] wrote:
Yep, seems so. osgdem still running... I probably should have chosen a
smaller dataset as a first test. :-)
If its a dataset with DEM's try adding --terrain to the command line,
it builds much, much faster using
I just wanted to thank all involved for the work on this.
Bob and I wanted to use SVN head of VPB for the upcoming terrain training
January 24, but aborted that idea and went back to 0.9.1 when we encountered
the Windows issues. I was reluctant to bite off porting it with so much to
do between
On Jan 10, 2008 3:15 PM, Jean-Christophe Lombardo
[EMAIL PROTECTED] wrote:
I still have 2 slight modifications to suggest on windows side:
* in vpb/FileUtils I had to add a #include fcntl.h to define the
O_RDWR flag with no leading _
Already checked in.
* in vpb/FileUtils.cpp I think that
Hi Robert,
The --terrain functionality is very early days though (checked in
yesterday) so there are still a few loose ends, but its certainly
enough to have a first pass look.
Cool, I'll try that out.
Yep, you can use multiple cores, and multiple machines, or multiple
cores on one
Hi Paul,
Bob and I wanted to use SVN head of VPB for the upcoming terrain training
January 24, but aborted that idea and went back to 0.9.1 when we encountered
the Windows issues. I was reluctant to bite off porting it with so much to
do between now and the course.
That was actually my
Hello Robert,
If its a dataset with DEM's try adding --terrain to the command line
If that gives me a file which doesn't display anything (when given to
osgviewer) does that mean that --terrain didn't work, or does it mean
that the dataset didn't have DEMs? I *think* I'm using geotiffs
Hello Robert,
--terrain should work fine with imagery only databases, not seeing
something suggests problems somewhere, but where? How knows with so
little info to go on. Does the generated database run without if you
don't use the --terrain option?
Sorry for the little info, don't really
On Jan 10, 2008 4:47 PM, Jean-Sébastien Guay
[EMAIL PROTECTED] wrote:
Hello Robert,
If its a dataset with DEM's try adding --terrain to the command line
If that gives me a file which doesn't display anything (when given to
osgviewer) does that mean that --terrain didn't work, or does it
Jean-Sébastien Guay wrote:
Is there any reference to the various formats that osgdem can use? I
could wait until Paul and Bob's course, but I'm curious :-)
As far as I understand, osgdem relies on gdal to read dem texture
files. So osgdem supported formats are gdal ones and GEOTiff is
On Jan 10, 2008 5:27 PM, Jean-Sébastien Guay
[EMAIL PROTECTED] wrote:
Sorry for the little info, don't really know what to give. The osgdem
without --terrain just finished, it worked and looks great. Running
with --terrain ran a lot faster, but I can't see anything in osgviewer
with the
Hello Robert,
Any chance you could make available the data and osgdem commndline
you've used?
I've put the data at
http://whitestar02.webhop.org/files/OSG/NED_59396523.zip
It's about 24MB. I'll remove it once you've gotten it... It comes from
http://seamless.usgs.gov/, as instructed
Hello Robert,
I tried fetching VPB from SVN and compiling it on Windows, and I
wonder if the current SVN version is in a state of flux. Apart from a
few errors that are down to it not having been tested on Windows,
there are a lot of errors that should be flagged on any compiler
(methods
Hi J-S,
VPB from SVN does need porting to Windows, in particular the posix
functions used for managing the file systems need to have equivalents
found. I'd appreciate Windows users tackling this as I don't have the
Windows here to test and work on.
A sort cut to Windows support would also be to
Hello Robert,
VPB from SVN does need porting to Windows, in particular the posix
functions used for managing the file systems need to have equivalents
found. I'd appreciate Windows users tackling this as I don't have the
Windows here to test and work on.
OK, I'll probably be able to help
Hi Robert,
Have you put -W -Wall in CMAKE_CXX_FLAGS.
I have a lot of warning too, but I know that your code work fine with
this warning.
So I never take the time to fix them.
Cheers
David
2008/1/9, Robert Osfield [EMAIL PROTECTED]:
On Jan 9, 2008 3:45 PM, Jean-Sébastien Guay
On Jan 9, 2008 3:45 PM, Jean-Sébastien Guay
[EMAIL PROTECTED] wrote:
OK, I'll probably be able to help there in the coming weeks.
Great, much appreciated.
I didn't mean warnings, there are some errors that should show up on
any compiler, such as a method declared as bool someMethod() not
50 matches
Mail list logo
