> 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
