Board index FlightGear Support Graphics

What frame rate (fps) do you have?

Graphics issues like: bad framerates, weird colors, OpenGL errors etc. Bad graphics ar usually the result of bad graphics cards or drivers.
Forum rules
In order to help you, we need to know a lot of information. Make sure to include answers to at least the following questions in your initial post.

- what OS (Windows Xp/Vista, Mac etc.) are you running?
- what FlightGear version do you use?
- what graphics card do you have?
- does the problem occur with any aircraft, at any airport?
- is there any output printed to the console (black window)?
- copy&paste your commandline (tick the "Show commandline box on the last page of FGRun or the "Others" section on the Mac launcher).
- please upload a screenshot of the problem.

If you experience FlightGear crashes, please report a bug using the issue tracker (can be also used for feature requests).
To run FlightGear on old computers with bad OpenGL support, please take a look at this wiki article. If you are seeing corrupted/broken textures, please see this article.

Note: If you did not get a reponse, even after 7 days, you may want to check out the FlightGear mailing lists to ask your question there.

What frame rate (fps) do you have?

Postby punkepanda » Fri Nov 15, 2013 3:40 am

Hi,
I just got me a fresh new AMD Radeon R9 270 GPU. I did buy this mostly to get better frame rates at FlightGear. I just love this project (so far... :roll: )

FlightGear was not my first game to test my new card on, but it has really good specs and run most of my games smoothly with max on video setting for most new games.

Then when it was FG´s turn for a test I could not believe my eyes. The FPS counter was between 5-8 at KSFO :shock:
That was absolutely NO fps increase from my old Radeon HD 5570 card witch is now about 4 years old. Ok, maybe 1-2 fps count higher. But the graphic cards itself is about 5 times faster at benchmarks.

What is the problem here? Does not FG use any of the GPU hardware to render the scenes? This must be my first really FG depression :lol:

Everybody have low framerates? I read someplace that somebody has 50-60 fps.. These guys have some kinda super computers or?
punkepanda
 
Posts: 237
Joined: Mon Nov 04, 2013 9:11 pm
Callsign: LostFlight
Version: 2.12
OS: Arch Linux

Re: What frame rate (fps) do you have?

Postby Hooray » Fri Nov 15, 2013 4:05 am

According to your profile you are on Linux (please always mention these details, we cannot read your mind, and we don't like asking redundant questions, because that's wasting time, that we could better use to help other folks who provide the required info in the first place (no offense!)), anyways: make sure that you are able to run other OpenGL software first, to ensure that your drivers are installed properly - check glxinfo, post its output here if you cannot make sense of it. And then please also use the help/about dialog in FG, which shows GPU related info.

Image
http://www.tomshardware.com/reviews/rad ... ,3669.html

I usually do have in excess of 60 fps here, and my card is several years older and less powerful according to TomsHardware.com- so it's probably your system setup/config in one way or another, but we cannot help you without you providing all useful info ... :D
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: 11354
Joined: Tue Mar 25, 2008 8:40 am

Re: What frame rate (fps) do you have?

Postby punkepanda » Fri Nov 15, 2013 5:45 am

Sorry about the lack of detailed info:

Actually I am on windows 7 at the moment to test if I got better performance. It seems to be the same fps on both platforms.
I forgot to mention that i have Rembrandt enabled, but still that is too slow for a good game experience!

It is the 2.99 version, but i had the same fps on 2.12.

Image

gl-vendor:ATI Technologies Inc.
gl-version:4.3.12614 Compatibility Profile Context 13.250.18.0
gl-renderer:AMD Radeon R9 200 Series
gl-shading-language-version:4.30


The driver loads as it should, i guess. Because any other OpenGL software runs just nice.

I also run it with --prop:/sim/rendering/shader-effects=false (if not buildings and stuff get some strange colors)
punkepanda
 
Posts: 237
Joined: Mon Nov 04, 2013 9:11 pm
Callsign: LostFlight
Version: 2.12
OS: Arch Linux

Re: What frame rate (fps) do you have?

Postby Thorsten » Fri Nov 15, 2013 6:33 am

What is the problem here?


Probably not the card... How fast is it without Rembrandt?

Rembrandt seems to have funny performance requirements and I think the bottleneck of it might be outside of the GPU. I'm getting 15 fps with all Rembrandt features on somewhere in the wilderness on a gaming laptop with a GeForce 670M - which runs FG with all the eye candy imaginable outside Rembrandt with 30-60 fps just fine. That's not grossly inconsistent with what you're seeing - I have never tried KSFO with Rembrandt on, but it might well end up around 8 fps.
Thorsten
 
Posts: 11136
Joined: Mon Nov 02, 2009 8:33 am

Re: What frame rate (fps) do you have?

Postby punkepanda » Fri Nov 15, 2013 8:23 am

I did try to run FG without Rembrandt. And as you say Thorsten, the FPS is now between 40-60 at and around KSFO. The main issue was Rembrandt then.
To bad because Rembrandt really make the simulator much more realistic when you can see the sunlight in the cockpit and all the shadows.

So if Rembrandt does not put the load on the GPU, will it help to buy the latest CPU on the market then? Since I prefer to run the simulator with Rembrandt it is good know what hardware not necessary to upgrade as this could have saved me about $350. Since my fps was not significant increasing with the latest graphic cards on the market.

Is Rembrandt under further development at the moment or is it as good as it can be? Do we need to find other framework to implement?
How does the future looks? Will it be any speed increase for the 3.0 release perhaps?

What hardware should we buy to have the frame rate in the range of 30-60 at detailed airports with Rembrandt enabled.. If possible?
punkepanda
 
Posts: 237
Joined: Mon Nov 04, 2013 9:11 pm
Callsign: LostFlight
Version: 2.12
OS: Arch Linux

Re: What frame rate (fps) do you have?

Postby Hooray » Fri Nov 15, 2013 1:01 pm

Right, you should have also mentioned that you are using rembrandt, I completely missed that ...

I don't think Remrandt is currently being actively developed/maintained, at least based on looking at the commit logs, it seems obvious that FredB is busy with RL, and other shader developers like i4dnf also don't seem to be very active these days - it's a pity, but Rembrandt will surely need some more time and work put into it. I don't think that it will be realistic to enable it by default in 3.0, something which some core developers discussed 1-2 years ago, obviously without foreseeing development stalling.

Technically, it is definitely possible to determine the "slow" parts, we have various built-in profiling options now - but to be honest, the rendering parts in the FG core that Rembrandt touches have only really been ever touched by 3-4 core developers, and at the moment only one of them is active in FG development, but doing mostly HLA development - so I wouldn't hold my breath.

So, it will take quite some time (and lots of expertise) for Rembrandt to get ready for prime-time, which isn't such a bad thing actually - because most average hardware these days cannot realistically handle deferred rendering, enabling Rembrandt by default in 3.0 would have meant that possibly 60-70% of our current user base would no longer be able to run FG.

Overall, FredB did a tremendous job at documenting Rembrandt for end-users and aircraft developers, but documentation for core developers interested in Rembrandt is severely lacking at the moment, so that it's unlikely that it will be picked up by some random C++ developer, because you need to be extremely familiar with SG/FG and OSG internals to understand what's going on there, keep in mind that FredB has been involved in the project for over a decade already, and the other 2-3 guys who have ever touched these parts of the simulator are equally "10-year overnight successes" :D

Also, if I remember correctly, Rembrandt uses quite a few internal/hard-coded shaders that are not easily accessible to our GLSL experts (like Thorsten, i4dnf or vivian) - otherwise, it wouldn't be all that far fetched to expect Rembrandt parts to be increasingly moved to GLSL space due to ever-increasing GPU capabilities, but for the time being you need to really be a C++ expert, intimately familiar with FG internals unfortunately.

BTW, from a troubleshooting standpoint, I find this suspicious: Compatibility Profile Context, you can check if that's the case by looking at the about info in non-rembrandt mode, if it shows another string there, it's probably that Rembrandt couldn't acquire some important resource and used some fallback mode instead (just a guess tho)
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: 11354
Joined: Tue Mar 25, 2008 8:40 am

Re: What frame rate (fps) do you have?

Postby punkepanda » Mon Nov 18, 2013 3:57 pm

Thanks for a detailed answer Hoorey..

I am sad to hear that the core developers of Rembrandt has left the project. As Rembrandt (or defered rendering) really sooner or later would be a expectation in modern computer gaming. If no other light technology comes in the near future.

I can't say i fully agree with you on loosing 60-70% of the userbase by using defered rendering because alle the modern game engines below uses it.
CryEngine 3 [39]
I-Novae [40]
Unity [41]
Frostbite 2 [42]
Unreal Engine 3 [43]
Chrome Engine
MT Framework
GameStart [44]
Source (game engine)[45]

And I think that most sim'ers already know that rendering a big scenery takes some bandwith on that GPU. I think a better approch would be to implement some more advanced menu system for turning off lights and shadow effects but still use Rembrandt as default by 3.0.. As I think that developing 2 different rendering system at the same time would really slow things down as I still se alot of progress on the atmospheric scattering part which in not compatible with Rembrandt. Atmospheric Light Scattering does not even work on my AMD R9.. Everything get crazy colors and the menu get all wiped out for some reason.

Not that I am an expert on the rendering part of FG, but developing on 2 different rendering platforms is kind of waste of time when they are not compatible with each others.
Same with scenery.. I see that airport and aircraft builders still releases there planes without Rembrandt support. That I think is mostly because its not in there by default.
So flying over airports made for standard rendering dont show up as nice. Airport lightning just look awfull and fake when in rembrandt mode.

By enabling rembrandt as default we would get all the community to look in one direction. Right now the FG 3D objects database is terrible and most of it uses fake lightning on it or show up strange mess in rembrandt mode.

Go Rembrandt as default (There could still be an option to turn it off for the nintees hardware out there :lol:


BTW, from a troubleshooting standpoint, I find this suspicious: Compatibility Profile Context, you can check if that's the case by looking at the about info in non-rembrandt mode, if it shows another string there, it's probably that Rembrandt couldn't acquire some important resource and used some fallback mode instead (just a guess tho)

It is the same without Rembrandt. BUT on my laptop with GForce 630M i dont get "Compatibility Profile Contex". So you are into something here :)

Ok.. More bugs on my card.

1. Runway light shows up like squares in Rembrandt (without rembrandt it doesnt show at all) - FIXED by disabling "point sprites" in the rendering menu. But then there is no animated runway light either. This works perfects on my GForce 630m.
2. "3d clouds ON" shows no clouds at all (both Rembrandt and standard, both windows and linux)
3. In windows I get between 30-60 FPS without Rembrandt. In linux i get between 10-25 (Using newest beta driver on both platforms)
4. Precipitation shows half screen without any rainfall or snowflakes. (Probably a known bug)


Some screenshots:


U can see the runway light are square, animated lights are missing and the precipitation is half screen
Image


No 3d clouds and ugly and to big runway light.
Image

With Atmospheric Light Scattering on the 3d clouds got back. Menu text gone-crazy and probably some cloud layers and puffs go too dark.
Image



Anyway... Great project, but we should look forward implementing some of the best in rendering as default and find a standard for all to focus on when it comes to 3d objects and lights. To much strange showing up here and there. Clean up the official 3d database and flag everyting that is not Rembrandt ready as depricated.
Last edited by punkepanda on Mon Nov 18, 2013 4:19 pm, edited 1 time in total.
punkepanda
 
Posts: 237
Joined: Mon Nov 04, 2013 9:11 pm
Callsign: LostFlight
Version: 2.12
OS: Arch Linux

Re: What frame rate (fps) do you have?

Postby Hooray » Mon Nov 18, 2013 4:16 pm

One more thing.. Extend the $_SESSION timeout on the forum so people dont loose what they are writing when they are slow on hiting that submit button :wink:

Please use the sub forum titled FORUM for such requests.

punkepanda wrote in Mon Nov 18, 2013 3:57 pm:Thanks for a detailed answer Hoorey..

You are welcome, and warned: I'm only just getting started with detailed responses, especially because you still seem to misunderstand the situation at hand.

I am sad to hear that the core developers of Rembrandt has left the project. As Rembrandt (or defered rendering) really sooner or later would be a expectation in modern computer gaming. If no other light technology comes in the near future.

Most of us don't really "leave" the project, but we may have to take some time off, due to real life - which is why you see some of not being around for weeks, months or sometimes even years.
Remember, this is a 100% spare-time effort, driven by volunteers. To understand what that means and involves, please see: viewtopic.php?f=42&t=15267

I can't say i fully agree with you on loosing 60-70% of the userbase by using defered rendering because alle the modern game engines below uses it.
CryEngine 3 [39]
I-Novae [40]
Unity [41]
Frostbite 2 [42]
Unreal Engine 3 [43]
Chrome Engine
MT Framework
GameStart [44]
Source (game engine)[45]

you are missing the point - because it must be supported by hardware, and by the software - FG is cross-platform software that uses OpenGL, most of the games you mentioned use DirectX instead. Deferred rendering must be explictly developed for a flight simulator like FG - I'm not sure how FSX/X-Plane handle this, but that would definitely be interesting. But otherwise, it's unfortunately pointless if some FPS-game uses deferred shading or not - because FG has hugely different requirements and demands.


And I think that most sim'ers already know that rendering a big scenery takes some bandwith on that GPU. I think a better approch would be to implement some more advenced menu system for turning off lights and shadow effects but still use Rembrandt as default by 3.0.. As I think that developing 2 different rendering system at the same time would really slow things down as i still se alot of progress on the atmospheric scattering part which in not compatible with Rembrandt. Atmospheric Scattering does not even work on my AMD R9.. Everything gets in crasy colors and the menu gets all wiped out for some reason.

Thorsten is the ALS developer, and he's using nvidia hardware - I don't think he's got access to AMD/ATI hardware, so there's just one bottleneck - and then again, he also doesn't use Rembrandt due to reasons that he mentioned earlier.


Not to be an expert on the rendering part of FG, but developing on 2 different rendering platforms is kind of waste of time when they are not compatible with each others.

You really should look at the article I linked to above - i.e. to learn how the project works, we really have several features that are competitive in nature, such as support for multiple FDMs for example. And you could even argue that we should only have a single aircraft in FG, to ensure that it is receiving lots of attention - instead, the situation is that people do end up coming up with their own works, and prefer doing so.

Same with scenery.. I see that airport and aircrafts builders still releases there planes without Rembrandt support. That I think is mostly because its not in there by default.
So flying over airports made for standard rendering dont show up as nice. Airport lightning just look awfull and fake when in rembrandt mode.

I suggest to phrase things more carefully, whatever you may dislike about FG, it's likely that some contributors have literally spend hundreds of hours on the corresponding feature :lol:
Then again, may I ask you why we should encourage aircraft/scenery developers to provide Rembrandt support if it cannot be run by many users, especially those with average hardware ?


By enabling rembrandt as default we would get all the community to look in one direction. Right now the FG 3D objects database is terrible and most of it uses fake lightning on it or show up strange mess in rembrandt mode.Go Rembrandt as default (There could still be an option to turn it off for the nintees hardware out there :lol:


I don't know, you are covering lots of ground here - but the real point being that Rembrandt isn't quite ready for "prime time" yet. The community does have experience with serious "advances" and enforcing technology changes, such as the OSG port back in ~2006, which causes lots of irritation within the community. So, I suggest to be careful about such suggestions, they're clearly colored by your own preferences, and not for the greater sake of the project ..

I suggest to use the issue tracker for anything rembrandt related, FredB may eventually notice any related issues and review them.


Anyway... Great project, but we should look forward implementing some of the best in rendering as default and find a standard for all to focus on when it comes to 3d objects and lights. To much strange showing up here and there. Clean up the official 3d database and flag everyting that is not Rembrandt ready as depricated.

Well, most core developers seem to disagree, for example see:

http://www.mail-archive.com/flightgear- ... 39922.html
Zakalawe wrote:concerning the larger issue of different rendering pipelines / approaches,
my opinion is, and remains, that the long-term solution is separate viewer
codebases - while a plethora would be bad, we would already benefit from a
'fixed-function, no shaders' renderer codebase distinct from a Rembrandt
renderer and modern, forward-rendering OpenGL 3.x pipeline. This needs the
viewer to be cleanly split out from the simulation backend, via HLA, which is
exactly what Mathias (and soon, myself) are working towards, but slowly.


So, there's a deeper problem here, not specific to Rembrandt at all - you need to look at things from a distance to kinda see the "hidden truth", it's an issue inherent to FlightGear development in general, which is happening in cyclic fashion and it's really "just happening" to be honest, where it's increasingly normal to have a very low number of active core developers who often take a hiatus from development for months, without coding/integration efforts being very coordinated afterwards, vs. an increasing number of sophisticated base package developers who are pushing the boundaries of FlightGear during each release cycle, while making a larger effort to coordinate things and collaborate to a much higher degree in comparison, as can be seen here on the forum, often without touching/building any C++ code. And that's the way modding communities work too in commercial games.

In a way, it's software evolution at work, i.e. "survival of the fittest", so from a certain standpoint there's actually hope on the horizon, even if Rembrandt were to remain in its current state - simply because there's a certain "competition" going on among related FG features.

So, it's not really Rembrandt that's the issue here, the bottleneck is the number of active expert C++ developers (you cannot really touch the 3D parts of the simulator with "just" C++ knowledge, you also need strong maths skills and OpenGL/OSG 3D rendering experience), especially once they're no longer around to help integrate their code and if there's little documentation to help newcomers maintain their code, because that's when base package development is often taking over eventually.

Like Thorsten briefly mentioned, there are probably some performance/efficiency problems in Rembrandt, presumably due to algorithmic reasons - Thorsten has identified quite a few of those in other parts of the rendering pipeline, and apparently also knows how to solve such things, but the underlying code isn't as accessible to fgdata developers, even if they write sophisticated GLSL code. Lack of documentation is just one factor here.

It really is an integration and accessibility issue - for hardcoded features to remain relevant they need to be primarily accessible to base package contributors like Thorsten, they don't even need to be particularly extensive or complete ironically, they just need to empower base package developers.

We've seeen that in various places, such as XML & the property tree (David Megginson), the XML-configurable GUI (also Megginson), Nasal (Andy Ross), the OSG port (Mathias Frohlich), the effects framework (Tim Moore) or, more recently, the Canvas (TheTom's baby) system. Basically, all of these turned out to be architectural pillars, enabler-mechanisms that delegate the development of certain features to other contributors, while handling all the technical low-level stuff at the framework level, i.e. the difficult stuff that's easy to get wrong if done by less-experienced developers.

It really is the difference between "feature programming" and doing large-scale software engineering, the recent reset/re-init work is another example for this - it touches tons of places and cleans up shortcomings in code that's been lingering -unmaintained- in the code base for years, without really resulting in immediate features/gratification.

Just look at the property tree, Nasal, the effects framework - these were major design extensions that were not just about individual end-user features, they were design pillars, that remained relevant and even gained momentum despite their original developers having "left" the project since quite some time.

The same could be said about the Canvas system: even if Tom were to drop development today, I'd argue that even 5 years from now, you would see it being increasingly used, and probably extended by others.

All of these architectural pillars started out fairly basic, and even in a pretty rudimentary state in comparison to existing hardcoded features (the Canvas started with just osgText support - compare that to all the od_gauge instruments we had), but ultimately these features did prevail as we know, not only did they survive, but they even surpassed those hardcoded features that seemed so much superior in the beginning.

And in FlightGear terms, the Canvas system really only just got started "recently" - and it's already affecting tons of places and features, and it's helping phase out old code that hasn't been maintained in years.

In comparison, just look at the AI traffic manager, the built-in map dialog, wxradar, agradar, the navdisplay or the PUI GUI - all of these are currently in the process of losing relevance (aka being increasingly phased out) due to less-developed, but more flexible, infrastructure changes, and due to their developers/maintainers being either inactive, busy or simply just aware that unifying backend code makes sense to get rid of code cruft.

Likewise, we've had a built-in/hardcoded weather system that basically got replaced by an implementation in scripting and shader space, without the C++ system being actively maintained...

So hardcoded systems that lack certain flexibility, especially accessibility to base package developers, end up being losing relevance sooner or later if their original developers are not around to maintain their systems.

This could also be said about Rembrandt probably.

And it can also be seen in the way scenery development and OSM adoption is happening currently, making the random buildings system scriptable has been suggested right from the beginning, and despite that never having happened so far, we're now seeing more flexible solutions coming up in scripting space and possibly replacing the original feature altogether (unless it gets decoupled and becomes script-able).

Another example is the autopilot system: It not being actively maintained meant that aircraft developers re-implemented certain parts in scripting space and even started running FDM-coupled Nasal code (despite certain GC ramifications and despite core developers generally discouraging this).

Thanks to cppbind, FlightGear's I/O features are currently revamped, too (e.g. HTTP bindings) - Nasal scripting is suddenly able to access networking hooks and do things that were previously impossible, and it is foreseeable how this is going to deprecate some legacy I/O features that simply lack the degree of flexibility that Nasal comes with, features that haven't been maintained in years.

So core development is simply not as active as base package development and C++ code that doesn't honor this fact by providing the required extension hooks (XML, property tree, scriptability) for fgdata developers, is likely to lose relevance over time if it's no longer maintained, despite the original C++ code often being more feature-complete (Map dialog, Navdisplay, agradar, wxradar, AI traffic manager etc)

That's kinda the irony here, it seems more future-proof to provide building blocks to base package developers than implementing fully-fledged features to end-users, because the latter usually results in tons of feature requests and maintenance issues, while the former simply delegates development and maintenance to the base package developer community.

There are some obvious exceptions like the Canvas system, which is being developed very actively, but those are really "enablers" pushing the whole process forward in the first place.

Time has shown that end-user features implemented in C++ space do not survive because of developers defending them, but because of base package developers adopting them and due to them being able to build new things on top (see route manager, NasalPositioned APIs etc), without having to build stuff from source and without having to touch any C++ code.

For example, I think it's pretty safe to say that the Canvas system was never intended to "compete" with Rembrandt, and most people here will be wondering how it could possibly be competing at all ? But ultimately it really is an integration and accessiblity issue, too. Admitedly, you need to be familiar with the way the project works to foresee what could be happening here, but it's not really far-fetched at all:

I had a quick look, and according to the initial Rembrandt commits by FredB, they were all about decoupling rendering into multiple stages and doing offscreen rendering to textures. This is also supported by the wiki and the initial Rembrandt discussions on the devel list. So far, straightforward to understand - even without knowing any GLSL.

So basically it's about decoupling each rendering step and rendering each stage to a separate offscreen texture, and then it's mostly about exposing each rendering step/stage to the effects/GLSL framework for further processing there.

Rembrandt obviously predates the Canvas system, but these days that's exactly what the Canvas is good at: offscreen rendering to an osg::Image, without having to touch any C++ code, and without having to build FlightGear from source.

However, the Canvas system is obviously all about 2D rendering, only.

Then again, Tim Moore (developer of the effects framework) did mention several times how it would be great to extend the effects framework to allow arbitrary textures to be used as inputs/outputs for the effects frame. For example, see: http://www.mail-archive.com/flightgear- ... 37873.html

So consider a Canvas texture as the potential input/output for an effect, and there you have it: Canvas + effects/shader => one important ingredient for a Canvas-based Rembrandt port. Still, Canvas is just about 2D rendering, right ?

Well, not quite: we also have dozens of feature requests from aircraft developers to allow scenery views to be rendered as cockpit textures, e.g. to render mirrors or tail camera images. A feature also commonly seen on FSX and XPlane.
Several years ago, Zan made lots of progress doing this sort of thing, long before the Canvas again - so it's also an integration issue.

These days, this would require the view_mgr code to be adapted and turned into a Canvas::Element. For example, see:
http://www.mail-archive.com/flightgear- ... 36673.html
http://wiki.flightgear.org/Howto:Use_a_ ... Instrument

Other aircraft developers have asked for effects/GLSL being available to cockpit textures for other reasons, e.g. to implement night vision views/FLIR imagings. And supporting effects/shaders in Canvas has been discussed various times on the forum too.

So, these are just two new features: 1) making effects/GLSL usable to Canvas textures and 2) rendering scenery views - and suddenly you have two major ingredients for a deferred shading scheme in place, without requiring extensive C++ changes, and without necessarily having to even look at Rembrandt ...

Obviously, the Canvas system only supports a few placement modes, i.e. gui/aircraft and scenery - but adding a new "fullscreen" osgViewer-based placement mode would also be less complicated than reverse engineering Rembrandt.

There was also discussion on the devel list about supporting multiple osgviewer windows in Canvas, see the comments by Tom and James:
http://www.mail-archive.com/flightgear- ... 37907.html

Honestly, I don't think that anybody is working on replacing Rembrandt, but I also don't think that we have any active core developers who could easily help maintain Rembrandt (except for FredB obviosuly) - still it is foreseeable that the Canvas system will -eventually- provide all essential building blocks to allow deferred rendering to be built on top, it's really just a matter of time.

At that point revisiting the Rembrandt code and moving its rendering stages into cascaded Canvas textures that make use of scenery views and effects/shaders with an osgViewer-based placement, would be straightforward for any GLSL developer, much more so than getting to grips with the underlying Rembrandt C++ code itself.

So, nobody is working on revamping/replacing Rembrandt, but even if it were to continue to be stalled, the idea could still evolve - C++ templates were also never intended to be turing-complete, it just happened by accident :lol:

As we know, even for good ideas, it usually takes ~3-5 years for them to be implemented (remember: OSG port, Rembrandt, Canvas etc).

So I still wouldn't hold my breath. But re-considering the way Rembrandt is done and integrating it with the Canvas system would help make it less obscure and more accessible to effects/GLSL developers, especially for times when there are no C++/3D experts around.

Ultimately, the 3D guys (Mathias, Tim, Fred) would need to talk and decide if thats something they want to pursue. But I'm sure that shader gurus like Thorsten, Zan, i4dnf or Vivian would appreciate Rembrandt becoming better maintainable that way. At the moment, it's unfortunately a pretty obscure niche feature that most end-users cannot really use easily, and that most core developers are not really familiar with from a design point of view.


Maybe that's something to consider for FlightGear's, 20-year anniversary, i.e. in 2016 ?
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: 11354
Joined: Tue Mar 25, 2008 8:40 am


Return to Graphics

Who is online

Users browsing this forum: No registered users and 0 guests