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
[Flightgear-devel] Add/Set properties to/in MP Protocol
Just my dime to it, as the regular ATC at EDDF (+triangle): It is correct: A (nearly) realistic ATC'ing is only possible with FGCOM - and a nice effect of ATC'ing is, that people visiting us more often mostly switch to FGCOM -- except girls: Obviously we need a Synthesizer that can transform girls voice to male!! As an ATC you endure already a lot of bad language - for a girl it just seems to be not advisable at all to reveal that they are girls!!! But to get people convinced to use/install FGCOM you first have to attract them - and for that you need MPchat. Also you need it to contact all pilots passing by in a normal, playing, non controlled, standard FGFS mode! You will never get ALL pilots (newbies or not) to switch frequencies every few minutes to make sure they notice an ATC trying to get their attention! Pilots do not do that in the real world either! So we do need MPchat - at least to tell those fun-pilots that there is an ATC and what is the FGCOM-frequency!! So I would not change the MPchat-mode of operation - even so it truly is a real pain when in the triangle up to 4 ATCs are talking to pilots being in MPchat-range of all 4 ATCs. On the other hand it is the very best propaganda for FGCOM. An even better propagation would be the integration of FGCOM-CODE into the FGFS release -- why can only OSX do that? All the best for FGCOM/MPchat/FGFS in the NewYear and to all of you jomo -- 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
