Re: [Flightgear-devel] Base Package size (was 3D clouds)
- Original Message - From: Frederic Bouvier [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 19, 2002 12:21 AM Subject: Re: [Flightgear-devel] Base Package size (was 3D clouds) Here is a large.sky file that fetch field56.cld in Clouds3D (not Clouds3D/SkyClouds, I don't see a need for an additional level) I see your point --- agreed The update to the loader handled the problem wherein the $fg_root was not used to determine the pathname string returned by the archive.getInfo(...) method. Reducing the level should not be a problem. Just say yes. Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Base Package size (was 3D clouds)
Jim Wilson [EMAIL PROTECTED] wrote : My guess is something is messed up in the large.sky file, or how it is picking up the cloud files (the index is probably 0 so the cloud loading loop in the loader isn't being run). When I get a chance I'll try a gdb session, but looking at the large.sky file in cvs I don't see anything that looks like a value for Numfiles (number of cloudfiles under the CloudFiles tag). This might not mean anything as I'm not sure that there even is such a value in large.sky's structure, but like I said the program is acting like it is getting 0 for number of cloud files. Have you set the current directory to $FG_ROOT ? The cloud loader don't prepend the cloud file name with the fg-root path. Cheers, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Base Package size (was 3D clouds)
Frederic BOUVIER [EMAIL PROTECTED] said: Have you set the current directory to $FG_ROOT ? The cloud loader don't prepend the cloud file name with the fg-root path. That was the problem. BTW the failure to find a cld file isn't being returned by the function. Now that it is working, the current code/method is a bit too heavy on my 32mb geforce2. Dropping down to 640x480 improves the frame rate to a useable level...but...well...that's an area for improvement :-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Base Package size (was 3D clouds)
What I meant is to only keep $FG_ROOT/Clouds3D/large.sky and $FG_ROOT/Clouds3D/field56.cld Right, thats what I thought you meant. I was talking about the other files in that directory. I know that field56.cld is the only file currently referenced in large.sky, but I'd still rather wait a little. Yes, might be useful down the road to keep the other cloud 'scripts' Okay, I sent an update of the loader to Curtis which hopefully cleared up some of the problems with the file names. The new loader allows you to place the base directory wherever you please as in: /my/favorite/place/FlightGear. Now large.sky should be at the FlightGear level and Data can be renamed to whatever. The suggestion Fred made for Clouds3D seems like an execellent choice provided the name in large.sky is changed to /Clouds3D/SkyClouds/field56.cld. this should be usable until we get around to rewriting the loader to remove all file pathname references from the file itself. You should be able to run from any location as long as your $fg_root is set to /my/favorite/place/ Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Base Package size (was 3D clouds)
John Check [EMAIL PROTECTED] wrote : On Tuesday 17 September 2002 2:53 am, Frederic Bouvier wrote: It also seems that only Data/SkyClouds/field56.cld is needed. I tried to remove the other files and it works. Let me try it... Yes, that seems to be the case. I'm going to hold off for now because we might need them later. field37.cld and valley.cld are ~5.5Mb combined and the cloudNN.cld ones are mostly 100k. I'm guessing that those of us with slow connections have them by now, so theres no point in (potentially) inflicting the same pain twice. The large.sky format is straightforward. It is easy to edit with a bin editor. We can easily change the path where the files are. For example, Clouds3D would be wiser than Data/SkyClouds. Just tell me and I will make the change. I just had a look with khexedit. Do we really want those in a top level dir? Let's see what everybody else has to say, then we can move 'em. What I meant is to only keep $FG_ROOT/Clouds3D/large.sky and $FG_ROOT/Clouds3D/field56.cld Cheers, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Base Package size (was 3D clouds)
On Tuesday 17 September 2002 5:58 am, Frederic BOUVIER wrote: John Check [EMAIL PROTECTED] wrote : On Tuesday 17 September 2002 2:53 am, Frederic Bouvier wrote: It also seems that only Data/SkyClouds/field56.cld is needed. I tried to remove the other files and it works. Let me try it... Yes, that seems to be the case. I'm going to hold off for now because we might need them later. field37.cld and valley.cld are ~5.5Mb combined and the cloudNN.cld ones are mostly 100k. I'm guessing that those of us with slow connections have them by now, so theres no point in (potentially) inflicting the same pain twice. The large.sky format is straightforward. It is easy to edit with a bin editor. We can easily change the path where the files are. For example, Clouds3D would be wiser than Data/SkyClouds. Just tell me and I will make the change. I just had a look with khexedit. Do we really want those in a top level dir? Let's see what everybody else has to say, then we can move 'em. What I meant is to only keep $FG_ROOT/Clouds3D/large.sky and $FG_ROOT/Clouds3D/field56.cld Right, thats what I thought you meant. I was talking about the other files in that directory. I know that field56.cld is the only file currently referenced in large.sky, but I'd still rather wait a little. Cheers, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Base Package size (was 3D clouds)
Jim Wilson [EMAIL PROTECTED] said: When I start up with the magic carpet and asl 4000ft it looks like my position is exactly the same as Norman's, but I don't see anything. If I rotate to approximately 9 o'clock the cartesian axes are there. Just poking around at the edges with the clouds that still don't show, I noticed that large.sky is being accessed, but the Data/SkyClouds/field56.cld file is not. Running with everything up to date, the usual suspects (file name capitalization, perms, etc) have been checked. Anyone else seen this? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Base Package size (was 3D clouds)
- Original Message - From: Jim Wilson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, September 17, 2002 4:18 PM Subject: Re: [Flightgear-devel] Base Package size (was 3D clouds) David Megginson [EMAIL PROTECTED] said: Jim Wilson writes: Just poking around at the edges with the clouds that still don't show, I noticed that large.sky is being accessed, but the Data/SkyClouds/field56.cld file is not. Running with everything up to date, the usual suspects (file name capitalization, perms, etc) have been checked. Anyone else seen this? For me, the clouds become untextured when I get close, then opaque white boxes when I get a little closer. They look nice at a distance, at least sometimes. I'm still not seeing anything except those three lines. It's seems as though it has something to do with the cld file not being read. Check the boolean property sim/rendering/clouds3d in the pull-down menu. If it is false the load failed. Also if you watch the init sequence there should be a string of msgs right after the materials/textures load that show the clouds loading Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Base Package size (was 3D clouds)
- Original Message - From: David Megginson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, September 17, 2002 4:15 PM Subject: Re: [Flightgear-devel] Base Package size (was 3D clouds) Jim Wilson writes: Just poking around at the edges with the clouds that still don't show, I noticed that large.sky is being accessed, but the Data/SkyClouds/field56.cld file is not. Running with everything up to date, the usual suspects (file name capitalization, perms, etc) have been checked. Anyone else seen this? For me, the clouds become untextured when I get close, then opaque white boxes when I get a little closer. They look nice at a distance, at least sometimes. Might try something like the following in main.cxx: glEnable(GL_TEXTURE_2D); after the menu section around line 805 and comment out the glBlendFunc(..) @ line 803. that might help. Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Base Package size (was 3D clouds)
John Wojnaroski [EMAIL PROTECTED] said: Check the boolean property sim/rendering/clouds3d in the pull-down menu. Checked that first, it shows as true. If it is false the load failed. Also if you watch the init sequence there should be a string of msgs right after the materials/textures load that show the clouds loading Actually it comes in right after initializing the environment subsytem. I am seeing no output at all on the log between initializing the enviroment subsytem and the navaid/fix init that comes after the 3d cloud init (see line 900 in fg_init.cxx). I know the loader is being called, because the last used date is getting touched on the large.sky file. And I know the loader is returning success because the clouds3d property is remaining true. My guess is something is messed up in the large.sky file, or how it is picking up the cloud files (the index is probably 0 so the cloud loading loop in the loader isn't being run). When I get a chance I'll try a gdb session, but looking at the large.sky file in cvs I don't see anything that looks like a value for Numfiles (number of cloudfiles under the CloudFiles tag). This might not mean anything as I'm not sure that there even is such a value in large.sky's structure, but like I said the program is acting like it is getting 0 for number of cloud files. Best, Jim Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Jim Wilson - IT Manager Kelco Industries PO Box 160 58 Main Street Milbridge, ME 04658 207-546-7989 - FAX 207-546-2791 http://www.kelcomaine.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
