Curtis Olson wrote:
> My recollection is that the "original" fgfs-construct created any shared
> edges that weren't already created. So if free standing tile was created
> before any of its neighbors, all the shared edges (and corners) should be
> created: N, S, E, and W.
>
> If that's not the
Martin Spott wrote:
> Topologically cleaned CLC2000v15 is now available on the FlightGear
> MapServer web map and if you download Shapefiles, you'll get them from
> the revised dataset. Please let me know if you encounter technical
> mistakes in this data !
CLC2006v15 likewise,
Martin.
On Thu, Jan 19, 2012 at 4:01 PM, Martin Spott wrote:
> Yup, using this "Shared" directory is still state-of-the-art. Anyhow,
> this machinery works only in the limited case where just one or two
> edges have to get seamed together - the western and the southern edge
> of the new tile. It doesn't
Hi Jason,
Jason Cox wrote:
> On Tue, 2012-01-17 at 17:49 +, Martin Spott wrote:
>> Supplying the flags "--xdist=19 --ydist=18" (around a center at
>> "--lon=9.875 --lat=49.375", but there's no difference with "--lon=10
>> --lat=49") seem to work nicely (test is still running, but looks good
>
> Hmm - actually, the wind properties _are_ interpolated over time if set
> from METAR which can be easily verified by observing
> /environment/sea/surface in the property browser and changing the
> global-weather scenario from, say "stormy monday" to "fair weather".
> Despite the fact that the pr
It seems like the wave go into hyperspeed while the interpolation process
is happening, and only settle down and look right after the interpolation
is complete.
Curt.
On Thu, Jan 19, 2012 at 3:54 PM, Torsten Dreyer wrote:
> Am 19.01.2012 11:59, schrieb Torsten Dreyer:
> > Am 19.01.2012 11:27,
Curtis Olson wrote:
> On Tue, Jan 17, 2012 at 11:49 AM, Martin Spott wrote:
>
>> 1.) As far as I can tell there's still no reliable solution for
>> creating proper, smooth seams between a newly built terrain tile and
>> the adjacent, old tiles.
>> The "fgfs-construct" honours two flags "--no-write
Am 19.01.2012 11:59, schrieb Torsten Dreyer:
> Am 19.01.2012 11:27, schrieb Emilian Huminiuc:
>> I had another question, could the wind vectors reported to the shader
>> be interpolated on a longer (10x - 20x or so) time frame, or could
>> they be updated only once a given time (1 minute or so)?
>>
Martin Spott wrote:
> Martin Spott wrote:
>> Supplying the flags "--xdist=19 --ydist=18" (around a center at
>> "--lon=9.875 --lat=49.375", but there's no difference with "--lon=10
>> --lat=49") seem to work nicely (test is still running, but looks good
>> so far), [...]
>
> Test is still running
On Thu, Jan 19, 2012 at 1:31 AM, Mathias Fröhlich
wrote:
> Yes, the usual user might ask 'what should I do?'
>
> What about:
> Image "..."
> uses compressed textures which cannot be supported on some systems.
> Please decompress this texture for improved portability.
How about something along the
Am 19.01.2012 11:27, schrieb Emilian Huminiuc:
> I had another question, could the wind vectors reported to the shader
> be interpolated on a longer (10x - 20x or so) time frame, or could
> they be updated only once a given time (1 minute or so)?
>
> I ask this in an attempt to cure the fast movi
On Thursday 19 January 2012 00:14:34 Torsten Dreyer wrote:
> Hi,
>
> due to a bug in weather-utility.nas, the wave shader properties were
> stuck at a constant value for wind-speed zero.
> There was more unfortunate code in that file, so I refactored it as
> xml based property rule. This is the re
12 matches
Mail list logo
