Re: [Flightgear-devel] Big black box
Tim Moore wrote: Yeah, the lack of frame buffer object support turned out to be the common denominator for users seeing the problem. I checked in code tonight that should resolve the issue when frame buffer objects aren't available. Great stuff - thanks Tim. I wonder whether it would be worthwhile merging these bug fixes into a 1.9 patch release. -Stuart -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Big black box
An early 1.9.1 ? -Fred -- message original -- Sujet: Re: [Flightgear-devel] Big black box De: Stuart Buchanan stuart_d_bucha...@yahoo.co.uk Date: 31.12.2008 09:51 Tim Moore wrote: Yeah, the lack of frame buffer object support turned out to be the common denominator for users seeing the problem. I checked in code tonight that should resolve the issue when frame buffer objects aren't available. Great stuff - thanks Tim. I wonder whether it would be worthwhile merging these bug fixes into a 1.9 patch release. -Stuart -- ___ 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] Big black box
Hi, On Wednesday 31 December 2008 11:11:16 Frederic Bouvier wrote: An early 1.9.1 ? -Fred -- message original -- Sujet:Re: [Flightgear-devel] Big black box De: Stuart Buchanan stuart_d_bucha...@yahoo.co.uk Date: 31.12.2008 09:51 Tim Moore wrote: Yeah, the lack of frame buffer object support turned out to be the common denominator for users seeing the problem. I checked in code tonight that should resolve the issue when frame buffer objects aren't available. Great stuff - thanks Tim. I wonder whether it would be worthwhile merging these bug fixes into a 1.9 patch release. I guess that as long as the updated binary is still compatible with the base package, we could just release a quick source / binary only release. If incompatibilities have already been introduced, we should consider doing a full 1.9.1 bugfix release soon. I'd like to get some more feedback, but perhaps early next week would be good. In any case: Happy new Year everyone! Cheers, Durk -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Big black box
Fred wrote An early 1.9.1 ? - -- message original -- Sujet:Re: [Flightgear-devel] Big black box De: Stuart Buchanan stuart_d_bucha...@yahoo.co.uk Date: 31.12.2008 09:51 Tim Moore wrote: Yeah, the lack of frame buffer object support turned out to be the common denominator for users seeing the problem. I checked in code tonight that should resolve the issue when frame buffer objects aren't available. Great stuff - thanks Tim. I wonder whether it would be worthwhile merging these bug fixes into a 1.9 patch release. -Stuart Whoa - not too fast - yesterdays update has regressed the z-buffer ordering. Prop disks, gun-sights, and precipitation render 3d clouds transparent here. On the other hand, there has been a recent and significant improvement in frame rate. I'm not sure if it's Yon's, Tim's or James' stuff, but well done all. I'm using Yon's 3d tree patch. That seems to be worthwhile here, but only up to 2-3 times the standard tree density Vivian -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Big black box
On 31 Dec 2008, at 10:50, Vivian Meazza wrote: On the other hand, there has been a recent and significant improvement in frame rate. I'm not sure if it's Yon's, Tim's or James' stuff, but well done all. I'd love to take credit, but I don't *think* it can be me - I've made some changes that make startup a little quicker (but, depends on disk- speed, disk-cache-hotness, and how fast/slow your malloc is), but nothing that should cause a noticeable win (or loss!) when running. I'm using Yon's 3d tree patch. That seems to be worthwhile here, but only up to 2-3 times the standard tree density I was running this patch for a while, and didn't see any improvement, but I suspect I'm fill-rate limited on my 7300GT (at 1680x1050). Equally, it didn't cause any problems for me. James -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Big black box
Hi Durk, my intention is to post a win32 binary update as soon as the issues reported by Vivian and you are addressed. I don't think the new commited code requires a data update. -Fred -- message original -- Sujet: Re: [Flightgear-devel] Big black box De: Durk Talsma d.tal...@xs4all.nl Date: 31.12.2008 10:36 Hi, On Wednesday 31 December 2008 11:11:16 Frederic Bouvier wrote: An early 1.9.1 ? -Fred -- message original -- Sujet:Re: [Flightgear-devel] Big black box De: Stuart Buchanan stuart_d_bucha...@yahoo.co.uk Date: 31.12.2008 09:51 Tim Moore wrote: Yeah, the lack of frame buffer object support turned out to be the common denominator for users seeing the problem. I checked in code tonight that should resolve the issue when frame buffer objects aren't available. Great stuff - thanks Tim. I wonder whether it would be worthwhile merging these bug fixes into a 1.9 patch release. I guess that as long as the updated binary is still compatible with the base package, we could just release a quick source / binary only release. If incompatibilities have already been introduced, we should consider doing a full 1.9.1 bugfix release soon. I'd like to get some more feedback, but perhaps early next week would be good. In any case: Happy new Year everyone! Cheers, Durk -- ___ 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] Big black box
On 31 Dec 2008, at 10:11, Frederic Bouvier wrote: An early 1.9.1 ? I think we need to get a handle on the 'scenery loading takes 2 minutes' issue before doing a 1.9.1 Completely wild guess - hitting a slow path in OSG or the driver due to some missing feature / unsupported extension? Since it does *eventually* start, if given long enough. James -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Big black box
Hi, On Wed, Dec 31, 2008 at 12:06 PM, James Turner zakal...@mac.com wrote: I think we need to get a handle on the 'scenery loading takes 2 minutes' issue before doing a 1.9.1 Some weeks ago I was looking around the database thread and I got the impression all --random-objects are getting copied. As in each object is a full-blown copy, not an OSG node reference to a single instance of the object. I may be wrong, I was just reading around that part. Surely disabling random objects makes a great difference in load times, I never use random objects. I havent cvs updated in a few days, but merging both the use OpenThreads atomic and use display lists for shader trees would benefit win32 users and general fps. I'll see if I can merge soon and repost a patch. Completely wild guess - hitting a slow path in OSG or the driver due to some missing feature / unsupported extension? Since it does *eventually* start, if given long enough. James Happy new year :) yon -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Big black box
Fred wrote Hi Durk, my intention is to post a win32 binary update as soon as the issues reported by Vivian and you are addressed. I don't think the new commited code requires a data update. -Fred -- message original -- Sujet:Re: [Flightgear-devel] Big black box De: Durk Talsma d.tal...@xs4all.nl Date: 31.12.2008 10:36 Hi, On Wednesday 31 December 2008 11:11:16 Frederic Bouvier wrote: An early 1.9.1 ? -Fred -- message original -- Sujet: Re: [Flightgear-devel] Big black box De: Stuart Buchanan stuart_d_bucha...@yahoo.co.uk Date: 31.12.2008 09:51 Tim Moore wrote: Yeah, the lack of frame buffer object support turned out to be the common denominator for users seeing the problem. I checked in code tonight that should resolve the issue when frame buffer objects aren't available. Great stuff - thanks Tim. I wonder whether it would be worthwhile merging these bug fixes into a 1.9 patch release. I guess that as long as the updated binary is still compatible with the base package, we could just release a quick source / binary only release. If incompatibilities have already been introduced, we should consider doing a full 1.9.1 bugfix release soon. I'd like to get some more feedback, but perhaps early next week would be good. In any case: Happy new Year everyone! The new default near-field value causes clipping problems in many, if not most, cockpits. I've already checked in a fix for the Camel, but this needs checking for all the data package models. Vivian -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Big black box
On 31 Dec 2008, at 11:28, Yon Uriarte wrote: I havent cvs updated in a few days, but merging both the use OpenThreads atomic and use display lists for shader trees would benefit win32 users and general fps. I'll see if I can merge soon and repost a patch. I've tested both locally, and found no problems, but I'm on Mac - and since they're optimisations (important ones, for sure), it'd be good to get some assent from a Windows user (or several) that both patches are okay - it'd be frustrating for everyone to post a 1.9.1 that fixes the black boxes but introduces another regression. Most people do run with random objects enabled, after all. Not that I don't think both patches are good, but there's quite a clamour for a more stable version 'soon' - throwing performance patches in to a bug-fix release seems like asking for trouble. (I've said such things in work situations before and been over- ruled... but I've also been the person pressing to include a 'safe' fix that promptly blew up...) James -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Big black box
James Turner wrote On 31 Dec 2008, at 11:28, Yon Uriarte wrote: I havent cvs updated in a few days, but merging both the use OpenThreads atomic and use display lists for shader trees would benefit win32 users and general fps. I'll see if I can merge soon and repost a patch. I've tested both locally, and found no problems, but I'm on Mac - and since they're optimisations (important ones, for sure), it'd be good to get some assent from a Windows user (or several) that both patches are okay - it'd be frustrating for everyone to post a 1.9.1 that fixes the black boxes but introduces another regression. Most people do run with random objects enabled, after all. Not that I don't think both patches are good, but there's quite a clamour for a more stable version 'soon' - throwing performance patches in to a bug-fix release seems like asking for trouble. (I've said such things in work situations before and been over- ruled... but I've also been the person pressing to include a 'safe' fix that promptly blew up...) As a Windows user, I would be delighted to test the other patch, if you would pint me at the appropriate place. I've rather lost contact with the succession of Yon's patches. Vivian -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Big black box
Frederic Bouvier wrote: Hi, seeing reports that the big black box is often met with a FBO error, I began to look at our way to render to texture. And I found this piece of code in od_gauge.cxx, line 63 : camera-setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT, osg::Camera::FRAME_BUFFER); so it looks like the render to texture occurs in the frame buffer when FBO are not available. Maybe I am mistaken, but what about : camera-setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT); or camera-setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT, osg::Camera::PIXEL_BUFFER_RTT); instead ? Old style RTT should be available widely without the need to draw to the frame buffer, and corrupt the scene. -Fred Yeah, the lack of frame buffer object support turned out to be the common denominator for users seeing the problem. I checked in code tonight that should resolve the issue when frame buffer objects aren't available. Tim -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
