Re: [Flightgear-devel] Is this usefull for flightgear/jsbsim?
Erik wrote: This still might be useful if you can get all the moments and coefficients from it. Then you would be able to create a JSBSim configuration file from the model geometry. The idea of using the gfx model you need to do anyone (or one of the thousands or ten thousands you find on the internet) and automatically get the config file. It would not matter if it takes over night or even if it takes a week. However, CFD programs need a watertight geometry. I would guess that far in excess of 90% of models are not. For example, each edge needs to have two neighbour faces. Erik Bye bye, Wolfram. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] are we switching from blender to ac3d?
David wrote: As long as we're just doing textured and tinted meshes, with the more complex stuff (like animations) in external XML files, is there any good reason *not* to go with VRML, especially since we can compress the files on disk with gzip? Do you completely hand edit the XML? Do you plan to keep it that way? All the best, David Bye bye, Wolfram. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] are we switching from blender to ac3d?
Curt wrote: I believe the main issue is that whatever format we go with has to have a good plib/ssg loader for it. Yes, if you standardise on one or two standard formats, the PLIB loader will be important. In fact, it seems like all the plib loaders (except for the ad/ssg loaders) have show stopping problems in places. Have you looked at ASE, OBJ and .X (in addition to AC3D)? Also, there is a new *.asc loader. BTW, all 3D models for a forthcoming commercial flight sim have gone through the ASE loader. I am working on animations for it right now. It currently works almost always :-/. The sim is called Battle of Britain 2 Wings of Victory :-/. Curt. Bye bye, Wolfram. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] are we switching from blender to ac3d?
Curt wrote: .ssg is extremely non portable, and would make it very difficult for people to edit the models with any non-plib based modelers, and I'm not aware of any plib-based modelers that are far enough along to be useful. ... as modelers, correct. However, PPE is nice as a converter and makes a great tool for anyone making 3D models for a flightsim. Regards, Curt. Bye bye, Wolfram. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] are we switching from blender to ac3d?
Norman Vine wrote: Erik Hofman writes: Norman Vine wrote: If someone was to do this I would suggest exporting to the native .ssg binary format :-) If they could fix the .ssg endianness problem in the process I'm all for it. Sounds good :-) [...] Am I missing something here ? Your idea should work. Norman Bye bye, Wolfram. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] are we switching from blender to ac3d?
Curt wrote: If I've missunderstood something about plib/ssg I'd appreciate being corrected. If modeling is still done in blender/ac/multigen/whatever, then you need a conversion path to plib. I think you guys are speaking aside each other. Curt wants to allow different modellers. James OTOH correctly says that the thing professionals do instead is to decide on one modeller, say Blender OR 3DS Max etc, and then write an exporter into their own propriatery format. This is the path suggested both by Kinetix (and probably the other big players in 3D modelling) and by mostgame developers that have done it. So, no standard format is involved. Norman - IMHO correctly - wrote that if you do that, the propriatery should be SSG, since that loads very fast. This is a HUGE thing for a flight sim. I am currently loading ascii files into the sim I work on to make development easy. A plane needs over a second. If you realise that a frame that is 50 ms longer than other frames is EASILY visible, then an ascii format is a factor 20 too slow. I think the first decision that needs taking is whether you want to mainly support say two modellers really well and the others not so well or whether it is a very high priority to support all modellers out there equally well. In the first instance, I support James/Norman's idea of an SSG exporter. Curt. bye bye, Wolfram. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Can someone give me some debugging tips?
FWIW, you might try the js_demo in the PLIB examples. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] crease for ac3d files and speedup
Is there a reason that models in the base package are not optimised by calling merge hierarchy nodes and possibly by calling stripify and then put into the base package in a file format like ssg that will keep the optimisations? Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Attn 3D model creators
I have tweaked the AC loader in PLIB to ignore the lines with crease. Until now, there was a fatal error since it was an unknown token. Such ac files can now be loaded int PPE and into FGFS, if FGFS is compiled with the newest PLIB. Also, I created a new PPE Windos binary from the current source code: http://www.bob-ma.org/PpeWinBin.zip Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Attn 3D model creators
Vivian wrote: Any chance of implementing the token? Sorry, no. Things have developed quite differently to how I hoped and so a) there was not much 3D modelling or model conversion for the flightsim I work on and b) I am currently down to almost no spare time :-(. Regards Vivian Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Teaser Screenshot
Hi Durk! Great to hear of progress in this important area! Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Spitfire Performance Testing
Rick aked himself: (Or do I remember seeing film with the canopy open during the approach?) Yes. It makes landing easier to open the canopy and look around the big engine in front :). :) Nice job Vivian :) Yes, indeed! Rick Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Spitfire Propeller vs. YASim
Spitfire Mk IIA Ah - surprising! Here is an email Rick Fuelcock sent me a short while ago. I hope it helps. Sorry for the poor formating. --- snip - Rather than send you the GBE code , I will direct you to the site where I got it: http://www.aeromech.usyd.edu.au/aero/propeller/prop1.html Just click on program 1 at the bottom of the page. Program 2 (right below) is mathlab code for the implementation without the bells and whistles. I have been playing around with program 1, and have obtained very encouraging results. I keyed in a Spitfire prop with radius 1.55 m and a blade area of 0.98m^3. The program only let's you design a simple blade with a straight, symetrical taper. Rather than complicate things, I just kept the cord constant at .210 the radius to give a total area of .327m^3 per blade. Not knowing anything for sure about the blade angle at a given radius, I just used the default pitch of 0.5, where: pitch = 2pi * r tan theta and theta is the geometric angle of the blade at r. The model also lets you tilt the whole blade +/- any desired angle setting. Assuming the max speed of the Spitfire to be 154.7 m/s, I toyed with angle setting until I obtained a max prop efficiency at angle setting 19.45, J value of 2.09, which corresponds to a true airspeed of 154.7 m/sec for a 1.55 m radius prop, engine running at 3000 rpm and gear ratio 0.477. The model produced a theoretical efficiency of about 85%, with Cq = 0.071. Next, I calculated the torque, using the formula Q=Cq * rho * n^2 * D^4, where n is prop rotation in revolutions per second ( the code converts this to radians) and D is prop diameter. I assumed rho of 0.5 Kg/m^3, an altitude of about 15,000 feet. I than multiplied the torque by angular velocity in radians per second, to get the power (watts) needed to counteract the torque of the prop. This worked out to 865 KW, which converts to 1159 HP. This is about 10% hiigher than what the Merlin could actually put out at the shaft, but it's pretty damn good. Remember, the model is known to be about 5% to 10% too optimistic in predicting performance, so if you take this into account, the prediction is nearly spot on! --- snip - Regards Vivian Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] COLLISION DETECTION: possible or not?
On Sat, 1 May 2004 09:15:09 +0200, you wrote: I think we have three possible solutions from the FDM - Flightgear interface point of view. 1. Have a callback function in FGInterface which is able to provide you a terrain level and a surface normal for a given lat/lon pair. 2. On every update push *all* tiles in an environment of the aircraft to the FDM and leave it to the FDM to fiddle with that information. 3. Provide a callback function to query a surface tile for a given lat/lon pair. I am not sure I understand 3, so excuse me should I just reformulate it: 4. There is one callback providing the level (altitude) for lat/lon. (and no normal!). The FDM is free to call it three times and from the three results create a normal, which does not need to coincide with the normal of any terrain poly. Actually, the normal computation might be part of flightgear (and not the FDM). Greetings Mathias Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: COLLISION DETECTION: possible or not?
Also being able to fly through buildings isn't really such a problem, BTW, I remember at LinuxTag, when we taxied the Cessna and by chance sometimes came under the wing of the 747 of the scenery, then the Cessna would try to jump up and the program would crash. m. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Motion Base Simulator ?
LoL, friends of mine where ion there last weekend. I don't think they know the picture, so I just sent them the link :-). BTW, they now have a Concorde there as well. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Spitfire Propeller vs. YASim
I did not see the original thread. What Spitfire version are you speaking about? Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft Todo List
BTW, I had a look for a X15 3D model a short while ago. There is a new MSFS/CFS model, but it is not much better than the old one, so I don't think it is worth it. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Low poly model LOD request
David wrote: It's not a hard task. Blender has a face-reduction function built in that does a wonderful job simplifying models -- the only problem is that you lose the UV mappings, so you have to spend an hour or so remapping textures. Are you serious ?? Did you ever try this? That would be completely awesome! All the best, David Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Low poly model LOD request
David wrote: Wolfram Kuss wrote: Are you serious ?? Did you ever try this? That would be completely awesome! It works fairly well, and lets you preview the results in case you don't like them. Give it a spin. Holy cow !! I wonder why no one else uses it! I know that it is VERY time consuming with both FSDS 2 (purpose built for creating models for a flight sim) and with 3DSMax, which is after all probably the most used program in professional game development houses. That should give FGFS a huge boost! I have just looked for some MSFS/CFS planes for some other project and most do not have LoDs at all. Crazy. But they get away with it, since the modellers either take screenies (fps does not matter) or just fly around in one plane, which in CFS is not really what it was made for. All the best, David Bye bye, Wolfram ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] ssg/ssgLoadSGI.cxx: treat grayscale with alpha layer correctly
Thank you! Committed. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D model mini howto
I says It usually takes a bit of experimentation to get the model positioned correctly. It might be a good idea to add that PPE has a custom function to postion aircraft on runways. Things like 90 deg rotation because the axis are different in the model than fgfs still have to be done manually first. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: PLIB on AIX; Was: [Flightgear-devel] FlightGear 'benchmark'
Erik wrote: Just be very persistent, state clearly this patch is needed for AIX before a new stable release is scheduled. Steve has committed them already. Erik Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear 'benchmark'
I would be very interested to know how many polygons per second FGFS is rendering. Do you have a ballpark number? It might be nice to have several sections of the benchmark and in one try to maximize poly count of the scene and minimize all else. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Changing a model format
using CATIA V5. This is a CAD program and not a modeller, so while you can use it, it is not what CATIA was created for. I guess that CATIA does things without polygons internally and uses splines, solid objects, booleans etc instead. Probably it just creates polygons from it (tesselates/polygonises) when you export to wrl. Of the formats you mentioned, wrl is best. Using another format would not make it faster at all. That you see something in FGFS means it is polygonised in the wrl file, as it should be. Like the others said, the problem is the number of polygons it created. I would guess that at some stage, probably during export, it creates the polys from the splines etc and normally it should ask you how fine the mesh should be. This is where you choose rendering speed in FGFS! This means if the fuselage is 2m in diameter, I want the model to have a 2m diameter fuselage as well! This can be done in any serious modeller. http://members.optusnet.com.au/~tjelliffe/Learjet55.jpg Nice. The problem is that CATIA works with surfaces, as you can see in the pic, but things like blender and ac3d seem to use nodes. ? This makes it hard to convert into .ac format. Converting to ac would not make it faster. BTW, if you look at one airplane close up, LoD would not help either. That is not to say you should not model LoDs later (you should ;-)), but first solve the current problem. Try to find out the number of polygons in the wrl. One way is to get PPE (PrettyPolyEditor) and load the model nd then look into the conolse window. Tim J Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Linux User Developer Expo 2004
Alex wrote: I have no idea whether I can make it. It would be great if we could meet up again. I think I will be at the european flightsim show again, but do not know yet when it will be. AFAIK, it is the biggest flight sim trade show in the world. Last year, it was in Birmingham on the 5th of October :-). Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Help creating a new model
I am probably WAY too late, but FWIW, you can buy a Bo105 plan here: http://www.airpictorial.com/acatalog/Online_Shop_Germany_14.html Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Panel Building ?!?
I agree that 3D is the way to go. Like David says, all the 3D polys in the scene can of course be textured. We (BDG) use a resolution of 512x512 pixels for the textures of each of the main displays (art. horizon, airspeed, VSI, boost gauge etc). The texture includes things like the bezel, it would cost too many polygons to make these in 3D. The two different possibilites are: A) Have 3D polygons and textures on them for everything. B) Have 3D polygons and textures on them for almost everything. Have a special feature panel that means a non 3D person can input coordinates and the program generates a panel. The normal thing to do in most flightsim communities is to have specialists for 2D and 3D. The disadvantage of A) is they have to work together, for example the texturer needs a 3D model to test his textures in flight in the correct type. However, B) has to include all features of A), so B) is actually more complex. There are lots of reasons why one flat dashboard with textures on and no additional polys is bad: - Switches and knobs, as already said by other people. - Often there are several dashboards (for example overhead, on the sides etc) - You might want to do other crew stations that are more 3D. - Often, the dashboard is subdivided. For example you have an outer dashboard on the sides that is a bit farther back and has the engine instruments etc and screw another dashboard on top of this with the 6 main instruments. - I know several planes that have instruments outside the cockpit. For example, the Ju52 (Iron Annie) had at least one instrument on each of the outer engines. - You might want to animate things like rudder pedals. With 3D, a know or a pedal is just another animated item. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help creating a new model
Do you use BMP textures? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Models Question
Hi I do not think it's a problem with the normal. Like someone else hinted, it might be the specular exponent. Unfortunately, I do not rememebr a good value, but I think one of the three numbers 1,3,10 should be good. So, if you try the three one after the other, maybe with an ascii editor in your ac file, IMVHO, at least one should look good in FGFS. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
Hi, They have mentioned FlightGear as a candidate simply for the reason that it can be modified and changed to do whatever we want it to do. No restrictions on functionality. Yes, that's the advantage of open source. BTW, I have lately heard people call Targetware and MSFS/CFS open source because you can mod it, but of course that is very different to having the program source in the open. We need at least one properly/accurately modeled aircraft that we can show off. I'm talking nice visually (high poly count) and with an accurate flight model. Regarding the visuals, the easiest way is use an existing model and convert it. We need some nice development tools. In particular a full blown scenery editor that one can use to lay down 3D objects (trees/buildings), taxiways, aprons, roads, rivers, etc. If it's done in OpenGL then you can make it WYSIWYG. I did that a long time ago, before the LinuxTag trade fair. It is in PPE (the open source modelle PrettyPolyEdit, which sits on top of the library PLIB, like FGFS does). You look at the terrain from above. Of course you can rotate and move the camera. You then simple click the mouse onto the spot you want to add the model. You then have three dials to edit the pitch rolll and yaw if possible. For example, with taildraggers converted from MSFS, they are normally horizontal and you have to rotate in pitch until all wheels are on the ground. I am not sure anyone used this apart from me. This should still work, but it uses ascii terra gear scenery. I do not know the status on that. Is there a converter? What 3D formats and apps are used? See the bottom of this page for file formats: http://plib.sourceforge.net/ssg/non_class.html In the big table, look for formats we can load. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SRTM 90 for Europe and Asia
SUPERB!! Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems with AC3D 4.0
Innis Cunningham wrote: FATAL: ac to gl: unrecognised token ' crease 45.'. So, in the new AC3D version, they added a so called token. This means that the new version saves some additional info that the old version does not. Since PLIB does not (yet ;-)) know about this, PLIB throws the above error message. I can even guess what the new info does: It says edges less than 45 degrees are smooth and more than 45 degrees are sharp. Since AC3D V4 always saves in the new format, it does not mater whether you changed something. Anyway, send me a small file with the problem and I will have a look. As ulta-short-term workaround, you could do this: Open the file in an ascii editor like notepad. Search for the line. I would guess the crease 45. stands alone on one line. Delete it. Make sure there are no other lines like it. Try again. Cheers Innis The Mad Aussi Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems with AC3D 4.0
Sorry that my email was not clear. The only thing I would implement (at least in the short term) is that PLIB ignores this token. So, it would hopefully be quite trivial to do; I do not have time for more right now anyway. However, like you also say, I do think this would also be a good thing. It seems that AC3D always writes this token, even if the user did not change it. Else Innis would probably have remembered setting it. So, if we would look at it always, it would be a bad thing IMHO. So, one would have to decide when to use it. And even then I guess there are more tedious, but flexible ways to get the same effect (some edges sharp, others smooth). bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Making a 3D Sea Harrier FRS.1
just want FlightGear to have its planes :). If you want me to, I can have a look whether there is a Harrier for MSFS/CFS that we could technically use (then we would have to ask for permission). Plenty of planes to last quite some time (no Spitfire yet for instance...). I think there is no high quality Spitfire I around, lets say of 5000 polys. Other sims might need it as well ;). Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] that ssgStripify fix
- 0.01f, /* DISTANCE_SLOP = One centimeter */ + 0.001f, /* DISTANCE_SLOP = One millimeter */ Done. Sorry it took so long, but when I wanted to do it I saw my last Windos reinstall :-( had clobbered my WinCVS access to Sourceforge. Thanks, Jim Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Converting .bgl to .dem or comparable ...
On Monday 06 October 2003 11:26, Tim Kober wrote: Hi members, I am a new to this list and have a tricky problem: is there a workaround to convert or extract DEM-Information from .bgl-Files of Microsoft or mesh data from Lagos .bgl.-files? A conversion to another file format (readable by 3D-Software) would be OK also ... Maybe FSterrain does? Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] heads up - aircraft reorg
Curt wrote: This is another step towards making aircraft self contained in their own subdirectory. The end goals is to be able to install / remove / distribute aircraft that are entirely contained in their own subdirectory tree making things easier on everyone [hopefully]. :-) Sounds good :-) Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flying in the UK
David wrote: I plan on doing a flight in the UK in summer as well, probably with a Tiger Moth. You can do this without any flying license. Really? In Canada, you need a license even for an ultralight or a glider. I probably formulated that very badly - it is like the introductory flight lesson, you fly with a instructor and I am sure he will not let you start or land or fly down low. All the best, David Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: 3DS Models in Flightgear
I haven't been able to find documentation on what is or is not supported in PLib I just tried several models and found out. See the table at bottom of this page: http://plib.sourceforge.net/ssg/non_class.html Erez Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] Shuttle breaks up
A very sad day indeed :-(. Our thoughts are with you, especially relatives and those connected to the Shuttle. Tony wrote: I find it a little hard to believe that a piece of insulation could have such an effect. Those tiles are designed to be impact tolerant and it seemed clear from the press conference that this sort of thing has occurred several times before. I did not see the press conference, but I think that in the past only single tiles went missing. If the impact has removed several neighbouring tiles, I would guess the heat will get to the metal underneath... Jon Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MSVC6 WIN98 Update - Nov. 2002
I also compiled the CVS version with MSVC and got the ufo to work.
Thanks to Geoff for his posts, they helped.
Geoff asked:
Metakit and zlib went smoothly ... although
my WinZip 8 refuses to unzip the current cvs'ed
gz files in src-libs! Do others have this
problem?
Yes, same here.
Also, I got the other problems, I did not need to change PLIB though.
It would be nice if someone with CVS access can implement his changes,
especially the one for DISCARD DOT.
I had to add a lot of files to the FGFS workspace:
exeternal.cpp external_net.cpp
objects\dir_lights.cxx
add navcom.cxx to project Lib_Cockpit
FGPropertyManager to jsbsim
dme.cxx to cockpit
aiplane.cxx to atc
externalnet.cxx to fligth
marker_beacion to cockpit
pt_lights.cxx to objects
new_gui.cxx to gui
uiuc_getwind.c top larcsim
uiuc_pah_ap.cpp (to larcsim?)
instrumentation directory!
systems directory!
util.cxx to main
The worst problem seem to be that with default settings, JSBSim has
bad problems. It says it can not find the aero. I debugged and it is
c172, so it seemms correct to me.
Oh well, in the ufo mode I can lok around, that is all I want right
now.
In fg_commands.cxx,
{ null, do_null },
{ exit, do_exit },
{ load, do_load },
{ save, do_save },
I did cast the functions with (SGCommandMgr::command_t)
In panelnode.cxx,
before
#include GL/gl.h
add for windows compiles:
#include windows.h
Bye bye,
Wolfram.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FSAA frustration continues (Nvidia forum post)
Geoff wrote: I was getting lockups in some games and fgfs before making my memory timings a bit more conservative, though it had passed memtest86 previously. Haven't had a lockup for weeks now. Interesting. You are speaking about the timings of the main memory, correct? Did the problems you had beforehand only occur with FSAA on or regardless of FSAA? Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear scenery editor?
Christian wrote: Didn't someone use PPE for this? Yes, that was me. You click somewhere and then get the coordinates. Also, you can add an object that is automatically rotated so that it points up (the up direction is often not axis paralell) and then have dials so you can rotate it further, especially around the up vector. See a old, partly complete doc of this here: http://wolfram.kuss.bei.t-online.de/Scenery/diy.txt Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Modeling wing twist animation
Yes that's right. Moving individual vertices would of course be ideal, PLIB is AFAIK able to do that with a technique called tweening. There is even an example of it, where a ball is tweened to a star and vice versa. Best, Jim Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Plib-devel] ANN: new version of the BGL loader in plib
Great! I tested the BGL loader only a bit. Most of the time it works *GREAT*. I will post some screenshots once I have time. I would be good to have some for the PLIB and FGFS websites. However, I also got some crashes. From avsim.com, get eddt2k_v2.zip. It says: FATAL: [ssgLoadBGL] Op-code out of range: 49932x. Do you know whether you can read gmax-generated BGL files? For the MDL loader, this is IMO the biggest limitation. BTW, I used the MDL loader intensively the last week or two and it works very similar to the old one, which is good news :). One of the major problems for the MDL loader was that it put every vertex into every leaf, so if you have 100 leaves with 10 vertices each (often they have even less...) you get 100 * 1000 vertices instead of 100 * 10 and often reading a 1MB MDL and writing as ssg or ase etc resulted in a 1GB file! I comitted a new function removeUnusedVertices and call it in the MDL loader, which cures the problem. I also put it into the BGL loader, although it only reduces the resulting file from 333kB to 296kB. Have a look. Any idea why it is only a small problem for BGLs? So when you load a BGL file you will see correctly piled gound layers (like asphalt on grass etc..) with no flickers anymore:) How do you do it, do you cut a hole into the lower layer? Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] A real C172 cockpit
FWIW, FYI: http://www.therealcockpit.com/main/index.php ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] dumb suggestion
Realistic night lighting would be great. I know how MSFS nightlighting works (Its fairly trivial), so if we could change the lighting parameters for the 3D model only (I guess we do not want MSFS lighting for the rest), we could have night-lit aircraft. Often, this looks really great, I experimentally implemented it in PPE. You have bright windows, an illumintade tail logo etc. Best, Jim Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] dumb suggestion
Yes, I've had this discussion as well. The sun should stop being a light source once it's, say, 15-30 deg below the horizon. IMHO it should be possible to have different rendering parameters for the aircraft than for the rest of the scenery, for example by having it in its own tree. Then, you could calculate whether it is sun-lit using its height. The formula for that is fairly easy. All the best, David Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MSFS2k2 MDL file format documented?
Interesting. I have looked into the EULA, but not yet the docu iteself. The EULA says: 1. GRANT OF LICENSE. This EULA grants you the following rights: Software Product. You may install and use the SOFTWARE PRODUCT on an unlimited number of computers, including workstations, terminals or other digital electronic devices (COMPUTERS) to design, develop, and test software application products that are designed to operate in conjunction with Microsoft Flight Simulator 2002 and subsequent versions thereof, (Application). [...] All rights not expressly granted are reserved by Microsoft. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Failed to load 3D model
I'd suggest that we not cause a fatal error on models that are not shipped in the base package? Or possibly, just don't cause a fatal error when any model fails to load. In PLIB's UL package there is a function bool ulFileExists ( const char *fileName ) ; So, it could be as easy as (pseudocode) if ulFileExists(model) ssgLoad(model); else ssgLoad(BlueGilder.ac); Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Cheaper 3D clouds?
Very interesting link! I have to say I did nmot like the www.cs.unc.edu clouds very much, the screenshots looked good, but the demo showed the problems. Off course it may be the same for this paper, often clouds look better in single screenshots than in a moving simulator, looking at them from all sides and distances. BTW, the IMHO best screenshots come from CFS3, see http://www.simhq.com/simhq3/sims/interviews/cfs3/ Lets see how this will turn out to when it ships. To look at the PDF in your link, I installed the japanese character set for Acrobat Reader 5.0, that solved the problem I had. The advantage of this algorithm is that the clouds can realistically change shapes and you can probably make them match the underlying terrain. Both is important for soaring enthusiasts. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Billboard animation
Use billboarded trees, especially when they rotate around z only, very careful. The funnniest sight I ever had in a flight sim was when I flew directly over a forrest of billboarded trees and (in outside view) looked straight down. You get concentric tree rings that move along at the speed of the airplane. I should have done an animation of that. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Trees, alpha, and the sky
Andy Ross wrote: Wolfram Kuss wrote: Andy Ross wrote: You could also experiment with turning off backface culling instead of rendering two quads for each direction. In principle, it should be faster. In practice, it's probably a good way to detect driver bugs. :) The speed difference will be very, very small. Are you sure? It reduces the vertex count by a full factor of two. IMHO you can use indexes (sp?) into the same vertices, so the vertex count would stay the same. The pixel count would off course also be the same. Andy Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Trees, alpha, and the sky
Andy wrote: Also, that's an awfully small texture. While it's good to not waste space, this thing is tiny -- one eighth the size of a single panel instrument's face. IMHO, it would look much better at 128x256 or so, with no measurable loss of performance. I agree. Some modders I know use one 512 x 512 texture file per instrument (for the face including the bezel (sp?) and the needle). This works very well, with GeForce 2 and higher you get no measurable slow down compared to smaller textures. You could also experiment with turning off backface culling instead of rendering two quads for each direction. In principle, it should be faster. In practice, it's probably a good way to detect driver bugs. :) The speed difference will be very, very small. Andy Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Trees, alpha, and the sky
Jim wrote: I've been thinking about that: how about not at the top, but halfway? Essentially, you'd have the XY, YZ, and XZ planes, one unit wide, all intersecting at the origin. Is that clear? Yes. You want to make the horizontal polygon at the largest extension of the leaf canopy. This means the chance that in your view the horizontal poly extends over the other two polygons is lowest. BTW, I recommend setting the origin to the place where the stem goes into the earth. Jon That might work...was even thinking about at the bottom so you'd only really see it from above. No - if you do not look directly from above, it will look very bad. Say the leaf canopy is a sphere (two polys with circular mask textures) and the horizontal poly is a circular disc as well. When looking with a pitch of say 20 degrees down onto it, you will see the sphere above and a ellipse below the shere. Best, Jim Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Using gmax models in FG
Interesting link. Still, I tried the MakeMDl that comes with MSFS 2002 Pro some time ago without success. The *.MDL it writes is too different, it is a new version. You might have luck with middleman, which might enable you to intercept the *.x file that gmax gives to MakeMDL. I did not try that. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RE: Using gmax models in FG
Try: a) export ASE or 3DS from 3DS Max 3 into flightgear (maybe look at it in PPE, if it looks good in that, it should look good in FlightGear as well). b) export 3DS from 3DS Max 3 and use the newest gmax (version 1.1), that should IIRC be able to read that. Thanks in advance, Matt. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] My First Flight
Jon wrote: When I was taking lessons some twenty years ago one thing the instructor did was to put a hood on me so I could only see the instruments. What he did next I am not quite sure, but he was trying to disorient me. Then he told me to level out and fly to a heading at an altitude. I should have gotten sick, Indeed! The number one reason for car or air sickness is that your brain interprets the motion signals from the inner ear and the eyes differently. This is off course especially bad if you don't look out, as the eye only sees static stuff like the panel and the inner ear tells you you are travelling. When I was young, I got car sick. I *had* to look out all the time. My ex boss, who is a pilot himself, did a ride in an acrobatic airplane once. He said his stomach was ok for quite a long time, while he always knew which way was up etc. Then he lost his orientation and his stomach got bad very quickly. From Davids description I think one problem for him was that he did not see the horizon or the earth in general. He looked out in front and saw only the sky or looked at the gauges. Maybe if he would look at the earth more often, that would help. I think the excitement also makes the stomach react worse. Jon Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] new_hitlist
The bigger problem, I suspect, will be main memory (or maybe disk bandwidth). An impostor scheme is going to be really tile hungry -- constantly dragging tiles off of disk, rendering them into textures, and forgetting about them. I know a sim that does what Norman suggest and it does not seem to have problems with loading tiles, although it rerenders tiles all the time (about one tile per frame). You're no longer limited by texture memory here, However, one problem is that not all gfx cards can render into a texture, so you have to do some moving of textures, which in some instances is *very* slow. There is a factor of 1000 between different moves of the same texture on my GeForce 3, as you may easily see with the readily available benchmarks. I am still not 100% sure whether the problem (texture movement sometimes leads to stutter) is a bad implementation of the idea or a basic problem of the algorithm. One certainly has to spend some thought on texture ram management. I *think* the easiest idea - if you dont need the texture any more and need memory, throw it away and when the user views again in that direction, rerender it, is also the fastest algorithm. Rendering may be faster than moving textures between texture mem and main mem. Andy Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear, FS2K2 and GMAX
David wrote: Wolfram mentioned that GMAX-exported models don't work with PLIB anyway. Yes, you can not load the gmax generated MDLs. You can try to use Quake models as intermdediary file or maybe with Middleman http://takeoff.to/landing you could get an *.x file. I have not had time to try either option myself yet, sorry. In other cases, the best bet would probably be to load the model into PPE, name the appropriate objects, then export it to some other format for FlightGear to use. Unfortunately, PLIB can generate many thousands of nodes. But we only need the names for the gear, props etc, which should IMHO work automatically for MDLs that you can import. All the best, David Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear, FS2K2 and GMAX
No. You could *try* to use tempest to export it as quake model and then convert that, but AFAIK no one has tried that yet. If you create the airplane with FSDS, then it works. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear, FS2K2 and GMAX
David wrote: I get confused about what MDL formats plib does and does not support. We can import almost any MSFS *.MDL model - if it has not been generated by gmax. I created a simply cylinder with gmax and tried to import it into PLIB and failed. I also tried the one gmax generated airplane I found at the time and it also did not work. Unfortunately, I don't really understand the MDL loader code and also have very little time, so I did not look further into it. I asked Thomas Sevaldrud (sp?) about it and he said he wuld look into it when he has some time. Apart from gmax generated models we can now read about 95% of the MDL models. Some with problems like opaque props, very few with wrongly flipped faces, one with parts missing that have obviously been duplicated and moved, but like I said, we can read almost all non-gmax MDLs. Also, it is hard to get back the original hierachie of objects and Combat Flight Sim airplanes may come with their hitboxes (additional boxes that you do not want and have to delete). All the best, David Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Hack for Virtual cockpit problem
Norman wrote: The resulting matrix, far from being view-only, in fact includes the global orientation as well. Again the 'test_matrix' or something like it should probably become the ''resultant of all the user inputs on the view note this had NO global orientation in it nor should it ever get any I agree, the view matrix should not contain the aircraft orientation. For the rendering code, it is easy to multiply the matrices. That is exactly what matrices are for and why there are 4x4 and not 3x3 matrices: You can simply multiply them, even if there is stuff like translation inside, which would normally mean adding things. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Hack for Virtual cockpit problem
David wrote: Norman Vine writes: Well the Mouse code certainly could but let's leave that alone as I REALLY don't want the Mouse reading properties :-) Not read them, but set them. It wouldn't much matter if the mouse code called globals-get_current_view()-set_orientation_offsets(r, p, h); Are r,p,h relative to the plane or the current view? Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help with XML and preferences.xml
David wrote: Wolfram Kuss writes: The XML files get IMVHO more and more confusing. I think that it would be more accurate to say that FlightGear is getting more sophisticated -- there's more to learn if you want to customize things, but that's only because there's so much more that you can customize. I wrote my critizism so that things will be improved, not to critize someone and certainly not one of the most active devlopers. I do admit I was a bit frustrated, since I have slept little for at least a month now and my current non coding free time is listening to tapes on the work to and from work. So, I got frustrated when I needed an hour or two just to find out the name of a parameter. So, IMHO, we should try to not change *after* 0.8.0 (or 0.7.10) again. Also, it was meant as encouragment to write a UI; If you can simply choose from possible parameters, you don't need to hunt for its name. If noone does a UI then one thing one can do is have a commmand line parameter to fgfs that forces it to write out all possible properties etc. I would guess fgfs has a complete list of these somewhere? The config files serve many different purposes; using the XML-based property-list format for all of them helps a lot, I am not arguing against XML. There are several things unclear to me that IMVHO should be (better) documented. preferences.xml- the top-level default preferences joysticks.xml - default joystick bindings, included by preferences.xml keyboard.xml - default keyboard bindings, included by preferences.xml Aircraft/*-set.xml - aircraft-specific settings, overriding the defaults in preferences.xml (and joystick/keyboard.xml) This should be in the Docs (or did I miss a major XML doc? I only read the http://www.megginson.com/flightsim/fgfs-model-howto.html ). As far as I can recall, these are the *only* files in the base package that affect FlightGear's main property tree. Other files use the property-file format for convenience to populate various data structures, but they do not touch the main tree and are not accessible through the property browser or through the command-line --prop: option; it's just a coincidence that they also use the property-list format: I see. At the beginning, this was unclear to me although I more or less realized this after a bit. Calling things properties that are not --prop: things is IMHO not a good idea. BTW, in your list you forgot the *-dpm.xml files, which are of most interest to me and which are currently the only ones that I really use :-). With the little time I currently have, I am glad if I manage to have a nice 3D model at the correct place in fgfs. All the best, David Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] UIUC models update
Michael wrote: If anyone has them, I'd like to get publicly released 3D models for: - Wright Flyer (I have one, but we have not yet got permission to give it out) - SGS 1-36 - Pioneer UAV - Marchetti S-211 - Learjet 24 - Piper Cherokee Wright flyer: You can use the one from www.flightsim.com, see my homepage. I am fairly certain there is no pioneer UAV, Schweizer 1-36 and Marchetti 211. But there are Marchetti 205, 208, and 260, maybe they are similar enough in the 3D? The others should be easy. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Plib Compiling problem
FWIW (probably not much): I think you need the Mesa or OpenGL and glut *developer* package (is that the word?). In the packet manager or somewhere there is a huge list of things you can check and you should probably tell the SuSE packet manager to install it for you. I do not think it is a path problem, although this does happen (but IIRC in other distros). By the way am I right in thought SuSE 7.2 already comes with Glut and Mesa support ? IMHO yes, but maybe you did not enable it. Thanks for any help. Sergio Roth Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help with XML and preferences.xml
Sounds like a worth while (sp?) project! The XML files get IMVHO more and more confusing. Maybe lets do the big reorg that Dave speaks about first, with the hope that things won't change often afterwards. When doing the python scripts to generate the very very rudimentary plane xmls on my website http://wolfram.kuss.bei.t-online.de, I saw that for example the spelling of z-offset changed twice and I was told to use a third spelling. Also, it is not clear to me, what the different xmls are for (what does -dpm, -set etc mean? set as in set options? Don't all xmls set options?) and whether you can use all properties in all XMLs and whether you can use all on the command line. So, a UI that showed you what you can do would be very nice. If you use python, you can include my stuff. I would love someone expand on it and say I download a MSFS 3D model, Python unpacks it, moves all files, generates warnings if applicable telling me what to do (for ex.: !This is an old MSFS 95 model, you need to convert it with the MS converter first, sorry!), lets me create a *.ppeloc file, generates the XML file with the z-offset and the pitch-deg for me, lets me choose a FDM, panel etc, inputs it into the XMLs, generates a small batch file to call everything, etc. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Virtual cockpit notes
I agree, full 3D is the way new sims work and FGFS should have that as well and not implement now a feature that was state of the art some years ago. It is easy to make the yoke optional. While modelling the cockpit I would strive for realism and then let FGFS disable it if the user wants. There may be small artistic freedoms to make things more legible, for example shadows on gauges that partly and non-uniformly shadow digits on gauge faces can make it more realistic and pretty, but harder to read. Also, if in reality there is much space between gauges, you can increase the size of the gauges. I also love a fully 3D, fully functional, fully clickable cockpit. But it is a lot of work, more than exteriour models. Also, an artist can make an exteriour model without help from a coder. If an aritist does a 3D cockpit that holds a switch or gauge or whatever that has not been coded before, he needs the help of a coder. It should off course be possible to change the view direction. I have heard (IIRC from warbirds or Aces High users) that a very nice effect is if the eyepoint moves at the same time. If you sit and look in another direction, turning your head, the eyes move since you will probably hold your neck fairly constant. Also, it should be possible to move the eyepoint via keys so that you can look around things. This may go so far that you can open the canopy and stick your head out to look besides the large obstructing engine. If this is realistic (this technique is used for some planes in RL), then users appreciate this effect a lot. Also, g forces should move the eyepoint as an option (some people like me like this, some don't). AFAIK, this is already in the code. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Virtual cockpit notes
Jim wrote: While this is nice to have for some limited purpose, it adds nothing to the realism of the simulator from the perspective of the person flying the sim. I think more people use flight sims for fun or entertainment than for serious uses. Including me, although I am a pilot. But lets stop this discussion and agree that whether you find good exteriour 3D models fun is a matter of taste (additional to the serious uses David wrote about). jj Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Virtual cockpit notes
Jim wrote: Fly! is a 3D cockpit. I was talking about usability, and IMHO it is a more usable panel because of its inaccurate eye point when in use. Just as the panel disappears when you use the mouse scrolling and reappears with a click, it'd be easy enough to snap to an operational centered viewpoint. In 3D, its easy to let the user move the eyepoint. It amazes me sometimes that people define reality in 3D as being something that looks like it was done with a video camera. To me its a more realistic experience if the gauge I'm looking at can easily be used I agree. Strangely enough, just a few days ago I had the same discussion on a forum and said what you say, legibility is more important than just good looks. They had smudges on the faces, different varieties of shadows, aging effects (white - yellow) etc. My only fear is - maybe I am missunderstanding - that we will implement some scheme that was state of the art 5 years ago when someone started work on a sim that was shipped 2 years later. As long as we don't close doors to future development by choosing the wrong scheme or waste time by doing several schemes, I am happy :-). IMHO the decision for a 3D cockpit is not a decision for bad legibility. Worse than a pure 2D cockpit, hand optimized for the resolution, yes, but not bad. and is closer to what it would be in size and perspective from my eyes sitting in the chair, not the camera's little box on the screen. In a 3D cockpit, this can be chosen via FoV. Actually, when I start a plane and click all the things in the cockpit, I reduce FoV a bit (zoom in, move my nose closer to the panel). OTOH, when I land, I zoom out very much to see the horizon left and right to judge my angle etc. Best, Jim Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Runway plow
Andy wrote: Jim Wilson wrote: Noticed that the c310 has its wheels below pavement. Is it ok to readjust the models for a recent change or is this a temporary? Or am I the only one Which FDM? There are three (count 'em) descriptions of where the Cessna 310 wheels are relative to the aircraft coordinate origin -- the model's, JSBSim's, and YASim's. My guess is that none of them agree. Regarding the models coordinates, there is a way to do it without trial and error for every plane, see my homepage. I am just in the process of cleaning up and of looking into 0.79 and the current cvs version in this regard. I will be done by the weekend and announce here. If you can not wait: 1. My description omits that you have to press 3 before creating the ppeloc 2. By error, the ppeloc is written into the qhull directory 3. I am still investigating whether the new fgfs versions have the model in another spatial place than old versions. Old versions had magic numbers 5 degress and 1.61 z-offset that you had to subtract from the real values to get the FGFS values. Does anyone know whether they changed? What units are the vertex coordinates in? Meters? Feet? Just yesterday I recreated the measuring rod I use to measure fgfs to get these magic numbers. If people are interested, i can publish it. BTW, FWIW, if you import *.MDL models directly into fgfs, which is possible with 0.79 (and was not possible when I started my homepage), then they are smooth. Andy Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main main.cxx,1.245,1.246
Curt wrote: Perhaps we need to do a separate pass for rendering the 3d model and change the near clip plane just for that portion of the rendering. Yes. That should be easy to do. BoB does it as well, they even have 3 or 4 different parts of the geometry that they render with 3 or 4 different near values. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ancient 'ascii' scenery format
Curt asked: Is anyone still using this ancient file format? Yes. Does anyone have any objections to ending support in flightgear for it? Is it easy to create a atg2btg converter (I only have btg2atg) or does someone write a btg importer/exporter to plib? If so, then it is completely ok by me. Mostly I don't change the scenery (only add objects via ind file etc) and also I work on this very seldomly, so even if there is no atg2btg and you need to remove the support, then I can live with it. BTW, in my experience developement is easier to do with ascii formats. For example, if your file contains polys with 100s of vertices, you see this at once in an ascii format, but might need hours or days to stumble upon this in a binary format. So I would guess TerraGear etc development would be easier if you keep the ascii, would it not? Thanks, Curt. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ancient 'ascii' scenery format
There is a binary to ascii converter named btg2atg (atg = ascii terra gear, btg = binary terra gear), but not vice versa, at least not that I know of. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear 3D Aircraft Model Mini-HOWTO
Very nice and helpful, thanks. BTW, the rotation and translation of the model can bee found via QHull (convex hull, see my homepage), but that is a package you have to install first. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Profiling run
David wrote:
For example, the
program spent 2.95% of its time in ssgVtxTable::getNumVertices,
This simply calls getNum of the list, which simply returns a member
variable:
int getNum (void) { return total ; }
See ssg.h.
David
Bye bye,
Wolfram.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animated C172
These are the output names you may find in the current MDL loader: rudder, elevator, ailerons, flaps, gear, spoilers, propeller Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D Model Configuration Changes
What do you suggest that I do to the models on my homepage? Is it somehow possible to create a model that works with the old and the new FGFS version? I fear you will tell me to use XML instead of Python? Maybe use both and generate a XML on the fly by Python? Can I easily find out what version of FGFS the user has? Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D Model Configuration Changes
David wrote: Wolfram Kuss writes: What do you suggest that I do to the models on my homepage? If I recall correctly, the models on your page are already oriented correctly; if so, then they should continue to work fine. You don't need to write any XML unless you need to reorient or animate the models. The Python script sets these parameters: /sim/model/path /sim/model/r-rotation /sim/model/z-offset What does the file version say for the current CVS version? If it says 0.8.0 or 0.7.10 or 0.7.9a or something like that, then I could update my script so that my planes work with 0.7.9 and the current CVS version. All the best, David Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FGEnvironment [not] vs. WeatherCM
David wrote: 3. Concentrate on JSBSim and YASim for the FDM integration at first. I still think sailing planes need a good weather database the most. While JSBSim and YASim may be the best flight models we have generally, AFAIK neither JSBSim nor YASim has a sailing plane (in the works). All the best, David Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FGEnvironment [not] vs. WeatherCM
Jon wrote: There is one in the works for JSBSim, at least Ah - excellent news! Jon Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] IMPORTANT ANNOUNCEMENT: UIUC Usage Change
John wrote: I'd like to do a reorg of the directory structure after the release. Sounds good to me. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] LinuxTag 2002: Call for Papers
BTW, have you also seen http://www.linuxtag.org/cfp/cfp3-en.html !! Anyone wants to do a talk on FlightGear? I for my part will not do a Linux FlightGear talk since I have little experience with Linux and am too little involved in FlightGear. Last year I expected I would become more active, but now I know that I will never become one of the main developers. Alex, Christian, Erik? Durk, AFAIK, you will not be in europe then? Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] LinuxTag 2002: Call for Papers
BTW, Alex, will you be at LinuxTag? I'm tempted to have one of the non-European developers as the lead presenter (and then beg assistance with travel) if someone has the time and interest. Good point - I did not want to exclude the non-europeans with my list. I am sure that apart from your own talk you will also enjoy the other talks and the show very much. If we do that, it's important that the presentation topic is one that can be given by a European dev should the travel intent hit a last minute problem. Well, I will certainly be at the fair. Two years ago, when I was there as visitor, it was *very* interesting. Also, while my Linux endavours have further declined lately, I am still very active and interested in open source. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] LinuxTag 2002: Call for Papers
Curt wrote: I'd love to travel over to Europe for a visit some time to meet as many of the european flightgear people as possible. Great !! ... although my wife won't let me go unless she get's to come along (and she even speaks some German) ... Great again :-). What kind of travel money might be available from the conference? Ask Alex, I am not sure what experiences he had. What would we expect to pay for a hotel. It should be under 100 Euro for 2 adults + baby with breakfast. What would be the closest major airport to fly into? Hm. Stuttgart, Frankfurt, Hahn. Regards, Curt. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] C 172 3side view and data
On another forum, Simon Knott gave me these links: http://aar400.tc.faa.gov/aar-430/reports/01-44.pdf http://www.avnet.co.uk/gtaviatn/betashop/categories_category=19023.htm The first includes a 3side view of a C172. Unfortunately, there are no crosssections. There is also a lot of data about te C172 inside, but more about usage statistics than maximum performance. The second one is a book store. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DC-3 3-D model (partial)
Ah, not bad! Just out of curiosity, how much time did you need (including learning Blender) and how many polys does it have? Maybe a bit early to ask, but: Do you plan to add animation, inclusive adding it to the FGFS code? David Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DC-3 3-D model (partial)
David wrote: I don't know how to tell how many polys it has -- I don't know all the intricacies of Blender yet. Perhaps someone could load the VRML model into PPE and tell me. PPE says 2608 triangles! 3D Exploration says 867 faces ?!? Also, in PPE, I see all faces from both sides, in 3D Exploration only from 1 side. Maybe this is a PPE bug, I will investigate. But the flipping of some faces seems to be wrong (normal 180 degrees wrong). BTW, I think the engine nacelles and especially the wheels have very high resolution. Have you looked at the profile of the wing yet? :-). I've considered it. The rudder, elevator, and gear (such as it is) are all separate top-level objects, and the aileron and flaps will be too when I get around to it. If there's some way to tag nodes in Blender/VRML, it wouldn't be hard to move and rotate those objections from inside FlightGear, but for now I'm going one step at a time. Good! All the best, David Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6-win32-0.7.9 (minus)
Unfortunately I don't have time right now. I just wanted to say to you and Christian and everyone working on making / keeping it MSVC compilable a big THANK YOU. I plan to compile FGFS again in the medium term. (a) the zlib.h question As a user of zlib objects in other projects, i do not care which way 'we' go on this ... If i have to remember to add a 'zlib' path(s) to my msvc6 dsw/dsp files, then this is no big shakes ... That's what 'Project - Settings' is for ... In my case it effects - simgear/sg_zlib.h, and 2 other headers - no problem. I usually 'fix' them locally and get on with the compile ... If we have to choose between those two, then I vote for everyone changing the workspace. If MSVC does not find files, then that is the first thing where one would look. (c) Compiler / Linker - Model I will mention again, that since metakit's win msvc6 'default' build is 'MultiThreaded DLL', I link with my PLIB libraries also compiled with this SAME 'model'. That should be ok. On the PLIB list it has been decided some time ago that the MSVC workspace will use multi threading. And of course I compile SimGear.lib and FlightGear.exe using this same 'model' ... Yes, it is very important to have the same model for all, the error messages you get when you do not are very missleading. rgds, Geoff. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6 - new year update
Geoff, are you sure you have the newest PLIB from CVS? Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Doc: How to position objects in FlightGear scenery
This atg file is the wavefront obj file? It is simply the ascii for of the btg. ATG = Ascii Terra Gear BTG = Binary Terra Gear There is code to convert between them. If you have Windows, I can give you the source for at least one direction. If you have another OS, then you need to call decode_binobj (IIRC, I would have to look it up). []'s Marcio Shimoda Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Doc: How to position objects in FlightGear scenery
Here is what you have to do to edit fgfs scenery tiles with PPE: 1) Get PPE (prettypoly Editor, see prettypoly.sf.net ). Get a program that converts btg to atg files, called btg2atg in this text. Windows people can simply download the binaries: http://prettypoly.sourceforge.net/download/ppewinbin.zip http://prettypoly.sourceforge.net/download/btg2atg.zip 2) In your .ppe_rc, you need to have something like viewer.setTexturePath($(APOM);$(APOM)/texture;$(APOM)/../texture;c:/FlightGear/textures/$(...)) This should mean that PPE finds the textures of .MDL models you load and the FlightGear textures. 3) To edit KLVK, extract KLVK.btg.gz, leaving the .gz file where it is. Say btg2atg KLVK to convert the binary KLVK.btg into the ascii KLVK.atg.I create a new work directory where I put this. Create a directory textures under this and put all the needed textures in there. Load KLVK.atg into PPE. If there are still textures missing, PPE will tell you in the console. 4) You could edit this atg file and save it and have FlightGear load it. However, the more up-to-date thing for adding objects is to load aditional objects via the *.stg files. For limitations on ATG loading and writing, see the PLIB docs, under the table on the file formats 5a) Lets say now that you want to add one or several models in some PLIB supported format. You have the model on your harddisc, can load it (incklusive textures) into PPE, it has the correct size (1 unit = 1 meter) and, preferably, the origin in the floor. 5b) Start PPE, load the *.atg file (terrain tile), and say view/make everything visible. Move to approximately where you want to be, so you see the spot where you want to add something from fairly close. You can use the num keypad for this. Open the structure editor and close the ssgBranch (it is probably the 3. line you see) containing all of the geometry. If you don't, you may have crashes in PPE later on. 5c) Type 3 and then click where you want to place the object. If you move the mouse between the press and the release a bit, you will see the coordinates in the console window. 5d) Using Merge and position, add the new object. It should be positioned more or less where you want. Also it is automatically rotated to be upright, but the heading is undefined. Give the structure viewer a second or two to update. 5e) In the structure vbiewer, left click on ssgTransform: PPE: Trafo, the first of the new nodes. Say view/Make curr. Subobject visible. Now, the view should be around the new object. Rotate the camera around it with the middle mouse button. Move a bit back using the num keypad. 5f) Now leftclick on the node ssgTransform: PPE: usertrafo. Like the name says, the is the transformation you, as user, should use to position the object. This is quite easy, since the difficult transform to get it upright lives in ssgTransform: PPE: Trafo. In the properties dialog, go to the Tab transformation. There will be three edits for the x,y,and z movement and three dials for h,p,r. I have no problems with the dials, but the edits sometimes don't work. It seems to pay to start with the edits. One trick is to, after changing a value in them, tab out of the changed edit field. The three dials are for rotating the object. With these 6 values, position the object to your liking. 5g) Press F11. This will write a (additional) line into (c:\)temp.stg Simply copy this line into the *.stg file that contains KLVK. 5h) Copy the new object into the directory of KLVK. Copy the textures into the textures dir. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MSFS models
Norman wrote: I keep a copy of my most recent MINGW FGFS executable at http://www.vso.cape.com/~nhv/files/fgfs/fgfs.exe.gz Excellent, thank you. I will look at it today. The current file was compiled against the CVS of Dec22 These executables usually have the sound disabled That is no problem for me, I often fly without sound anyway. Cheers Norman Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Cessna 182
David wrote: There is now a Cessna 182 flight model in the base package There are much more freeware C182s than C172s. C 172 are part of most flight sims, so there was no big reason for the Freeware people to make one. What is the quality of the C182 FDM compared to the C172 FDM? David Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3d cockpit and some ideas
Starting small, but being extensible is a good idea. Often, the 3D cockpit model is much more complex than the exteriour model. For example, for BoBs Spitfire: - Cockpit as 3D Studio ascii file: 324 k without the instruments. This melts down to a 45 k binary. - Exteriour model, highest LOD, with hitboxes: 211 k. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Unable to select '--fdm=larcsim'
Ross wrote: (as a hang-glider pilot, sometimes I can't be bothered with engines and props ! :) Hehehe :-). Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Starting up flightgear.
Christian wrote: Wolfram: When was the last time you've tried FGFS with MSVC? Long ago. CU, Christian Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] OT: Building dual throttles.
I think this subject is currently OT (on topic :-)). Here is someone that built himself dualthrottles and connected them to the PC. Since its mainly about the hardware, this should be interesting to Linux people as well: http://www.flightsim.com/cgi/kds/main/howto/dualthr.htm Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
