On Wednesday 18 January 2006 20:00, Oliver wrote:
> > Is the resolution the same (IIRC FGFS has a resolution of 30 or 40
> > meters)?
>
> No, MSFS 2004 ships by default with a mesh resolution that is a lot
> lower (i assume 1 km) than the one in FGFS.
> MSFS 2004 doesn't use SRTM terrain data, but
Am Sonntag, den 15.01.2006, 11:59 +0100 schrieb Christian Mayer:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Paul Surgeon schrieb:
> > On Sunday 15 January 2006 12:08, Christian Mayer wrote:
> >> (*) unless you want to get fancy with blending the textures, etc. pp.
> >> But this will c
Hi Curt,
I suppose I'm less sensitive to the abrupt change problem as most of the
scenery both face material and triangle edges show some form of abrupt
change due the the mountainous terrain that covers most of the country.
Personally I like the blending solution for edges although this still
Ralf Gerlich writes:
> Hi,
>
> Paul Surgeon schrieb:
> > When TerrorGear does the UV mapping calculations on the terrain polys it
> > should take the terrain slope into account.
> > Flat ground = standard resolution
> > More slope = higher resolution
>
> I think the only point where TerraGear a
dene maxwell wrote:
Hi Paul,
From: Paul Surgeon <[EMAIL PROTECTED]>
On Sunday 15 January 2006 10:25, dene maxwell wrote:
> Hi Paul, to my way of thinking the resolution is not important.
Pythagarus
> is more important, the distance as seen in a birds-eye view as seen
by FGSD
> is not the di
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
dene maxwell schrieb:
> Hi all,
> my reading of the situation;
> a) No adjustment of the textures takes place at the moment for sloping
> terrain...hence the "stretch" problem.
> b) a "cylindrical" solution has been proposed(that I don't understand
>
Hi all,
my reading of the situation;
a) No adjustment of the textures takes place at the moment for sloping
terrain...hence the "stretch" problem.
b) a "cylindrical" solution has been proposed(that I don't understand the
maths of) that may/will have an unacceptable performance hit.
c) x-plane an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Paul Surgeon schrieb:
> On Sunday 15 January 2006 12:08, Christian Mayer wrote:
>> (*) unless you want to get fancy with blending the textures, etc. pp.
>> But this will create an big overhead.
>
> Well yes but a half decent scenery engine using tex
On Sunday 15 January 2006 12:08, Christian Mayer wrote:
> (*) unless you want to get fancy with blending the textures, etc. pp.
> But this will create an big overhead.
Well yes but a half decent scenery engine using texture blending like the one
in X-Plane and MSFS would do just fine and they act
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Paul Surgeon schrieb:
> It doesn't work because TerrorGear doesn't do it.
> Nothing is broken because there's no code to do it yet. :)
>
> If I'm not mistaken TerrorGear doesn't take the elevation into account at all
> when doing the UV mapping -
On Sunday 15 January 2006 11:38, dene maxwell wrote:
> this certainly seems to follow the geometric logic. One problem...it
> doesn't seem to work.
>
> Without being familiar with the code concerned, my impression is that this
> logic is not being applied in a way that produces the desired result o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Ralf Gerlich schrieb:
>> One thing I have noticed, we have alot of urban areas on very steep
>> hill sides. This "draping" approach can cause some very unpleasant
>> visual effects in these instances...the terrain looks ...stretched...
>> like drawi
Hi,
Paul Surgeon schrieb:
When TerrorGear does the UV mapping calculations on the terrain polys it
should take the terrain slope into account.
Flat ground = standard resolution
More slope = higher resolution
I think the only point where TerraGear assign UV coordinates is during
generation of
Hi Paul,
From: Paul Surgeon <[EMAIL PROTECTED]>
On Sunday 15 January 2006 10:25, dene maxwell wrote:
> Hi Paul, to my way of thinking the resolution is not important.
Pythagarus
> is more important, the distance as seen in a birds-eye view as seen by
FGSD
> is not the distance of the terrain.
On Sunday 15 January 2006 10:25, dene maxwell wrote:
> Hi Paul, to my way of thinking the resolution is not important. Pythagarus
> is more important, the distance as seen in a birds-eye view as seen by FGSD
> is not the distance of the terrain. Hence if you cut a material to a
> birds-eye distance
htgear-devel@lists.sourceforge.net
Subject: Re: [Flightgear-devel] Will my updates be used/useful?
Date: Sun, 15 Jan 2006 08:44:02 +0200
On Saturday 14 January 2006 23:43, Martin Spott wrote:
> "dene maxwell" wrote:
> > One thing I have noticed, we have alot of urban areas on ve
On Saturday 14 January 2006 23:43, Martin Spott wrote:
> "dene maxwell" wrote:
> > One thing I have noticed, we have alot of urban areas on very steep hill
> > sides. This "draping" approach can cause some very unpleasant visual
> > effects in these instances...the terrain looks ...stretched... lik
taken into account eg so 10x10 isn't stretched to try and cover what is in
reality 10x 14.14
Cheers
Dene
From: Martin Spott <[EMAIL PROTECTED]>
Reply-To: flightgear-devel@lists.sourceforge.net
To: flightgear-devel@lists.sourceforge.net
Subject: Re: [Flightgear-devel] Will my updates be u
"dene maxwell" wrote:
> One thing I have noticed, we have alot of urban areas on very steep hill
> sides. This "draping" approach can cause some very unpleasant visual effects
> in these instances...the terrain looks ...stretched... like drawing a
> picture on a piece of rubber then stretching
Hi,
BING, the light just came on!!! :-) This clarifies alot of the
confustion I also had over where FGSD was heading.
:-D
One thing I have noticed, we have alot of urban areas on very steep hill
sides. This "draping" approach can cause some very unpleasant visual
effects in these instances.
From: Ralf Gerlich <[EMAIL PROTECTED]>
Hi,
Perhaps an additional attempt for clarification: The basic idea is that the
terrain database will mainly contain 2D land coverage data in the form of
line data (e.g., for roads and streams) and polygon data (e.g., for cities,
lakes, forests, etc.). T
Hi,
dene maxwell schrieb:
Dene, I'm very sorry that we won't be able to integrate your current
work directly. The main problem here is that the database stores
primitives in order to allow easier modifications of larger scale.
What sort of primitives are you referring to? I think you might m
Hi Ralf
I've come back to this post because there is a lot in here that I don't
fully nderstand and for my efforts to be of any use to anyone I think I need
to understand it a bit better.
From: Ralf Gerlich <[EMAIL PROTECTED]>
Hi,
Dene, I'm very sorry that we won't be able to integrate your
dene maxwell wrote :
>
>> dene maxwell wrote :
>> > More to the point... Fred, is there any more I can do to help
>>
>> Test the current version and give feedback
>>
>> -Fred
>>
> I only run the win32 version. I am not aware of any way I can run the
> version currently under development in the CVS
dene maxwell wrote :
> More to the point... Fred, is there any more I can do to help
Test the current version and give feedback
-Fred
I only run the win32 version. I am not aware of any way I can run the
version currently under development in the CVS (excuse the tense, I only
have a very ba
dene maxwell wrote :
> More to the point... Fred, is there any more I can do to help apart
> from stop bugging you? ;-) (no reply necessary ).
Test the current version and give feedback
-Fred
---
This SF.net email is sponsored by: Splunk Inc
if that's ok?
Cheers
Dene
From: Martin Spott <[EMAIL PROTECTED]>
Reply-To: flightgear-devel@lists.sourceforge.net
To: flightgear-devel@lists.sourceforge.net
Subject: Re: [Flightgear-devel] Will my updates be used/useful?
Date: Fri, 13 Jan 2006 08:11:28 + (UTC)
"dene maxwell
"dene maxwell" wrote:
> Great, that sounds a good way of doing it. If any one is very keen to try
> the new scenery before the official release we can make off-line
> arrangements to distribute it and I can tag it with "alpha test" status then
> when the official release comes out everyone will
From: [EMAIL PROTECTED]
dene maxwell wrote:
>
> Thanks heaps, if i understand you...my first step would be to wait for
> Fred's FGSD enhancements to output WSDB compatible data and submit them
to
> the WSDB.
>
> Then wait for the "offical" WSDB/Terragear scenery release and correct
any
> an
dene maxwell wrote:
>
> Thanks heaps, if i understand you...my first step would be to wait for
> Fred's FGSD enhancements to output WSDB compatible data and submit them to
> the WSDB.
>
> Then wait for the "offical" WSDB/Terragear scenery release and correct any
> anomolies.
> or
> Continula
From: [EMAIL PROTECTED]
dene maxwell wrote:
>>From: Paul Surgeon <[EMAIL PROTECTED]>
>>On Tuesday 10 January 2006 09:14, [EMAIL PROTECTED] wrote:
>>>
>>> A recent (within the last week?) discussion in the fgsd-devel mailing
>>> list
>>> was about this. The goal is for fgsd to be able to output da
I wrote:
>
> Did you check the archives? There's been a *lot* of threads about
> this topic. I know it might take a while to sort through it all to
> get the answers you want; but then again, it takes other people a
> while to explain it again, too.
This was snippier than I would have liked; s
dene maxwell wrote:
>>From: Paul Surgeon <[EMAIL PROTECTED]>
>>On Tuesday 10 January 2006 09:14, [EMAIL PROTECTED] wrote:
>>>
>>> A recent (within the last week?) discussion in the fgsd-devel mailing
>>> list
>>> was about this. The goal is for fgsd to be able to output data in a
>>> format
>>>
From: Paul Surgeon <[EMAIL PROTECTED]>
On Tuesday 10 January 2006 09:14, [EMAIL PROTECTED] wrote:
> > It seems most of the mechanisms to provide changes in a format that
can
> > be submitted to the World Scenery Database (WSD) are based around *nix
> > systems and programs. Will I ( as a win32 u
On Tuesday 10 January 2006 09:14, [EMAIL PROTECTED] wrote:
> > It seems most of the mechanisms to provide changes in a format that can
> > be submitted to the World Scenery Database (WSD) are based around *nix
> > systems and programs. Will I ( as a win32 users) be able to submit in a
> > useful/us
"dene maxwell" wrote:
> It seems most of the mechanisms to provide changes in a format that can
be
> submitted to the World Scenery Database (WSD) are based around *nix
systems
> and programs. Will I ( as a win32 users) be able to submit in a
> useful/usable form, my updates, that I have use
Hi,
Dene, I'm very sorry that we won't be able to integrate your current
work directly. The main problem here is that the database stores
primitives in order to allow easier modifications of larger scale. It
might be technically possible to extract polygon primitives from the
.btg.gz files (s
"dene maxwell" wrote:
> Having read the posts concerning the World Scenery Databse and other
> associated posts, I am concerned that I won't be able to share the changes I
> have made to the scenery tiles around my local (NZWN) with others.
This is sad but in fact it's the case. One of the majo
> It seems most of the mechanisms to provide changes in a format that can be
> submitted to the World Scenery Database (WSD) are based around *nix systems
> and programs. Will I ( as a win32 users) be able to submit in a
> useful/usable form, my updates, that I have used Fred's FGSD to produce
Hi,
Having read the posts concerning the World Scenery Databse and other
associated posts, I am concerned that I won't be able to share the changes I
have made to the scenery tiles around my local (NZWN) with others.
It seems most of the mechanisms to provide changes in a format that can be
s
40 matches
Mail list logo
