Following a 'tradition', I'd like to remind of a few issues which I think
should perhaps be sorted out before 3.0, partially have been discussed
previously and involve me asking for some help on the C++ side.
1) rain layers still do not drift with the wind and will be eventually
displaced from
> But several people reported that hi-res aircrafts break fps in MP, and
> downscaling liveries solves the problem (and this follows from Stuart's
> email). But if mipmap _is_ applied to liveries, then why we have to have
> lo-res liveries separately? Won't one of mipmap levels do the same?
> Recently I was told that some planes have liveries of so high resolution
> that you have to install low resolution versions to have a decent fps
> during multiplay. But doesn't FG use mipmaps for liveries? If not then
> are there plans to do so? Or should the livery be prepared in a certain
> So, in V3.0 I plan to change this. Instead of using a scatter-gun
> approach to placement and a mask, random building location will be
> read directly from the mask, defined by a single pixel. The color
> (actually blue value from 0-255) will define the size of building
> (small medium, large)
> - a baseline texture set that is of adequate, but not high quality
> (e.g. max 1024x1024 size for landcover, or something else agreed to be
> good enough) to be included by default in the installers
> (this would also be friendly to people on older hardware with limited
> VRAM)
> ..another test case suggestion: if you have a radeon card, pop that
> in and see how it looks with that, if you don't have a radeon card,
> try swap out "nvidea" for "nouveau" in your /etc/X11/xorg.conf and
> install your distro's nouveau and libdrm-nouveau2 etc drivers
> alongside your nvidea dr
> Did a fresh install and needed all day to get ~7GB of aircrafts only to
> find that my most loved the IAR 80 has gone.-
>
> Who was ridden by hell to remove the best airplane?
The author himself. But you've downloaded 7 GB of GIT repository, not 7 GB of
aircraft, and the GIT repository contai
A report of performance dramatically improving for advanced weather when 3d
clouds are switched off in the rendering menu (you still get to see 3d clouds)
http://www.flightgear.org/forums/viewtopic.php?f=69&t=16630&start=30#p189983
I've played around with this, and I can't reproduce any signif
> Does FlightGear currently "support" cloud turbulence? You know, like
> when you go through a cumulus cloud, there's /a lot/ of turbulence?
> Well, IIRC, FlightGear doesn't support have any.
Yes, it does - it's part of modelling thermals in Advanced Weather. There's a
checkbox on the detaile
... to Vivian, the converted wake shader appears to be working
http://users.jyu.fi/~trenk/pics/als_new_8_13_02.jpg
(not sure when I will be able to commit it, but at least the work is done).
* Thorsten
--
Introducing Per
> I propose pushing out the release by a month. I've got a bit more time
> available
> for FG right now, but not as much as I did 12 months ago, and it sounds
> like
> James and Thorsten R are similarly time limited. I think it will take
> longer than usual to address any issues found in the R
On the risk of making myself really unpopular, but would now be a good time to
defer the release? It seems James is caught in the middle of moving, Stuart
indicated some other private things piling up, I have the maddest travelling
schedule I've ever had in my life this fall, and I haven't seen
> On a related note there's also the question of the mouse modes to
> consider. I no-longer use the old-style mouse modes, instead using
> the right-click-to-pan-view mode instead. Should that be available
> through the GUI (in which case I've got to re-write various parts of
> The Manua)
I'm a
This is terrific news. Big thanks for the hard work, and especially for going
for GPL in the end! This will easily be one of the showcase planes of FG.
* Thorsten
--
This SF.net email is sponsored by Windows:
Build for
> 1. I noticed some distortion in the texture placement in grass airfields
> when using the ALS.
>
> Here are some snapshots:
> --basic shader: http://imageshack.us/f/15/p917.png/
> --ALS: http://imageshack.us/f/196/9lcl.png/
> --Rembrandt: http://imageshack.us/f/839/4ll1.png/
>
> The shots are f
> I am seeing the same(NVidia GT450, Windows 7) . All runways are black.
>
> If I set shader options –> generic to minimum the runway is restored.
>
> It happened within the last few days.
I've had a different sort of problem with the runway shaders since a few weeks
on my up-to-date Linux versio
> That would be appreciated. Emilian already reminded me of the normalmap
> feature, so it'd be interesting to compare the two and see which one I
> prefer.
I don't know if Emilian gave you the notion that these would be competing
options or not, but the notion isn't correct. You're not technic
>> Having thought about this a bit more I'm going to propose we do 2.12.0
>> now and
>> "pre-announce" 3.0 as the Feb 2014 release to give us just a little
>> more time
>> to prepare and make the 3.0 as polished as possible. After all, it'll
>> be the third
>> major release in 15 years :) .
O
Hi Stuart,
> Ah yes. I remember you mentioning this before, me saying I'd add it
> to my TODO list, and then failing to do so. Sorry. I've now added it
> to my wiki TODO list so I don't forget again. Are you thinking about
> the sprinkling of lights that we put over the terrain, the VASI/PAPI
> Interesting! Any way we can see this example "live"? I'd love to
> experiment with it in the 744's cockpit, but that'll have to wait till
> after next weeks exams...
I'll be happy to let you have the files - but the Vinson can't go to GIT
because it doesn't really work due to the uv-mapping
> I looked at this possibility already. The carrier deck is made up of a
> number of odd-shaped areas, for historical reasons. I don't think that a
> complete rebuild of the flight deck is worth it for this very nice
> eye-candy
> (just too much work). Alexis might think differently.
Do you real
Since the idea hasn't really caught with modelers yet, I've tried to get a more
practical demo of the virtue of a grain texture and tried to put a grain effect
on the Vinson flightdeck (I've always felt that the homogeneous grey color
doesn't justice to the details of the model otherwise).
Her
Referring to the version number discussion, I've been given to understand here
http://www.flightgear.org/forums/viewtopic.php?f=19&t=20137#p185619
that there have been already "core developers referring to the next release as
2.12" a while ago who would now be "obviously pretty annoyed about it
> It would need to take in all of the, by now well known, variables -
> making it by no means a simple beast to manage.
>
> If this could be automated in some way it would be much easier to
> capture, and then submit, consistent data.
Let's think this from the end. What would we like to know?
> I guess the professional you are has done statistics about the FG users
> world, thus you are able to be more precise about those unfortunate users
> who are getting only "the single frame per second", which hardware? which
> operating systems ?
Strangely enough I have (you might have noticed by
> Referring to my poor experience with these two computers , i conclude , i
> can accept a decrease of performance, without loosing any FG facility.
> I'll be far from "the single frame per second" your are talking about.
First of all, there are people who get a single frame per second with Rembra
> - ALS now works much better with the random trees. I think
> there's still work to be done with other shaders (presumably
> the wake shader has still to be ported?)
Yes (if that is really a major holdup, I can probably do this within the next
weeks if it makes Vivian smile :-) ...).
A more
> Pushing in front your supposed to be know how is not an argument ,
> usually the more person' s know how is great the less they are
> pretending to have it.
> Please stop to pretend to be the best.
So you mean to say that actually having written all the ALS code has not in any
way given me
> 3/ To wait for better development reaching the target to have REMBRANDT
> and
> ALS working well all together, and definitively included within FG.
(...)
> The basic content remains the same, some Aircrafts are flying with
> Rembrandt not with ALS , others are flying with ALS not with Rembrandt
> A nice list and it's all worthwhile improvement, but it's all tinkering
> around the edges of existing stuff. There's no step change which would
> justify 3.0 IMO. For that we need something major, like new terrain
> (850) or Rembrandt as the default.
*shrugs*
This would depend on if you're
> What version number will we give to the new
> release? Are we ready for a 3.0 or is it 2.12?
Looking through my list of goals for the last coding period:
> * Get a high-quality model shader running under Atmospheric Light Scattering
This is now available, working for random buildings and for s
> It could help you to understand why you are getting that poor
> performances
> with your pretty fast beast GTX 670M.
Thanks, though I remain mystified.
There are few differences I can spot:
* you have tree density to 0.7 in the shots, I had it at 2.4 - since there's
lots of trees in the s
> Which screen size ?
> With my old GPU Geforce 9600 GT at 1024x800 i never got less than 24 fps
> (usually 30 fps). It is when using FG 2.10.
> Decreasing on the fly the screen size increase the fps.
Yeah, well, fragment shader load (and hence deferred rendering) scales with the
number of pixels
I've had a my first short go with Rembrandt on my new machine yesterday. The
test case was a small airport in Sulawesi (Indonesia) (WAAJ) where I'm
discovering a very nice scenery. There are no static or shared models to speak
of, there is some forest around, and that's basically it. I chose fa
> The primary increase seems to be in Textures.high/Terrain. In 2.10.0,
> the size of the folder was 181 MB, while in the current git version, the
> size of the folder is 300 MB.
If no one has any problems with the autumn texture versions in any rendering
scheme (i.e. nobody sees a semi-transpare
After a fresh pull and recompile today (I've not had much time for FG the last
weeks...) I've noticed that the hires runway effect of ALS appears to have been
partially broken by something - I now see a checkerboard pattern when I look at
runways and taxiways which hasn't been there before. Is
> By any chance, is this a bug when using atmospheric light scattering?
Yes.
The issue you see is that real terrain is drawn out to some draw distance set
by visibility and LOD range, and beyond what appears as fogged terrain is drawn
by the skydome code. And the sun is set to be always visibl
Hi Stuart,
sorry for the silence from my side, I haven't been able to start FG up for the
last week or so, I am a bit swamped in work and family issues at the moment...
> I'm slightly surprised that Thorsten's
> new system doesn't
> support this, as evidenced from his screenshots.
glxinfo clai
I finally got around to fly a few air-air refueling exercises with the revised
system with configurable refueling envelope. I have tested the F-16 using a 3 m
envelope and the F-14b using a 10 m envelope (I figured the hose allows a bit
more flexibility than the boom - I'm not completely sure a
The package of tree photographs is here
http://users.jyu.fi/~trenk/files/trees.tgz
I will leave this online for about a week for grab. Let me know if photographs
taken that way are useful or not, I am just trying out things.
* Thorsten
---
I have a series of tree photographs if anyone is interested in creating new
tree textures.
The images are 1200x1600 JPEG, taken on an overcast day in diffuse light,
outlining the trees against the bright sky, isolated as good as possible
against the background. I've experimented with different
>>The downside is that I think it would require adding
>> an if()
>> test to the vertex shader, something I've been avoiding due to
>> (unfounded?)
>> concerns about performance.
> General advice that I can find is that GLSL is designed as a linear
> program:
> conditionals and loops are best
> * Canvas instances can now be placed on scenery objects. This allows
> for example creating animated signs/monitors. I've started to create
> a Visual Docking Guidance System, which is not fully functionally yet
> but should be complete enough to be used for a screenshot (eg. azimuth
> gu
I thought it'd be a nice idea to present one or two articles on the FG project
page about things to expect from the next release (3.0?). These would be
features which have appeared on GIT since 2.10 or are epected to appear before
the release. Consider the articles as advertisement material, so
> That's not quite right: you should be able to use one _effect_ across all
> rendering schemes, but under the hood different flavours of shaders do the
> work.
(...)
>We have recently broken that principle with the grain effect - it only works
>in ALS.
Oh, so Rembrandt-declared lights do work pr
> Sorry it is not ALS Compliant.
I think we covered that one early on in the discussion last week. Quoting
myself:
> You'll have noticed that the ALS ubershader (short of inserting the tangent,
> normal and binormal attribute for normal maps which I understand really
> _must_ be airplane-side
>> There was so many wrong remarks , that i forgot that one:
>> I am quoting you
>> "Only Rembrandt requires separate Rembrandt and no Rembrandt versions of
>> aircraft. Are you unable or unwilling to acknowledge that point?"
> Aren't you talking about stuff you don't know?
>
> An aircraft which h
>>> How could you say "you're both not even users of the scheme" ?
(...)
>which would appear to the English-speaking reader indicating that you
>> don't use it.
(...)
> Yes there not any contradiction ,since i said, quoting myself:
> "To me the project was promising , until you engage to develop
> If this is the cause, it's been that way since January, and I assume you
> would have compiled from source since then.
I still have the funny GPU problem under Linux that the GPU refuses to go to
high performance, so I don't actually develop shader code under Linux but use
it just to interf
> However, one reason I didn't spend more time on it was that it didn't
> seem particularly useful from a sim perspective. If found that to see
> the effect at reason (<30kt) winds you either need to be sitting on
> the ground or at quite low altitude when your attention is elsewhere.
I think yo
With the recent FG, both Linux self-compiled and Jenkins for Windows, I no
longer get compilation errors from the shaders thrown to the console - badly
formed shaders just don't work without complaining. This makes developing a
bit awkward now and will make it close to impossible to trace pr
Vivian:
> I don't want to download fgdata/fg/sg to find that I have to spend
> hours fixing up my work. I'd rather get on with my own stuff.
Your actions don't match your words. You're the remaining maintainer of the
water effect in default. Its environment interface still doesn't support
Adva
> If something exists and works in the default scheme, but is missing or does
> not work in a child scheme then that child scheme is broken or we might say
> that there is a regression.
Which all would be relevant if it would be a child scheme - which it isn't.
>The solution was obvious - combine
> That said - I don't see why an Atmospheric
> Light Scattering scheme should have embedded in it some ac modelling
> stuff.
> That serves to diverge the schemes. And it makes it look like ALS is your
> private sandbox.
Offering new and different options is the whole point of having a different
I've thought about if I really should comment on Henri or not, and I won't
dignify most with a reply, but just this:
> I don't mean i don't like ALS, i mean i don't like your approach ,
> instead of working on consistency with the existing valuable features which
> were
> implemented within F
> I don't think it's quite that bad. In a deferred shader like Rembrandt,
> the ALS would run in the deferred lighting pass. While it's true that the
> heavy work is done in a fragment shader, it only runs for each pixel on
> the screen, not for every rendered fragment.
Yes - but you need to ex
> I've also taken a bit of a look at merging Rembrandt and ALS, and I think
> I understand the Rembrandt pipeline enough that I could add ALS to it.
Just to provide some expectation management:
Rembrandt (as deferred rendering) is very heavy on the fragment shader. ALS at
low quality is currentl
Hi Stuart,
this tree movement code is wonderful - how could you possibly not implement
this?
I've been looking out of the window, timing the movement of trees in our
forest, and I think the time constant should rather be 1.7-2.0 and the
amplitude about 2.5 times as large - all of which make
Hi Vivian,
> ALS is very impressive work, but things broken? Have you forgotten the
> flag shader (now fixed), wake effect and rainbow effect? I don't have a
> particular problem with these and hope that they will be fixed
> eventually, although I note that do you seem to have raced on to oth
> ..yes, but we also need some patience with non-native English
> writers who _should_ include their French etc original so we
> don't get people wound up on questionable translations of things
> that may warrant discussion
For the record, there is a repeating pattern here on and off list and I d
Hi Henri,
> However your approach is questionable.
> I can understand you are working on an other FlightGear "variant" for
> yourself.
(...)
> It is not the Atmospheric Light Scattering, we want.
Who is the 'we' you're claiming to represent? I look at the FGUK weekly flight
screenshots in the
It occurred to me yesterday that there seems to be a major misunderstanding in
the way Atmospheric Light Scattering (ALS) is perceived by different people. So
in order to avoid future misunderstandings, let me try to clarify my side once
again.
Vivian:
> Do we need to go down this road? We ar
> Actually, I had this working very nicely a couple of months ago - using
> a sine function on time multiplied by wind factor to shift the top
> texture coordinates so the top of the trees move. I even had a nice
> larger scale effect to produce the sort of wave affect you see across
> the
> Definitely looks like it. Could you provide some further details on
> this please:
> a) Where are you seeing this ?
> b) which materials file (dds ? regions? )
> c) Have you deleted the Textures.high file to use lower resolution
> textures? The
> trees in the screenshot look even more blocky t
> Removing the rainbow effect spoils the highly polished aluminium effect on
> the b29 and the Lightning F1.
As I said, I don't plan to remove it for good. Quoting myself:
" in any case a 2d texture lookup call seems an overkill for a simple 1d
color table, so I plan to replace that by a func
Okay, I've pushed an experimental version of a grain overlay texture for the
model ubershader to FGData. It affects Atmospheric Light Scattering only, i.e.
will be absent in the default rendering, which should make for easy comparison.
For lack of texture units, I had to take the rainbow color
> Ive been thinking about this since since you posted, and now i'm curious
> to see it.My initial fear was more framerate drop, but if it can be truly
> disabled I think its worth a try
I think one thing we have pretty consistently implemented in the effect
framework is that all effects can be
> I was wondering if there is a future plan in uniting these two amazing
> attributes of FG...
My development plan as outlined for the period between 2.10 and 3.0
(hopefully...)
http://wiki.flightgear.org/User:Thorsten
is still valid:
"After thinking about this for a while, I have decided tha
> No ,Advanced weather forced 3d clouds on me even when i disable 3d clouds
> so i don't use it.
> Of course i could be doing something wrong , but Im not quite convinced
> yet to get a new computer.
> Looks like I'll have to pretty soon ;)
Interesting, I thought the 3d cloud checkbox was a shad
> I'd say no , its easy enough to do without yet another shader, since each
> new shader 'improvement" has me tweaking my aircraft
> to get back the frame rates I lost.But thanks for offering.
Well, according to GLSL specifications and my experiments, texture lookups
cannot be made conditional on
I have a question to aircraft/cockpit modellers: Would a shader effect with the
equivalent of a grain texture be useful to you?
For the terrain, the grain texture is a semi-transparent overlay pattern of
grainy dots - which is superimposed on the normal texture at 25 times the
nominal resoluti
>>> Thorsten suggested [1] separating foilage and trunk; is this what you
>>> have in mind?
>
> At the moment I'm simply using 4 separate complete textures ; one for
> each combination of summer/winter and clear/snow-covered.
>
> So I 'just' need straight pictures from summer and winter. Snow-
I've just pushed a few major modifications to the highest quality shaders of
Atmospheric Light Scattering - the lower quality levels are at present
unaltered. Please give some feedback so that I can decide what to do with the
lower levels.
* I've converted fog and snow overlay from tile-coordi
> If you just want a quick and dirty way to read one property, we have
> getprop / setprop - for any other use, you should be doing what the API
> already supported; getting a props.Node object for the leaf, and then
> manipulating it with no further string/path handling.
> Using getprop on
@Erik:
> They are read from the ambient, diffuse and specular files in
> fgdata/Lighting. For the default lighting scheme these do get altered,
> but I think you already override that scheme completely.
Um... as they depend on the sun angle, these appear to be the light intensity
curves. I indee
Following a forum discussion
http://www.flightgear.org/forums/viewtopic.php?f=47&t=19693
I've done some experiments with terrain self-shading based on changing the
balance between ambient and diffuse light.
The results look fairly compelling and the illusion (even without a real
shadow-map)
> Presumably making cirrus clouds after more sprites doesn't make for
> very realistic clouds because of the size of the cloud structures?
Well, they are very faint - say an alpha of 0.1 or less. If we make 10 sprites,
each of them needs an alpha of 0.01 in order to get the same visual impression
I want to bring a potential issue of the cloud detail range system to
everyone's attention.
What it does it reducing sprite count by dropping sprites in the back half of
the cloud if the cloud is more than a configurable distance away, so faraway
clouds have less overall density.
This works g
Thanks Fred, this pretty much addresses all my questions.
> Light objects are built in simgear/scene/tgdb/pt_lights.cxx
> There effect is built in C++ in the getLightEffect function. It is not
> configurable as it is now. Ideally, this function should be replaced
> by a lookup in the material file
> I suspect they are just using the default terrain effect, if anything.
> They are generated from the C-code when the tile it loaded (IIRC
> simgear/scene/tgdb/obj.cxx though I'm not at my FG computer to check)
>
> If you want any changes I'd be happy to make them, though I'd expect
> it's the s
If I may bother everyone again - here's my current list of open questions. Any
help or pointers would be appreciated:
* Where do the runway and taxiway lights enter the rendering scheme? They need
to be fogged consistently with the rest of the scene, but I do not know where
to set this - whic
In addition to what Heiko said, Nasal script loops can be used to print any
properties or functions of properties under any set of pre-defined conditions
with adjustible sampling interval on-screen. If you re-direct console output to
a file, you also get something that is plottable with minimum
>>> After all,
>>> head tracking is one of the most important aspect of flight sim.
>> It's fine that people are interested in something, but could we please
>> tone down the rhetorics and refrain from arguments 'I am interested in X,
>> hence it must be one of the most important aspects of f
> After all,
> head tracking is one of the most important aspect of flight sim.
It's fine that people are interested in something, but could we please tone
down the rhetorics and refrain from arguments 'I am interested in X, hence it
must be one of the most important aspects of flight simulation
Hi Tom,
sorry if I sound overly pessimistic, but... several of the potential issues are
structurally not that different from problems I've encountered in painting
terrain or setting up credible weather. it doesn't mean that I am in any way
against your plan, but I want to see if you have any n
> I've been playing with populating my home airport's area with buildings
> derived from OSM floorplan data. I think having many buildings in the
> correct place greatly improves realism over the current random
> buildings/sparse static models, especially when you know the area.
This become
> Often airports are in or
> near very scenery-intensive areas and reducing visibility can help a lot
> in making the sim run usably for take-off, whereas once you're up and
> away it's nice to be able to open the view back up again for
> cross-country flying.
This is applying a sledgehamm
> *Please* don't drop the z/Z key binding. This is one of the most
> useful and direct controls we have to affect the visual experience.
(...)
> It's fecking difficult to operate a mouse/menu/slider while using a
> joystick
> unless you are ambidextrous
> (which I'm not)
Can anyone please explai
> I need someone to reset my brain on this, explain to me what
> functionality is required, show me the Nasal code and Vivian's version,
> and so on.
Rain layers and Cirrus clouds are not shader-generated 3d stacks of sprites
like the 3d clouds but normal, Nasal-spawned models.
3d clouds ar
> This feels like a moderately large issue to me, because out of the box,
> we select basic weather, and hence we're going to get bug reports about
> clouds not appearing. We could make basic weather drive the real
> visibility based on altitude, but then we're moving away from 'basic
> wea
>> > Did you test your airfield grass with some of the newer generated
>> terrain
>> > (LOWI in my case)?
>>
>> No, I didn't. Shouldn't make a difference for rendering purposes how you
>> created it, at this stage it's all vertices and pixels and the shaders
>> don't care where they come from or
Hi Vivian,
> That's really good to hear - but if we are falling behind in some
> respect
> then we will make an effort to improve. I am reminded that the flag and
> wake shaders are inoperative when Atmospheric Light Scattering is activated.
> With the departure of Emilian, I see no prospe
I've pushed some updates to Advanced Weather and the cloud shader of
Atmospheric Light Scattering.
Clouds now fade to transparent at distances between the visibility and 3 times
the visibility. This gives a much better impression when in heavy groud fog
(CAT I to CAT III) and shouldn't be a pr
> So whatever we do, we can't override the ability to get low level
> granular
> control of the weather parameters, and not just so that advanced weather
> can manipulate them exclusively, also so that external tools can
> manipulate
> them without advanced weather getting in the way or overrid
> You asked for ideas for a more descriptive text - I've gone one better
> and
> added descriptive texts to the gui. My design aim was to provide the
> average
> user with some indication of which option he should choose and in which
> circumstance. It's only a shallow redesign. It would be nic
> Renk, you should take a look at the default Cessna 172 in FG and it's
> mate in FSX. The FSX version wipes the floor with the FG version with respect
> to the cockpit model.
(I'd really appreciate if you guys would call me on first-name basis
'Thorsten'...)
That's a question of what a fair
> Thorsten, work is halted as my co-ordinates must be wrong, can you tell
> me the dimensions I need to use?
Bruce, I'm not sure I understand your question - the coordinates in the
conditional used to define a region are latitude and longitude in degrees (but
I guess you know that, so probabl
> A small addition: what has always bothered me about terrain in FG is that
> roads and rivers are all the same size.
Good point. That wasn't really apparent from the FSX demo (not so many roads of
different size in the Caribbean).
I think rivers are less of an issue in CORINE based custom scene
Following a forum discussion, I finally became curious and tested the FSX demo
version yesterday. I've spent about two hours flight with it, testing 3
different planes (the ultralight, the Baron and the Learjet) and had a look at
different weather conditions and daytimes around TNCM.
The insta
> I've just committed some small changes to the AI air-to-air refueling
> function:
Had a short look yesterday - nice! I like the option to customize the envelope.
Does anyone know what realistic numbers are - I guess the boom can be moved
somewhat, so there must be a tolerance of few meters (
1 - 100 of 415 matches
Mail list logo
