Re: [Flightgear-devel] problems with z-buffer
Also if I'm not mistaken, the current version of the Bravo alters the startup field-of-view from default of 55 to 60; would that make it more prone to problems in this area? -R. Robert M. Shearman, Jr. Transit Operations Supervisor, University of Maryland Department of Transportation also known as rm...@umd.edu From: James Turner zakal...@mac.com To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Sent: Monday, December 29, 2008 6:46:47 PM Subject: Re: [Flightgear-devel] problems with z-buffer On 29 Dec 2008, at 08:40, Tim Moore wrote: .4 meters seemed sufficient to me, but others don't agree, so perhaps we can settle on some value larger than .1. The near plane value is settable, both in the camera configuration and as a live property in /sim/rendering/camera- group/znear. Just ran into this with Bravo. A value of 0.2 works, but 0.3 causes some minor clipping of the cockpit roof, and 0.4 causes nearly the entire side-pillar to be clipped. I wonder if part of this is about camera position placement in the models, but my ignorance of such matters is vast, so I'll say no more. James -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] problems with z-buffer
Alex Romosan wrote: the latest commit to src/Main/CameraGroup.cxx changed the value of zNear from .1 to .4 and this causes strange artifacts to show up when panning around (like holes in the cockpit, etc.). the following patch changes it back: --- src/Main/CameraGroup.cxx27 Dec 2008 14:35:33 - 1.9 +++ src/Main/CameraGroup.cxx29 Dec 2008 06:58:41 - @@ -446,7 +446,7 @@ cgroup-buildGUICamera(pNode); } } -bindMemberToNode(gnode, znear, cgroup, CameraGroup::_zNear, .4f); +bindMemberToNode(gnode, znear, cgroup, CameraGroup::_zNear, .1f); bindMemberToNode(gnode, zfar, cgroup, CameraGroup::_zFar, 12.0f); bindMemberToNode(gnode, near-field, cgroup, CameraGroup::_nearField, 100.0f); any reason for the change? FlightGear displays an enormous visual range, from 4 inches in front of your eyes out to 120km now and more in the future. It's a basic fact when using Z-buffered computer graphics that the precision of the Z-buffer deteriorates with huge near-far spreads and that the near plane distance has a much greater effect than the far plane. The symptoms are flickering, jitter, and other unpleasantness. About a year ago I added a scheme to use several cameras within the scene graph to work around this problem. Each camera draws a slice of the scene using the full range of the Z buffer. This mostly works well, though depending on your video hardware you can occasionally see a line in the scene. This should be able to be eliminated with some tuning. Recently, as part of the work in implementing shadow maps, I moved the cameras out of the scene graph to a top level. For some reason this provoked the black-rectangle bug on some video hardware that's reared its head in the forums, but that's another story :) Anyway, my intention is to restrict shadows to the near camera. Shadow maps are even more sensitive to near-far plane precision issues than the normal Z buffer, so I'm experimenting with pushing the near plane out. .4 meters seemed sufficient to me, but others don't agree, so perhaps we can settle on some value larger than .1. The near plane value is settable, both in the camera configuration and as a live property in /sim/rendering/camera-group/znear. Tim -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] problems with z-buffer
On 29 Dec 2008, at 08:40, Tim Moore wrote: .4 meters seemed sufficient to me, but others don't agree, so perhaps we can settle on some value larger than .1. The near plane value is settable, both in the camera configuration and as a live property in /sim/rendering/camera- group/znear. Just ran into this with Bravo. A value of 0.2 works, but 0.3 causes some minor clipping of the cockpit roof, and 0.4 causes nearly the entire side-pillar to be clipped. I wonder if part of this is about camera position placement in the models, but my ignorance of such matters is vast, so I'll say no more. James -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] problems with z-buffer
Hi, I tried this change on my MacBook Pro with ATI Radeon X1600. Setting .1 to znear increases a chance of flickering 3D clouds as Tim mentioned. Changing it to .4 reduces the flicker but not enough on my Mac. .7 will be sufficient to eliminate flicker in most of views but you cannot see very near side of the cockpit. As Tim mentioned, we need to settle the default value of this property for reasonable result in many machines, but I guess it is a bit hard. I wonder if decreasing the zfar reduces the chance of flickering. Will try it tonight. Anyway, it is very good to have these properties exposed so that users can adjust these for getting a suitable result. Thanks Tim! In my own opinion, the default value can be .1 if we provide a brief guide for ajdusting these properties. We can write a wiki page about it and advertise the guide via here and/ or the forums. I also found the side effect of putting small number to near-field (the boundary of near and far camera). If you place the boundery in front of the propeller, the alpha blend of the propeller seems not working and thus it hides the 3D clouds behind it. For example, putting 1 to near-field when in the cockpit view of A6M2 hides the 3F clouds behind the propeller. I think the far camera is for avoiding such problem so this can be predictable side effect. But if this can be solved, that would be great. (I'm not that sure if we need to though). I also want to add a fact that the blackbox issue does not appear on my macs, and I have never heard about similar issues from Mac users yet. So most of mac users don't have to adjust these properties. Best, Tat @ iPhone On Dec 29, 2008, at 5:40 PM, Tim Moore timo...@redhat.com wrote: Alex Romosan wrote: the latest commit to src/Main/CameraGroup.cxx changed the value of zNear from .1 to .4 and this causes strange artifacts to show up when panning around (like holes in the cockpit, etc.). the following patch changes it back: --- src/Main/CameraGroup.cxx27 Dec 2008 14:35:33 - 1.9 +++ src/Main/CameraGroup.cxx29 Dec 2008 06:58:41 - @@ -446,7 +446,7 @@ cgroup-buildGUICamera(pNode); } } -bindMemberToNode(gnode, znear, cgroup, CameraGroup::_zNear, .4f); +bindMemberToNode(gnode, znear, cgroup, CameraGroup::_zNear, .1f); bindMemberToNode(gnode, zfar, cgroup, CameraGroup::_zFar, 12.0 f); bindMemberToNode(gnode, near-field, cgroup, CameraGroup::_nearField, 100.0f); any reason for the change? FlightGear displays an enormous visual range, from 4 inches in front of your eyes out to 120km now and more in the future. It's a basic fact when using Z-buffered computer graphics that the precision of the Z-buffer deteriorates with huge near-far spreads and that the near plane distance has a much greater effect than the far plane. The symptoms are flickering, jitter, and other unpleasantness. About a year ago I added a scheme to use several cameras within the scene graph to work around this problem. Each camera draws a slice of the scene using the full range of the Z buffer. This mostly works well, though depending on your video hardware you can occasionally see a line in the scene. This should be able to be eliminated with some tuning. Recently, as part of the work in implementing shadow maps, I moved the cameras out of the scene graph to a top level. For some reason this provoked the black-rectangle bug on some video hardware that's reared its head in the forums, but that's another story :) Anyway, my intention is to restrict shadows to the near camera. Shadow maps are even more sensitive to near-far plane precision issues than the normal Z buffer, so I'm experimenting with pushing the near plane out. .4 meters seemed sufficient to me, but others don't agree, so perhaps we can settle on some value larger than .1. The near plane value is settable, both in the camera configuration and as a live property in /sim/rendering/camera- group/znear. Tim --- --- --- - ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] problems with z-buffer
On Tue, Dec 30, 2008 at 10:46 AM, James Turner zakal...@mac.com wrote: On 29 Dec 2008, at 08:40, Tim Moore wrote: .4 meters seemed sufficient to me, but others don't agree, so perhaps we can settle on some value larger than .1. The near plane value is settable, both in the camera configuration and as a live property in /sim/rendering/camera- group/znear. Just ran into this with Bravo. A value of 0.2 works, but 0.3 causes some minor clipping of the cockpit roof, and 0.4 causes nearly the entire side-pillar to be clipped. I wonder if part of this is about camera position placement in the models, but my ignorance of such matters is vast, so I'll say no more. James Hi All, I checked the Honda Jet and found that along with parts of the window frame and even parts of the pilot's arms are clipped. The workaround of --prop:/sim/rendering/camera-group/near-field=0.1 is okay though noted that the ships wash near KSFO flickered. Change the value to 1 showed the clipped cockpit again. If anyone is interesting, I'm happy to document this case further with software version details and the like. Regards George -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
