Board index FlightGear Development Effects and shaders

A long shot

An exciting "new" option in FlightGear, that includes reflections, lightmaps, the particle system etc.. A lot is yet to be discovered/implemented!

Re: A long shot

Postby adrian » Wed Mar 26, 2014 5:53 am

Hooray wrote in Tue Mar 25, 2014 9:20 am:it still is amazing how many features they have that are overlapping with stuff we have and vice versa - some things we're missing (but are working on) they have already:


They do better in the visual department (we would too if we had a team of dedicated people to optimize Fred's Rembrandt), but they're not so far ahead in core features. I think we have a couple very unique stuff. And we could have even more, if the powers that be didn't put a very high barrier for entry.
adrian
 
Posts: 362
Joined: Wed Sep 15, 2010 3:15 pm

Re: A long shot

Postby Thorsten » Wed Mar 26, 2014 10:31 am

we would too if we had a team of dedicated people to optimize Fred's Rembrandt


Out of curiosity - why? My understanding is that deferred rendering gives you advantages in visuals mainly for the shadow map and for secondary lights. These have an impact on visuals, but in very specific situations.

One of my rationals for not using Rembrandt is that I don't want to spend my framerate for the shadow map and secondary lights but for things I consider having more visual impact (terrain roughness and de-tiling, correct lighting balance, credible haze layers,...) At the end of the day you can burn performance only once - and what good is it to me to have a shadow map and secondary lights in addition to terrain roughness and de-tiling if I end up with 5 fps on a high-end system?
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: A long shot

Postby Bjoern » Wed Mar 26, 2014 6:54 pm

adrian wrote in Wed Mar 26, 2014 5:53 am:but they're not so far ahead in core features.


Flight sim core features or visual core features?

(If flightsim: ATC...and I'm not talking about the multiplayer kind of ATC.)
Bjoern
 
Posts: 484
Joined: Fri Jan 06, 2012 11:00 pm
Location: TXL (RIP)
Version: Next
OS: ArchLinux

Re: A long shot

Postby Hooray » Wed Mar 26, 2014 8:16 pm

adrian wrote in Wed Mar 26, 2014 5:53 am:They do better in the visual department (we would too if we had a team of dedicated people to optimize Fred's Rembrandt), but they're not so far ahead in core features. I think we have a couple very unique stuff. And we could have even more, if the powers that be didn't put a very high barrier for entry.


Actually, a couple of weeks ago we started "reverse-engineering" Rembrandt to better understand what's having such a massive impact on performance there , because its internals are not very well documented unfortunately. And "barrier to entry" is two-folded obviously - because some "obscure" features are inevitably also pretty complex to come up with in the first place.
Rembrandt itself is already much better documented than most existing FG features, FredB did a great job there - it stalling is certainly because of the lack of "internals" knowledge, i.e. the camera/renderer/rendering stages side of things.

The original "Understanding Rembrandt" effort got kinda stalled in the meantime admittedly. But based on working through the commits, as well as Fred's and Mathias' comments on the devel list, I do believe that Zan's "newcameras" work could (and probably) should be revived and generalized for this - that would expose all building blocks required for "deferred rendering", which would mean that those would not just be available to Rembrandt itself, but also to other effects/shaders, such as Thorsten's work (ALS et al).

But to be honest, I think if Thorsten were to decide that he wanted to take some time off from FG, we would also be facing a similar "technology lock-in", because most of his work also isn't really understood/maintained by others. So what we're dealing with here is not so much a "barrier to entry" per se, but instead the bus factor.

We've seen some extremeley skilled contributors making sizable contributions without them ever documenting the internals, so that getting up to scratch with things later on may be next to impossible without spending a huge amount of time, that could be equally spent on re-designing certain features/systems.

This is something that we have actively worked to address in the context of Nasal/Canvas and efforts like the ND/MapStructure frameworks, i.e. those are now extensively documented, not just including "roadmaps" and "milestones", but also internal design stuff, including even step-by-step tutorials and coding examples - admittedly, this has taken up quite a bit of spare time, that could have just as well been spent "coding" - but given the wiki stats, we seem to be on the right track here, i.e. most of these articles have seen between 2k-8k views within just ~10-12 weeks, which is kinda impressive (some of our most popular articles "only" have seen 40k views in years!), but this also ensures at the same time that even if some of us were to disappear for a few months, people would still be able to pick up where we (TheTom, Philosopher, Gijs, me) left off, no matter if this means "maintaining" our existing code - or modernizing/replacing it completely.

In professional software development circles, writing documentation is a necessary evil, as is writing unit tests - in FlightGear, people prefer to spend their time doing "fun" stuff instead for understandable reasons. Then again, some of the main building blocks and key technologies in FlightGear were developed by people who obviously understood that having sufficient docs is at least as important for a feature to survive than the actual code, just look at architectural pillars contributed by people like David Megginson or Andy Ross - those are typically the same guys who were responsible for much of the original documentation targeted at core developers, no matter if it's through extensive use of doxygen comments or through dedicated design articles.

So the issue really is twofold, assuming that we are talking here about novel features like the radio propagation code, I fully agree that this would be great to have in FG as an option - but at the same time, I am wondering how much of its design is actually documented for fellow/future developers ? :D

Seriously, documenting and mentoring seems to scale particularly well around here, just look at the plethora of features conceived/implemented within the last 18-24 months, and all the stuff that people are currently working on, or look at the number of views that the TerraGear/WorldScenery 3.0 article has seen in just a few weeks (~250).

Some of our most active contributors spent little to no time ensuring that future developers will be able to continue their work - and that's a problem that will only really become obvious once someone is too busy with other aspects of their life to contribute (or even just back to answer questions).

Now, regarding Rembrandt in particular, we are only missing 2-3 Canvas enhancements to allow effects/shader guys to pick up where FredB left off - which are primarily, 1) camera support, 2) effects/shader support, and people have this working in various stages already, sometimes unrelated to Canvas (Zan's newcameras branch), and sometimes not yet fully integrated (e.g. the shader stuff). But generally it is foreseeable that additional rendering schemes (deferred rendering) could then be implemented by people without having to touch any C++ code.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: A long shot

Postby adrian » Wed Mar 26, 2014 10:11 pm

Hooray wrote in Wed Mar 26, 2014 8:16 pm:In professional software development circles, writing documentation is a necessary evil, as is writing unit tests - in FlightGear, people prefer to spend their time doing "fun" stuff instead for understandable reasons.


You must be living in an alternate world :) From all the pieces of code I've had to spend time on, Flightgear is by far the best documented, beating all "professional" stuff by a mile.

Hooray wrote in Wed Mar 26, 2014 8:16 pm:So the issue really is twofold, assuming that we are talking here about novel features like the radio propagation code, I fully agree that this would be great to have in FG as an option - but at the same time, I am wondering how much of its design is actually documented for fellow/future developers ? :D

That was novel two years ago, X-Plane is going to have it pretty soon, and anyway it's going to be superseded by the new code Torsten will write. As far as documentation goes, it's got a pretty complete wiki page and minidocs, but it will remain just a small fork and a proof of concept for my main engine which runs on simgear too.

But my point was that we could have great visuals if we had a dedicated team like a pro simulator, which could piece together Rembrandt and Thosten's shaders. Unfortunately, Flightgear remains a very small niche project in flightsim world.
adrian
 
Posts: 362
Joined: Wed Sep 15, 2010 3:15 pm

Re: A long shot

Postby Thorsten » Thu Mar 27, 2014 10:20 am

But my point was that we could have great visuals if we had a dedicated team like a pro simulator, which could piece together Rembrandt and Thosten's shaders.

(...)
But to be honest, I think if Thorsten were to decide that he wanted to take some time off from FG, we would also be facing a similar "technology lock-in", because most of his work also isn't really understood/maintained by others


I dunno - I've been learning pretty much all GLSL I know by reverse-engineering shaders other people wrote - none of which had any understandable documentation. Well - now, after I've had to write so many effect files, I slowly start to understand the words in the effect file documentation which tells you that it's less accessible than reverse-engineering the existing stuff. I wrote my first cloud shaders for Nasal-spawned models based on the math in Stuart's clouds, whenever I have ported an effect from default or Rembrandt to ALS, like the Ocean depth effect recently, I just read through the code how it's done and then port the parts which are interesting. Initially I didn't know any GLSL, so it was a week to go through a shader and port it, now I understand much better how things work and it's down to maybe a day (writing a working point sprite shader as soon as the lights were exposed was a matter of 2 hours or so).

So, maybe I'm the only guy in town who can do that, maybe not. But the point is - I do understand what the shaders outside ALS do, and I could fix them and/or develop them further if needed. And, given a few weeks to iron out the details, I could also make ALS work under Rembrandt.

The actual reason why this isn't happening is twofold:

First, as I said, you can spend performance only once. For my default settings of random vegetation and buildings and clouds, I'm getting 15 fps out of Rembrandt as it is once I want nice shadows (i.e. apply sufficient filtering that I don't get a headache watching them) vs. 60 fps in ALS at highest quality settings. ALS would require to squeeze another 1000 lines of code into the fragment shader, i.e. make it perhaps 5 times longer than it it (on average). That's on a modern gaming laptop. So who's expected to be able to run Rembrandt + ALS with anything above 5 fps? I don't see it on my machine. And of course, assume I do it - guess at whose feet complaints about low framerate end up? Guess who gets told by every amateur GLSL coder that he's stupid because 'there must be a faster way'?

Second, there seems to be something religious about Rembrandt. I've always gotten help and good advice from FredB for whatever I was trying to do, but there's a very outspoken and agressive community of Rembrandt-users which pass no opportunity to tell me that what I do is crap, rubbish and that Rembrandt is the best and I should better quit what I'm doing because it's so inferior. Maybe so - but I sure won't lift a finger for anything these people want to see done. If anyone wants ALS under Rembrandt, insulting me is a sure way to not get it done.

Personally, I see the potential of deferred rendering, but if it ends up with 15 fps on a gaming rig, then that's what it's going to remain - potential waiting for the next or next-to-next hardware generation. For me personally, real secondary light sources and shadows aren't a big deal. They're important on the ground, at an airport, but I'm usually flying.

Self-shadowing of the terrain can be done in 90% of the cases accurately without Rembrandt because the terrain is rarely that steeply sloped, and the interesting other shadows in nature - clouds and trees - can't be done by Rembrandt in any case.

I think what we really need for better visuals are some graphic artists which help with terrain texturing. Access to more diverse textures, people who blend them better. We don't lack effects, FG looks quite spectacular where we have CORINE terrain to work with and do regional texture definitions and procedural texturing. It just looks less good where we have no terrain resolution and use default materials. At some point, you can improve the tools as much as you want, but it becomes a question of the artwork, and the best brush and the best color palette in the world won't result in a Mona Lisa if the painter isn't a da Vinci.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: A long shot

Postby Hooray » Thu Mar 27, 2014 11:00 am

but I sure won't lift a finger for anything these people want to see done. If anyone wants ALS under Rembrandt, insulting me is a sure way to not get it done.

right, I think this particular problem is mostly due to some of our users being extremely constructive, such as the Russian/French parts of our community, they seem to work together to a much larger degree than is common for most of us - and it seems some of them are also fairly young, so time is on their side, and attitude may be a problem once in a while.

Personally, I see the potential of deferred rendering, but if it ends up with 15 fps on a gaming rig, then that's what it's going to remain - potential waiting for the next or next-to-next hardware generation. For me personally, real secondary light sources and shadows aren't a big deal. They're important on the ground, at an airport, but I'm usually flying.

Not disagreeing, but Rembrandt is just one particular (and experimental) implementation of deferred rendering implemented via FlightGear - when running other simulators/games -with comparable scenes (not necessarily 400km of visibility!)- you'll see that performance isn't typically that much affected. So I guess there's nothing wrong about Rembrandt per se, but it just isn't very optimized at the moment, and it not being maintained doesn't really help. A few weeks ago when we exchanged screen shots and Rembrandt stats, there were apparently a few low-hanging fruits, and Rembrandt was obviously doing stuff that wasn't really necessary (e.g. computing shadows at night time without any light sources within 50km...)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: A long shot

Postby Thorsten » Thu Mar 27, 2014 12:19 pm

The situations I'm aware of were deferred rendering is used are frequently first person shooters. From the ground, where you have plenty of objects obscuring each other, deferred rendering would give you a pronounced boost in framerate as you spend minimal time with vertices you're not going to see. That advantage never really materializes for a flightsim.

Imo, what makes our performance in comparison worse than other software where a large scene is rendered is the lack of a terrain LOD system. Our vertex count just explodes at high visibility.

I mean, FredB obviously spent quite some time with Rembrandt, and he isn't really stupid (far from it in fact). If someone can make it run much faster, than that'd change the game, but so far we have mostly talk.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: A long shot

Postby Bjoern » Thu Mar 27, 2014 3:09 pm

Thorsten wrote in Thu Mar 27, 2014 12:19 pm:Imo, what makes our performance in comparison worse than other software where a large scene is rendered is the lack of a terrain LOD system. Our vertex count just explodes at high visibility.


+1
Bjoern
 
Posts: 484
Joined: Fri Jan 06, 2012 11:00 pm
Location: TXL (RIP)
Version: Next
OS: ArchLinux

Re: A long shot

Postby f-ojac » Sat Apr 05, 2014 10:51 am

Shots taken yesterday IRL when descending to LFRB :
Image
Image
Image
GPLed pictures of course, feel free to use.
f-ojac
 
Posts: 1304
Joined: Fri Mar 07, 2008 10:50 am
Version: GIT
OS: GNU/Linux

Re: A long shot

Postby wlbragg » Fri Apr 11, 2014 12:57 am

think what we really need for better visuals are some graphic artists which help with terrain texturing. Access to more diverse textures, people who blend them better.


That would do more for visuals, with no additional costs, than just about anything else we could do imo,
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7588
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Previous

Return to Effects and shaders

Who is online

Users browsing this forum: No registered users and 6 guests