Presumably you could just ask osg or the gl to discard the top mip level(s)
rather than altering the source art to work around apple's driver bugs?
--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to K
Hi,
on some Mac Models with Intel HD 3000 graphics flightgear showed a really nasty
flickering effect.
I had the problem with c172p and the bumpspec shader effect enabled.
After a lot of investigations I discovered that actually "size matters". I get
this kind of flickering artifacts if text
The airports I would like to add within my area of interest are HUJI Jinja,
HUKJ Kajjansi, and HUKK Kakira. They are all in Uganda - many Ugandan airports
are not in the database, but there are also less than five airports with paved
runways in the country, as far as I can tell.
How can I appen
Hi John
Are this strips/fields missing in apt.dat 810 and 850 ? Do this strips
have a FAA code or is it outside U.S. ?
Cheers, Yves
- Ursprüngliche Nachricht -
Von: "FlightGear developers discussions"
An:
Cc:
Gesendet:Fri, 13 Apr 2012 08:23:54 -0700 (PDT)
Betreff:[Flightgear-devel] Addi
Thorsten wrote:
>
> > Plus, if you neglect the curvature effect in every relevant vector,
> > the rendering artefacts at the tile boundaries must go away, because
> > the differences in rendering geometry between tiles go away, and
> > they're the only thing which can introduce the artefacts in t
> Plus, if you neglect the curvature effect in every relevant vector, the
> rendering artefacts at the tile boundaries must go away, because the
> differences in rendering geometry between tiles go away, and they're the
> only thing which can introduce the artefacts in the first place.
Turns
I have made a couple airports which are not in the airport database in the 8.10
format in TaxiDraw.
Before anyone tells me about 8.50 these airports are nothing more than missing
grass/dirt airstrips.
What is the best way to add them to apt.dat, so I might be able to use
Terragear with these a
Sorry. I have the settings corrected now.
gapalp
gap...@gapalp.net
> Original Message
> Subject: Re: [Flightgear-devel] List Etiquette was airport list
> From: Ron Jensen
> Date: Fri, April 13, 2012 9:12 am
> To: FlightGear developers discussions
>
>
>
> On Thursday 12 April
On Thu, 12 Apr 2012, Frederic Bouvier wrote:
>
> Here is a video with a steady view to see shadow stability.
>
> http://youtu.be/JtEXIn2yL94
>
> I also added 3 different sequences with different levels of filtering.
> Filtering is not yet configurable but is selectable in the
> sunlight shader wit
On Thursday 12 April 2012 16:11:14 gap...@gapalp.net wrote:
> Wow, this works better, is simpler code, and is much
> faster! Plus it will be easy to allow the user to pass configurations such
> as range and airport type as mentioned, to suit GA planes or
> heavies. AirportInfoFilter
> filter;
> If it looks right in one limited test case, doesn't mean it's right, or
> the proper way to deal with it (so it won't backfire later on)
Look, basic ray optics says that the error in ray propagation I make by
neglecting the curvature is linear proportional to the error in normal angle
which
> Actualy it makes assumptions about the lighting scheme used, and it
> "boosts" the visible reflection of the sun using a texture instead
> of the light's specular in the specular pass.
> That gets to be less aparent in the Rembrandt specular pass.(That
> would be easily converted by using the su
On Fri, 13 Apr 2012 06:23:23 +, Renk wrote in message
:
> > Here is a video with a steady view to see shadow stability.
>
> Okay, thanks, that's helpful. My flickering is a bit worse than in
> the first case in this video, but not much.
..what happens if you run your video card at a slower
On Friday 13 April 2012 11:00:14 Renk Thorsten wrote:
> >> 'flat' = 'For any visibility we can actually render, the normal (before
> >> wave
> >> noise) is (0,0,1) in model space to such a good approximation that you
> >> won't spot the difference to the actual normal including earth
> >> curvature
On Friday 13 April 2012 12:35:57 Frederic Bouvier wrote:
> Emilian can testify that the current water shader is extremely
> difficult to convert to Rembrandt because it doesn't have a
> clear reference frame. It seems to work in object space but
> with assumptions on the object-to-world transform
>> 'flat' = 'For any visibility we can actually render, the normal (before
>> wave
>> noise) is (0,0,1) in model space to such a good approximation that you
>> won't spot the difference to the actual normal including earth
>> curvature if
>> I show you a picture.'
>>
>> Cheers,
>>
>> * Thorsten
On Friday 13 April 2012 10:42:48 Renk Thorsten wrote:
> > Apart that the earth is a sphere and ocean tiles are large pieces
> > of terrain where the curvature is quite apparent, how whould you
> > define flat ?
>
> 'flat' = 'For any visibility we can actually render, the normal (before wave
> nois
On Friday 13 April 2012 10:09:12 Renk Thorsten wrote:
> > To be safe you need to limit yourself to 32 float varyings.
> > Note: a vec3 counts as 3 float varyings, a vec4 as 4 etc.
>
> Okay thanks, then I am safe. Btw (spotted this while checking) - is there
> any particular reason to compute a nor
> Apart that the earth is a sphere and ocean tiles are large pieces
> of terrain where the curvature is quite apparent, how whould you
> define flat ?
'flat' = 'For any visibility we can actually render, the normal (before wave
noise) is (0,0,1) in model space to such a good approximation that y
> De: Renk Thorsten
>
> > To be safe you need to limit yourself to 32 float varyings.
> > Note: a vec3 counts as 3 float varyings, a vec4 as 4 etc.
>
> Okay thanks, then I am safe. Btw (spotted this while checking) - is
> there any particular reason to compute a normal from gl_Normal in
> the ver
> To be safe you need to limit yourself to 32 float varyings.
> Note: a vec3 counts as 3 float varyings, a vec4 as 4 etc.
Okay thanks, then I am safe. Btw (spotted this while checking) - is there any
particular reason to compute a normal from gl_Normal in the vertex shader, use
a full varying ve
> Emilian proposes the weather system to be agnostic about the shaders,
> not the shaders to be agnostic about weather.
Advanced Weather works based on abstraction layers. The high levels are unaware
of any technical issues ('we have a tile with 6/8 Nimbostratus coverage and
light rain'), as th
On Fri, 2012-04-13 at 11:53 +0300, Emilian Huminiuc wrote:
> To be safe you need to limit yourself to 32 float varyings.
> Note: a vec3 counts as 3 float varyings, a vec4 as 4 etc.
Ah I dind't know there was a difference between floats and vectors.
Erik
Renk Thorsten wrote:
Emilian wrote:
>> It would be good to make it Weather system agnostic from the
>> effect/shader side of things, don't you think?
>
> No.
>
> If you want to render atmospheric light effects, the shader needs to
> know the structure of the atmosphere and at what altitude the
On Fri, 2012-04-13 at 09:25 +0100, Vic Marriott wrote:
> Hi,
>
> More and more, the FG forums are showing that the most recent improvements,
> added to the existing code, are too memory consuming for operation on
> anything less than a high powered, up-to-date, well equipped computer.
>
> Thoug
On Fri, 2012-04-13 at 08:45 +, Renk Thorsten wrote:
> > Not when the varying number is limited. So you gain a bit of speed, but
> > you lose a lot of compatibility.(think ATi/intel, or OSS drivers for nVidia)
>
> You gain a lot of speed. But what is the max. allowed number of varying? It's
On Friday 13 April 2012 08:45:26 Renk Thorsten wrote:
> > (*)No it's not bad design, it's a conscious hack around the state that
> > the environment interface was in when the shader was developed.
>
> Something like a property rule or a Nasal script outside the shader would
> have done the trick a
> (*)No it's not bad design, it's a conscious hack around the state that
> the environment interface was in when the shader was developed.
Something like a property rule or a Nasal script outside the shader would have
done the trick as well... But I'm not arguing why it's done the way it is, an
Hi,
More and more, the FG forums are showing that the most recent improvements,
added to the existing code, are too memory consuming for operation on anything
less than a high powered, up-to-date, well equipped computer.
Though I, and probably most other FG users, am delighted that improvements
On Friday 13 April 2012 07:05:40 Renk Thorsten wrote:
>
> I know that Vivian and Emilian had the plan to separate fog and light
> computations from the shaders and have them in general functions to be
> called by all shaders. While this is very elegant and maintenance friendly,
> I've come across
I've made a case study converting the high quality water shader (my favourite
shader effect :-) ) to lightfield rendering in the last two days (see some pics
in the forum here
http://www.flightgear.org/forums/viewtopic.php?f=47&t=14755&start=150#p155110
sunrises with water reflection look awes
31 matches
Mail list logo