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
Only a win if
1) your draw order wrt depth is chaotic and unfixable, and
2) you are fillrate bound
...
-- Chris
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
The runway effect parameters override any parameters it has in common
with the terrain-default effect (since it inherits from it), it is not a bug,
that's how the system is supposed to work.
I don't know, it doesn't strike me as consistent.
There are two control structures here:
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
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 destroy?
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 conditional based on
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 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:
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 that get
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
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
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.vert
Hi Heiko,
Okay, so cloud and terrain shaders on both detail levels perform okay, but the
skydome shader doesn't come on - one can see the mismatch between terrain and
sky in the distance, and there's no scattering effect at all in the sky. Which
means we need to find the reason why, and
On Tuesday 01 May 2012 12:19:27 Renk Thorsten wrote:
Question to Fred (and other Effect people) - is this a bug or am I misusing
the system?
What happens is as follows:
* the code finds a runway and looks first through terrain-default.eff to see
what it should do. It finds, if skydome
On Tuesday 01 May 2012 15:33:36 Emilian Huminiuc wrote:
The runway effect parameters override any parameters it has in common with the
terrain-default effect (since it inherits from it), it is not a bug, that's
how the system is supposed to work.
This is fixable by changing the snow texture
I did try that- after some more tryings with different settings I found
out that I didn't know yet that it only works with advanced weather AND
at high altitudes (above 10.000ft!!)
Agreeing somewhat with Fred, the screenshots don't make it easy to see what is
going on, as there is neither
Actually, no. All that needs to be on is the skydome shader button, no
matter altitude or shader settings. When you move water or landmass above
4, the detailed version of the shaders come on. It is possible that the
non-detailed version of the shader doesn't run for you either (Emilian told
I tested last night with win7 and xp using ATI cards (winXP - hd3850,
win7
64bit hd5870 tested with all ATI drivers since 11.4 beside the latest)
and
the skydome shader is crashing fgfs. The crash looks like the crash that
occours if i enable the generic shader. No console output.
Well,
Hello Thorsten,
First again sorry when it sounded like rant.
But I must admit I was dissapointed seeing the results on my system here.
Having said that:
To the best of my ability to determine from the screenshots, the skydome
shader doesn't work for you (for some yet to be determined
Hello Thorsten,
a) watch the console for any error message from shaders trying to compile
but not succeeding
Absolutly nothing- no error messages, just the usual .dds-warnings
b) get me a screenshot from ~20.000 ft with good visibility over land
facing the rising sun at dawn with skydome
Hi Heiko,
What do I miss? Where am I wrong? Do we get something like back with
the next release in less than 3 months?
In case you didn't notice, Thorsten screenshots are from altitude, not
from the ground, with more clouds on screen, and at dusk or dawn.
Put yourself in the same conditions
On Sun, 2012-04-29 at 12:42 +0100, Heiko Schulz wrote:
Hello,
I updated data today with the latest Hudson Build.
Regarding the Terrain Haze v1.3. Lightfield I must admit, I'm really
dissapointed.
Somehow I don't get the images presented on the forum. Or am I wrong, and all
this only
Hello Fred,
In case you didn't notice, Thorsten screenshots are from altitude, not
from the ground, with more clouds on screen, and at dusk or dawn.
Put yourself in the same conditions to do the comparison
I did try that- after some more tryings with different settings I found out
that I
Chris
It would be interesting to use skeletal animation to get rid of some of
the
batch spam with complex multipart models. It wouldn't even necessarily
require reworking the model data -- we could initially do the merge and
bone
attachment when a model is loaded.
What are the animation
You'll have to elaborate on how 'spin' is special.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond.
The direct link to the merge request is usually handy.
Will do next time.
Effects/terrain-default.eff has two techniques number 4. They seem
similar
Could you check ?
Aarg... GIT strikes again. The two blocks with technique 4 are identical copies
- one of them can go. Must be my screwup
Thorsten,
One comment - to avoid any problems with merge requests being
lost/ignored - who is this 'aimed' at? I.e who needs to review it
and decide? I don't feel qualified, for example :)
(But maybe I just merge it and see who complains ;)
Not that you need to pick on
It also seems that some model are not lighted anymore :
http://frbouvi.free.fr/flightsim/fgfs-haze-1.3.gif
The only place models get the effect is if they go via
Effects/model-default.eff if they're using their own effect file they are not
in the scheme.
In addition, neither the random
Thorsten,
One comment - to avoid any problems with merge requests being
lost/ignored - who is this 'aimed' at? I.e who needs to review
it
and decide? I don't feel qualified, for example :)
(But maybe I just merge it and see who complains ;)
Not that you need
It also seems that some model are not lighted anymore :
http://frbouvi.free.fr/flightsim/fgfs-haze-1.3.gif
The only place models get the effect is if they go via
Effects/model-default.eff if they're using their own effect file
they are not in the scheme.
I was speaking about the
Presumably all these effects could actually be done as one screenspace pass?
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT
Presumably all these effects could actually be done as one
screenspace pass?
Please elaborate
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has
I usually commit Thorsten's work. Will have a look in the next days.
This is in git now, with the duplicated technique removed
-Fred
--
Live Security Virtual Conference
Exclusive live event will cover all the ways
On Friday 27 April 2012 06:50:22 Renk Thorsten wrote:
Thank you for the info - that's good to know (although admittedly I have to
do some reading trying to understand what 'that' precisely is - the linked
article is a bit opaque for me). Seems there's a lot to learn about the
hidden secrets
That problem goes away if landmass shader is disabled. The strange thing
is that when set to some value, the problem appears but as soon as you
click on the landmass slider, without changing the value, the problem
goes away too.
Is this anything I could have caused? Because I have no idea
That problem goes away if landmass shader is disabled. The strange
thing is that when set to some value, the problem appears but as soon as
you click on the landmass slider, without changing the value, the
problem goes away too.
Is this anything I could have caused? Because I have no
I have no idea too. It looks like an uninitialized value that get one
when we click on the slider. Do you reproduce the problem I see ?
For some (yet to be determined) reason the shader settings are not archived on
Flightgear exit in my local devel branch since my next-to-last update three
I have no idea too. It looks like an uninitialized value that get
one when we click on the slider. Do you reproduce the problem I see ?
For some (yet to be determined) reason the shader settings are not
archived on Flightgear exit in my local devel branch since my
next-to-last update
Do you reproduce the problem I see ?
Okay, found the problem with userarchive and eliminated it Now I see the
same thing you describe, the model shader doesn't start up correctly, but all
goes well once one just clicks the slider. The model shader doesn't seem to be
doing anything at all,
Do you reproduce the problem I see ?
Okay, found the problem with userarchive and eliminated it Now I
see the same thing you describe, the model shader doesn't start up
correctly, but all goes well once one just clicks the slider. The
model shader doesn't seem to be doing anything at
Btw - with the recent GIT, I now get Rembrandt working with --prop:/sim/
rendering/no-16bit-buffer=true in the commandline and a shadow map no
larger than 4096x4096. I'm getting ~9-10 fps out at KSFO, about 14 in
low vertex count situations like TNCM or a carrier - is that in the
expected
This doesn't happen when you click on another slider or when we start
at 1. Should be something specific to landmass.
Tenuous, but:
Terrain and models are sent to the same shader code (terrain-haze.*) by the
effect file technique 5. To switch the detailed terrain rendering on, I used
the
It would be interesting to use skeletal animation to get rid of some
of the batch spam with complex multipart models. It wouldn't even
necessarily require reworking the model data -- we could initially do
the merge and bone attachment when a model is loaded.
What are the animation cases? So far I
. but that is wishful thinking
Date: Sat, 28 Apr 2012 08:46:37 +1200
From: chr...@ijw.co.nz
To: flightgear-devel@lists.sourceforge.net
Subject: Re: [Flightgear-devel] Terrain Haze v1.3
It would be interesting to use skeletal animation to get rid of some
of the batch spam with complex multipart models
I've just created a merge request containing the recent work I've done for the
haze shaders (haze in water shader, dust effect, Mie scattering on clouds, ...).
The procedure described in the wiki to create a merge request did not work for
me, I could not push a local branch containing my
On 26 Apr 2012, at 13:20, Renk Thorsten wrote:
I've just created a merge request containing the recent work I've done for
the haze shaders (haze in water shader, dust effect, Mie scattering on
clouds, ...).
The procedure described in the wiki to create a merge request did not work
One comment - to avoid any problems with merge requests being
lost/ignored - who is this 'aimed' at? I.e who needs to review it
and decide? I don't feel qualified, for example :)
(But maybe I just merge it and see who complains ;)
Not that you need to pick on any one person, but if
On Thursday 26 April 2012 12:20:36 Renk Thorsten wrote:
I've just created a merge request containing the recent work I've done for
the haze shaders (haze in water shader, dust effect, Mie scattering on
clouds, ...).
The procedure described in the wiki to create a merge request did not work
Thorsten,
One comment - to avoid any problems with merge requests being
lost/ignored - who is this 'aimed' at? I.e who needs to review it
and decide? I don't feel qualified, for example :)
(But maybe I just merge it and see who complains ;)
Not that you need to pick on any one
49 matches
Mail list logo
