Re: [Flightgear-devel] FG scam resurfaces...
On 7 February 2012 03:24, Chris Wilkinson wrote: > It is a very mixed bag when it comes to screenshots - some look good, some > look old (bad?), some look fake - surely that would be a give-away to warn > people away from it? :-) > And the 419 Nigerian scams doesn't work. Surely the suggestion of winning X million British Pounds from Microsoft would be a give away? On a serious note, do we know if they have updated "their" product? Or just new and improved packaging? Regards George -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader performance
Thorsten, >> And especially in FGFS not really Vertices is one of the big problems, >> but .xml's and nasal-scripts. >No, you can't say that in general. It quite depends on what you do and >what options you use. Whatever you compute, it costs some amount of >resource, and how long your frame takes is determined by the slowest >element. Gary adressed those creating the 3d-models and aircraft in FGFS. Of course, logically you will always run out of GPU power at a certain vertice count which inludes all vertices (aircraft, terrain, clouds, trees...). But GPU's getting better and better today, but still the shape of the aircraft does not need hundred of vertices to make it look smooth. And yes, terrain itself has a big influence on framerate and perfomance. I can remember very good the time (2006/07 ??) when the first detailed Custom Scenery made by Martin Spott and Ralf Gerlich came out- I noticed a good hit on the frame rate, which was only due the more use of terrain-vertices. But that was with an old one-core processor and a very old GeForce 5200... Today I notice that even increasing the visibility no real framerate hit- even with 120km visibility. But a big increase of RAM-Usage. But again: Gary was talking about 3d-models like aircraft. And that was what I adressed as well. I experimented a bit with the different aircraft, and it always turned out that especially Nasal-scripts, and sometimes some .xml's has an big influence of perfomance. Bigger than an high vertice count. Problem is- this behavior depends a very lot on the hardware. In the forum you will find a very lot of people who seems to have an older computer, or a simple Office-computer with low graphic-perfomance. >But for instance, you told in the forum that you are running a lower than >1 value of cloud density because of performance reasons. Which means that >you are seeing the impact of the 3dcloud vertex shader as limiting factor, >not some Nasal or xml, because what the cloud density slider does is >reduce cloudlet (=vertex) count. GW on the the ocean gives me even with density =1 about 50-60fps (Fair weather)- when I'm inside the clouds and the full screen is covered with cloudlets I get much, much less (about 15-30fps). The limiting factor here seems to me the transparent textures. The LW does use less cloudlets even with density =1, and so less vertices than GW. Still I can see a higher use of CPU and lower Framerates. I can see what you wanted to say me- and I do see, that you have make great work with your Nasal-driven weather-system. You showed what is possible by using Nasal-scripts, and used this in a very intelligent way. >I guess my bottomline is that any code running on a per-frame basis should >be made more efficient when it can be made more efficient, regardless if >it is currently the limiting factor for someone or not, simply because it >may be the limiting element for someone else. Yes. And as Nasal-scripts has a natural limit of perfomance compared to code integrated into Simgear/ Flightgear your work will have much better perfomance if as much as possible has been hardcoded. Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader performance
Hi, On Sunday, February 05, 2012 22:29:18 Heiko Schulz wrote: > Because no one, not Tim Moore, not me, not anyone, did say this! > The wiki article is btw by Tim Moore. > > But they said, that the bottleneck of GPU's is not the vertice count, but > other things. That never meant that you have to use many vertices as you > want. > > "... As many vertices as needed- not more or less!" ACK. Currently OpenGL wise we are basically geometry setup bound - at least for the models. This really means that vertices are not an issue. That still means that for setting up that one draw with 3 triangles is about as heavy as setting up say 500 triangles, but the conclusion of this is *not* that you should schedule as many triangles ass possible. The right conclusion is to collapse as many triangles as *sensible* for culling into a single draw. A simple help is to switch on the onscreen stats in the viewer or flightgear and see if the yellow bar is longer than the orange one. A yellow bar longer than the orange one means that the cpu is not able to saturate the gpu. Again, beware this does in no way mean that you should write complicated shaders to saturate the gpu! This rather means that the geometry setup/state change time - the yellow one - must decrease! How to achieve that is a very long chain of right decisions. Starting with the modeler: Avoid having leaf geometry with very small parts. Collapse as much triangles as sensible for culling into the same leaf geometry. Sure if geometry needs a different texture or anything that requires a different OpenGL state you cannot collapse this into the same leaf. May be it makes sense then to collapse the textures into a common one. Then you might be able to collapse more geometry. Avoid animations that are not really required. If you need a transform node in between some geometry, the geometry below the transform needs to be drawn seperate which takes time on the cpu. Everything that needs geometry to be drawn seperately should be avoided to that level where it stops to make sense because of culling. May be introduce some level of detail. Not just avoid the whole model in some distance, but also provide a static model without animations, simple geometry for the mid range. May be provide some more culling friendly and detaild with the animations you need for the short range. Keep in mind that culling a model that you are close to should make you split the model into more parts that could possibly be culled away. But for culling a far away model is probably very sufficient to cull it either as a whole or not. Avoid state changes. Use as much common state as possible. Osg does a good job in sorting together draws using the same state, but if the overall scene contains plenty of different state osg cannot change that. A new texture is a new state for example. A new shader is a new state. Once your orange bar is longer than the yellow one, you can start to care for the shaders and their execution. When thinking about shaders, keep in mind that different GPU's perform very different on the same shader. Appart from OpenGL we spend a lot of time in scenegraph traversal. This is mostly due to plenty of structural and often needless nodes in the scenegraph. The reason or this is that historically the xml files did some implicit grouping for *every* animation in the xml file. To make that reilably work I had to introduce a huge amount of group nodes in the xml file loader. These really hurt today as they introduce a whole lot of group nodes that just have a single child which need to be traversed for update and for cull. Profiling shows that Group::traverse is the most used function in flightgear. The lowest hanging fruit could be to optimize away the redundant nodes from the top level model that gets loaded by a database pager request. We cannot do that recursively once a model part is loaded since the mentioned grouping nodes might be referenced in any level in the model hierarchy above the currently loaded model. So only the top level model could do this without braking tons of models. And regarding all that, even if your box already is gpu bound this does not mean that other driver/hardware combinations are gpu bound too. Always: As much as needed and as few as possible. Ok, there are plenty of other aspects of performance tuning a scene graph, but these are the ones I think are most important for flightgear as of today. Mathias -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https:/
Re: [Flightgear-devel] FG scam resurfaces...
It is a very mixed bag when it comes to screenshots - some look good, some look old (bad?), some look fake - surely that would be a give-away to warn people away from it? :-) Regards, Chris Wilkinson, YBBN/BNE. From: Frederic Bouvier To: FlightGear developers discussions Sent: Tuesday, 7 February 2012 2:17 AM Subject: Re: [Flightgear-devel] FG scam resurfaces... And they even have an old screenshot of FGSD showing LFPX (the airfield where I used to fly in RL) ROFL -Fred -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel-- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG scam resurfaces...
And they even have an old screenshot of FGSD showing LFPX (the airfield where I used to fly in RL) ROFL -Fred -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG scam resurfaces...
Please refrain from providing real/full links to those websites. You help them getting more exposure on search engines etc. (these mailinglist discussions are available online) Gijs -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG scam resurfaces...
On Mon, 6 Feb 2012, Chris Wilkinson wrote: > http://flightsimulatorplus.com/terms.html > > Seems FSP or PFS or FPS or whatever has reinvented itself - that link > showed on my Facebook page just now for the first time in perhaps 6 > months. > For those of you with YouTube accounts, please search for "flight simulator plus" and flag the videos as scam/fraud and post a comment about how they're selling FlightGear. Jon Stockill(sp?) has some good tips about doing this. :) g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Political correctness is a doctrine, fostered by a delusional, illogical minority, and rabidly promoted by an unscrupulous mainstream media, which holds forth the proposition that it is entirely possible to pick up a turd by the clean end. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FG scam resurfaces...
http://flightsimulatorplus.com/terms.html Seems FSP or PFS or FPS or whatever has reinvented itself - that link showed on my Facebook page just now for the first time in perhaps 6 months. What shits me is that the site shows screenshots from v2.4.0 or from git, as the new shader effects are shown in some. Some others are obvious mock-ups. Once again they state that they provide "world class support", something they claim is absent in the opensource community. I hereby (once again) declare them to be a scourge on this earth, bereft of any decency or humanity, only interested in making a fast buck from the ill-informed or the unsuspecting. Oh well, at least they're still around 12 months behind on the code...if project rembrandt and other new stuff can make it into git then once again fg will stay streets ahead of this imposter, something we should feel free to inform people about via forums, review sites etc... Kind regards, Chris Wilkinson, YBBN/BNE. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader performance
Am 06.02.2012 09:51, schrieb thorsten.i.r...@jyu.fi: > I guess my bottomline is that any code running on a per-frame basis should > be made more efficient when it can be made more efficient, regardless if > it is currently the limiting factor for someone or not, simply because it > may be the limiting element for someone else. My keyboard does not have a big enough '+' key to second that! Torsten -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader performance
> > > Pushing most of the haze shader computation from the vertex to > > > the fragment level would seem to suggest an approximately constant > > > cost for the haze for the same view regardless of scenery complexity > > > since the number of hazy fragments remain about the same. > > > > Thanks for the explanations - that was *really* helpful to > > understand what is going on. > > FWIW, I saw with gDebugger that the sky dome is made of more than > 23000 vertices, even if a small amount of them are really displayed on > screen. > > In Rembrandt, several pass are done on 1/16th of the size of the > screen (1/4th of each dimension), relying on the mag filter to cover the > whole screen. This is the case of the blur pass in the AO or Bloom effects. BTW, in my other terrain engine project, the sky is drawn with a quad (4 vertices at the corners of the screen). The view direction is computed in the vertex shader and then interpolated in a varying and renormalized in the fragment shader. That way there is no wasted computation (except the region overdrawn by the terrain, but that could be optimized with a stencil buffer) -Fred -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader performance
> > Pushing most of the haze shader computation from the vertex to the > > fragment level would seem to suggest an approximately constant cost > > for the haze for the same view regardless of scenery complexity since > > the number of hazy fragments remain about the same. > > Thanks for the explanations - that was *really* helpful to understand > what is going on. FWIW, I saw with gDebugger that the sky dome is made of more than 23000 vertices, even if a small amount of them are really displayed on screen. In Rembrandt, several pass are done on 1/16th of the size of the screen (1/4th of each dimension), relying on the mag filter to cover the whole screen. This is the case of the blur pass in the AO or Bloom effects. Regards, -Fred -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader performance
> Pushing most of the haze shader computation from the vertex to the > fragment level would seem to suggest an approximately constant cost for > the haze for the same view regardless of scenery complexity since the > number of hazy fragments remain about the same. Thanks for the explanations - that was *really* helpful to understand what is going on. I did a quick check pushing everything which is not vector geometry to the fragment shader, and... * below 20 km visibility range or so, the scheme appears to be a bit (~10 %) slower than it was previously as vertex-based rendering * from about 20 to about 120 km visibility range, I had a constant and quite usable framerate around 22 fps for full screen 1920x1200 resolution (I suppose since this goes per pixel, the screen resolution should affect this). * above 120 km, the vertex part seemed to become an issue again and I went down to 15 fps around 200 km visibility range (this is a lot more than I had previously seen for that range) I guess this confirms your scaling prediction. * best part - for most of the range below 100 km visibility range, maxing out the cloud view range to 75 km didn't make a lot of difference for the framerate (apparently plenty of extra capacity for vertex rendering) In summary: 120 km visibility range with clouds drawn to 75 km at 22 fps with terrain haze and sunset effects on in the F-16 at full screen resolution 1920x1200. There seems to be something going into the right direction here :-) Have to test this more systematically, and also see if I can shuffle stuff from the skydome frag part to vertex. * Thorsten -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader performance
On Sun, 5 Feb 2012, thorsten.i.r...@jyu.fi wrote: > > I haven't really seen any guidelines about efficient shader coding, but > I've come across a few statements here and in the forum now and then, > which I so far assumed to be true. I've now spent the last few days > benchmarking my lightfield/terrain haze framework to see if I can't > squeeze a bit more performance out. Since the results somewhat > contradicted things I have assumed to be true before, I thought I might > share my observations. > > 1) vertex shader is fast and efficient, fragment and geometry shaders are > comparatively slow and cost performance Some thoughts here (bearing in mind that I'm no expert on the internals of GPUs): The vertex shader is run for each vertex of the mesh each time it is rendered. The fragment shader is run for each fragment generated from the mesh - if the mesh covers a small part of the screen there will be few fragments - if the mesh covers a large part of the screen there will be many fragments (excluding the early Z-clipping of fragments that some GPUs may do). Some implications: - The amount of vertex shader work (to draw a mesh) ought to increase with the #vertices and the complexity of the vertex shader. For a particular mesh and shader the cost is the same each time it is drawn. - The amount of fragment shader work ought to increase with the #fragments/pixels generated for the mesh and the complexity of the fragment shader. This changes online depending on how many pixels of the screen the mesh covers. So, e.g. for effects used on (MP/AI) aircraft it would seem preferable to push complexity to the fragment shader since, most of the time, most of the aircraft will be very small on the screen. OTOH this would seem to suggest the opposite case for the sky-dome - relatively few vertices and often covering a significant part of the screen. Pushing most of the haze shader computation from the vertex to the fragment level would seem to suggest an approximately constant cost for the haze for the same view regardless of scenery complexity since the number of hazy fragments remain about the same. It would be interesting to see more measurements on this. One could account for the cost of the increased number of processed vertices by using the case with no haze at all as a base line. Cheers, Anders -- --- Anders Gidenstam WWW: http://gitorious.org/anders-hangar http://www.gidenstam.org/FlightGear/ -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader performance
Heiko wrote: > And especially in FGFS not really Vertices is one of the big problems, > but .xml's and nasal-scripts. No, you can't say that in general. It quite depends on what you do and what options you use. Whatever you compute, it costs some amount of resource, and how long your frame takes is determined by the slowest element. I used to develop in a situation in which I was completely driven by the speed at which Nasal scripts executed, i.e. I saw quite drastically the effect of switching certain Nasal scripts on or off. Handing more and more work over to the GPU means that in general things speeded up and I now see the execution speed of the Nasal scripts no longer, but rather I am now completely driven by the speed at which the GPU can do the rendering, and I actually see improvements in framerate by handing computations elsewhere, e.g. to (to be slightly provocative) Nasal. Basically, you want a situation in which all available processing pipelines are equally filled for best performance. Also, if you notice vertex count or not is a question of visibility range. If you're happy with 16 km default visibility, then it's probably not an issue. I used to think 30 km is a hell of a lot, but after having seen how 120 km look from cruise altitude and actually start to compare with real life, I actually want something like 120 km if I can get it. And since terrain vertex count goes with the square of the visibility, this becomes the determining factor rather sooner than later, and scenery models factor into that in a major way. So you can also pretend it's my fault and I'm asking too much visibility range, while all others are happier with 16 km visibility range and hires high-vertex count models (which is probably better for helicopter people :-) ). But for instance, you told in the forum that you are running a lower than 1 value of cloud density because of performance reasons. Which means that you are seeing the impact of the 3dcloud vertex shader as limiting factor, not some Nasal or xml, because what the cloud density slider does is reduce cloudlet (=vertex) count. I guess my bottomline is that any code running on a per-frame basis should be made more efficient when it can be made more efficient, regardless if it is currently the limiting factor for someone or not, simply because it may be the limiting element for someone else. @Stuart: > That's very interesting. Do you have any suggestions for what > information we could push onto the fragment shader? I'm still not sure how well my experiences generalize, but the obvious thing to try bothering the fragment shader with would probably be the bottom and away side shading computation. It probably also depends on what other shaders are running - for me, my terrain-haze is the major player, followed by the 3dcloud whereas skydome uses far less resources. I don't know how the balance is changing if water or urban are on. If any of those makes use of the fragment part more heavily, then shifting more things into there might not be as good. Cheers, * Thorsten -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
