nagging problem with sceneries

[Guest]

Hi - I rendered and sliced entire globe tiles at once (i.e, my Terrascene projects (that I just uploaded BTW) are a whole globe tile each).I haven't had a chance to try moving them all to the shared directory yet, since I was busy with other things today, but I'll try that ASAP and report back.Thanks for the ideas everybody!John/madmax

[MGS 0]

John, the problem is surprising. I've done over 60 globe tiles which load without a hitch--with only a few occassional exceptions, which have been easy to cure (see below), but your problem with quartiles of full globe tiles doesn't quite conform to the few problem behaviors I experienced. From the above, it looks like you used the snap to grid option, so that shouldn't be a problem. Anyway, this may be worth a try: increase the load parameters in the scf files of the problem globe tiles by 1 degree. I have been doing this for all my globe tiles for over a year, and have never have any loading problems or "Can't load texture.." messages since. If it doesn't work, you will not have spent much time trying it out, and you can copy the original scf files back over the modified ones.

[Guest]

Mark - I will certainly try changing the loading params and see if that helps matters any.I am currently (even as I type) trying someone else's suggestion of putting all the sceneries in "shared". Too early to know yet since I just started the flight, but I'll report back on that too.I agree, it's a weird problem. I start to wonder if it might be something in my fly.ini or render.ini that causes the difficulties.Thanks for your idea; it seems promising.

[Guest]

Ha! It's too early to know with 100% certainty, but I moved all my WA sceneries into the shared folder, and took a flight spanning 3 globe tiles. Everything seemed fine - no missing terrain at all. Just pure terrascened airborn bliss.Next question is: why? :) I'm going to try tweaking the loading parameters in the .scf files and see if that buys me anything.This is cool though - the first promising thing so far. I'll try some longer flights later on and see if my luck holds out here.John/madmax*edit* - I forgot to mention that I didn't see any obvious performance issues with moving it all to Shared. I'm sure it only loads the metadata for everything in shared, not the textures themselves, so perhaps it isn't such a bad thing.

[Guest Fly II Pilot]

John:Glad to see it worked! (the signature...) ;-)If you find "the trick" by editing the SCFs let us know.Take care,Alejandro AmigorenaCheshire, CTFly! II Beta Team MemberAthlon XP 1800ABIT KR7A-RAID768Mb RAMMSI GeForce 3 Ti 500 64MBSB Audigy GamerCH Flight Yoke USBCH Pro Pedals USB

[MGS 0]

This is encouraging, because you no longer are using the scf files to load the scenery from the shared directory, and the pods themselves are fine. The problem you are having is with the scf files. I think you can solve that by increasing the load parameters by one degree, which will allow you to place the pods back in the scenery directory.

[Guest]

I'm making my 2nd flight with all the scenery in shared just to verify, (longer this time, around 350 nm) and if it still looks good, I'll have a go at moving the loading bounds inwards by a bit in the SCF files.I'm psyched now - I'm gonna go buy a few terrabytes of disk space and terrascene the entire #$!)@ continential US :)John/madmax

[MGS 0]

John, move the load parameters Out by one degree. Moving them in will not solve the problem. Here, I had a problem with Erie, so now I have 2 degree (rather than one degree margins for loading the globe tile for Erie: ==== BEGIN SCENERY FILE ==== ---- scenery set name ---- erie TerraScene Scenery version x.x ---- coverage area lower left ---- 41 07 08.4 N 80 09 58.3 W ---- coverage area upper right ---- 42 11 53.5 N 78 44 24.0 W ---- load lower left ---- 39 07 08.4 N 82 09 58.3 W ---- load upper right ---- 44 11 53.5 N 76 44 24.0 W ---- pod file ---- erie.pod ==== END SCENERY FILE ====

[Guest]

Erp - out, yes. I knew that, just had a "bad brain moment" :)I have quite a few, so I think I shall write a little emacs lisp gizmo to automate the process.John/madmaxPS - I'm getting a number of crashes to the desktop recently, but I'm thinking that it is because I installed C4TO. I read on here that Flyscripts has some problems with patch 240, so I might back out C4TO and see if it helps that any. It's unfortunate, since C4TO is pretty cool.

[Guest]

I just completed a fairly long flight spanning around 5 or 6 globe tiles. I saw only one missing 1/4 tile the entire way, which is a vast improvement over my non-shared-scenery record of just about every other 1/4 tile missing. So it seems that this almost, but not quite, entirely fixes the problem, and that's good enough I suspect.Tomorrow I'll have a try at the SCF modifications and report back when I have some results on that (and maybe include a little emacs gizmo to automate it, if anybody else wants to use it).John/madmax

[MGS 0]

John, C4TO is great. I haven't used it since the 240 patch, because I had almost no time to Fly much since mid-Dec. I will try it out, but probably won't get a chance until this weekend. Someone else maybe has something to offer on this. By the way, the above problem will not be solved really until you let us know whether the scf fix works.

[Guest Hagar]

Gents-I am quoting Richard here on this important issue.Quote:Here's the skinny on the Shared folder. Any .pod or .epd file put in the Shared folder is auto-mounted when Fly! starts. All shared pod catalogs are stored in RAM for the ENTIRETY of the time Fly! is running, so if these pods have alot of files (particularly scenery files with lots of textures), you are eating memory that can never be recovered. This may not be a big deal with models that use one texture per model, but for TerraScene or similar ground scenery it's deadly, because you can easily have 20K+ or more files per pod, eating a few megs of memory just to store the catalogs in memory.Moving them out of the Shared folder, and providing an SCF file, solves this. Instead of keeping the pod online all the time, Fly! keeps track of the lat/lon boundaries of the scenery area specified in the SCF file. This area should be the maximum boundary of all ground and scenery models included in the scenery area. When you approach this area, Fly! will auto-mount the pod and eat RAM to store the catalogs. But, once you exit the area Fly! will unmount the pod and recover all the RAM. This allows you to store hundreds of not thousands of megabytes of scenery and still travel coast-to-coast without needing 512MB of RAM just to get Fly! up and running.Hope this helps,RichEnd Quote.Personally I use a folder for each Globe Tile, with a scf that loads all scenery and models inside. Guess you could make a folder for each state, maybe. Anyway, what Rich tells us here is so important that I burnt this info to a CD straight away :)

[Guest Colins2]

Andrew,Thanks for reminding us all.This would indicate, perhaps, that Fly! has an error in its memory management code in that it is either not releasing the memory fully and/or it is not storing the catalog properly, or the catalog is overwriting itself at times, hence the 'missing texture' message when the file is plainly there.Unfortunately, if this is the case, I don't see any workaround for it other than loads of ram and moving files in and out of the shared folder as required. Thisn't so daft, ram is absurdly cheap now, much more so then when Fly!2 was released.Just my

[Guest Hagar]

Hi There,Just a reminder. If there is no other workaround, I would do the same off course, buying lotsa RAM >:-)

[MGS 0]

Andrew, thanks for underscoring the consequences of placing them in the shared folder. My goal here all along has been to fix the scf files so the pods will load from the scenery directory. It is nevertheless useful to know that the pods work when they are in the shared directory, because this means there is probably nothing wrong with them and that the problem likely lies with the scf files.