> 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.
I don't know how y
> How should we call our new baby? Is it 3.0.0 or is it 2.10.0? This is a
> carry-over from our last release and gets answered along with: "Is
> Rembrandt production ready?"
Hm, I had a list of items for a 3.0 half a year ago, so some progress chack
along these lines:
* Scanery-related
'Publish
> Hmm . that's an underwhelming list, and I can't come up with anything
> that's
> really any better. Does that encapsulate the problem?
Well well, it would seem our shader-based treatment of light and the
environment is quite competitive against what FSX has to offer:
http://www.flightgear.or
I don't know if anyone is interested in what precisely I've been up to of late,
but I do know that I get frequently asked why the reflection (bump, you name
it) effect isn't yet working in atmospheric light scattering, so this is sort
of an answer to that. Well, I also sort of wanted to write t
> But if this thunderstorm looks exactly the same from different angles is
> not that important in case there IS a thunderstorm probably. Sharing the
> center position, pressure, movement, winds and probably cloud density
> over network is sufficient, in case this data could be shared in
> metar-li
> Could this weather properties be shared trough network somehow
> ?
No idea, I'm not into MP at all, so I know next to nothing about how easy or
difficult it is to transmit anything more.
> Sorry this dumb questions, I just had the intention to show flightgear
> weather on a external map/radar
> Flightgear has a nice (local and global) weather implementation AFAIK.
> Are there some ideas (or solutions) how to map custom or shared weather
> values in a (internal or external) weather radar" ?
Someone was working on that, and we got to the point that Advanced Weather
writes thunderstorm i
> You need to do High Dynamic Range rendering to accurately capture these
> differences and the eye's ability to adapt to them. Basically, you do all
> the rendering in floating point and at the end convert the values to RGB
> colors with a mapping operator. We don't do that yet.
I'm currently ren
> I suspect the difference in light intensity
> (dynamic range) doesn't fit in an 8-bit 3-component color.
It sure doesn't, but I think you're thinking way too complex. We don't want to
render physical light intensity, we want to render perceived light intensity,
and there the Weber Fechner law
> I think that's just a side-effect of having so many pixels covered by
> (multiple) quads with alpha. I'm not sure there's much we can do
> about that, unless we somehow start dropping sprites. I'll have a
> think - 3D cloud perf has always been a big challenge.
Based on my own experiments, I
> If you need any information about the moon's position and/or phase, just
> let me know. It should be trivial to extract these values from the
> ephemeris code.
Thanks, that was what I was hoping for :-)
It depends a bit on if Fred wants to do anything with the moon - my scheme
would be fin
> Interesting, looks good. So effectively it glows...
Not really - unlike glowing stuff, it is actually obscured by cloud cover for
instance.
* Thorsten
--
Everyone hates slow websites. So do we.
Make your web apps faste
I was toying with this for a while, but now I have a reasonably cheap solution
to render moonlight effects:
http://www.flightgear.org/forums/viewtopic.php?f=47&t=14755&start=195#p170250
Now, all I need is the info about the current moon phase and if the moon is
above the horizon which is *some
Thanks for the responses, I think I understand the issue much better.
> The eye catcher is not the gem, but things you see, and notice, from a
> distance,
> like a huge flag with "free" writen on it.
I guess it'd just be a matter of setting things up. Sure, on a laptop things
tend to get lost.
Hi Durk,
> Please note that I never said that we didn't *have* any major new
> features. The major difference between previous years and this year was
> that we didn't have *obvious* eye catchers. Every feature you mention is
> really a great improvement, but they are not sufficiently salien
> So I know clouds write a z-buffer, and I know terrain reads a z-buffer -
> they just don't seem to use the same z-buffer. In which case the whole
> scheme doesn't work as advertized. Does that make any sense? Is there
> anything special about clouds?
Seems I can't figure that one out on my
> presenting something drastically new every year. But this year the new
> essence seemed to be missing somewhat. I didn't really feel that we had
> any major innovations to show (with the notable exception of project
> rembrandt, which ran well on Alexis' machine). With our multiscreen
>
> If I understand correctly, you have only one model of the cloud, which
> has a bunch of sprites and a few tracer polygons. I don't know if this
> is practical in the current system, but I'm saying that it would be
> better to draw only the tracers in the tracer pass and the sprites in
> the real
> I realize that I'm confused about whether you are working on Stuart's
> clouds in C++ or clouds in Nasal.
They're the same now - there's an interface to generate a cloud from Nasal
which is what I'm using, whereas Basic Weather uses and xml format for layer
declaration, but for rendering purp
> I haven't really been following this thread closely... are the
> "tracers" basically occludes? Are they completely opaque?
Yes, they're completely opaque. That's tracer.frag - if it gets a white
gl_Color from the vertex shader, it's a real cloud and the fragment is dropped,
if it gets any othe
> I see no reason to include multiple options of the same texture if one
> could do just fine. It's just a matter of removing them from the xml
> file (or comment hem out).
I take the lack of other responses as silent agreement and will proceed as I
see fit then.
> I also noticed you effectively
I've managed to get a test implementation for the idea of filling the depth
buffer early by clouds by inserting tracers into some of the cloud calls. The
tracers are in essence just opaque white sheets marked with a top shade factor
of 0.0 (black - no real cloud can ever have that low a value)
I have two questions to which I'd like to gather a few opinions:
1) Emilian pointed out here
http://www.flightgear.org/forums/viewtopic.php?f=68&t=17114&hilit=procedural+texturing&start=30#p165312
that terrain textures are a fair share of memory consumption and concluded that
we shouldn't use mu
> I'm talking about the ep ... which is done for each vertex, everytime
... and the relevance of that observation to the ongoing discussion is...?
It's needed among other things to construct a sun/horizon coordinate system for
the lighting computations, so the ep has to be computed regardle
> 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 uniform float doesn't have a matrix transform. I thought y
> Maybe it would be better next time to ping some more people and notify
> them
> about problems in the scenery toolchain.
> Emilian did it
> (http://code.google.com/p/flightgear-bugs/issues/detail?id=888)
> and we fixed the bug, which means that your additional calculations are
> unnecessary now
> Hint... I already knew that
In which case I'm puzzled by your remark that I wouldn't be interested in
supporting custom scenery anyway when you know that I've cooked up a scheme
which does just that. But maybe I'm simply too tired.
* Thorsten
--
> 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 snowline problem for custom terrain half a year ago by passing
camer
>> 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 have a north-pointing vector, the rest is trivial
because you
> Even the oldest hardware that
> supports OpenGL programmable shaders implements vector operations, and
> a vector multiply-add has, as far as I know, the same cost as a scalar
> operation. On the other hand, the shader compiler might be able to
> combine multiple scalar interpolations into vecto
> One can assume that
> a vec4 varying is no more expensive than a vec3.
(...)
> I'm not sure it's useful to think of each component of a varying
> vector as a "varying" i.e., three vec3 varying values use up three
> varying "slots," and so do 3 float varying values
I dunno...
Just counting the
I thought it might be a good idea to write up a few things I've tried recently
and not seen in widespread use - so that either others know about them as well
or I can find out what the pitfalls are.
Basically this is about reducing the number of varyings, which is desirable for
at least two re
> Do you have some other local modifications (materials / texture set) in
> this screenshot? But it's not a part of the world I have explored, maybe
> I'm simply ignorant of our textures in such places.
I think this is all classified as EvergreenForest (or at least some forest...),
and the re
> and it works particularly well with some of the
> angle-dependent rock shaders.
Indeed it does - Yosemite valley from above (not bad for default scenery...):
http://users.jyu.fi/~trenk/pics/tree_slopes.jpg
* Thorsten
---
Hi Stuart,
played around with this a bit yesterday... *very* nice feature!
> The default values look about right to me from a typical
> temperate latitudes viewpoint, and using
> much smaller values gives a quite nice effect possibly suitable for
> more northerly latitudes.
I agree that the def
> The reason I didn't just label it "material definitions" was that I
> don't think that
> a new user is going to understand what that means, while the concept of
> different textures should be familiar to people who have some background
> in graphics, or gaming.
I'd go for something like 'terrai
Hi Emilian,
> Understood...
> I will refrain from any further tests/opinions on this topic then. Please
> accept my apologies, and disregard any of the issues I've raised.
> Everything's working smooth, and looks better than IRL... it's just my
> imagination playing tricks, better get my eyes che
> 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 the right, and can't be of much use.
Assuming that this is the
> 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 for Scotland (hmmm, good idea :)
I wanted to have a look
> I've sometimes wondered if we could have much greater variety of
> 'trees', to place scrub (cactus in Central America, bramble in Scotland)
> in areas where full trees don't make sense. I guess wi the regional
> materials that ought to be much easier?
Yes, it's quite straightforward - trop
Nice - looking forward to it!
> (and before anyone asks, I'm not planning to reduce tree density on
> shaded slopes...)
We wouldn't really want that - shaded slopes in my experience do not grow less
trees, they just grow different tree species... :-) I wonder if we could trick
the shader into d
> I'm taking a look at this merge request. One thing I don't quite
> understand from doing a code read is the chance to the overall
> Grasscover to use the tundra-hawaii-green texture, on line 1909 of
> regions/materials.xml.
>
> Can I check this is intentional?
This is intentional - I'm trying t
I've just created a merge request
https://gitorious.org/fg/fgdata/merge_requests/181
with the following content - if Fred and/or Stuart could take a look:
Weather:
* bugfixes for the combined weather GUI which restore the Advanced Weather
functionality
* new weather scenarios corresponding to
> I am pretty confident (and hope to test, but it sounds like you might
> beat me to it) that for either the classical (non-Rembrandt) render,
> doing a depth-write *only* pass of the entire scene will be a net win.
> (Again assuming the fragment shader is the bottleneck). Since this will
>
> 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 as white with
essentially no light and fog computations t
> I wonder how we deal with this with the next release- I'm sure a whole
> lot more users will complain about the "stuck" while launching FGFS.
By printing a message like 'Building database during first startup' on the
screen? By including the binary nav data with the release? Doesn't look like
> To summarize, all objects having a pass of render bin -1 are rendered
> before any object having a render bin 1. If an object have two passes,
> it is rendered twice, once with the objects of the same render bin than
> the first pass, once with the objects of the same render bin than the
> second
It seems some change during the last weeks broke parts of Advanced Weather in
at least two places (I had no problems under any conditions until my update
yesterday, now I can reproduce both issues consistently on both master and my
devel branch).
The more serious problem is that under some cond
I'm trying to understand why clouds can obscure hills and hills can obscure
clouds properly.
My individual bits of knowledge are:
* clouds are drawn from outside in, because they are in a depth sorted bin, and
this is why clouds obscure other clouds properly.
* hills are not drawn from outsid
I'm trying to catch up with recent developments, and I've pulled and compiled
an up-to-date snapshot today. One thing I stumbled across by accident is that
we seem to have lost the ability to do software rendering as a fallback. If I
start today's Flightgear binary without access to the GPU dev
> So you are calling for git monkeys that take care of the "tedious"
> process of getting changes into the tree?
If it is as critical to do this right as you say, everyone might be better off
if only people who know what they're doing handle commits and every other
commit goes through them, ra
> Every fgdata contributor who creates complicated xml/shader files should
> be able to understand basic git workflow as well...
I'm not sure if you really mean every contributor, or every contributor with
commit rights to FGData. In the second case I'd agree with you, but in case
it's the fir
Hi All,
unfortunately, due to personal reasons, I won't have much coding time for the
rest of the year, which means that I probably won't have a chance to do some
things I sort of promised to do (make more shaders work in the atmospheric
light scattering framework, help making atmospheric ligh
There remains this strange discrepancy between what people are outraged about
and what could potentially stand in court.
> Wah. They're immoral scammers by any examination. They're suckering
> people into not only buying free software, but public domain materials as
> well!
> I think the trut
> We haven't
> been able to pin them down on a specific technical violation of the gpl,
> but that doesn't mean they are legitimate, honorable, and ethical.
> They're immoral scammers, plain and simple.
It galls me to speak up for FlightProSim, but such statements are, as far as I
am concerned,
>> FlightProSim does not defraud its customers as far as I am aware.
>
> According to reports on this very list (hint) and elsewhere they don't
> comply with the money-back guarantee they advertize.
Well, since there's always small-print (which I don't know) I would leave that
to the courts to es
>>Hence I would use the same license to keep off scammers.
(...)
> Anything but code should be possible to license similar to GPL, but not
> allowing any commmercial use.
My two cents:
First of all, define your use of 'scammer' here. From Wikipedia, I get "A
confidence trick is also known as a
> I know, some people on the forum would like to eventually replace
> fgfs(.exe) with nasal(.exe), because apparently everything is "just
> better" (tm) when implemented in Nasal (core = bad, nasal = good). But I
> really think this is a completely wrong direction - and harming the
> project.
Co
> Computing constant values at runtime is bad design and we should not do
> that. No matter if we notice a significant increase in load time now or
> not. The ground elevation at a specific point is well known at scenery
> generation time and that is where the vertical position of an object has
> t
I still haven't given up on the idea of 'masking' the terrain pixel shading by
the cockpit, since even a very simple mask easily makes the system 50% faster
for me. Lauri has kindly given me some instructions on how to use the stencil
buffer - so the idea was to start by filling the stencil buff
Of late, I have increasingly been running into some segfaults which seem to
have to do with peak memory usage (I don't think memory leaks are a major issue
for what I've been seeing, since some segfauls happened quite early on, and
especially when I try pushing my limits of graphical goodies).
> The typical fix is to edit the conflicting files and "git add" them the run
> "git rebase --continue".
> But these files don't exist so I can't edit them, git add fails, git rm also
> fails since they don't exist.
If the files no longer exist, I think one solution is to tell the system to
s
> Do I want atmospheric scattering on or off? That affects which are the
> top two sliders.
You want atmospheric scattering on. Then the top sliders are 'Landmass' and
'Transition'. These you want at 5.
What did it take to make the correct dialog appear? Are you sure you have the
updated ef
> I'm on the master/next branch here for these tests. But I haven't kept
> close enough tabs on the lightfield/regional gui options dialog box to
> quite know exactly what I should be seeing or where to start for hunting
> what's going on. Shouldn't I be seeing quite a few detailed shader
> op
> Hmmm, my shader micromanagement dialog box is only showing two options
> right now. Category General: landmass and water.
I don't have the bandwidth at the moment to pull back master, but I've checked
the local branch from which I merged and I checked the log for FGData master on
GIT - amon
> Is this work something that is active by default or does it need to be
> turned on? Or is it only availble in a particular area? Do I need to do
> anything special to look at the results beyond just take off and fly
> around
> anywhere?
* atmospheric light scattering: on
* shader micromanage
> Is this work something that is active by default or does it need to be
> turned on? Or is it only availble in a particular area? Do I need to do
> anything special to look at the results beyond just take off and fly
> around
> anywhere?
Forgot: Works currently only with Materials/regions/mat
> are there any screenshots available which compares "before/after"?
Not as such... A collection of work in progress is in the forum
http://www.flightgear.org/forums/viewtopic.php?f=47&t=16884
but this is with my private not-necessarily-GPL development environment.
The comparison is otherwise q
> Are you sure about the syntax of the --prop=/sim/... command line
> option? I thought it should be something like: --prop:/sim/... If I'm
> right, you might still have the traffic manager running.
For all I know and can test, they're equivalent. Changing to --prop:/sim/...
doesn't change t
Some variants of this have been going on for some time - currently my console
ends up swamped with messages (I suspect the AI traffic) like this:
Checking for end of cruise stage for :
Descent rate : 7.62
Descent speed : 154.333
VerticalDistance : -483.402. Altitude : 3584.04. Elevatio
Hi Fred,
I have created a merge request containing part of my recent experiments with
procedural terrain texturing - please have a look (I hope I haven't messed up
the request again...).
https://www.gitorious.org/fg/fgdata/merge_requests/175
Thanks,
* Thorsten
--
> Are you sure you're using/looking at the correct fgdata? Looking at the
> files here they use the proper uniform to determine if the normalmap is dds,
> and reverse the normals only in that case:
I was looking at my devel branch rebased against master. Seems like one of my
'GIT strikes agai
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 water_lightfield.frag which has pretty
identical normal-generating line
> I've just pushed a change that allows a material definition in
> materials.xml
> to include a section, which is merged with the
> section of the effect. So you can now define parameters in the
> materials.xml
> file that can be used as uniforms in the effects file, and therefore
> shader
> I'm very keen on the placement maps myself, but they are fundamentally
> incompatible with the crop shader, as the placement information is
> required well above the shader layer.
I like the idea of the placement masks, and one could use them to do LOD by
passing the mask itself to the shader
Since we usually don't have roadmaps and things, I thought I might try to put
this up for discussion early on.
I've been experimenting with a partially procedural texturing approach, and I
think this is the way to go forward, the outcome looks very convincing. My
experiments are coded within t
> Actually, the code that creates the texture is in
> scene/util/StateAttributeFactory.cxx, but you would have to do
> something similar to the noise texture code in TextureBuilder to
> access your texture from a texture. It would be nice if the Effects
> framework had a way to load arbitrary textu
First of all, a big thanks to Tim - Akenine-Moller &Co. is indeed quite an
interesting read, and in addition to gaining a better understanding, I've so
far experimented successfully with a heightfield for parallax and normal
mapping and a simple irrandiance map instead of the ambient term in lig
>>> The depth-pass-only pass is a well known optimization, but the fact it
>>> is not helping implies that our bottleneck is not in fragment
>>> processing.
Most of the discussion is drifting a bit over my head now, but I'm pretty sure
that's not what I am talking about.
I am talking about a sit
> Which is very unfortunate, since in the common case it would allow a
> huge amount of tile/terrain pixels to be dumped. Could we use a buffer
> copying to trick to initialise a stencil plane on the far camera based
> on the near-camera Z-buffer?
>
> I've no idea what the penalty of a z-buff
> This is an optimization to avoid running really expensive shaders on
> geometry that will be hidden from view. The GPU has an "early Z"
> capability and won't run a fragment shader if it knows the result will
> be discarded.
But that can't be all that is going on. In this case I'd expect that if
> The main reason to render textures at this stage is that textures with
> transparency do change the fragments that are rendered. Calculating
> the fog color seems wrong, but I don't have the sources in front of me
> and gitorious is acting up.
So since we're not using transparent textures for te
May I ask yet another dumb question?
In the first rendering pass of default terrain rendering, we use default.vert
and terrain-nocolor.frag as shaders. I have so far mindlessly copied the first
pass since I had no real clue as to what it is for. Its purpose seems to be to
establish that farawa
Hi Tim,
> If I could give some gentle advice, perhaps based on out-of-date
> observations: you could really benefit from a serious study of
> computer graphics. I highly recommend the book "Real Time Rendering"
> by Akenine-Moller et al.
Thanks, that's actually not a bad idea. I think I'll get my
> A number of effects files use .dds textures, leading to error messages
> on the console.
>
> IIRC in the last release, we suppressed these error messages for the
> release, and I think we need
> to do something for for 2.8.0 as well.
>
> Of particular concern is terrain-default.eff which uses
> T
> ..this kinda blending looks so good it should IMHO go into the
> current release, even if it means delaying the release.
Just in case: The effect is quite tricky to get right, because the parameters
and overlay texture need to be somewhat carefully tuned for each landclass,
untuned it looks qu
> Believe it or not, computer graphics researchers (not me) think about
> shader work in those terms too. It comes off as a bit pompous to
> assume that no one here would understand what you are talking about or
> be able to come up to speed on the math if necessary.
I'm assuming here that the mai
> Action plan for recovery :
>
> 1. Go straight to the point (actionee: Thorsten R.)
> 2. Write much shorter e-mails (actionee: Thorsten R.)
> 3. Read Thorsten's e-mails (actionee: rest of the world)
> Bertrand.
>
> (My) Life insurance : This is a miserable attempt of humour to try to
> remind eve
> So no reason the get polemic or arrogant:
>
>> I wrote 'scenery and models', I did not write 'trees'.
> ...
>> Which of these two statements did you find hard to understand?
Heiko, that didn't come out of the blue. That came after I took the time to
explain something, then explained it in diffe
>> I get to see a seamless
>> and plausible match between sky and terrain from ground level to low
>> Earth orbit, at all times of the day and under any weather condition.
>> Scenery and models are now rendered correctly with the sky at all locations
>> and
>> all times.
>
> Really? Look at th
Hi Stuart,
> Question for Thorsten: I've only integrated the
> terrain-haze.[vert|frag], not terrain-haze-detailed.[vert|frag]. How
> much additonal quality does that add, and is it appropriate for trees?
I'm in the middle of my holiday right now and will basically be mostly offline
for anothe
> FIRST: I'm not criticing your work. Instead I really appreciate your
> work, as you try to make things right!
> But I criticise the way we handle new features. Due to this I can pretty
> well understand Freds concerns about adding a simple switch for enabling
> Rembrandt, which is a experim
My (completely biased) opinion:
> *2.6.0
> In 2.6.0 we had only the choice between default sky or Zan's sky shader.
> In both variants shaders on aircraft and on terrain worked, but there
> was the problem with horizon.
>
> It gave us pretty cool looking skies, as you can see on the 2.6.0
> ga
Heiko: > Thanks, that's now an answer I was looking for.
>
> Though I'm sure we will get bug reports as well by users complaining
> where the shader from 2.6.0 went, or why shaders won't work.
> Some of this confusion was already visible in the forum.
I don't want to bitch, but the thread starte
> Is there a way we can have all three possibilities (default, skydome
> shader, Thorstens atmospheric light scattering) selectable?
Atmospheric light scattering should not be thought as different from skydome
shader - it is the terrain/model/whatnot shader combination consistent with the
skyd
> 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 the sun
direction in the horizon plane to compute light
> So.if.someone.could.setup.a list of effect(combination)s that don't
> work, I can try to construct something.
>From my side:
Lightfields currently support
- of the detailed shader config dialog: water reflection (water slider) and
snow/dust (currently on landmass slider), all other sliders
> Anyway, just reporting what I see, but I am sure other
> users must get VERY confused by such strange - it works,
> then it does not work - behavior... but I suppose when
> it is all documented the sun will shine, and shadows
> cast...
Indeed. Forum reports suggest that users do get confused. So
I would like to point the attention of people who can commit on flightgear and
simgear to two merge requests put in by Vivian recently:
https://www.gitorious.org/fg/simgear/merge_requests/26
https://www.gitorious.org/fg/flightgear/merge_requests/1564
This contains functionality which is releva
> I'd add to this list
>
> * lightfields integrating well with other shaders.
>
> For example, I know that the random vegetation doesn't work with
> lightfield shaders, and the fix that Emilian put together to allow the
> random buildings to work was a workaround rather than a full fix. I
> think
201 - 300 of 415 matches
Mail list logo