Re: [Flightgear-devel] Goals for the 3.0 release
What's the a / b performance impact? All to be taken with some caution, since it seems to be very hardware dependent how expensive certain options are. For my new GTX 670M, I can't measure performance without external tools because any terrain is always rendered with vsync of 60 fps, and only the presence/absence of cloud layers in the scene decides my in-sim framerate. All performance benchmarks I have done are thus with my old 8600M. Here, the classic suite of effects had some incredibly expensive candidates - landmass drove me consistently from 50 to ~10 fps, so I never used it. I think there's a geometry shader somewhere... Apart from that, I'd say that the costs of a) and b) are approximately comparable (which might look a bit surprising at first). For instance, in the classic effects, snow is done loading a noise and a snow texture. On the 8600M, a texture2D() lookup was very expensive, each taking about 10% of the base framerate. On this machine, creating snow procedurally (i.e. doing noise and texel by function rather than texture) is about twice as fast than in the classic scheme by texture. Also, a texture _has_ to be loaded regardless if you actually need it for a pixel or not, so you pay the price for looking up the snow texture regardless if you have any snow in the scene or not. A function can be evaluated conditionally, i.e. you pay only if you actually have snow in the scene - you can condition on a trivial snow pixel 500 m below the snowline. So despite the fact that the procedural snow offers more options (non-tiling distribution, user-controlled layer thickness) it turns out to be slightly faster than the classic option even in completely snow-covered scenes. Similarly, the terrain roughness is based on a very cheap technique creating an optical illusion rather than a proper heightmap (which is probably ~50 times faster than the detailed heightmap technique used for the urban effect) - so it allows to get a lot more bang for the buck provided you're willing to overlook the occasional inconsistency (this is a bit like with the 3d clouds - if you try really hard, you can see them rotate and deduce how it's done - but you have to go looking for it, it won't jump out). From you screen shots it seems like it ought to be scalable, since we could enable certain aspects (grain, bump-mapping) based on a performance / quality slider, while still having a single approach. Well, yes, in theory... In practice, you may be forced to create a different effect and shade fordifferent quality settings. if() statements inside shader code are very tricky - you might easily end up evaluating both branches. For instance, in theory (=according to the specification) texture lookup can be conditional on uniforms. In practice, on my box I found that this works only for uniform int, not for uniform float - for an uniform float, always both branches were evaluated. I have also no idea how, say, Radeon drivers respond to the same design - they may have a completely different strategy evaluating branches... Which means in practice, you get to see the lower quality as indicated by the slider, but the framerate isn't any better than with high quality. So you can not easily design a shader which takes quality levels from the gui and just enables what you like - if you're careful in designing it, it works up to a point, but eventually no longer. There's a reason why terrain-haze.frag, terrain-haze-detailed.frag and terrain-haze-ultra.frag are different files... So this has to be designed carefully up-front. * Thorsten -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Goals for the 3.0 release
On 30 Dec 2012, at 08:55, Renk Thorsten thorsten.i.r...@jyu.fi wrote: What's the a / b performance impact? snip Similarly, the terrain roughness is based on a very cheap technique creating an optical illusion rather than a proper heightmap (which is probably ~50 times faster than the detailed heightmap technique used for the urban effect) - so it allows to get a lot more bang for the buck provided you're willing to overlook the occasional inconsistency (this is a bit like with the 3d clouds - if you try really hard, you can see them rotate and deduce how it's done - but you have to go looking for it, it won't jump out). Thank you for your response, it's extremely informative for me, as someone who knows a bit about shaders, but has not written many 'real' ones. Everything you describe makes sense, especially the tradeoff between 'real' lookups vs procedural data. And the cost of always doing texture lookups, eugh. We have to accept some inconsistencies if we want even vaguely tolerable performance, and pretty much everything you said convinces me we should switch to the 'b' approach, or family of them (see below), as the default option after 2.10, to get as much test and feedback as possible before 2.12. (But keep the current 'a' terrain effects as a GUI option) If anyone during that time-frame finds a serious area where the 'a' approach is better, there will hopefully be time to address it, so that by the time 2.12 is code-frozen, the 'a' effects can be removed (and the GUI switch). How plausible does that sound? So you can not easily design a shader which takes quality levels from the gui and just enables what you like - if you're careful in designing it, it works up to a point, but eventually no longer. There's a reason why terrain-haze.frag, terrain-haze-detailed.frag and terrain-haze-ultra.frag are different files... So this has to be designed carefully up-front. Indeed - what we'd really like (and what some other systems have) is a pre-processors to adjust the shader body before compilation. So would could #ifdef out certain pieces, but still have one shader codebase. Though I guess we'd still need different effect files … h - not really feasible I guess. I guess until there's some wider feedback and testing of the new effects, to see if there are in fact any cases where the performance drop is unacceptable, we don't know how many simplified variants are needed. Hopefully it's just one, i.e 'full quality' and 'reduced quality'? Or at worst three - low, medium and full? But that's still unpleasant to maintain :( James -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Goals for the 3.0 release
Stuart, one thing that caught me out earlier today with using 2D cloud layers - while using a 2D layer and modifying visibility inside the layer is working quite well, the edge (moving vertically) is very sharp. I wonder if there's some technique to perturb the top and bottom of the cloud layer as the view transitions them, so it feels more natural. Or maybe there's even better ways to handle overcast / broken layers than the current 2D approach? I've done some experiments in that department when I started on clouds. It doesn't help you to actually perturb the sheet, because what you want is a fluffy appearance of the cloud fading into the sky, whereas if you introduce more vertices into the sheet and randnomize them, you get a sharp line separating cloud and sky. There are two techniques which probaby do work. They're based on projecting the view integral through the upper (lower) edge of the cloud layer onto something. The easiest would be to simply paint it on the skydome, but I guess that requires that the skydome is done in a shader, not in the default scheme. The alternative is to introduce a faraway quad which you just keep at the same distance from the plane onto which you paint the cloud edge. I'm not sure how this quad would best be moved and transformed. The skydome technique would be fairly trivial, all it requires is to match colors with the layer correctly (which is a problem in its own, because the 2d clouds do not seem to participate in scene lighting properly). * Thorsten -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122912 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Goals for the 3.0 release
Perhaps we could use something similar for the trees? I.e. pass in a uniform indicating which fraction of the texture sheet on the x-axis should be color-rotated. The uniform can be taken from a property on the material definition. Ah, that's clever - I think that would do just fine. Thanks! As part of that I think I need to make some changes to the Basic Weather to populate the appropriate properties. Thorsten - are the properties documented anywhere? No, not really :-( But I can write a summary for you. I'm very keen that the atmospheric light scattering and procedural effects are merged fully into both the classic and Rembrandt renderers, and would absolutely be part of any team effort to make it happen. I'd really like to get to a position where the Atmospheric Lighting checkbox in the Rendering dialog can be removed, as the elements of the atmospheric renderer are simply part of the classic and Rembrandt rendering schemes. I'm not sure if that is a good idea. Even the 'bare' atmospheric scattering (just atmosphere and light, no terrain shader effects) has a drastic performance impact on older systems as compared to the classic scheme (on my old system, it brought me from ~50 to ~20 fps). So we might want to continue offering a computationally cheap rendering scheme, which the classic is. Then, there are genuine differences in the philosophy of some effects, in which alternatives are now available. Personally I'm not a fan of the classic landmass and slope/inverse slope transition effects - so I introduced something else. This can't easily be 'merged' - either we abandon one set of effects (but then, there are people who like the other set) or we make them available as alternatives - in which case you end up with a different checkbox. Most of the procedural texturing is quite distinct from the atmospheric light scattering part, and it's also easily separable - so implementing the terrain effects in classic or Rembrandt should be fairly easy if that is desired. I guess we need to discuss just what we want to impement: Based on how we do the light, we have 1) Rembrandt (multiple light sources) 2) Atmospheric light scattering (only one light source, but with position/time differential light computations) 3) classic (only one light source computed for the whole scene) 4) a future Rembrandt + atmospheric light scattering (time/position differential light computations for the sun + multiple secondary light sources) Based on how we render terrain we have a) the classic set of effects (slope transition, landmass,...) b) the procedural texturing set of effects (de-tiling, hires overlay, dust/autumn/vegetation..., closeup bumpmapping, grain overlay,...) That gives all in all 8 possible rendering frameworks, out of which currently 1a), 2b) and 3a) exist. I was talking about creating 4b) (or maybe 4a) ) - you seem to have something else in mind (?) - AI Tanker enhancements to allow users to select from a range of tanker models. This is particularly relevant for naval probe-equipped aircraft, where there is a much greater variety of tanker types. Could we also tighten the envelope in which we receive fuel? I did AAr with the F-16 yesterday, and my tanks were basically full by the time I had reached the actual refueling position... I started getting contact ~50 m away from the tanker ?! * Thorsten -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122912 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Goals for the 3.0 release
On 29 Dec 2012, at 09:03, Renk Thorsten thorsten.i.r...@jyu.fi wrote: I guess we need to discuss just what we want to impement: Based on how we do the light, we have 1) Rembrandt (multiple light sources) 2) Atmospheric light scattering (only one light source, but with position/time differential light computations) 3) classic (only one light source computed for the whole scene) 4) a future Rembrandt + atmospheric light scattering (time/position differential light computations for the sun + multiple secondary light sources) Based on how we render terrain we have a) the classic set of effects (slope transition, landmass,...) b) the procedural texturing set of effects (de-tiling, hires overlay, dust/autumn/vegetation..., closeup bumpmapping, grain overlay,...) That gives all in all 8 possible rendering frameworks, out of which currently 1a), 2b) and 3a) exist. I was talking about creating 4b) (or maybe 4a) ) - you seem to have something else in mind (?) What's the a / b performance impact? From you screen shots it seems like it ought to be scalable, since we could enable certain aspects (grain, bump-mapping) based on a performance / quality slider, while still having a single approach. The de-tiling makes a massive visual improvement, and the vegetation changes would be great too - especially with more work on regional textures. James -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122912___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Goals for the 3.0 release
On Sat, Dec 29, 2012 at 9:03 AM, Renk Thorsten wrote: As part of that I think I need to make some changes to the Basic Weather to populate the appropriate properties. Thorsten - are the properties documented anywhere? No, not really :-( But I can write a summary for you. If you have the time, that would be great, I guess I can probably guess by going through all the effects files in turn and tracing properties through uniforms, but getting it straight from the horses mouth would be more efficient. I'm very keen that the atmospheric light scattering and procedural effects are merged fully into both the classic and Rembrandt renderers, and would absolutely be part of any team effort to make it happen. I'd really like to get to a position where the Atmospheric Lighting checkbox in the Rendering dialog can be removed, as the elements of the atmospheric renderer are simply part of the classic and Rembrandt rendering schemes. I'm not sure if that is a good idea. Even the 'bare' atmospheric scattering (just atmosphere and light, no terrain shader effects) has a drastic performance impact on older systems as compared to the classic scheme (on my old system, it brought me from ~50 to ~20 fps). So we might want to continue offering a computationally cheap rendering scheme, which the classic is. We'll still offer the computationally cheap rendering scheme - that's what setting the quality slider to 0 should be for Then, there are genuine differences in the philosophy of some effects, in which alternatives are now available. Personally I'm not a fan of the classic landmass and slope/inverse slope transition effects - so I introduced something else. This can't easily be 'merged' - either we abandon one set of effects (but then, there are people who like the other set) or we make them available as alternatives - in which case you end up with a different checkbox. I must admit that I'd forgotten about the landmass shader. I never have it switched on as it's incompatible with the object/vegetation masking which I value more. it does handling tiling artifacts very well, but perhaps we can address them with the work you've been doing? Out of interest, do lots of people on this list use the landmass shader? For the slope/transition effects we should settle on one version and remove the other. I suggest you write a summary of the advantages of yours, along with some comparison screenshots, and if anyone wants to argue the other way they can do the same. I guess we need to discuss just what we want to impement: Based on how we do the light, we have 1) Rembrandt (multiple light sources) 2) Atmospheric light scattering (only one light source, but with position/time differential light computations) 3) classic (only one light source computed for the whole scene) 4) a future Rembrandt + atmospheric light scattering (time/position differential light computations for the sun + multiple secondary light sources) Based on how we render terrain we have a) the classic set of effects (slope transition, landmass,...) b) the procedural texturing set of effects (de-tiling, hires overlay, dust/autumn/vegetation..., closeup bumpmapping, grain overlay,...) That gives all in all 8 possible rendering frameworks, out of which currently 1a), 2b) and 3a) exist. I was talking about creating 4b) (or maybe 4a) ) - you seem to have something else in mind (?) I'm thinking of 2b and 4b, but using the quality slider properties such that a quality=0 is the same as 3a. As James has said - we should be able to make this scalable. - AI Tanker enhancements to allow users to select from a range of tanker models. This is particularly relevant for naval probe-equipped aircraft, where there is a much greater variety of tanker types. Could we also tighten the envelope in which we receive fuel? I did AAR with the F-16 yesterday, and my tanks were basically full by the time I had reached the actual refueling position... I started getting contact ~50 m away from the tanker ?! I was already planning to make the refuelling point configured on a per-tanker basis, as obviously different aircraft have different (sometimes multiple) refuelling positions. It sounds like it would be worth having a slide to allow the user to configure how large the envelope is as well. -Stuart -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122912 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Goals for the 3.0 release
- AI Tanker enhancements to allow users to select from a range of tanker models. This is particularly relevant for naval probe-equipped aircraft, where there is a much greater variety of tanker types. Could we also tighten the envelope in which we receive fuel? I did AAR with the F-16 yesterday, and my tanks were basically full by the time I had reached the actual refueling position... I started getting contact ~50 m away from the tanker ?! I was already planning to make the refuelling point configured on a per-tanker basis, as obviously different aircraft have different (sometimes multiple) refuelling positions. It sounds like it would be worth having a slide to allow the user to configure how large the envelope is as well. a slider seems good to me, as the code is used for the mp tanker too, and i think the box was done this size to allow mp refueling with some jitter effects. jano -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122912 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Goals for the 3.0 release
On Fri, Dec 21, 2012 at 12:06 PM, Renk Thorsten wrote: It has emerged from forum discussions that gathering the goals for developers so that people can synchronize efforts better and users know what to expect would be a good idea. I've sort of been trying to do that previously, so I might as well continue, even if it's a bit early and 2.10 isn't rolling out yet. My project goals till a 3.0 release are: * Get a high-quality model shader running under Atmospheric Light Scattering Pretty straightforward, has been requested a number of times, it's on the agenda and I hope to have it in the next month That's great news, and feeds into one of my goals (see below). * Implement a scheme for generating autumn colors procedurally I'm currently on that by encoding the amount of autumn color rotation in the texture alpha channel - some proof of principle here: http://www.flightgear.org/forums/viewtopic.php?f=47t=18580 There are still open questions how to do trees efficiently (I would like to switch to the autumn version of trees at some point, but I don't know how to do this without always loading both sheets. It'd be way more efficient to simply color-rotate the tree texture sheet, but then I don't know how to discriminate needle trees on the mixed forest sheet) and lots of detail work needs to be done, but I expect that we'll soon be able to generate lots of different seasonal and environment-influenced themes from the same basic texture set. It'll never be as good as creating dediicated autumn textures, but... it smoothy interpolates between summer and autumn. One idea I used with the 3D clouds was to use the position of the texture in the texture sheet to encode additional information. In that case, cloud textures at the bottom of the sheet are used for the bottom of the clouds. Perhaps we could use something similar for the trees? I.e. pass in a uniform indicating which fraction of the texture sheet on the x-axis should be color-rotated. The uniform can be taken from a property on the material definition. * Atmospheric light scattering and Rembrandt After thinking about this for a while, I have decided that I am definitely not going to do this on my own. Being maintainer of one major rendering scheme and one weather system is quite enough to keep me busy, and it's not something which is very close to my heart. However, if there is a decision that there is going to be a team effort making this work, I will join it and do my part. I'm very keen that the atmospheric light scattering and procedural effects are merged fully into both the classic and Rembrandt renderers, and would absolutely be part of any team effort to make it happen. I'd really like to get to a position where the Atmospheric Lighting checkbox in the Rendering dialog can be removed, as the elements of the atmospheric renderer are simply part of the classic and Rembrandt rendering schemes. As part of that I think I need to make some changes to the Basic Weather to populate the appropriate properties. Thorsten - are the properties documented anywhere? Other than that I don't have any significant plans for the next release, though I do have some small projects in mind: - Improvements to the A-4F - Improving random building placement. While it looks OK for towns, buildings aren't placed very well in cities. - AI Tanker enhancements to allow users to select from a range of tanker models. This is particularly relevant for naval probe-equipped aircraft, where there is a much greater variety of tanker types. -Stuart -- Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Goals for the 3.0 release
On 28 Dec 2012, at 21:40, Stuart Buchanan stuar...@gmail.com wrote: I'm very keen that the atmospheric light scattering and procedural effects are merged fully into both the classic and Rembrandt renderers, and would absolutely be part of any team effort to make it happen. I'd really like to get to a position where the Atmospheric Lighting checkbox in the Rendering dialog can be removed, as the elements of the atmospheric renderer are simply part of the classic and Rembrandt rendering schemes. As part of that I think I need to make some changes to the Basic Weather to populate the appropriate properties. Thorsten - are the properties documented anywhere? Other than that I don't have any significant plans for the next release, though I do have some small projects in mind: - Improvements to the A-4F - Improving random building placement. While it looks OK for towns, buildings aren't placed very well in cities. - AI Tanker enhancements to allow users to select from a range of tanker models. This is particularly relevant for naval probe-equipped aircraft, where there is a much greater variety of tanker types. Stuart, Thorsten, your respective goals sounds great to me. As always, if there's any help you'd like, just ask. And I absolutely agree with getting rid of confusing checkboxes by making features 'just work' - especially something that works as nicely as the atmospheric effects. Stuart, one thing that caught me out earlier today with using 2D cloud layers - while using a 2D layer and modifying visibility inside the layer is working quite well, the edge (moving vertically) is very sharp. I wonder if there's some technique to perturb the top and bottom of the cloud layer as the view transitions them, so it feels more natural. Or maybe there's even better ways to handle overcast / broken layers than the current 2D approach? James -- Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Goals for the 3.0 release
Hi Thorsten, De : Renk Thorsten thorsten.i.r...@jyu.fi Envoyé le : Vendredi 21 décembre 2012 13h06 It has emerged from forum discussions that gathering the goals for developers so that people can synchronize efforts better and users know what to expect would be a good idea. I've sort of been trying to do that previously, so I might as well continue, even if it's a bit early and 2.10 isn't rolling out yet. Not only should the roadmap is a good idea, but I think it's just something essential for core dev of opensource projects: - this can help make converge things devs are planning/willing to do next and things users are looking for; - this is a good public communication plan; - this helps triaging between what would make a 2.12 and what would make a 3.0; - this is essential to make devs focus on the same features, as some feature enhancements need a few devs to work together to be achieved. Your plans for 3.0 sound great. Olivier -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
