> On Wednesday 02 May 2012 23:47:59 Emilian Huminiuc wrote:
>
> > Fred,
> > One small question, what's with the multiple passes/ shader
> > overrides and al
> sort of funky stuff (colour mask O.O) going on in
> terrain-default.eff. It
> looks like a real mess.
> > I wanted to clear out the unneed
Since the random buildings are now in the effect system, I've run a few tests
with the lightfield shaders yesterday.
The good news is: It works just fine.
The bad news is: It eats performance like mad.
For comparison: Without lightfield shading, I had a test case involving a large
urban area (
On Wed, 2 May 2012, Jon Stockill wrote:
>>>
>>> http://www.nanjika.co.uk/flightgear/buildings-evening.jpg
>>>
>> That looks fantastic Stuart!
>>
>> It'll be cool when you can fly over and catch someone playing Tetris
>> on
>> the side of one of those buildings. :D
>
> Damnit, now I need to find ti
On Wednesday 02 May 2012 23:47:59 Emilian Huminiuc wrote:
> Fred,
> One small question, what's with the multiple passes/ shader overrides and al
sort of funky stuff (colour mask O.O) going on in terrain-default.eff. It
looks like a real mess.
> I wanted to clear out the unneeded include_fog.ver
Fred,
One small question, what's with the multiple passes/ shader overrides and al
sort of funky stuff (colour mask O.O) going on in terrain-default.eff. It
looks like a real mess.
I wanted to clear out the unneeded include_fog.vert that crept back in somehow
and found that...
Or is this an arte
Good to know, thanks.
Texture work is not important, since there's way more people who know
their way around PS/GIMP than people who can code such autogen
systems. :)
--
Live Security Virtual Conference
Exclusive live eve
On Wed, May 2, 2012 at 4:18 PM, Björn Kesten wrote:
> Stu, do you have plans to "regionalize" the autogenerated buildings?
This is already supported in the code, and just needs someone to spend
some time creating textures and changing some XML.
The buildings (including the texture to use) are def
Wow!
Stu, do you have plans to "regionalize" the autogenerated buildings?
If so, one could lift the concept from MSFS. They assigned a
letter-code to every global region (e.g. Germany and Scandinavia was
"K") and thus, you didn't have american wooden houses in Germany or
cobblestone houses in Asi
On Wed, 2 May 2012 07:17:45 -0700 (PDT), Gene Buckle wrote:
> On Tue, 1 May 2012, Stuart Buchanan wrote:
>
>> Hi All,
>>
>> I've just committed a change that adds emissive lighting to the
>> random
>> buildings:
>>
>> http://www.nanjika.co.uk/flightgear/buildings-evening.jpg
>>
> That looks fantas
On Tue, 1 May 2012, Stuart Buchanan wrote:
> Hi All,
>
> I've just committed a change that adds emissive lighting to the random
> buildings:
>
> http://www.nanjika.co.uk/flightgear/buildings-evening.jpg
>
That looks fantastic Stuart!
It'll be cool when you can fly over and catch someone playing T
Am Wed, 2 May 2012 15:02:42 +0200 (CEST)
schrieb Frederic Bouvier :
> Hi Chris,
>
> >
> > Am Wed, 2 May 2012 14:25:09 +0200 (CEST)
> > schrieb Frederic Bouvier :
> >
> > >
> > > These messages are link error. Did you do a 'make clean' on all
> > > OSG,
> > > SG et FG ? My guess is that some fi
Hi Chris,
>
> Am Wed, 2 May 2012 14:25:09 +0200 (CEST)
> schrieb Frederic Bouvier :
>
> >
> > These messages are link error. Did you do a 'make clean' on all
> > OSG,
> > SG et FG ? My guess is that some files could be compiled with on
> > version of gcc and some with another.
> >
> > Regards,
Am Wed, 2 May 2012 14:25:09 +0200 (CEST)
schrieb Frederic Bouvier :
>
> These messages are link error. Did you do a 'make clean' on all OSG,
> SG et FG ? My guess is that some files could be compiled with on
> version of gcc and some with another.
>
> Regards,
> -Fred
>
Hi Fred!
Thanks for yo
Hi Chris,
> Hi all!
>
> This is my first mail on this list, so please forgive me
> newbie-mistakes. :)
> I've posted this request for help on the forum and had no luck with
> it.
> No one answered. So, I'll try here. I hope I'm no bother...
> http://www.flightgear.org/forums/viewtopic.php?f=45&t=
On Wednesday 02 May 2012 10:08:07 Renk Thorsten wrote:
> > Sorry, was looking at the wrong shader. You don't assign the terminator
> > to an
> > uniform in the in the model-default.eff.
>
> I'll be buggered... you're right. How embarrassing...
>
> * Thorsten
I'll push a hot-fix then.
Emilian---
What I think happens, is that, without the detail option on, the same shaders
are used for terrain and models (terrain-haze), thus they get the terminator
assigned from the teerain-default.eff. Once you enable the detailed shading
for the terrain, that uniform is no longer assigned, since in ter
> Sorry, was looking at the wrong shader. You don't assign the terminator
> to an
> uniform in the in the model-default.eff.
I'll be buggered... you're right. How embarrassing...
* Thorsten
--
Live Security Virtual Con
Hi all!
This is my first mail on this list, so please forgive me
newbie-mistakes. :)
I've posted this request for help on the forum and had no luck with it.
No one answered. So, I'll try here. I hope I'm no bother...
http://www.flightgear.org/forums/viewtopic.php?f=45&t=16180
My problem:
I've tri
Sorry, was looking at the wrong shader. You don't assign the terminator to an
uniform in the in the model-default.eff.
Adding the correct entry fixes it here:
terminator
float
terminator
--
On Wednesday 02 May 2012 09:28:44 Renk Thorsten wrote:
> > Hmm, that would be really strange, and a legitimate bug then.
> > Worth a try with the property filter to see if that fixes them.
>
> That's actually how terminator-relative-position-m (the sun position for
> shader purposes) is done - see
> Hmm, that would be really strange, and a legitimate bug then.
> Worth a try with the property filter to see if that fixes them.
That's actually how terminator-relative-position-m (the sun position for shader
purposes) is done - see
Environment/local-weather-rules.xml
* Thorsten
--
> On Wed, May 2, 2012 at 9:53 AM, Frederic Bouvier wrote:
> > But when two techniques use the same number, they are merged.
> > I don't know if it was intended but one effect can modify one of
> > it's parent without rewriting the predicate, and can lead to
> > problems
> > when we need to reassign
On Wednesday 02 May 2012 09:18:15 Renk Thorsten wrote:
> > Using tied properties as uniforms?
>
> I don't think so, because the same parameters do get updated per frame just
> fine when shading the terrain.
>
> * Thorsten
Hmm, that would be really strange, and a legitimate bug then.
Worth a try w
On Wednesday 02 May 2012 12:13:23 Emilian Huminiuc wrote:
> Using tied properties as uniforms?
> http://code.google.com/p/flightgear-bugs/issues/detail?id=445
This is easily solvable using a property-filter (check
Environment/metarinterpolator.xml), that writes the properties to some other
plac
On Wed, May 2, 2012 at 9:53 AM, Frederic Bouvier wrote:
> But when two techniques use the same number, they are merged.
> I don't know if it was intended but one effect can modify one of
> it's parent without rewriting the predicate, and can lead to problems
> when we need to reassign numbers
In f
> Using tied properties as uniforms?
I don't think so, because the same parameters do get updated per frame just
fine when shading the terrain.
* Thorsten
--
Live Security Virtual Conference
Exclusive live event will cov
On Wednesday 02 May 2012 09:07:57 Renk Thorsten wrote:
> So far we had: start with skydome shader on and landmass set to 4:
>
> -> models appear black and are not shaded properly
>
> Click on landmass slider without changing the value:
>
> -> modelss jump to proper shading
>
> I've made one mor
So far we had: start with skydome shader on and landmass set to 4:
-> models appear black and are not shaded properly
Click on landmass slider without changing the value:
-> modelss jump to proper shading
I've made one more observation: Do the above at noon. Then change to dawn
-> models rema
On Wednesday 02 May 2012 10:53:31 Frederic Bouvier wrote:
> > On Wednesday 02 May 2012 11:43:28 Emilian Huminiuc wrote:
> > > The default effects usually specify their techniques with higher
> > > numbers to >allow any inheriting effect to insert their own
> > > techniques below them, >techniques t
> On Wednesday 02 May 2012 11:43:28 Emilian Huminiuc wrote:
> > The default effects usually specify their techniques with higher
> > numbers to >allow any inheriting effect to insert their own
> > techniques below them, >techniques that get activated by the same
> > condition.
> Actualy this shou
On Wednesday 02 May 2012 11:43:28 Emilian Huminiuc wrote:
> The default effects usually specify their techniques with higher numbers to
>allow any inheriting effect to insert their own techniques below them,
>techniques that get activated by the same condition.
Actualy this should read:
The
On Wednesday 02 May 2012 07:55:19 Renk Thorsten wrote:
> > No, you got the system wrong.
> > When an effect inherits from another it "rewrites" those parts that are
> > common
> > between the two xml files, keeping the parts that are different.
>
> Yes, but what's wrong with making that conditiona
> No, you got the system wrong.
> When an effect inherits from another it "rewrites" those parts that are
> common
> between the two xml files, keeping the parts that are different.
Yes, but what's wrong with making that conditional based on technique number?
What functionality would this destr
No, you got the system wrong.
When an effect inherits from another it "rewrites" those parts that are common
between the two xml files, keeping the parts that are different. Thus if
runway inherits from terrain the actual runway effect as seen by flightgear
gets a technique 4 of its own (inherit
34 matches
Mail list logo
