> I see applications that care for stable 60 hz. If you get for one frame > 59 hz they have too much jitter and look for an other renderer. > > What I really do not like is that people purely push in the direction > they just like more.
Beats me when this has ever been a problem. My first contact with FG was with 0.9.1, and I can make today's 2.11 look pretty much the same way at the simple expense of using the rendering GUI and switching eye candy off - which would probably result in something like 500 fps if I wouldn't throttle framerate to vsync (even my old GPU managed 180 fps or so with all eye candy off). There's still the non-shader skydome around, there are 2d clouds around, there's Basic Weather to manage them... it's not like we would discard all the basic options because we now have more shiny ones. (The problem related with that is of course an increased confusion of users with so many 'experimental' and 'legacy' schemes around...) > If you work sensibly, you can support both. If you want > photorealistic pictures use a raytracer or do global illumination and > use a cluster to do the pictures. Well, it would depend on your hardware, no? My GTX 670M delivers me all the terrain details I want with stable 60 hz (as long as I do not use 3d clouds ). > But this is a *training* *flight* *simulation*. And as this having nice > pictures is great to have, but if this is at cost realtime frame rates > this is not acceptable at all. See above - if you don't have the hardware, you can switch it off. I don't think what you say is a real problem in FG development. Some of us just don't think FG has to look like the last 10 years of 3d rendering developments didn't happen or like we all had integrated Intel chipsets. :-) > And no, attacking the big base package by procedural textures > exclusively is something that gets my clear NACK. > If done sensibly, you can do a lot with shaders, and this even can look > way better than a texture. This can be even faster than with textures. If > you work sensibly and also care for performance I am all for this *as* *an* > *alternative*. Seems to me we're not talking about the same thing. 1) all things discussed here are optional - not even regional texturing is a must-have, you can use the old-style scheme if you prefer 2) the question is not 'Do we replace the base package by a completely procedural approach?', the question is 'Do we add different-hued textures to the base package (taking up some disk space unconditionally) or do we do different hues by uniform vectors (taking up performance if someone uses the feature)? 3) we already have procedurally generated water (slower than texture, but better-looking) and snow (faster than superimposed snow texture, and better-looking) - both of which implemented optionally. So it's not like there wouldn't be some experience around :-) > If you want to have a smaller download, you can for example walk all > textures that are in the base package and in the scenery, look if there are > rgba > textures with a constant equal to zero alpha channel. Then for textures > with a needless alpha chanel, replace these with rgb textures. > That would be a simple and effective candidate for improovement. Yeah, except we just decided we want the terrain texture alpha channel to encode autum vegetation color shifts. So we're probably even going to add alpha channels to textures which didn't have one before. Look, personally I don't care at all about adding 10 MB to the download size. I'm trying to be considerate here, I'm trying to find out what others flag as the bottlenecks rather than simply going ahead and doing stuff and being told later 'But you should have considered...' at a point when things can't be changed easily. Unfortunately your feedback isn't really so helpful, because it sums up to 'better graphics cost performance and we don't want to waste it'. I've sort of known that, but I still want better graphics as long as my hardware plays along, and we have to agree to disagree about this direction then. > You could use an other mail for example. > And to me this is *really* annoying. Sorry, it's not meant personally. Believe me, one gets used to it. But having to use another mailer would be annoying for me. * 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/learnnow-d2d _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
