> ..a pointer to your previous message would help here, this thread
> is broken (in at least my MUA) and getting hard to follow.
Maybe we just have some cultural misunderstandings?
The way I see it - if you want to make a statement in a discussion, you have to
read what has been said before. No
Hi,
On Thursday, February 21, 2013 16:43:51 James Turner wrote:
> This is moving in the right direction for sure. I'd like to go a little
> further, and make the LOD setting a simple checkbox labelled 'reduce detail
> adaptively'. Then make the LOD ranges (for trees, clouds, AI models,
> whatever
On Thu, 21 Feb 2013 18:53:06 +, Renk wrote in message
:
> > the reason to be of the EQUIPMENT is to override the limit of the
> > EYE vision.
> > Are we doing the error to merging this two ?
>
> Would you mind reading the previous messages in the thread? I don't
> mean to be impolite, but I
> the reason to be of the EQUIPMENT is to override the limit of the EYE
> vision.
> Are we doing the error to merging this two ?
Would you mind reading the previous messages in the thread? I don't mean to be
impolite, but I really don't want to write everything twice. Thanks.
* Thorsten
On 02/21/2013 04:26 PM, James Turner wrote:
> On 21 Feb 2013, at 15:54, Stuart Buchanan wrote:
>
>> On Thu, Feb 21, 2013 at 12:59 PM, James Turner wrote:
>>> Suggestion - if z/Z are pressed with advanced weather enabled, make the
>>> popup-message say 'disabled since visibility is being controlle
On 21 Feb 2013, at 16:32, Renk Thorsten wrote:
> I think not... I was about to bring this up as well. We have a mixture of
> real visibilities and auxiliary LOD parameters
>
> * we have visibility-m and ground-visibility-m which are actually used for
> rendering, i.e. they really correspond t
> Another option would be to move the visibility control to a dialog, with
> a slider / spin box, and explicitly disable it when advanced weather is
> selection. Then we could lose the keybinding completely, which is
> something I want to move towards for options that are infrequently used,
On 21 Feb 2013, at 15:54, Stuart Buchanan wrote:
> On Thu, Feb 21, 2013 at 12:59 PM, James Turner wrote:
>> Suggestion - if z/Z are pressed with advanced weather enabled, make the
>> popup-message say 'disabled since visibility is being controlled by advanced
>> weather'.
>>
>> Another option
On Thu, Feb 21, 2013 at 12:59 PM, James Turner wrote:
> Suggestion - if z/Z are pressed with advanced weather enabled, make the
> popup-message say 'disabled since visibility is being controlled by advanced
> weather'.
>
> Another option would be to move the visibility control to a dialog, with a
Thorsten
> -Original Message-
> From: Renk Thorsten [mailto:thorsten.i.r...@jyu.fi]
> Sent: 21 February 2013 10:31
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] Low visibility issues
>
> > I was not referring to a frame rate issue, but FG running out of memory.
On 21 Feb 2013, at 11:33, Emilian Huminiuc wrote:
>> 4) z/Z is disabled because weather comes with a model for the vertical
>> change of visibility as you go to different altitudes. You are allowed to
>> affect that model (that's what sliders are for), but you are not supposed
>> to micro-manage
> I was talking about the 16km value (sorry for not being more clear about
> that) and see below for the huge value.
Let me get this straight. You state that the 16 km are a pretty sane value. The
proposal being discussed is to load terrain to 20 km no matter what the
visibility is. Vivian ha
> I was talking about the 16km value (sorry for not being more clear about
> that)
Sorry this should have read:
I was talking about the 16km value (sorry for not being more clear about that)
and see below for the huge value.
---
On Thursday, February 21, 2013 11:13:21 Renk Thorsten wrote:
> > Why should those users be forced to give up on those goodies just
> > because one
> > part of the rendering scheme doesn't want to play by the rules? Even
> > more so when there's no indication that happens...
> >
> > The default ma
> Why should those users be forced to give up on those goodies just
> because one
> part of the rendering scheme doesn't want to play by the rules? Even
> more so when there's no indication that happens...
>
> The default max visibility value is a pretty sane default, and simply
> increasing t
On Thursday, February 21, 2013 10:31:18 Renk Thorsten wrote:
> > I was not referring to a frame rate issue, but FG running out of memory.
> >
> > http://www.flightgear.org/forums/viewtopic.php?f=5&t=18913&p=177392#p17739
> > 2
> >
> > It is rare to see that happening using the current scenery, bu
On Wednesday, February 20, 2013 08:44:24 Renk Thorsten wrote:
.
>
> 1) Black skies: This may either be skydome unloading which I can't reproduce
> (but we should have a property preventing that, I don't know if it's set
> only by Advanced Weather, if not then this is a Basic Weather problem, n
> I was not referring to a frame rate issue, but FG running out of memory.
>
> http://www.flightgear.org/forums/viewtopic.php?f=5&t=18913&p=177392#p177392
>
> It is rare to see that happening using the current scenery, but here if I
> select random buildings and objects with a high value for trees,
Thorsten wrote:
> -Original Message-
> From: Renk Thorsten [mailto:thorsten.i.r...@jyu.fi]
> Sent: 21 February 2013 06:54
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] Low visibility issues
>
> Vivian:
>
> > There seem to be significant issues with the loading
19 matches
Mail list logo
