Re: [Flightgear-devel] 3d clouds on multi-display systems (was Re: FSWeekend 2012...)
I think that's just a side-effect of having so many pixels covered by (multiple) quads with alpha. I'm not sure there's much we can do about that, unless we somehow start dropping sprites. I'll have a think - 3D cloud perf has always been a big challenge. Based on my own experiments, I agree. If we have 20 sprites in the cloud and the cloud covers the whole screen, the fragment shader does at last 20 texture lookups per pixel - which are pretty expensive. It's basically the equivalent of rendering the urban effect on the whole screen (anyone here who can do this with good framerates? - I get about 6 fps if I try...) There's one thing we could try which might help a bit - in addition to texture lookup, the fragment shader also fogs the clouds. If we don't do fogging for nearby clouds (i.e. the ones which cover the whole screen), we don't really change the visuals, but save 20+ repetitions of fogging computation. An alternative option would be to not render really close cloud by texture at all (= drop fragments based on a distance cut) and replace them by a procedurally generated pattern. This may be rather tricky to get right, but if the function isn't too complicated, it may be cheapter than to read textures, and we'd get hires closeups as a bonus. Dropping sprites certainly helps, but it takes away the feeling of volume - which is especially important for nearby clouds. :-( * Thorsten * Thorsten -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3d clouds on multi-display systems (was Re: FSWeekend 2012...)
On Fri, 09 Nov 2012 21:08:07 +0100, Torsten wrote in message 509d62a7.7000...@t3r.de: Am 08.11.2012 23:24, schrieb Stuart Buchanan: I'm confused. From my reading of Durk's post, 3D clouds would appear to work fine for a multi-display system out-of-the-box, but your comment here indicates that there is an issue that requires fixing by restricting the random seed. Hi Stuart, just one more note about multi-displays on a single machine: With our four cards driving eight displays at 1600x1200, ..you have 60fps with with one display, with the 8 too? -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3d clouds on multi-display systems (was Re: FSWeekend 2012...)
Am 08.11.2012 23:24, schrieb Stuart Buchanan: I'm confused. From my reading of Durk's post, 3D clouds would appear to work fine for a multi-display system out-of-the-box, but your comment here indicates that there is an issue that requires fixing by restricting the random seed. Hi Stuart, just one more note about multi-displays on a single machine: With our four cards driving eight displays at 1600x1200, the 3d clouds appear seamless across the individual displays and they work fine when clouds are scattered or few and you stay well clear of the clouds. When a cloud starts occupying a big part of one or more screens, there is a massive drop in frame rate, down to unusability. The same hardware runs smooth with 60fps (synced to vblank) in any situation with just a single display. Torsten -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3d clouds on multi-display systems (was Re: FSWeekend 2012...)
On Thu, Nov 8, 2012 at 11:12 PM, John wrote: Yes, your are correct it you run a single instance of fg with three displays with whichever scheme you use; e.g. using the XML file to create a left, center, and right camera for the scene or one of the video splitters to break a single large camera into three channels for each display. However, if you run an instance of fg using, for example, the center as the master FDM, then create two slave fg's using the FDM=NULL option for each left and right instance each instance starts with a different random seed. This occurs whether you run all three instances on a single CPU or, as in our case, each instance on a single core of a multi-core machine since each instance creates it's own scene graph. The advantage of the multi-core machine is performance limited only by the bandwidth of the busses and graphics pipelines and GPUs. have not really drilled down just where or what are the limiting factors using a multi-core machine with multiple video cards; just know it is faster based on fps for each core versus running everything on a single core machine. The disadvantage is many of the dynamic features like clouds, AI traffic, etc are not sync'd across processes. Jan Comans solved the problem by using a *fixed* random seed ( another oxymoron ;-) ) for the 3d clouds at least. As mentioned elsewhere, I've just committed a time-based random seed for cloud generation to fix this in origin/next. Please let me know how you get on. On Fri, Nov 9, 2012 at 8:08 PM, Torsten Dreyer wrote: just one more note about multi-displays on a single machine: With our four cards driving eight displays at 1600x1200, the 3d clouds appear seamless across the individual displays and they work fine when clouds are scattered or few and you stay well clear of the clouds. When a cloud starts occupying a big part of one or more screens, there is a massive drop in frame rate, down to unusability. The same hardware runs smooth with 60fps (synced to vblank) in any situation with just a single display. I think that's just a side-effect of having so many pixels covered by (multiple) quads with alpha. I'm not sure there's much we can do about that, unless we somehow start dropping sprites. I'll have a think - 3D cloud perf has always been a big challenge. -Stuart -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3d clouds on multi-display systems (was Re: FSWeekend 2012...)
Yes, your are correct it you run a single instance of fg with three displays with whichever scheme you use; e.g. using the XML file to create a left, center, and right camera for the scene or one of the video splitters to break a single large camera into three channels for each display. However, if you run an instance of fg using, for example, the center as the master FDM, then create two slave fg's using the FDM=NULL option for each left and right instance each instance starts with a different random seed. This occurs whether you run all three instances on a single CPU or, as in our case, each instance on a single core of a multi-core machine since each instance creates it's own scene graph. The advantage of the multi-core machine is performance limited only by the bandwidth of the busses and graphics pipelines and GPUs. have not really drilled down just where or what are the limiting factors using a multi-core machine with multiple video cards; just know it is faster based on fps for each core versus running everything on a single core machine. The disadvantage is many of the dynamic features like clouds, AI traffic, etc are not sync'd across processes. Jan Comans solved the problem by using a *fixed* random seed ( another oxymoron ;-) ) for the 3d clouds at least. Another approach, perhaps a bit more complicated to make it cross-platform compatible, would be to use shared memory to have one 3d cloud generator as the master and the slaves would simply read the data from shared memory. BTW the warping code will run in a single core machine with multiple displays and the performance hit is minimal. John - Original Message - From: Stuart Buchanan stuar...@gmail.com To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Sent: Thursday, November 8, 2012 3:24:37 PM Subject: [Flightgear-devel] 3d clouds on multi-display systems (was Re: FSWeekend 2012...) On Wed, Nov 7, 2012 at 5:03 PM, John wrote: second, we also run fgfs on a multi-core machine with three graphics cards. Performance is around 50-60 fps for each core. and thanks to Jan Comans the 3d clouds are sync aross all three displays. Hi John, I'm confused. From my reading of Durk's post, 3D clouds would appear to work fine for a multi-display system out-of-the-box, but your comment here indicates that there is an issue that requires fixing by restricting the random seed. Can you explain a bit more about how you are running FG in this instance? In particular are you running multiple instances of the simulator? I _should_ be the case that if you're running multiple cameras on a single scene-graph, the existing code will Just Work. However I've not got the option to test this myself. -Stuart -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
