> -----Original Message----- > From: Mathias Fröhlich [mailto:mathias.froehl...@gmx.net] > Sent: 29 December 2011 20:04 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] Improving random trees & buildings > > > Vivian, > > On Thursday, December 29, 2011 17:36:24 Vivian Meazza wrote: > > I don't fully understand the point - we're not using .dds, and fancy > shaders > > as the default option - what else isn't working with open source > drivers? > > Well, the default f16 does not work anymore for example. > I have also never tried the new textures, but I assume that these also > contain > precompressed data? Also you claimed that the old texture files start to > bitrot > comared to the new ones which makes me think that the new standard should > be > the dds files. This together makes me think that the dds files should > replace > the traditional image files.
Yes - the new textures do contain pre-compressed data. Emilian is the driving force behind the new .dds terrain textures, and some of the features he has used cannot (as I understand it) be back-ported to png textures. So yes, there would be merit in making the dds terrain textures the default, but since we were aware of at least some of the problems this might cause we made it a switchable option. > > > FlightGear should be working just as it always was. Those unable or > > unwilling to use closed source or fully compliant drivers just don't get > to > > see some of the fancier eye-candy, but that should be all. > Well, the drivers are fully compiant. And if compliance would be a problem > I > would rather improove the driver than raise this at an application level. > > These kind of precompressed images limits their usage to a specific set of > drivers. And no, due to the patent issues no open source code including > ours > is allowed to implement compression/decompression code for these image > formats. Even if this is easy implementation wise. > > > > So, I think the mipmap generation hangs with the nvidia drivers are a > > > serious > > > problem. But just limiting everything to the use of exactly this > driver > > > where > > > this problem is worst cannot be a valid answer. > > > > I haven't see such a problem - now I will look for it. The hangs are caused by mipmap generation on the fly by OSG? > Ok, for that you might need to understand that the reason for Erik to use > the > dds files for the f16 is that they appear to improove the hangs that occur > with > ati and nvidias drivers on mipmap computation. I would expect that. Of course, dds should improve the situation. > Which means either use the f16 together with the closed source stuff or > don't > use the f16. > > This is as of today *practically mutually exclusive*. That isn't the only solution - it is not difficult to provide an F16 with png texures and one with dds, allowing the user to select which one is most suitable. Not ideal, but a workaround > > > I would like to have a flightgear that is by default just running on > > > every average system. Having this run faster on a special configured > > > system with some > > > better configuration options and hand tuned hardware and drivers is > very > > > fine. > > > But without tuning it must at least work in an acceptable way. > > > > It should - and I thought it did - I see no problems here with shaders > off > > and using the default materials.dds - where is the problem? > > As long as all is optional, the 'old stuff' is not bitrotting and as long > as > the usual model still work, this should not be a huge problem. > > I already told, I can tolerate not having the f16 - that would be sad, but > ok > - but if the same happens with the majority of our texture files, I would > object. The old texture files are static and I would expect them to work into the future, but the new dds textures will leave them further behind as work progresses. The only problem in htat is that some users will lose out on some eyecandy - it will not affect the basic operation of the sim. > And this is what I try to do now: > Object against using these patented compression algorithms. > I do not care for the on disk format of any image file we have. But the > problem > is that some kind of precompression that can be stored in these dds files > cannot be used with other drivers than the closed ati and nvidia ones. > As long as these patented compression techiques are not used, every OpenGL > driver can use this and displays this fine. > > Think: Intel has the hugest marketshare in graphics today. If I remember > right, they sell more than ati and nvidia together (*). This kind of > change in > effect rules out the majority of users as intel cannot work with these > files. > > (*) There are several statistics out there, this is the intel one that > counts > all sold computers. AMD does usually counts the revenue made with graphics > boards (where ati wins I believe) or nvidia that usually limit statistics > to > professional systems (where nvidia wins). > ... or something along the lines - you get the idea. > > > > I have checked in a change to flightgear to make the use of the > > > compressed internal formats a starttime configuration option. > > > I am still interrested if we have that hangs also with texture > > > compression disabled and without providing precompressed dds textures? > > > > Yes - good idea - I'm using that now - unfortunately my system was > working > > just fine before so it might be a little hard to see if there is any > effect! > > I'm not entirely clear what bug this fix is trying to solve. > > You do not experience any hangs? None that I have seen so far > What is the motivation for you to use dds files? It's a better way of storing cubemaps for reflections or other layered images. The built in mipmap OSG algorithm is a bit slow - using dds works around this (for some systems) > What do you gain by not using the usual image files? Dds textures remain in video memory, so we get improved performance when switching textures. We expect that at least some people will see smoother performance when loading scenery textures. I haven't been able to measure any gain, but there are some have reported that they see a subjective improvement. > The motivation behind this mentioned change is to sort out the best > compromise > so that the hangs hopefully disappear - which I hope to get with > precomputed > mipmaps - and being able to display fine with any driver/gpu. Seems to work here - I have tried --prop:sim/rendering/texture-compression="dxt5" I hope that is the right syntax - no warning from fg anyway. I don't see any problems with running the F16 using that. I might be entirely wrong of course. Anyway, thanks for your clear explanation, Regards, Vivian ------------------------------------------------------------------------------ Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
