Re: [Flightgear-devel] reminder: entering feature freeze now
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 several aircraft. A reminder to aircraft creators using the ubershader - normal mapping requires to declare tangent, normal and binormal generation airplane-side. These need to be also declared as vertex attributes in a numbered technique - in order for this to work, the technique n=4 matching the model ubershader effect in model-combined.eff for ALS has to be added, otherwise normal maps do not work and the model receives incorrect lighting. * Implement a scheme for generating autumn colors procedurally The scheme exists and generates autumn colors in central Europe. Since the majority of feedback for this was rather skeptical, I have not pursued the idea much further or extended it to tree autumn coloring, but Stuart has implemented his tree work in a nice way that trees shed all leaves in late autumn, so it's not as good as it could be, but reasonably plausible. At least I like changing the colors a bit. Since autumn coloring doesn't work correctly everywhere in the world (I've mainly adjusted Europe and the North Atlantic Islands), I would regard it as experimental. * make clouds render faster Stuart has done the main work on this one with a LOD scheme dropping sprites beyond some distance. Since this mutilated faint clouds which have just 1-2 sprites to begin with, I recently pushed a way that these clouds are not treated by the LOD system at all. I'd say we need feedback from users playing with the LOD distance if it improves framerates while keeping the visuals or not. We now have overall cloud density, draw distance and the LOD distance to configure the framerate impact of 3D clouds - is this enough? In what form should this best be exposed to the user? What are reasonable defaults? * Improve cloud appearance from high altitude This is mostly done - I've introduced three quite sophisticated cloudlet placement scheme, and it does miracles from high altitude. There are still the rather blocky 8/8 cover scenarios remaining when clouds tend to cover the whole square tile - I wanted to do something to the edges, but haven't gotten around to doing so. Not sure if this qualifies as a bugfix or a novel feature, but I think it's harmless. * The 'ultra' terrain shader This is done - at highest landmass and transition slider setting, the terrain shader renders details to a quality that you can park your helicopter in the scene and have a nice ground resolution (the smallest details are cm-sized, and they move with the wind). From my side, this would be the main selling point for a 3.0 release. The water shader also has received upgrades with color and reflectivty variations of the water and a trick to generate surf at steep coasts. Also drift ice and be procedurally drawn on the water. In arctic regions, we have drifting icebergs by default now. * Regional texturing Since the last release, I've added Indonesia, Madagascar, North Atlantic Islands (Greenland, Faroe, Shetlands,...) and Middle East and Vivian added UK definitions. Combined with Hawaii, Iceland, Caribbean and tropical South America which we've had previously, this is already a substantial variation to illustrate how FG can look like. Especially Hawaii can serve very well as a showcase scenery now. * Atmospheric light scattering and Rembrandt There hasn't been a volunteer to help me look into this from the Rembrandt side, and so according to the plan there has been no development. Based on my current test results, my computer doesn't seem to be able to get Rembrandt fast enough for this to make any sense, although I don't understand this finding. While things can always be better, from my side that's a clear vote for 3.0. With the hires terrain shader and wind effects on terrain and vegetation, combined with the pixel post-processing effects, we can offer much higher resolution visuals on the terrain than before (and I understand with the autum color effect or drift ice some genuine novel effects which are in no other flightsim). * Thorsten -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reminder: entering feature freeze now
Thorsten Sent: 18 June 2013 07:40 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] reminder: entering feature freeze now 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 several aircraft. A reminder to aircraft creators using the ubershader - normal mapping requires to declare tangent, normal and binormal generation airplane-side. These need to be also declared as vertex attributes in a numbered technique - in order for this to work, the technique n=4 matching the model ubershader effect in model-combined.eff for ALS has to be added, otherwise normal maps do not work and the model receives incorrect lighting. * Implement a scheme for generating autumn colors procedurally The scheme exists and generates autumn colors in central Europe. Since the majority of feedback for this was rather skeptical, I have not pursued the idea much further or extended it to tree autumn coloring, but Stuart has implemented his tree work in a nice way that trees shed all leaves in late autumn, so it's not as good as it could be, but reasonably plausible. At least I like changing the colors a bit. Since autumn coloring doesn't work correctly everywhere in the world (I've mainly adjusted Europe and the North Atlantic Islands), I would regard it as experimental. * make clouds render faster Stuart has done the main work on this one with a LOD scheme dropping sprites beyond some distance. Since this mutilated faint clouds which have just 1-2 sprites to begin with, I recently pushed a way that these clouds are not treated by the LOD system at all. I'd say we need feedback from users playing with the LOD distance if it improves framerates while keeping the visuals or not. We now have overall cloud density, draw distance and the LOD distance to configure the framerate impact of 3D clouds - is this enough? In what form should this best be exposed to the user? What are reasonable defaults? * Improve cloud appearance from high altitude This is mostly done - I've introduced three quite sophisticated cloudlet placement scheme, and it does miracles from high altitude. There are still the rather blocky 8/8 cover scenarios remaining when clouds tend to cover the whole square tile - I wanted to do something to the edges, but haven't gotten around to doing so. Not sure if this qualifies as a bugfix or a novel feature, but I think it's harmless. * The 'ultra' terrain shader This is done - at highest landmass and transition slider setting, the terrain shader renders details to a quality that you can park your helicopter in the scene and have a nice ground resolution (the smallest details are cm-sized, and they move with the wind). From my side, this would be the main selling point for a 3.0 release. The water shader also has received upgrades with color and reflectivty variations of the water and a trick to generate surf at steep coasts. Also drift ice and be procedurally drawn on the water. In arctic regions, we have drifting icebergs by default now. * Regional texturing Since the last release, I've added Indonesia, Madagascar, North Atlantic Islands (Greenland, Faroe, Shetlands,...) and Middle East and Vivian added UK definitions. Combined with Hawaii, Iceland, Caribbean and tropical South America which we've had previously, this is already a substantial variation to illustrate how FG can look like. Especially Hawaii can serve very well as a showcase scenery now. * Atmospheric light scattering and Rembrandt There hasn't been a volunteer to help me look into this from the Rembrandt side, and so according to the plan there has been no development. Based on my current test results, my computer doesn't seem to be able to get Rembrandt fast enough for this to make any sense, although I don't understand this finding. While things can always be better, from my side that's a clear vote for 3.0. With the hires terrain shader and wind effects on terrain and vegetation, combined with the pixel post-processing effects, we can offer much higher resolution visuals on the terrain than before (and I understand with the autum color effect or drift ice some genuine novel effects which are in no other flightsim). 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. Right now we have Terrasync partly broken in Win 64, which will probably not be fixed until after the release. We still cannot select the Screenshot Directory from the gui. I think that all argues for 2.12. Unfortunately, only Fred
Re: [Flightgear-devel] reminder: entering feature freeze now
On 18 Jun 2013, at 09:38, Vivian Meazza vivian.mea...@lineone.net wrote: We still cannot select the Screenshot Directory from the gui. I think that all argues for 2.12. Hmm, that is 'just a bug' which will be fixed during the release cycle, I just keep forgetting about it since there's no issue i the tracker and I never use that feature. Of course, you could look at fixing it yourself! BTW I don't have any strong opinion on 3.0 vs 2.12 - it's simply an increasing number, and given our timed release plan, it's inevitable that the amount of work in each release will fluctuate based on people's time availability. James -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] TerraSync libSVN replacement testing
James
I have a fix to make it compile.
In SVNRepository.hxx, change names off 1st two elements in enum ResultCode
e.g.
enum ResultCode {
ERROR_NONE = 0,
ERROR_UNFOUND,
ERROR_SOCKET,
ERROR_XML,
ERROR_TXDELTA,
ERROR_IO,
ERROR_CHECKSUM
};
Also change these names in SVNRepository.cxx, SVNReportParser.cxx,
SVNDirectory.cxx and terrasync.cxx.
Also #if defined(HAVE_SVN_CLIENT_H) or defined(SG_SVN_CLIENT) should be
corrected on each occurence in terrasync.cxx
Alan
From: Alan Teeder
Sent: Monday, June 17, 2013 11:34 PM
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] TerraSync libSVN replacement testing
James
I found this, in terrasync.cxx, line 91, but the compilation is still failing
#if (defined(HAVE_SVN_CLIENT_H) or defined(SG_SVN_CLIENT))
should be ?
#if (defined(HAVE_SVN_CLIENT_H) || defined(SG_SVN_CLIENT))
Alan
From: Alan Teeder
Sent: Monday, June 17, 2013 10:00 PM
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] TerraSync libSVN replacement testing
Sorry James, I just reported ,and then left it.
I can give it a go, but my C++ debugging is somewhat hit and miss.
Alan
From: James Turner
Sent: Monday, June 17, 2013 9:38 PM
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] TerraSync libSVN replacement testing
On 17 Jun 2013, at 21:25, Vivian Meazza vivian.mea...@lineone.net wrote:
Haven't managed to get it to work for Win 7 64 bit either - still seems to
want LIBSVN to build. Seems to be a cmake issue, but I'm not confident that
I know how to fix this one.
That's because I didn't yet remove the libsvn checks - that would be risky,
this close to the freeze. It's strictly a new, optional feature until after
2.12 is branched.
Alan, did you have any luck with the compiler errors? it builds on the Windows
build slaves on Jenkins I believe.
Regards,
James
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reminder: entering feature freeze now
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 a Rembrandt user (in which case you'd like to have a major step in Rembrandt) or an ALS user (in which case you'd expect a major step in ALS for a 3.0). From my perspective, it's not tinkering around the edges. In terms of code, ALS has about doubled the number of lines. In terms of features, ALS has now all the features that it could theoretically serve as default rendering scheme if so desired without major gaps like missing trees or model effects - this wasn't the case last time, which is why I didn't vote 3.0 last time but why I do now. If you're not a user of these features, they obviously won't impress you much, but they are there nevertheless. The way I see it, waiting for a dramatic step will not ever give us a 3.0, because if some dramatic new feature is introduced, we'd first want to test and observe it, so it will be experimental for a while (so with Rembrandt, ALS and Advanced Weather which all didn't prompt a new number before the decimal), and then the next release will obviously only see progress on existing things, not dramatic new stuff. So, from that perspective, also Rembrandt has by now reached a stable and well tested state and featuring it no longer as experimental would also argue for a 3.0. Right now we have Terrasync partly broken in Win 64, which will probably not be fixed until after the release. We still cannot select the Screenshot Directory from the gui. I think that all argues for 2.12. I'm not sure I follow you that selecting a screenshot directory from the GUI is a major advance justifying a 3.0, but a detailed terrain shader is not. I'm also not sure why Terrasync partially being broken argues for not releasing 3.0 rather than fixing it before the release. But 3.0 is only my (certainly biased) impression. I agree that it would be terrific to have new terrain. But I don't really see a date, and at some point it seems to me we have added so many features beyond what used to be in 2.0 that it's now 3.0 - which is, from my perspective, now. * Thorsten -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reminder: entering feature freeze now
What is the most important ? 1/ To have a working stable Program whose the major options ( ALS, REMBRANDT) remains options since conflicting each other. 2/ To have a working stable Program which include as a standard one of these two options, which would definitively push on the back the other one. OR 3/ To wait for better development reaching the target to have REMBRANDT and ALS working well all together, and definitively included within FG. Though the FG release numbering choice won't be that important ( it is only symbolic), if the policy by choosing 3.0 is to say to the world , yes we have a new great FG version,right now *we don't have it* . We only can say: we are on progress , there is some improvements, there is some bugs which are fixed. The basic content remains the same, some Aircrafts are flying with Rembrandt not with ALS , others are flying with ALS not with Rembrandt. BTW: There is a huge issue which should be solved, we have noticed some not explained performances drop down when using some GPU Thank Ahmad fro the team On 18 June 2013 10:57, Renk Thorsten thorsten.i.r...@jyu.fi wrote: 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 a Rembrandt user (in which case you'd like to have a major step in Rembrandt) or an ALS user (in which case you'd expect a major step in ALS for a 3.0). From my perspective, it's not tinkering around the edges. In terms of code, ALS has about doubled the number of lines. In terms of features, ALS has now all the features that it could theoretically serve as default rendering scheme if so desired without major gaps like missing trees or model effects - this wasn't the case last time, which is why I didn't vote 3.0 last time but why I do now. If you're not a user of these features, they obviously won't impress you much, but they are there nevertheless. The way I see it, waiting for a dramatic step will not ever give us a 3.0, because if some dramatic new feature is introduced, we'd first want to test and observe it, so it will be experimental for a while (so with Rembrandt, ALS and Advanced Weather which all didn't prompt a new number before the decimal), and then the next release will obviously only see progress on existing things, not dramatic new stuff. So, from that perspective, also Rembrandt has by now reached a stable and well tested state and featuring it no longer as experimental would also argue for a 3.0. Right now we have Terrasync partly broken in Win 64, which will probably not be fixed until after the release. We still cannot select the Screenshot Directory from the gui. I think that all argues for 2.12. I'm not sure I follow you that selecting a screenshot directory from the GUI is a major advance justifying a 3.0, but a detailed terrain shader is not. I'm also not sure why Terrasync partially being broken argues for not releasing 3.0 rather than fixing it before the release. But 3.0 is only my (certainly biased) impression. I agree that it would be terrific to have new terrain. But I don't really see a date, and at some point it seems to me we have added so many features beyond what used to be in 2.0 that it's now 3.0 - which is, from my perspective, now. * Thorsten -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot, Way point, GPS definitively broken ?
Hello, James Back to the topic. Thanks for the fix , right now we can use again the Autopilot with the GPS. However the altitude is lost at each WP loading, set to Zero. We could, before, keep on the original defined AP altitude, all over the trip. I know it was not realistic. May be that cruise altitude given within the route manager could be used, to init the AP altitude, thus to keep on the right altitude along the trip. Any idea ? Thank Ahmad On 18 June 2013 01:40, grtuxhangar team hohora...@gmail.com wrote: Just tested with the Cub, working perfectly. Thank a lot Ahmad On 17 June 2013 16:42, James Turner zakal...@mac.com wrote: On 17 Jun 2013, at 15:41, grtuxhangar team hohora...@gmail.com wrote: If you refer to your last fix (yesterday) , it is not sufficient, since like said the /autopilot/settings/gps-driving-true-heading property is not set to true. No, I need to make further tweak this evening, don't worry :) Regards, James -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reminder: entering feature freeze now
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 Much has been said about this already. So I'll be brief (by my standards...). Please consider: The framerate you get to see depends, with full eye candy on and on modern CPUs, almost exclusively on how fast the GPU can process the shaders. Shader execution speed depends measurably on the number of operations performed. I've now had three years to gain hands-on experience benchmarking shaders what runs how fast - I believe I do have a good understanding of what's going on by now. You seem to imagine a 'best of two worlds scenario' here. Just looking at the operations which the GPU needs to perform for ALS+R and comparing with ALS or R alone, the following is far, far more likely to happen: * The framerate of ALS+R will be a bit slower than the minimum of the framerate you get in Rembrandt now and the framerate you get in ALS now. You say you can't run ALS on your machine right now - you'll also be unable to run ALS+R, because it will be even slower. * I have yet to see a plane in which the normal mapping is properly declared fails to render properly under ALS, but assuming for a moment it exists - for a plane to render under ALS+R, it would have to render now under ALS *and* under Rembrandt. Which is to say, if it doesn't run under ALS now, it won't run under ALS+R, if it isn't Rembrandt compatible, it also won't run under ALS+R. So the number of planes which renders properly for you will be even smaller. * As a result, we would be advertizing features which almost no one can run. You won't be able to run it because ALS fails to be fast enough for you, I won't be able to run it because Rembrandt fails to run fast enough for me, so we'll end up creating a major PR disaster with endless user complaints about abysmally low framerates and posts all over the place 'But I can run insert 3d game here without any problems, so Flightgear must be really badly written.' So all problems which the individual rendering frameworks have now will be worse. You will also combine the features of course, so you could render gorgeous sunset scenes with long shadows cast by mountains - but what's the use if that happens at 10 fps? I have yet to see any real argument why this shouldn't happen. I have test data how much you save by perfect z-buffering as used in deferred rendering, and that will mitigate the problem but not solve it. Frankly, I'm not keen to spend half a year coding something just to create a stream of complaints about unusable framerates. All tests I have done so far back me up. So - are you sure you would want it even if less planes work and you get less framerate than now? Because asking for features just costs a few lines of typing, implementing them is a lot more expensive. * Thorsten -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] trees
No one else has mentioned this so maybe its time for a make clean , but this is what Im seeing after the recent tree updates : http://imagebin.org/261806 -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
Syd, We fixed that bug a while back, I hope J. Could you rebuild with the latest FG/SG and try again with the latest FGDATA? I really hope that fixes it! Vivian From: syd adams [mailto:adams@gmail.com] Sent: 18 June 2013 19:16 To: FlightGear developers discussions Subject: [Flightgear-devel] trees No one else has mentioned this so maybe its time for a make clean , but this is what Im seeing after the recent tree updates : http://imagebin.org/261806 -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
On Tue, Jun 18, 2013 at 8:22 PM, Vivian Meazza wrote: Syd, We fixed that bug a while back, I hope J. Could you rebuild with the latest FG/SG and try again with the latest FGDATA? I really hope that fixes it! Me too! Syd - if it doesn't fix it, can you let me know the following: 1) Are you seeing this for all forested areas (e.g. around KHAF)? Or is this specific to explicitly placed trees in the scenery? 2) Any errors on the console? 3) What rendering settings do you have? Thanks, -Stuart -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reminder: entering feature freeze now
ALS already has an ON/OFF selection button. Wouldn't it be useful for Rembrandt to also have such a button, thus being able to switch it on or off either without restarting the sim?? It would skip all the inconvenience of restarting the sim for activating Rembrandt. Thank you! :)/Kle - From: thorsten.i.r...@jyu.fi To: flightgear-devel@lists.sourceforge.net Date: Tue, 18 Jun 2013 16:26:16 + Subject: Re: [Flightgear-devel] reminder: entering feature freeze now 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 Much has been said about this already. So I'll be brief (by my standards...). Please consider: The framerate you get to see depends, with full eye candy on and on modern CPUs, almost exclusively on how fast the GPU can process the shaders. Shader execution speed depends measurably on the number of operations performed. I've now had three years to gain hands-on experience benchmarking shaders what runs how fast - I believe I do have a good understanding of what's going on by now. You seem to imagine a 'best of two worlds scenario' here. Just looking at the operations which the GPU needs to perform for ALS+R and comparing with ALS or R alone, the following is far, far more likely to happen: * The framerate of ALS+R will be a bit slower than the minimum of the framerate you get in Rembrandt now and the framerate you get in ALS now. You say you can't run ALS on your machine right now - you'll also be unable to run ALS+R, because it will be even slower. * I have yet to see a plane in which the normal mapping is properly declared fails to render properly under ALS, but assuming for a moment it exists - for a plane to render under ALS+R, it would have to render now under ALS *and* under Rembrandt. Which is to say, if it doesn't run under ALS now, it won't run under ALS+R, if it isn't Rembrandt compatible, it also won't run under ALS+R. So the number of planes which renders properly for you will be even smaller. * As a result, we would be advertizing features which almost no one can run. You won't be able to run it because ALS fails to be fast enough for you, I won't be able to run it because Rembrandt fails to run fast enough for me, so we'll end up creating a major PR disaster with endless user complaints about abysmally low framerates and posts all over the place 'But I can run insert 3d game here without any problems, so Flightgear must be really badly written.' So all problems which the individual rendering frameworks have now will be worse. You will also combine the features of course, so you could render gorgeous sunset scenes with long shadows cast by mountains - but what's the use if that happens at 10 fps? I have yet to see any real argument why this shouldn't happen. I have test data how much you save by perfect z-buffering as used in deferred rendering, and that will mitigate the problem but not solve it. Frankly, I'm not keen to spend half a year coding something just to create a stream of complaints about unusable framerates. All tests I have done so far back me up. So - are you sure you would want it even if less planes work and you get less framerate than now? Because asking for features just costs a few lines of typing, implementing them is a lot more expensive. * Thorsten -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
