On 11/06/2011 11:43 AM, James Turner wrote: > On 6 Nov 2011, at 09:43, Eric van den Berg wrote: > > >> So we now have a Terragear version that produces nice and more detailed >> terrain, but can only be seen with current GIT flightgear. As the >> fraction of people using older FG versions is large (>95%?...just a >> guess, correct me if you have an accurate number) the current Terragear >> version is not going to find many users. >> >> Is there a way and/or will to fix the current Terragear / Simgear to be >> compatible with 2.4 and lower? >> > Assuming we're only talking about the change to support larger (more > detailed) BTG files, the situation is a little more intelligent, hopefully: > > - current tg/sg write either version '7' or version '10' files. Version 10 > uses 32-bit indices, and will not be read by FG 2.0 or 2.4. But those FG > versions should realise this, and reject loading the BTG file at all, since > they will see version '10' and say, okay, I cannot read this. > Well large files generated by current tg/sg (v10 I guess) are not loaded by 2.0 / 2.4, but hangs FG as well (CPU 100%). This prevents any other tiles from being loaded and from exiting FG the normal way. > - current tg/sg writes version 7 files, *if the data will fit 16-bit > indices*. So, for any tile that would previously have displayed correctly (no > stretching / 'swirlies'), the result with the current code should be the same > - we create a version 7 file, and 2.0 / 2.4 should load it. > Understood. That is why smaller files create no problem at all FG versions... > - I could easily add code, to force version 7, and hence reject 'large' files > which exceed the index limits. However, this will make scenery generation > more difficult, since you only discover the problem at the end of generating > the tile, but to reduce the detail, means changing the input data... > I can already do that I guess, compiling tg with 2.4 sg. But a fgfs-construct --force-version=7 option would be a good idea because most people want their scenery to be able to be used by everyone! An early warning / rejection system '16-bit limit exceeded, reduce input data' (or whatever) would be a good feature also. Or does the message "Degenerate tri!" do this already? > I suspect, people have been generating tiles slightly exceeding the 16-bit > limit, for some time, but not noticing a few stretched textures in a few > tiles, but now the code generates a 'correct', but incompatible BTG, which is > noticeable. > > All of this is how the code should be working - of course there may be bugs :) > > James > Thanks for your answers James!
Eric > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > _______________________________________________ > Flightgear-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > > ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ Flightgear-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/flightgear-devel
