[Flightgear-devel] Rembrandt - Some Feedback
Hello, I updated my FGFS yesterday and today, after a whole while. Of course I tried Rembrandt and I'm impressed- finally shadows again! Rembrandt does work here without any error messages. (DualCore 2,6 Ghz, 4GB RAM, Nvidea GeForce GTX460) What I noticed is, that Anti-Aliasing does not work, and the quality of the shadows is not good yet, though using the 4096px-size. See image [1] below. Changing shadow size at runtime gives me following error message: Warning: detected OpenGL error 'invalid operation' at after RenderBin::draw(..) Sometimes I see some Z-fighting, but can be explained with the strobes/beacon animation. What I do like is, that even the cockpit has now self-shadowing- can look great! See Image [2] below RAM-Usage looks o.k. to me, not much different as before. Framerate-Perfomance is different: With default sceneries, disabled random vegetation and disabled randon objects I get between 30-60fps, depending on view and complexity of the aircraft. With enabled random-vegetation framerates goes down to less than 30-15fps, so about the half I got before. The density of random vegetation is set 1.0. That's something I did not expected, as the 3d-clouds doesn't show this behavior. To my surprise some aircraft does not have any problems with random vegetation enabled: First I thought that if an aircraft has the more faces the more power we need to achieve a good frame rate, but looking at the RAH66 from the forum, the B1b Bone or a converted MSFS-model with about 5vertices it seems not the case. On the other side the C337G or the C172p has a quite bad framerate compared with. Maybe face-numbers, number of objects objects or xml's as reason- I don't know, I will test it deeper and provide the numbers here. The 3d-clouds shows some z-fighting as well, and the draw order seems to be broken. See image [3] below With Rembrandt disabled, some shaders are broken, I already filed a bug-report, and work is going on there. It looks promising, but also still like a long way to go, especially as many aircraft and shaders has to be adapted. [1]http://www.hoerbird.net/fgfs-screen-588.jpg [2]http://www.hoerbird.net/fgfs-screen-586.jpg [3]http://www.hoerbird.net/fgfs-screen-587.jpg Cheers Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Rembrandt - Some Feedback
With Rembrandt, brightness of the scenery seems to depend on the view's pitch angle a lot. So, when you fly along and pitch up/down heavily (take the ufo), you see the ground becoming brighter and darker. It mainly seems to affect the bright (non-shadow) areas. When pitching up, the ground eventually becomes as dark as the shadows (no contrast), while when pitching down, you see the ground being bright and only the shadows are dark: http://imageshack.us/photo/my-images/837/fgfsscreen.png/ cheers, Thorsten -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG caching and other OSG issues
Hi, I try to catch up on things past an other busy week. On Thursday, March 29, 2012 00:22:46 ThorstenB wrote: Mathias, maybe you can have a look at the simgear changes. Maybe you see a way to improve this even further - i.e. do we still need all these cache maps? Or could we simply rely on some OSG cache in some places? Just looking quick over what you checked in, I think that this needs some improovements: The change just returns pointers to objects you get from the observer_ptr. In general, this is not exactly thread safe. I do not see currently if you can ensure from a higher level that this is not a problem or not. In general consider the following situation: Thread 1 has an observer_ptr to A. Thread 2 owns the last reference to A. Thread 1 gets the still valid raw pointer to A from the observer_ptr. Thread 2 releases the last reference to A and deletes it. Thread 1 assigns the raw pointer to a ref_ptr. This probably ends in a segfault. If you work with weak pointers/observer_ptr you need to use the lock method. That one gives you a atomically a dead or alive ref_ptr to A. If you have this ref_ptr in our hands, you own a thread safe reference which makes sure that nobody deletes the object. If your ref_ptr is invalid. An other one was faster on unreferencing. In effect this groups step 3 and 5 into an atomic operation which can not be intercepted by step 4 in the example above. So, if you use this kind of weak stuff, you need to ensure that all the call chain from getting the ref_ptr from any cache down to adding this object to the scenegraph does not use raw pointers. Also the initial ref_ptr in this chain must be gained by observer_ptr::lock(). Regarding the effects, I don't think we can rely on any caching in osg since we do not currently use any osg based loader mechanism to gain these objects. At least nothing that I know of. Greetings Mathias -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FlightGear Newsletter - March 2012
After more than three years without, shadows are about to return to the FlightGear world. At the same time, some people prefer to fly away from that world and watch it from space. All possible thanks to recent developments! These are just two examples of what's covered in the March edition of the FlightGear newsletter. Contributions for this month's newsletter are welcome at FlightGear Newsletter April 2012.-- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Rembrandt - Some Feedback
On Sunday, April 01, 2012 01:45:52 PM ThorstenB wrote: With Rembrandt, brightness of the scenery seems to depend on the view's pitch angle a lot. So, when you fly along and pitch up/down heavily (take the ufo), you see the ground becoming brighter and darker. It mainly seems to affect the bright (non-shadow) areas. When pitching up, the ground eventually becomes as dark as the shadows (no contrast), while when pitching down, you see the ground being bright and only the shadows are dark: http://imageshack.us/photo/my-images/837/fgfsscreen.png/ cheers, Thorsten This sounds (looks) like the gamma is changed with the pitch angle. This would cause the mid-tones to change while the highlites and shadows remain the same. Hal-- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG caching and other OSG issues
Am 01.04.2012 18:25, schrieb Mathias Fröhlich: If you work with weak pointers/observer_ptr you need to use the lock method. Ok, you're absolutely right. I wasn't aware of the lock method before, indeed it has to be used here. I'll push a change. Thanks for reviewing this! cheers, Thorsten -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Rembrandt - Some Feedback
With Rembrandt, brightness of the scenery seems to depend on the view's pitch angle a lot. So, when you fly along and pitch up/down heavily (take the ufo), you see the ground becoming brighter and darker. It mainly seems to affect the bright (non-shadow) areas. I believe it was fixed by these commits : https://gitorious.org/fg/flightgear/commit/8a382cd536743e4cef5b16b37a11fa1282441c5b https://gitorious.org/fg/fgdata/commit/e5d226b26ff4390cdbc1a47706ff735eb3ad6df9 Nevertheless, I am not able to reproduce this behavior here now. Regards, -Fred -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
