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
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
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
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 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 more
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
place
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 with
Sorry, was looking at the wrong shader. You don't assign the terminator to an
uniform in the technique n=5 in the model-default.eff.
Adding the correct entry fixes it here:
uniform
nameterminator/name
typefloat/type
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
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 technique n=5 in the model-default.eff.
I'll be buggered... you're right. How embarrassing...
* Thorsten
I'll push a hot-fix then.
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
On Friday 11 May 2012 22:19:43 syd adams wrote:
Hi guys,
Is it just me or has the model-combined shader stopped reflecting ?
Moving the model slider seems to have no effect now .
Syd
Hi Syd,
Any specific aircraft you're refering to? I've just tested it and it works.
(777-200ER and IAR80)
On Saturday 12 May 2012 21:49:46 Stuart Buchanan wrote:
Unfortunately, it appears to no longer work when the lightfield shader
is enabled - the buildings all lose their textures.
I've had a look at the hierarchy of effects files, but can't see any
obvious problem. Do you have any idea what
On Wednesday 23 May 2012 10:23:12 Renk Thorsten wrote:
Using the default random building density, the tiles that are loaded
initially when sitting on the runway generates ~ 340k random
buildings.
We might be generating too many buildings then?
The greater Los Angeles area has between
On Wednesday 23 May 2012 12:10:16 Stuart Buchanan wrote:
Actualy the Geater LA + Inland Empire area should use more somewhat small
buildings, as the overwhelming majority of the residential buildings in
that area are individual houses, all the way E to San Bernardino.
So, are these
On Wednesday 23 May 2012 14:16:02 Emilian Huminiuc wrote:
So, are these areas defined as Urban, or Suburban/Town in our global
scenery?
-Stuart
Just by looking at how the terrain is textured in FG, I can say they are
defined as Urban.
And the mapserver seems to agree
On Wednesday 23 May 2012 11:20:28 Renk Thorsten wrote:
We're not talking a regionalized building placement concept here... we're
doing an order of magnitude case study for our average US-themed city.
* Thorsten
No, I think you're extrapolating from a particularly bad case of mismatch
On Wednesday 23 May 2012 12:05:05 Renk Thorsten wrote:
No, I think you're extrapolating from a particularly bad case of mismatch
between reality and simulation. I wasn't talking about regionalized
building
placement, I was talking about bad landclass representation in that
particular
On Friday 08 June 2012 09:53:58 Renk Thorsten wrote:
tie to some yet unknown master switch?
Who has a plan?
* Thorsten
There's no master switch anymore. There's a property that's checked by some
nasal to set the quality of the shaders, but there's no master switch
available for effects.
On Monday 11 June 2012 07:25:44 syd adams wrote:
hi all.
I updated the Citation-II to use model-combined-deferred , but it
originally used reflect.eff.Try as i might i cant seem to get the
reflectmap section to work.Is this a bug? Ive tried greymaps and alpha
maps but see no effect . I get a
On Wednesday 13 June 2012 12:05:42 Renk Thorsten wrote:
Now, random vegetation seems to increase vertex count a lot, and this may
well be not doable by just taking the code and applying it to the
vegetation (it didn't work with clouds either). So it probably needs a
dedicated approximation
On Tuesday 19 June 2012 12:29:34 Renk Thorsten wrote:
There is a simple solution to that. Move the work in the fragment
shader. You
won't be scene complexity bound, and you'll also have the correct depth
available as (...)
Right... but I need the projection of the vertex position into
On Wednesday 27 June 2012 16:37:11 Heiko Schulz wrote:
Is there a way we can have all three possibilities (default, skydome shader,
Thorstens atmospheric light scattering) selectable?
Cheers
Heiko
Not quite, since both terrain-default and model-default effects have a
separate set of
On Wednesday 27 June 2012 18:39:30 Heiko Schulz wrote:
Hello all,
I think the problem now is that the nice scatter effect sky dome no longer
works correctly with any render mode in the git version. The scatter
effect sky dome will give you very pretty skies -- especially in
combination
On Friday 29 June 2012 12:13:31 Edheldil wrote:
On 06/28/2012 05:31 PM, Heiko Schulz wrote:
I have no idea how to communicate it or present it.
That's why I hoped that we maybe can have all three skydome variants
selectable. So we would have the default skydome, the skydome shader and
the
On Saturday 30 June 2012 10:44:46 James Turner wrote:
I happen to have a spare 8800GT (512MB, 64k rom - NOT suitable for Mac use)
First person to say they want it for something useful gets it. Ideally you'd
PayPal me the price of posting it to wherever you are in the world.
If something
On Thursday 05 July 2012 15:21:24 Viktor Radnai wrote:
1. When the aircraft is parked with no parking brake, it will usually
start to roll slowly backwards -- pushed by the wind and maybe the
runway slope. If I start the engine on idle, the thrust generated by the
idle prop might stop this
On Saturday 14 July 2012 06:22:06 Renk Thorsten wrote:
In case we want to remove those, the corresponding *.ac files have to be
changed. Is there an opinion on that question either way?
* Thorsten
This should be fixed too, as of now, in GIT.
Hopefuly, warning messages (if left enabled)
On Monday 30 July 2012 16:29:28 Curtis Olson wrote:
I am in no way picking on any single committer here. This just happens to
be the most recent commit message that came through while I was thinking
about this (sorry Gijs, we do really love you. I'm mean, not really really
really love, but
On Friday, August 03, 2012 12:29:51 Renk Thorsten wrote:
Just stumbled across this one:
Effects/water.eff now declares png textures for reflection and nose to avoid
dds. The relevant commit changed the effect file and water_sine.frag but
didn't change the corresponding lines in
On Friday, August 03, 2012 15:43:45 Emilian Huminiuc wrote:
On Friday, August 03, 2012 12:29:51 Renk Thorsten wrote:
Just stumbled across this one:
Effects/water.eff now declares png textures for reflection and nose to
avoid dds. The relevant commit changed the effect file
Hi,
I've just pushed a change to fgdata that modifies the model-combined and model-
combined-deferred effects when running under Rembrandt.
This was done in order to be able to provide the same effects that are
available for transparent surfaces in the clasical pipeline for transparent
Hi,
Another change, hopefuly after this things will be clearer.
With previous change I forgot the case of the model shader being disabled,
thus transparent surfaces would lose transparency and be rendered wrong.
I've commited a new effect, Effects/model-combined-transparent, which should be
On Monday, October 01, 2012 19:16:09 Alan Teeder wrote:
James
I have just run a very quick check on a few aircraft. My apologies, but I
should have used the word opaque and not translucent.
F22 (jsbsim) has an opaque HUD, Mirage F1 has an opaque cockpit. They are
both transparent when
On Thursday, October 04, 2012 06:42:30 Renk Thorsten wrote:
You know that rendering a transparent object twice alter its
transparency.
Of course, you can avoid to render it in the color buffer using write
mask in one pass.
What I do with the trees is render just the opaque bits early on
On Saturday, October 06, 2012 23:34:13 Stuart Buchanan wrote:
Hi All,
I've just added a trivial enhancement to the rendering options dialog
to allow in-sim selection of the materials.xml file. This is limited
to those available in the base package (regions, default, dds).
I've used the
On Sunday, October 07, 2012 07:44:53 Renk Thorsten wrote:
I've had a look at this in Scotland, where it is a bit too bright based
on my own experience, so I'd like to leave this change so it only applies
to South America. Obviously I could do the opposite and make some
specific materials
On Sunday, October 07, 2012 11:28:24 Renk Thorsten wrote:
First I get this when opening the shader settings dialog:
Nasal runtime error: non-objects have no members
at $FG_ROOT/Nasal/props.nas, line 181
called from: __dlg:shaders-lightfield, line 32
and the slider is off to
On Thursday, October 18, 2012 06:43:32 Renk Thorsten wrote:
Speaking of which - it'd be nice to have local north as well defined
direction as well - that would allow for things like the snowline
being higher on south slopes ...
In the Northern hemisphere ;-)
Quite so - but once you
On Thursday, October 18, 2012 07:58:14 Renk Thorsten wrote:
Btw, in terrasync terrain you can safely use gl_Vertex.z as altitude.
There are some issues with that one, but only in custom terrain generated
after 2009, which you're not interested in supporting anyway.
FYI, I fixed the
On Thursday, October 18, 2012 08:58:43 Renk Thorsten wrote:
In any case, since the 'additional computations' are subtracting one number
from another number, I can just about live with the performance degradation
caused by the operation, given that it provides backwards compatibility to
On Thursday, October 18, 2012 09:31:27 Renk Thorsten wrote:
And the matrix transform is for free...?
Oh, I forgot, a useless matrix transform is ok to be run on milions of
vertices, but one that actualy has a use, and runs on tens or maybe
hundreds at most, is killing performance
A
Hi all,
I've pushed a change to the effect files that makes sure that shaders are
disabled when /sim/rendering/shaders/quality-level is 0 or non existant.
Previously this relied on gui.nas to set the individual shader levels to 0,
and fgviewer had no easy way to disable them.
This will change
Hi Thorsten
The atmospheric rendering scheme should not be affected by this change.
All I did was to add /sim/rendering/shaders/quality-level to the techniques
that had a single check on /sim/rendering/shaders/$shader.
The atmospheric rendering related techniques, and the Rembrandt ones, have
Hi,
You might want to take a look here:
http://ubuntuforums.org/showthread.php?s=92e1641ae03fc09b4a10e772e569987bt=1478192page=2
I'm not sure if the settings suggested there still work with current drivers,
but it's a start.
Cheers
Emilian
On Wednesday, November 28, 2012 08:17:56 Renk Thorsten wrote:
Um... what should I do with this? I've gotten one comment pointing to a
problem with the urban shader, but I can reproduce the same problem on a
pristine master branch, so it's not
On Friday, December 14, 2012 10:15:16 Stuart Buchanan wrote:
On Fri, Dec 14, 2012 at 7:25 AM, Renk Thorsten wrote:
Aw, that looks bad... I've never seen anything like, so my first guess
would be that it's one of these NVIDIA vs. ATI issues (which are really
tough to
understand from my side
On Friday, December 14, 2012 10:15:16 Stuart Buchanan wrote:
On Fri, Dec 14, 2012 at 7:25 AM, Renk Thorsten wrote:
Aw, that looks bad... I've never seen anything like, so my first guess
would be that it's one of these NVIDIA vs. ATI issues (which are really
tough to
understand from my side
On Friday, December 14, 2012 12:33:52 Renk Thorsten wrote:
Thorsten, from discussion on irc, it seems you're assigning to a varying
in
the fragment shaders. See this log: http://dpaste.com/845317/
Most likely the other errors will go away once you fix that.
Thanks, the log was very
On Friday, December 14, 2012 13:28:08 Renk Thorsten wrote:
Those are fixed, but you still have some implicit casts/coversions in
there,
those are tolerated by the nvidia compiler but not by other drivers:
http://dpaste.com/845842/
Aw, a forgotten decimal point - that's picky. Okay, how
On Sunday, December 16, 2012 19:37:37 James Turner wrote:
On 16 Dec 2012, at 19:18, Stuart Buchanan wrote:
I'm surprised there's any benefit to using a very low resolution texture
set. Surely the normal textures are already loaded by OSG and it's
cheaper just to refer
to those rather than
The DR400 Guide (Aircraft/DR400/DR400 Guide.pdf)
commited in this has a non-GPL compatible license (All rights reserved).
I think this situation needs to be fixed
(either the guide removed, or a proper GPL version of the guide is pushed)
I think it would be a good idea if contributors would
On Thursday, January 10, 2013 08:03:39 Renk Thorsten wrote:
Which reminds me - is there a performance penalty for using many uniforms?
My impression is not, at least I've never seen any, but it'd be good to
have this confirmed. Also, can be declare uniform vec 3 in the effect
files, and if
On Friday, January 11, 2013 12:07:27 Renk Thorsten wrote:
I was wondering if anyone has experience with the stereoscopic view modes of
FG. Coming with my new laptop were very fancy NVidia IR synchronized LCD
shutter glasses for 3D vision, and I've used them to have a look at some 3D
movie
On Thursday, January 17, 2013 13:16:03 Renk Thorsten wrote:
I've recently come across the idea of using one generic sand or rock texture
and selecting the particular hue desired by multiplying every pixel value
with an (rgb) vector - so rather than two different-colored sands, we'd
just store
Also see here for uniforms:
https://www.opengl.org/wiki/Uniform_(GLSL)
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with
-combined-deferred.eff and
ubershader.vert/frag) has not been introduced by myself but by Frederic
Bouvier and Gijs de Rooy with major additions and revisions by Emilian
Huminiuc and Vivian Meazza 2011 (says so in the shader code). That shader
requires to insert generate tags into each model which
On Tuesday, February 05, 2013 08:17:43 Renk Thorsten wrote:
2) Flickering in water
http://www.flightgear.org/forums/viewtopic.php?f=68t=18924start=15#p176001
With the sun in the back, under some conditions a strange flickering in the
water can be observed. Dialling down the amount of
On Tuesday, February 05, 2013 11:12:14 Renk Thorsten wrote:
Cannot reproduce here on today's GIT.
Given the intermitent nature of it, I have a possible culprit (but
you're not
going to like it):
-try with the texture fetches outside of the conditionals, see if you
(or the reporter)
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, not
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=5t=18913p=177392#p17739
2
It is rare to see that happening using the current scenery, but here if I
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 max
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 12:33:17 Renk Thorsten wrote:
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
On Saturday, February 23, 2013 07:08:41 Renk Thorsten wrote:
A lot of stuff, mostly deflecting the discussion to other irelevant points
* Thorsten
While I should know better than to answer to this, as it will again get
deflected to other areas, let's imagine ourselves a simple scenario:
On Saturday, February 23, 2013 09:36:23 Renk Thorsten wrote:
It's a fact that the distances out to which we draw trees and buildings are
considerably less than how far we potentially draw terrain (120 km max.) So
these things are separated even now - we don't attempt to render random
On Saturday, February 23, 2013 11:51:55 Stefan Seifert wrote:
The solution is not to give crude tools like limiting visibility to the
user. The solution is to fix FG to be consious about how much memory is
available and make the best use of it. Yes, many games simply limit
visibility if
On Saturday, February 23, 2013 13:09:29 Stefan Seifert wrote:
Why do you want the user to have to repeatedly press a key after starting
the sim instead of setting the maximum visibility once and for all in the
advanced weather dialog? In other words: why should the user press a key
_n_ times
101 - 169 of 169 matches
Mail list logo
