Re: [Flightgear-devel] AN225
Jim Wilson wrote: Yes, exactly. That's what I meant when saying that we wouldn't have to rewrite the whole thing. I doing just that once before and the result was the model came out flat shaded. We need the part that traverses the tree and calculates the normals which is buried in the optimizer. This is part of the stripify function and I would guess this is where we get to the shading: /* So, now we have all the important information sucked out of all those nodes and safely tucked away in the OptVertexList Let's take this opportunity to compute vertex normals. */ list . makeNormals () ; Setting up for this is the part I don't quite understand yet. list is an object of the OptVertexList class (optimized vertex list). Idealy, and this does involve some modification to plib, we would also fix the loader so that it'll respect the shading paramter in the ac3d surface structure. The most important part is getting rid of the optimization step. I believe David Megginson wrote this part of the loader for better ac3d support in FlightGear. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [flightgear] Re: [Flightgear-devel] AN225
Frederic Bouvier [EMAIL PROTECTED] said: I guess the close factor is a percentage of the dimensions of the whole model. I had those problems with the knobs of the A320 but the instruments modelled independently are fine. Hmmm... Are you modeling in blender or ac3d? The reason why I ask is the ac3d files express vertices differently than the blender conversion. AC3D uses offsets from an object origin, where the blender converter, last I knew, is all relative to the model origin. In any case, I have had lots of trouble doing knobs on the VC instrumentation and occaisionally other parts like the bezels. The needles seem to work ok. They are flat and it doesn't seem to be a problem with flat objects. That fact actually could be a clue as to what the real bug is. I've been looking at the code and am trying to narrow down the area where the problem occurs. After thinking about it I'm pretty sure the flatten routine is not where the problem is coming up. It might be in the triangulation or maybe a glitch in the normals code producing inverted (or some how bogus?) values. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AN225
Matevz Jekovec wrote: What I'm hoping is there will be a bunch of good quality low polygons aircraft available also (for people like myself using less than optimal hardware). My J-22 has only 2500 vertices and looks nice besides ;). ... and still works pretty well on my system. Somehow the AN-225 crosses a line which brings my O2 to it's knees. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AN225
On Thursday 02 October 2003 03:52, Jim Wilson wrote: BTW there is a plib bug showing up on the bottom. That is one example of how the ac3d loader really is screwing up the shading. My guess is the optimization is to blame. Checking it out in wire frame mode (in flightgear) might reveal something. It would be awful nice to do away with that step. Oops - I thought I'd got 'em all;) I'll have a look at it. The model loader/renderer does do some funny things at times - I've been re-working the TSR-2 and hit a problem on the front canopy inner lining where a couple of sections seemed to be clipped out of it in fgfs. I remember you showing me some screen shots of a similar problem you had with the tip of the p-51d control-stick. Anyway, I could see that the missing sections were the diagonal halves of the original rectangle so I thought I'd manually triagulate the effected polys but switch the orientation of the diagonal. It made no difference at all, which was strange - the new triangles couldn't be re-triangulated to produce the missing sections and it wasn't a case of particular triangles being missed because the new triangles ran across the missing area:/ Then I went back to the original rectangular polys and tried sub-dividing them. This actually changed the shape of the missing sections but didn't fix it:\ Fortunately, re-sizing it a little did:) Lot of messing about though. LeeE Ultimately though, the quality of anything we do has to increase and without some revolutionary changes in graphics technology this is going to mean more complex and detailed models. Agreed. Anyway, very nice model. The nose looks great. The 747 nose, which is actually a little simpler than that one, has been about as challenging as anything I've done so far and it still is not right. Best, Jim ___ 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] AN225
Lee Elliott [EMAIL PROTECTED] said: On Thursday 02 October 2003 03:52, Jim Wilson wrote: BTW there is a plib bug showing up on the bottom. That is one example of how the ac3d loader really is screwing up the shading. My guess is the optimization is to blame. Checking it out in wire frame mode (in flightgear) might reveal something. It would be awful nice to do away with that step. Oops - I thought I'd got 'em all;) I'll have a look at it. The model loader/renderer does do some funny things at times - I've been re-working the TSR-2 and hit a problem on the front canopy inner lining where a couple of sections seemed to be clipped out of it in fgfs. I remember you showing me some screen shots of a similar problem you had with the tip of the p-51d control-stick. Anyway, I could see that the missing sections were the diagonal halves of the original rectangle so I thought I'd manually triagulate the effected polys but switch the orientation of the diagonal. It made no difference at all, which was strange - the new triangles couldn't be re-triangulated to produce the missing sections and it wasn't a case of particular triangles being missed because the new triangles ran across the missing area:/ Then I went back to the original rectangular polys and tried sub-dividing them. This actually changed the shape of the missing sections but didn't fix it:\ Fortunately, re-sizing it a little did:) That works sometimes. The problem is that the optimization tries to merge polys together that it thinks it can. The exact criteria I haven't gotten into yet. Probably looking harder at the code would reveil the exact process. The reason I haven't looked hard is that I am fundamentally opposed to having plib DO ANYTHING to change my model when it loads it. It seems that the plib ac3d loader will eat vertices (so to speak) when all the vertices are within a certain tolerance of each other as opposed to exact matches. Probably Steve or whoever wrote the optimization was trying to compensate for sloppy modeling and by merging together vertices that were really close togehter. Of course this begs the question of what do you call really close? That is where the problem lies. Another thing that I found works can only be used when the surfaces are untextured or textured with a solid color or pattern. If you map adjacent surfaces differently, then the vertices won't line up in the file. For example, map one surface to XY and the next to XZ the next to XY and so on. I used that method to fix some knobs in the 747. The reason why it works probably has something to do with the optimizer _not_ reordering vertices to find a match. That would result in a different normal with AC3D models. Last I looked at the code it seemed as though we could customize a good part of the ac3d loader in simgear without having to redo or copy the entire guts of it. It would be _really_ nice to have this fixed. I'm not sure that the people who have opposed reimplementing the loader or making a greater effort to persuade Steve Baker to accept a fix realize how much time is involved frigging with these stupid little glitches that the optimizer introduces. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AN225
Jim Wilson wrote: That works sometimes. The problem is that the optimization tries to merge polys together that it thinks it can. The exact criteria I haven't gotten into yet. Probably looking harder at the code would reveil the exact process. The reason I haven't looked hard is that I am fundamentally opposed to having plib DO ANYTHING to change my model when it loads it. I think we can prevent that from happening by calling this line of code: ssgAddModelFormat ( .ac , ssgLoadAC , ssgSaveAC ); Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AN225
Erik Hofman [EMAIL PROTECTED] said: Jim Wilson wrote: That works sometimes. The problem is that the optimization tries to merge polys together that it thinks it can. The exact criteria I haven't gotten into yet. Probably looking harder at the code would reveil the exact process. The reason I haven't looked hard is that I am fundamentally opposed to having plib DO ANYTHING to change my model when it loads it. I think we can prevent that from happening by calling this line of code: ssgAddModelFormat ( .ac , ssgLoadAC , ssgSaveAC ); Yes, exactly. That's what I meant when saying that we wouldn't have to rewrite the whole thing. I doing just that once before and the result was the model came out flat shaded. We need the part that traverses the tree and calculates the normals which is buried in the optimizer. This is part of the stripify function and I would guess this is where we get to the shading: /* So, now we have all the important information sucked out of all those nodes and safely tucked away in the OptVertexList Let's take this opportunity to compute vertex normals. */ list . makeNormals () ; Setting up for this is the part I don't quite understand yet. list is an object of the OptVertexList class (optimized vertex list). Idealy, and this does involve some modification to plib, we would also fix the loader so that it'll respect the shading paramter in the ac3d surface structure. The most important part is getting rid of the optimization step. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AN225
On Thursday 02 October 2003 21:21, Jim Wilson wrote: Lee Elliott [EMAIL PROTECTED] said: On Thursday 02 October 2003 03:52, Jim Wilson wrote: BTW there is a plib bug showing up on the bottom. That is one example of how the ac3d loader really is screwing up the shading. My guess is the optimization is to blame. Checking it out in wire frame mode (in flightgear) might reveal something. It would be awful nice to do away with that step. Oops - I thought I'd got 'em all;) I'll have a look at it. The model loader/renderer does do some funny things at times - I've been re-working the TSR-2 and hit a problem on the front canopy inner lining where a couple of sections seemed to be clipped out of it in fgfs. I remember you showing me some screen shots of a similar problem you had with the tip of the p-51d control-stick. Anyway, I could see that the missing sections were the diagonal halves of the original rectangle so I thought I'd manually triagulate the effected polys but switch the orientation of the diagonal. It made no difference at all, which was strange - the new triangles couldn't be re-triangulated to produce the missing sections and it wasn't a case of particular triangles being missed because the new triangles ran across the missing area:/ Then I went back to the original rectangular polys and tried sub-dividing them. This actually changed the shape of the missing sections but didn't fix it:\ Fortunately, re-sizing it a little did:) That works sometimes. The problem is that the optimization tries to merge polys together that it thinks it can. The exact criteria I haven't gotten into yet. Probably looking harder at the code would reveil the exact process. The reason I haven't looked hard is that I am fundamentally opposed to having plib DO ANYTHING to change my model when it loads it. It seems that the plib ac3d loader will eat vertices (so to speak) when all the vertices are within a certain tolerance of each other as opposed to exact matches. Probably Steve or whoever wrote the optimization was trying to compensate for sloppy modeling and by merging together vertices that were really close togehter. Of course this begs the question of what do you call really close? That is where the problem lies. Another thing that I found works can only be used when the surfaces are untextured or textured with a solid color or pattern. If you map adjacent surfaces differently, then the vertices won't line up in the file. For example, map one surface to XY and the next to XZ the next to XY and so on. I used that method to fix some knobs in the 747. The reason why it works probably has something to do with the optimizer _not_ reordering vertices to find a match. That would result in a different normal with AC3D models. Last I looked at the code it seemed as though we could customize a good part of the ac3d loader in simgear without having to redo or copy the entire guts of it. It would be _really_ nice to have this fixed. I'm not sure that the people who have opposed reimplementing the loader or making a greater effort to persuade Steve Baker to accept a fix realize how much time is involved frigging with these stupid little glitches that the optimizer introduces. Best, Jim Ta for the explanation - it makes some sort of sense now and is understandable in the context of 'loose' vertices. I'd much rather it didn't try any optimisations with the geometry though - it's better fixed by fixing it in the model, imo. As this problem is mostly encountered with small objects, where the vertices are close together, I've wondered about it occurring while modelling VC instruments. I've not tried doing any yet but considering how easily it can occur with something the size of a canopy hoop, the thought of trying to sort it out on an instrument part, like a needle is a bit off-putting. Have you had many problems with the instruments you've done? LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [flightgear] Re: [Flightgear-devel] AN225
Lee Elliott wrote: Ta for the explanation - it makes some sort of sense now and is understandable in the context of 'loose' vertices. I'd much rather it didn't try any optimisations with the geometry though - it's better fixed by fixing it in the model, imo. As this problem is mostly encountered with small objects, where the vertices are close together, I've wondered about it occurring while modelling VC instruments. I've not tried doing any yet but considering how easily it can occur with something the size of a canopy hoop, the thought of trying to sort it out on an instrument part, like a needle is a bit off-putting. Have you had many problems with the instruments you've done? I guess the close factor is a percentage of the dimensions of the whole model. I had those problems with the knobs of the A320 but the instruments modelled independently are fine. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AN225
Hi Lee Great aircraft.You sure know how to make us feel inadequate.LOL Would just like to ask a couple of questions if I may What program did you use for the model. The texture looks like it is made in layers I have never seen this before.What did you use to make it. And now I am going to have to spend a couple of weeks reading your animations xml to see how you have done things.Makes the animations I have done look rather crappy. Once again great job. Cheers Innis The Mad Aussi _ Hot chart ringtones and polyphonics. Go to http://ninemsn.com.au/mobilemania/default.asp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AN225
Innis Cunningham wrote: Hi Lee Great aircraft.You sure know how to make us feel inadequate.LOL Just to get ahead of every one, the 10,000+ vertices are just too much for my poor O2. One every 20 seconds is slightly too slow for good simulation purposes. Try to get somewhere near 1,000 and you should be fine (actually 2,000 will be fine also, but so far all my models ended up near 1,000 vertices). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AN225
On Wednesday 01 October 2003 11:42, Innis Cunningham wrote: Hi Lee Great aircraft.You sure know how to make us feel inadequate.LOL Would just like to ask a couple of questions if I may What program did you use for the model. The texture looks like it is made in layers I have never seen this before.What did you use to make it. And now I am going to have to spend a couple of weeks reading your animations xml to see how you have done things.Makes the animations I have done look rather crappy. Once again great job. Cheers Innis The Mad Aussi Ta for the compliment, but I've been doing 3d stuff for years. I use Realsoft3D V4.5 on Linux for all of the modelling, export the model in .OBJ format and then import it into AC3D to convert it into .AC format and texture it. I've been experimenting with using 'carrier' objects for a lot of the detail textures and these are probably the layers you're seeing. Basically, I duplicate sections of the underlying surface and then raise them slightly above the surface. Then I map the detail textures, which needs to have a transparent background, onto the carrier object. The advantage of this is that I can use high-res textures without having to texture the entire model at that res, cutting down on the amount of texture space needed. The downsides are that there's a risk of z-buffer problems and I sometimes get some funny black borders around the texture where it blends to fully transparent - on the AN225 for example, this happened at one point where I found that if I added another transparent layer to the image in the Gimp, and then merged the the two layers and re-saved it, without making any other changes, I got the black boundaries around all the red stripes. I'm still trying to track down the cause of this one. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AN225
On Wednesday 01 October 2003 13:39, Erik Hofman wrote: Innis Cunningham wrote: Hi Lee Great aircraft.You sure know how to make us feel inadequate.LOL Just to get ahead of every one, the 10,000+ vertices are just too much for my poor O2. One every 20 seconds is slightly too slow for good simulation purposes. Try to get somewhere near 1,000 and you should be fine (actually 2,000 will be fine also, but so far all my models ended up near 1,000 vertices). Erik Yeah - none of my models could be regarded as low-poly. Then again, the shapes of the models I tend to do are quite complex and not a simple tube like the majority of airliners. There's quite an overhead in doing the detail stuff like the engines and u/c, but I try to ameliorate that by de-selecting all the u/c stuff when it's retracted. I figured out the single-sided polys thing too:) The vertex count is also increased by having to split all the surfaces to avoid the smoothing glitches - every adjacent pair of edges that have been split will have twice the number of vertices but until a better solution to the smoothing problem's found I can't see a good way around it. The poly count is an issue I've thought about quite a lot but I don't think I can acheive the same level of detail and smoothness without using a lot of polys, and as far as sims are concerned there's an irreversable trend towards greater realism where that detail and smoothness is needed. One aspect of the problem is that the renderer is polygon based - whatever gets rendered has to be converted to polys (triangles infact). If it were possible to use a spline based renderer the models wouldn't need to be as complex, at least for smoothness reasons. I'm not aware of any h/w based spline renderers although I believe they're being worked on. Trim curves on a spline surface in h/w would be nice too - ideal for cutting out the windows:) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AN225
Lee Elliott [EMAIL PROTECTED] said: On Wednesday 01 October 2003 13:39, Erik Hofman wrote: Innis Cunningham wrote: Hi Lee Great aircraft.You sure know how to make us feel inadequate.LOL Just to get ahead of every one, the 10,000+ vertices are just too much for my poor O2. One every 20 seconds is slightly too slow for good simulation purposes. Ouch! Are you sure it is vertices and not texture ram? Hmmm...I can remember being blown away by the O2's speed first time I saw one, but that _was_ quite a while ago. :-) Yeah - none of my models could be regarded as low-poly. Then again, the shapes of the models I tend to do are quite complex and not a simple tube like the majority of airliners. There's quite an overhead in doing the detail stuff like the engines and u/c, but I try to ameliorate that by de-selecting all the u/c stuff when it's retracted. I figured out the single-sided polys thing too:) The vertex count is also increased by having to split all the surfaces to avoid the smoothing glitches - every adjacent pair of edges that have been split will have twice the number of vertices but until a better solution to the smoothing problem's found I can't see a good way around it. That wouldn't be a glitch in the sense of a model data or rendering bug though. Usually if I split something it is because I want a more detailed shape, with a smoother curve. IMO that's a good thing, especially in the hands of someone more skilled than myself :-). BTW do systems that store normal data in the model file not have this problem because you can adjust the shading manually? I do not have experience with anything like that. The poly count is an issue I've thought about quite a lot but I don't think I can acheive the same level of detail and smoothness without using a lot of polys, and as far as sims are concerned there's an irreversible trend towards greater realism where that detail and smoothness is needed. Yes. If there is enough demand, however, we could scale down the vertices and add a lowres variant of the bigger models to the base package. There is an option right on the ac3d menu to do that. It'd probably be possible to organize the model wrappers so that the same animation xml would apply to both models. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AN225
Lee Elliott wrote: On Wednesday 01 October 2003 13:39, Erik Hofman wrote: Innis Cunningham wrote: Hi Lee Great aircraft.You sure know how to make us feel inadequate.LOL Just to get ahead of every one, the 10,000+ vertices are just too much for my poor O2. One every 20 seconds is slightly too slow for good simulation purposes. Try to get somewhere near 1,000 and you should be fine (actually 2,000 will be fine also, but so far all my models ended up near 1,000 vertices). Erik Yeah - none of my models could be regarded as low-poly. Then again, the shapes of the models I tend to do are quite complex and not a simple tube like the majority of airliners. There's quite an overhead in doing the detail stuff like the engines and u/c, but I try to ameliorate that by de-selecting all the u/c stuff when it's retracted. I figured out the single-sided polys thing too:) Don't get me wrong, I do like your models very much. But I hate to see all the models having the same level of details. Some aircraft need a lot of polygons, I can understand that. What I'm hoping is there will be a bunch of good quality low polygons aircraft available also (for people like myself using less than optimal hardware). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AN225
Erik Hofman [EMAIL PROTECTED] said: Yeah - none of my models could be regarded as low-poly. Then again, the shapes of the models I tend to do are quite complex and not a simple tube like the majority of airliners. There's quite an overhead in doing the detail stuff like the engines and u/c, but I try to ameliorate that by de-selecting all the u/c stuff when it's retracted. I figured out the single-sided polys thing too:) Don't get me wrong, I do like your models very much. But I hate to see all the models having the same level of details. Some aircraft need a lot of polygons, I can understand that. What I'm hoping is there will be a bunch of good quality low polygons aircraft available also (for people like myself using less than optimal hardware). What's the max you can run comfortably? If you want to do the xml I can upload reduced detail versions of some my models. Let me know which ones are of interest. Do folks think this is a good idea? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AN225
Jim Wilson wrote: Lee Elliott [EMAIL PROTECTED] said: On Wednesday 01 October 2003 13:39, Erik Hofman wrote: Innis Cunningham wrote: Hi Lee Great aircraft.You sure know how to make us feel inadequate.LOL Just to get ahead of every one, the 10,000+ vertices are just too much for my poor O2. One every 20 seconds is slightly too slow for good simulation purposes. Ouch! Are you sure it is vertices and not texture ram? Hmmm...I can remember being blown away by the O2's speed first time I saw one, but that _was_ quite a while ago. :-) That's hard to imagine. I have 448 Mb main memory of which all free memory can be used for textures. But I haven't checked it. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AN225
Could anyone provide a screen dump image of this aircraft flying in FlightGear? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AN225
Lee Elliott [EMAIL PROTECTED] said: If it's not too much effort it's got to be worth looking into. Feel free to try reducing some of mine if you wish. I've had a little play with the reduce function in AC3D but to be honest, it's in the opposite direction to what I want to do. Sure, same here. The 747 will be growing a bit in the latest round of revisions. The low poly version would look very chunky next to the original. David and Fred and have done some excellent low poly models. I'm not particularly interested in doing these versions, but if folks wish to fly models like the wright flyer and the p51d I wouldn't be opposed to adding a low-res file to the base package. It would be difficult for someone to do that themselves if their machine didn't handle the large model in the first place. Having said that, I could probably go through it and manually merge polys where it would have little effect on the appearance but when I've actually tried doing that it hasn't made a huge difference to the overall counts. Yeah I just spent a few minutes looking at the model in ac3d. It really is nicely done. There are _maybe_ a dozen or so vertices that could be removed without affecting appearance. Your texturing approach for this model is very effective no significant depth buffer issues at 24bpp. BTW there is a plib bug showing up on the bottom. That is one example of how the ac3d loader really is screwing up the shading. My guess is the optimization is to blame. Checking it out in wire frame mode (in flightgear) might reveal something. It would be awful nice to do away with that step. Ultimately though, the quality of anything we do has to increase and without some revolutionary changes in graphics technology this is going to mean more complex and detailed models. Agreed. Anyway, very nice model. The nose looks great. The 747 nose, which is actually a little simpler than that one, has been about as challenging as anything I've done so far and it still is not right. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AN225
Curtis L. Olson wrote: Did anyone change anything with property names recently? My flight recorder is also broke now. :-( Not that I'm aware of. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AN225
Curtis L. Olson [EMAIL PROTECTED] said: Lee Elliott has just contributed an AN225 to the FlightGear project and I have just committed it to CVS. This aircraft is the biggest one built for FlightGear so far and it flies and looks really nice. And the 747-400 quietly steps aside :-) BTW the only thing that might be bigger would be a spruce goose, but nothing will beat the an-225 for capacity (close to double the 747?). How much runway does it need at mto weight? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AN225
Jim Wilson writes: Curtis L. Olson [EMAIL PROTECTED] said: Lee Elliott has just contributed an AN225 to the FlightGear project and I have just committed it to CVS. This aircraft is the biggest one built for FlightGear so far and it flies and looks really nice. And the 747-400 quietly steps aside :-) BTW the only thing that might be bigger would be a spruce goose, but nothing will beat the an-225 for capacity (close to double the 747?). How much runway does it need at mto weight? Not sure, Lee has done a bit of research so he probably would know. It has a huge wing and 6 engines so it may not be all that bad. The only thing that is missing is the Soviet space shuttle to go on top. :-) Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AN225
Lee Elliott has just contributed an AN225 to the FlightGear project and I have just committed it to CVS. Does the an225 need an an225-set.xml wrapper? Scanning command line for: --aircraft= aircraft = an225 Cannot find specified aircraft: an225 Scanning command line for: --aircraft= aircraft = T38 Reading default aircraft: T38 from /home/dave/FlightGear/data/Aircraft/T38/T38-set.xml Dave - David Culp davidculp2[at]comcast.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AN225
David Culp writes: Lee Elliott has just contributed an AN225 to the FlightGear project and I have just committed it to CVS. Does the an225 need an an225-set.xml wrapper? Scanning command line for: --aircraft= aircraft = an225 Cannot find specified aircraft: an225 Oh, or more likely, run fgfs --show-aircraft to see the specific name (--aircraft=an225-yasim) Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AN225
David Culp wrote: Lee Elliott has just contributed an AN225 to the FlightGear project and I have just committed it to CVS. Does the an225 need an an225-set.xml wrapper? Scanning command line for: --aircraft= aircraft = an225 Cannot find specified aircraft: an225 Try with --aircraft=an225-yasim -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AN225
It should be there in the an225 directory (requires recent simgear/flightgear CVS.) If you have that, make sure you did a cvs update -d (to fetch newly created directories, which aren't fetched by default.) It isn't there as of ten minutes ago, so I made one. By the way, that's a great model! Ah, I see the aircraft=an225-yasim email. So, with the new all-in-one-directory paradigm FlightGear knows that an225-yasim resides in the directory an225? And aircraft=an255 would refer to a JSBSim configuration called an225-set.xml or an225-jsbsim-set.xml? Also I get this console output on exiting (fresh CVS build as of this morining): Failed to untie property /consumables/fuel/tank[0]/level-gal_us Failed to untie property /consumables/fuel/tank[1]/level-gal_us Failed to untie property /engines/engine[0]/fuel-flow-gph Failed to untie property /engines/engine[0]/rpm Failed to untie property /engines/engine[0]/mp-osi Failed to untie property /engines/engine[0]/egt-degf Failed to untie property /engines/engine[1]/fuel-flow-gph Failed to untie property /engines/engine[1]/rpm Failed to untie property /engines/engine[1]/mp-osi Failed to untie property /engines/engine[1]/egt-degf Failed to untie property /engines/engine[2]/fuel-flow-gph Failed to untie property /engines/engine[2]/rpm Failed to untie property /engines/engine[2]/mp-osi Failed to untie property /engines/engine[2]/egt-degf Failed to untie property /engines/engine[3]/fuel-flow-gph Failed to untie property /engines/engine[3]/rpm Failed to untie property /engines/engine[3]/mp-osi Failed to untie property /engines/engine[3]/egt-degf Failed to untie property /engines/engine[4]/fuel-flow-gph Failed to untie property /engines/engine[4]/rpm Failed to untie property /engines/engine[4]/mp-osi Failed to untie property /engines/engine[4]/egt-degf Failed to untie property /engines/engine[5]/fuel-flow-gph Failed to untie property /engines/engine[5]/rpm Failed to untie property /engines/engine[5]/mp-osi Failed to untie property /engines/engine[5]/egt-degf leave NewTgtAirportInit() Dave -- David Culp davidculp2[at]comcast.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AN225
One of these flew into work last year I think, It's quite spectacular to watch land, it's enormous, blots the horizon out. On Mon, 2003-09-29 at 16:24, Jim Wilson wrote: Curtis L. Olson [EMAIL PROTECTED] said: Lee Elliott has just contributed an AN225 to the FlightGear project and I have just committed it to CVS. This aircraft is the biggest one built for FlightGear so far and it flies and looks really nice. And the 747-400 quietly steps aside :-) BTW the only thing that might be bigger would be a spruce goose, but nothing will beat the an-225 for capacity (close to double the 747?). How much runway does it need at mto weight? Best, Jim ___ 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] AN225
David Culp writes: It should be there in the an225 directory (requires recent simgear/flightgear CVS.) If you have that, make sure you did a cvs update -d (to fetch newly created directories, which aren't fetched by default.) It isn't there as of ten minutes ago, so I made one. By the way, that's a great model! Ah, I see the aircraft=an225-yasim email. So, with the new all-in-one-directory paradigm FlightGear knows that an225-yasim resides in the directory an225? Yes. And aircraft=an255 would refer to a JSBSim configuration called an225-set.xml or an225-jsbsim-set.xml? No, jsbsim is the default fdm so if you specify a non-existant -set file you end up running jsbsim with no aero specified. Also I get this console output on exiting (fresh CVS build as of this morining): Failed to untie property /consumables/fuel/tank[0]/level-gal_us Failed to untie property /consumables/fuel/tank[1]/level-gal_us Failed to untie property /engines/engine[0]/fuel-flow-gph Failed to untie property /engines/engine[0]/rpm Failed to untie property /engines/engine[0]/mp-osi Failed to untie property /engines/engine[0]/egt-degf Failed to untie property /engines/engine[1]/fuel-flow-gph Failed to untie property /engines/engine[1]/rpm Failed to untie property /engines/engine[1]/mp-osi Failed to untie property /engines/engine[1]/egt-degf Failed to untie property /engines/engine[2]/fuel-flow-gph Failed to untie property /engines/engine[2]/rpm Failed to untie property /engines/engine[2]/mp-osi Failed to untie property /engines/engine[2]/egt-degf Failed to untie property /engines/engine[3]/fuel-flow-gph Failed to untie property /engines/engine[3]/rpm Failed to untie property /engines/engine[3]/mp-osi Failed to untie property /engines/engine[3]/egt-degf Failed to untie property /engines/engine[4]/fuel-flow-gph Failed to untie property /engines/engine[4]/rpm Failed to untie property /engines/engine[4]/mp-osi Failed to untie property /engines/engine[4]/egt-degf Failed to untie property /engines/engine[5]/fuel-flow-gph Failed to untie property /engines/engine[5]/rpm Failed to untie property /engines/engine[5]/mp-osi Failed to untie property /engines/engine[5]/egt-degf leave NewTgtAirportInit() Did anyone change anything with property names recently? My flight recorder is also broke now. :-( Thanks, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AN225
On Mon, 29 Sep 2003 12:02:26 -0500 Curtis L. Olson [EMAIL PROTECTED] wrote: Did anyone change anything with property names recently? My flight recorder is also broke now. :-( What's the date on JSBSim.cxx? There were some changes that were made to that file for engines, I think. If that was takenf rom JSBSim CVS to FGFS CVS ... maybe ... Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AN225
On Mon, 29 Sep 2003 11:42:18 -0500 David Culp [EMAIL PROTECTED] wrote: Failed to untie property /consumables/fuel/tank[0]/level-gal_us Failed to untie property /consumables/fuel/tank[1]/level-gal_us Failed to untie property /engines/engine[0]/fuel-flow-gph Failed to untie property /engines/engine[0]/rpm Failed to untie property /engines/engine[0]/mp-osi Failed to untie property /engines/engine[0]/egt-degf Failed to untie property /engines/engine[1]/fuel-flow-gph Failed to untie property /engines/engine[1]/rpm Failed to untie property /engines/engine[1]/mp-osi Failed to untie property /engines/engine[1]/egt-degf Failed to untie property /engines/engine[2]/fuel-flow-gph Failed to untie property /engines/engine[2]/rpm Failed to untie property /engines/engine[2]/mp-osi Failed to untie property /engines/engine[2]/egt-degf Failed to untie property /engines/engine[3]/fuel-flow-gph Failed to untie property /engines/engine[3]/rpm Failed to untie property /engines/engine[3]/mp-osi Failed to untie property /engines/engine[3]/egt-degf Failed to untie property /engines/engine[4]/fuel-flow-gph Failed to untie property /engines/engine[4]/rpm Failed to untie property /engines/engine[4]/mp-osi Failed to untie property /engines/engine[4]/egt-degf Failed to untie property /engines/engine[5]/fuel-flow-gph Failed to untie property /engines/engine[5]/rpm Failed to untie property /engines/engine[5]/mp-osi Failed to untie property /engines/engine[5]/egt-degf leave NewTgtAirportInit() Dave Oops - sorry - you are probably referring to the AN-225-YASim, which would not be affected by JSBSim changes. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AN225
On Monday 29 September 2003 16:24, Jim Wilson wrote: Curtis L. Olson [EMAIL PROTECTED] said: Lee Elliott has just contributed an AN225 to the FlightGear project and I have just committed it to CVS. This aircraft is the biggest one built for FlightGear so far and it flies and looks really nice. And the 747-400 quietly steps aside :-) BTW the only thing that might be bigger would be a spruce goose, but nothing will beat the an-225 for capacity (close to double the 747?). How much runway does it need at mto weight? Best, Jim I saw one figure of 9,200ft. Didn't say what altitude it was though;) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AN225
On Monday 29 September 2003 16:24, Jim Wilson wrote: Curtis L. Olson [EMAIL PROTECTED] said: Lee Elliott has just contributed an AN225 to the FlightGear project and I have just committed it to CVS. This aircraft is the biggest one built for FlightGear so far and it flies and looks really nice. And the 747-400 quietly steps aside :-) BTW the only thing that might be bigger would be a spruce goose, but nothing will beat the an-225 for capacity (close to double the 747?). How much runway does it need at mto weight? Best, Jim I got 9,200ft from the only site I found that had anything more detailed than the obvious data. Didn't say at what alt that was so I've assumed sea level. Trouble is, although I made quite a few notes, I didn't actually book-mark the site:/ It also gave the max landing weight and the max taxiing weight, both of which are quite a bit below the mto, but I didn't make a note of those exact figures either:( (=about 0.85 fuel load, iirc) I didn't really realise exactly how big this a/c was until I was well into working on it but the range of flying weights is pretty extraordinary - roughly between 600,000lbs - 1,200,000+lbs. With a full fuel load for max ferry range (15,000km) more than half the t/o weight is fuel (600,000lbs) I got some good pics of it flying at an airshow, where it appears to be surprisingly agile for such a large plane, but then it probably had less than a 5% fuel load and with over 300,000lbs of thrust, at around 700,000lbs of weight, it would've had lift and energy to spare. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
