From: Roberto I. <ro...@gm...> - 2006-12-28 18:19:18
|
Hi, I am digging into terrain tiles creation in order to get a few airports layout more close to reality. I wonder if there's an alternative or if there's even space to experiment new ways in getting a highly customized geometry (especially for airport terrain meshes). I am not very satisfied about the TaxiDraw/Terragear pipeline because of its limitations in the mesh creation technique. Using TaxiDraw rectangle blocks is not flexible enough to get proper custom geometry. I understand TerraGear is aimed at building airports layout from a specific data format and does not accept other kind of geometries for taxiway/runways/aprons. Since terrain meshes are based on triangles, I see full flexibility in that (more than what's used today). I guess rectangle blocks (I refer to taxiway/runway/aprons) were choosen in order to get airport layouts quick and easy (automatic texture mapping and lighting positioning from standard source data) but are not mandatory. I would not be surprised if someone tells me I could model my own airport mesh using any kind of geometry, texture it with custom image files, position lights (border, middle, PAPI etc...), windsocks and so on. All without being stuck to TaxiDraw/TerraGear limitations. Maybe TerraGear would be used anyway when compiling the custom mesh to a suitable .btg file, even if it does not come from a .dat TaxiDraw output? Well, what should I investigate for? I guess a good knowledge of the .btg file format would be a good first step, but ... here I get puzzled. I did find very few details on that. BTG stands for Binary TerraGear, right? Nothing more to know? Should I really read Terragear source code to get it clear? Should I search into Simgear docs? I'd really appreciate if someone could share some thoughts about this topic with me. I'd like to try and get a high quality airport layout and I'm open to not very standard approaches if needed. Curtis, I understand you are very busy with a lot of stuff, do you have any hints for me anyway? thanks, Roberto |
From: Ampere K. H. <amp...@sy...> - 2006-12-28 19:11:14
|
On Thursday 28 December 2006 13:17, Roberto Inzerillo wrote: > Hi, > I am digging into terrain tiles creation in order to get a few > airports layout more close to reality. I wonder if there's an > alternative or if there's even space to experiment new ways in getting a > highly customized geometry (especially for airport terrain meshes). > > I am not very satisfied about the TaxiDraw/Terragear pipeline because of > its limitations in the mesh creation technique. > > <snip> > > thanks, > Roberto Last year, a few others and I did experiment with converting FAA airport diagrams (vector PDF) into 3D models then importing them into FlightGear... if that's what you are looking for. Ampere |
From: Curtis O. <cur...@gm...> - 2006-12-28 19:46:03
|
On 12/28/06, Ampere K. Hardraade wrote: > > On Thursday 28 December 2006 13:17, Roberto Inzerillo wrote: > > Hi, > > I am digging into terrain tiles creation in order to get a few > > airports layout more close to reality. I wonder if there's an > > alternative or if there's even space to experiment new ways in getting a > > highly customized geometry (especially for airport terrain meshes). > > > > I am not very satisfied about the TaxiDraw/Terragear pipeline because of > > its limitations in the mesh creation technique. > > > > <snip> > > > > thanks, > > Roberto > > Last year, a few others and I did experiment with converting FAA airport > diagrams (vector PDF) into 3D models then importing them into > FlightGear... > if that's what you are looking for. > > Ampere > > I've done some very limited and reasonably successful experiments with recreating an area in Multigen Creator (I'm not claiming any particular 3d modeling skills here, I'm horrible at it) and then just placing the model in the FlightGear world a meter or two above the original surface. In my case we created a simple grid and laid google earth imagery on top of it ... it was an internal not-redistributable effort, although we did get explicite permission from google to post/publish screen shots. Curt. -- Curtis Olson - University of Minnesota - FlightGear Project http://baron.flightgear.org/~curt/ http://www.humanfirst.umn.edu/ http://www.flightgear.org Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d |
From: Roberto I. <ro...@gm...> - 2006-12-28 20:46:07
|
> Last year, a few others and I did experiment with converting FAA airport > diagrams (vector PDF) into 3D models then importing them into FlightGear... > if that's what you are looking for. > > Ampere No, that's not the idea. I know about that experiment, I followed the thread and looked at the results. Impressive and mostly usefull when you have high detailed PDF diagrams. But out of my scope. I'm trying to fine model the mesh without using other sources. I'd like to have much more control on the geometry, without the limits imposed by predefined primitives (like TaxiDraw rectangles and lighting schemes). What I need is more freedom when modifying geometry, full controll on mesh vertices movement and alignment; the same goes for textures and lighting positioning. E.g. I like the basic runway texture scheme used in FlightGear, but taxiway/apron textures is way too uncontrollable and rigid when trying to create high quality layouts. What I need is more freedom in creating/modifying geometry. That's the point. That's at least the first step in every possible working pipeline I could imagine. Roberto |
From: Ralf G. <rge...@kn...> - 2006-12-28 21:30:34
|
Hi Roberto! Roberto Inzerillo wrote: > What I need is more freedom in creating/modifying geometry. That's the > point. That's at least the first step in every possible working pipeline > I could imagine. Maybe you are aware that there is a new version of the apt.dat file format upcoming that should provide you with exactly this: more freedom. It shall allow the definition of taxiways and aprons using polygons including - IIRC - rounded edges as well as the exact definition of the locations of markings and lighting. I had started a reorganisation of the TaxiDraw code structure some time ago (might be around 1 year) to support exactly this type of change. Unfortunately, I'm not done yet with the restructuring (essentially, the whole UI codebase is rewritten from scratch) and we'd still need somebody to write an appropriate generator to convert the new apt.dat files into btg-files. I'm currently using my holidays to get as much done as possible on the TaxiDraw reorganisation side. You can follow this by watching the NEW_GUI_CODE branch in the TaxiDraw CVS. We will get that new freedom, but it may still take a bit of time. Cheers, Ralf |
From: Roberto I. <ro...@gm...> - 2006-12-29 15:02:13
|
Typo: But that's _my_ interest right now :-) That's because I ask for suggestions and ideas here. |
From: Roberto I. <ro...@gm...> - 2006-12-29 15:33:42
|
> I like to think about things "algorithmically", but I know that others > prefer to do manual touchups because you can build in so much more detail > and correctness that way. Some how we need to figure out how to bridge > this > divide and make it easy for people to be able to do manual changes to the > airports if they like while still maintaining our ability to > algorithmically > regenerate the world when ever some new revision of one of our data sets is > released. That's the point Curt. I don't care about that now. That's not my aim in any way. Your "algorithmic" approach suits well when thinking globally, and you have to, because you provide a base to a global scenery generation process; that has to follow strict, standardized rules. All that is good but this thread is not about a new way to get the global scenery regenerated with more details, it's about customizing (with high level of freedom) just a few airports, juts the ones a few people are especially interested into. I see space for doing that, it's just about modelling geometry of restricted world areas and integrating it with the already existing terrain mesh; but tools around do not provide a way to develop it (I mean taxidraw/fgsd, maybe even Terragear tools). Roberto |
From: Torsten D. <to...@t3...> - 2006-12-29 07:35:27
|
> Maybe you are aware that there is a new version of the apt.dat file > format upcoming that should provide you with exactly this: more freedom. > It shall allow the definition of taxiways and aprons using polygons > including - IIRC - rounded edges as well as the exact definition of the > locations of markings and lighting. Description of the new format is here: http://www.x-plane.org/home/robinp/Apt850.htm Torsten |
From: Roberto I. <ro...@gm...> - 2006-12-29 13:13:28
|
> Description of the new format is here: > > http://www.x-plane.org/home/robinp/Apt850.htm Good to know for those who don't know :-) I have a question here. Such .dat files define lat/lon but not height (excluding the base airport height). That means the heights are obtained from an external terrain database. What if I want to manually alter the height of some points within the airport area? In case I use this .dat approach, I do have to modify the terrain mesh separately, before merging it with the airport data using TerraGear, right? Roberto -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer |
From: Roberto I. <ro...@gm...> - 2006-12-29 14:57:33
|
> > In > > case I use this .dat approach, I do have to modify the terrain mesh > > separately, before merging it with the airport data using TerraGear, > > right? > > Yes, you are right. Do you have a specific example in mind for such a > modification? Airport Palermo Puntaraisi runway had an incorrect up_and_down height variation in lenght which I suppose was an heritage of not correct terrain mesh elevation data (since I don't recall it in the real one). There's a road at Koeln airport which goes down into a tunnel under a taxiway (in the middle of the airport area) which cannot be modelled without touching the terrain mesh. I think it would be easier to have those details modelled while working on the airport mesh and not on the underlaying terrain mesh. It's just my point of view, that's because I like following a consistent working pipeline where I have full control on the geometry in its whole (comprising height). Maintaining a default height when no modification is needed and letting the developer add personal fine details when wished should be an added value to all that airport generation process. This is not possible with current tools. I know that approach is mostly out of people interest because it regards scenery beautyfying more than flight simulation. But that's _my_ interest right now :-) > Of course, TaxiDraw is not limited to creating apt.dat data as Durk's AI > extension shows. I know that, I'm using the latest development binary available with AI capability built inside, and I find that useful for those who want to dig into that. I do not, at the moment :-) That's because I ask for suggestions and ideas here. Roberto |
From: Ralf G. <rge...@kn...> - 2006-12-29 13:39:01
|
Hi Roberto! Roberto Inzerillo wrote: >> Description of the new format is here: >> >> http://www.x-plane.org/home/robinp/Apt850.htm > > Good to know for those who don't know :-) > > I have a question here. Such .dat files define lat/lon but not height > (excluding the base airport height). That means the heights are > obtained from an external terrain database. What if I want to > manually alter the height of some points within the airport area? In > case I use this .dat approach, I do have to modify the terrain mesh > separately, before merging it with the airport data using TerraGear, > right? Yes, you are right. Do you have a specific example in mind for such a modification? Of course, TaxiDraw is not limited to creating apt.dat data as Durk's AI extension shows. Cheers, Ralf |
From: Martin S. <Mar...@mg...> - 2007-01-07 17:17:48
|
Ralf Gerlich wrote: > Of course, TaxiDraw is not limited to creating apt.dat data as Durk's AI > extension shows. Maybe we can inspire the involved developers to head for a joint effort of TaxiDraw- and FGSD-development here .... ;-) The upcoming 'standard' for editing geographic vector data appears to be "WFS-T". This is a data interchange method that is best used at smaller areas - because it uses XML - and is based on HTTP, thus allowing operation even over a HTTP proxy. Interested parties are invited to read here: http://docs.codehaus.org/display/GEOSDOC/WFS/ http://udig.refractions.net/confluence/display/GOWS/WFS/ http://en.wikipedia.org/wiki/Geography_Markup_Language/ We're in the progress of offering such service for the Landcover-DB which then allows to edit not only lakes, forest, roads and rivers but we'd offer a repository of elevation contour lines as well. Current status of our geodata repository is here: http://wiki.osgeo.org/index.php/Geodata_Repository#PostGIS_serving_vector_data Have fun, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- |
From: Ralf G. <rge...@kn...> - 2007-01-07 17:33:38
|
Hi, Martin Spott wrote: > Ralf Gerlich wrote: > >> Of course, TaxiDraw is not limited to creating apt.dat data as Durk's AI >> extension shows. > > Maybe we can inspire the involved developers to head for a joint effort > of TaxiDraw- and FGSD-development here .... ;-) [SNIP] > We're in the progress of offering such service for the Landcover-DB > which then allows to edit not only lakes, forest, roads and rivers but > we'd offer a repository of elevation contour lines as well. Current > status of our geodata repository is here: I didn't have this in mind, but it fits the concept I had in mind. Especially the elevation contour data might be interesting for people wanting to modify the elevation setup in their airports ;-) Oh, and in the redesign of the TaxiDraw infrastructure I laid much weight on the requirement of the infrastructure being reusable. So if someone has an idea on map editing that doesn't fit the concept of TaxiDraw (and possibly doesn't operate in the mapping context of an airport) can use the basic TaxiDraw infrastructure for setting up a mapping application based on wxWidgets quite fast. Cheers, Ralf |
From: Martin S. <Mar...@mg...> - 2007-01-09 06:29:24
|
Moggeeen ! Ralf Gerlich wrote: > Martin Spott wrote: > > We're in the progress of offering such service for the Landcover-DB > > which then allows to edit not only lakes, forest, roads and rivers but > > we'd offer a repository of elevation contour lines as well. Current > > status of our geodata repository is here: > > I didn't have this in mind, but it fits the concept I had in mind. Das ist doch das Schoene daran, wenn man einen Plan baut und dabei ueber den naechsten Schritt schonmal etwas hinausschaut .... Fuer mich ist das ein wesentlicher Grund, _ueberhaupt_ soviel Zeit da 'reinzustecken. Natuerlich ist es schoen, wenn man etwas macht und dann lobende Rueckmeldung von den Benutzern dafuer bekommt. Noch viel schoener ist es fuer mich aber, wenn man sich Gedanken um die Vorhehensweise mache und sich nach vergleichsweise langer Zeit bestaetigt, dass man quasi in weiser Voraussicht frueher die richtigen Entscheidungen getroffen hat - wenn naemlich verschiedene Einzelteile anfangen, ineinander zu greifen, als sei das schon immer so vorbestimmt gewesen. Beste Gruesse, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- |
From: Martin S. <Mar...@mg...> - 2007-01-09 06:31:56
|
Martin Spott wrote: > Moggeeen ! Disregard ! Sorry for the noise, this should have been a private EMail, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- |
From: Curtis O. <cur...@gm...> - 2006-12-29 15:24:40
|
On 12/29/06, Roberto Inzerillo <ro...@gm...> wrote: > > Typo: > > But that's _my_ interest right now :-) That's because I ask for > suggestions and ideas here. What ever approach we come up with needs to be done in a way that doesn't invalidate all your efforts the next time we regenerate the world scenery or the next time Robin Peel comes out with a new airport and taxiway data set. I like to think about things "algorithmically", but I know that others prefer to do manual touchups because you can build in so much more detail and correctness that way. Some how we need to figure out how to bridge this divide and make it easy for people to be able to do manual changes to the airports if they like while still maintaining our ability to algorithmically regenerate the world when ever some new revision of one of our data sets is released. Curt. -- Curtis Olson - University of Minnesota - FlightGear Project http://baron.flightgear.org/~curt/ http://www.humanfirst.umn.edu/ http://www.flightgear.org Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d |
From: Curtis O. <cur...@gm...> - 2006-12-29 15:42:59
|
On 12/29/06, Roberto Inzerillo wrote: > That's the point Curt. I don't care about that now. That's not my aim in > any way. Your "algorithmic" approach suits well when thinking globally, > and you have to, because you provide a base to a global scenery > generation process; that has to follow strict, standardized rules. > > All that is good but this thread is not about a new way to get the > global scenery regenerated with more details, it's about customizing > (with high level of freedom) just a few airports, juts the ones a few > people are especially interested into. Right, we are talking about the same thing here. I see space for doing that, it's just about modelling geometry of > restricted world areas and integrating it with the already existing > terrain mesh; but tools around do not provide a way to develop it (I > mean taxidraw/fgsd, maybe even Terragear tools). I don't know if I was successful, but when discussing the upcoming apt.datformat to include a much more flexible taxiway spec, I also lobbied to have an airport boundary also included. If this boundary was fixed and never changed, then a user could change anything inside that boundary (leaving the actual boundary points intact) and their airport would always mesh in perfectly with the surrounding terrain, even if we autogenerated the world again. Right now the airport boundaries are derived from the runway/taxiway data so if those change in the slightest bit, the terrain cutout for the airport also needs to change ... that's a hard problem to deal with. So back to your point, there's no reason you couldn't convert an airport model to a more convenient 3d model format and then edit it in what ever tool you want ... ac3d, multigen creator, blender, etc. Regards, Curt. -- Curtis Olson - University of Minnesota - FlightGear Project http://baron.flightgear.org/~curt/ http://www.humanfirst.umn.edu/ http://www.flightgear.org Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d |
From: Roberto I. <ro...@gm...> - 2007-01-02 15:40:17
|
I hope you all had a nice new year start. Ok, now back to FGFS. > I don't know if I was successful, but when discussing the upcoming > apt.datformat to include a much more flexible taxiway spec, I also > lobbied to have > an airport boundary also included. If this boundary was fixed and never > changed, then a user could change anything inside that boundary (leaving > the > actual boundary points intact) and their airport would always mesh in > perfectly with the surrounding terrain, even if we autogenerated the world > again. I have to say I don't think having fixed airport boundaries is _the_ definitive solution to the problem. Things change in time, airport areas grow up and the cities in the world are expanding. There will be changes in terrain geometry every once in a while. Those boundaries will have to change too. Anyway, I don't like to discuss about this point, I will adapt my work to whatever decision will be made in this regard. > So back to your point, there's no reason you couldn't convert an airport > model to a more convenient 3d model format and then edit it in what ever > tool you want ... ac3d, multigen creator, blender, etc. That's where I'm stuck. I don't know how to deal with that conversion. I already asked in ML about the conversion but got no practical answer. Do you have one? Just to be clear, I can make use of whatever common 3d file format but the .btg file is pretty useless right now. And then I need to convert the manipulated 3d file back to .btg; that's "misterious" to me too; do you think we can arrange a way to let Terragear accept some kind of generic 3d file input, .obj .ac or whatever, complete with textures? I will have to struggle with those two basic tasks before going deep into other details. Once I got that cleared out I can investigate more on lighting, ground markings etc... The boundary stuff should not be that big of a problem if I can operate with a generic 3d mesh both in the airport modelling phase and in the Terragear including phase. I guess it's fairly easy to determine those boundary edges in the airport 3d mesh, and later on define them as being the boundary of the hole to be created into the world terrain mesh when it comes to import the airport into terragear. That's my idea, tell me if you see more obstacles to such an apporach. Regarding textures and lighting I would use the standard fgfs textures for taxiway/runway/aprons as a starting point, and I guess I'll stay with that untill I really need new ones. The same goes for lighting, I just want to change the positioning of those light points in space because I don't like the way they are automatically positioned now (specifically on taxiways). Anyway, the starting point is the 3d mesh file conversion. Without this step I wont go far. Should I really write down a conversion script by myself (that will take time and there's no way to tell if I'll be successful :-) ? Did anyone already experimented with that? Roberto |
From: Martin S. <Mar...@mg...> - 2007-01-07 07:18:21
|
Roberto Inzerillo wrote: > > I don't know if I was successful, but when discussing the upcoming > > apt.datformat to include a much more flexible taxiway spec, I also > > lobbied to have an airport boundary also included. If this > > boundary was fixed and never changed, then a user could change > > anything inside that boundary [...] > I have to say I don't think having fixed airport boundaries is _the_ > definitive solution to the problem. Sir, I have to object ;-) Defining fixed boundaries around airfields is a bad idea in the long term. To my understanding FlightGear still focuses on methods that are laid out in a forseighted manner and fixed boundaries is definitely not a part of this collection. While claiming this I have three reasons in mind: 1.) Airport boundaries change. I'm subscribed to the monthly update of the "Jeppesen Bottlang Airfield Manual" and from reading almost every page in these updates I remember that I've seen changing boundaries from time to time. 2.) Maybe one day we'll see a modification maybe not only to the Scenery format itself but also to the process of Scenery creation. If you start adding 'proprietary' geometries into the terrain then you are likely to waste this work one day because you'll probably be unable to reverse-engineer the information on which your detailed airport layout was based. 3.) It's very likely that people not only want to create a detailed arrangement of their local airfield entourage but of other places of intersting geography as well. This would mean scattering fixed boundaries around numerous places around the world - something that definitely will get us into trouble over the time. Therefore I'd like to remind us of some insight that Fred Bouvier posted about one and a half year ago on the fgsd-devel list - and which almost coincindenced with the start of my Landcover Database project: > Instead, I will implement higher level primitives, in the same vein as > current curve embedding. The primitives I am thinking of are : > > - flatten the area in a closed curve, > - embed curves, > - assign material to area of a closed curve, > - draw road or steam along an open curve, > - project a map fragment on the terrain to produce photo-scenery, > - etc... If we're going to define accurate layout of a region by respective primitives like contour lines for detailed description of changes in elevation, then we'll be able to re-use this data whatever way of representing terrain will be used with FlightGear in the future. Frederic has already shown in FGSD that it's feasible to modify the triangle schema of FlightGear Scenery according to countour lines which are defined by the user. If this 'apparatus' would be incorporated into the respective TerraGear tools, then everybody would be able to create one or more contour files (i.e. Shapefiles) for the area of his interest and build the Scenery accordingly. Just for fun: This image is made from a Shapefile which contains elevation contour lines in steps of 10 m around EDDK: http://foxtrot.mgras.net/bitmap/FGFS/EDDK_contour.png .... and the Shapefile is made from SRTM elevation data. The contents of such Shapefiles could be stored and distributed via the same Landcover DB as well and everybody would profit from it. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- |
From: Roberto I. <ro...@gm...> - 2007-01-09 08:19:25
|
Martin Spott ha scritto: > Defining fixed boundaries around airfields is a bad idea in the long > term. To my understanding FlightGear still focuses on methods that are > laid out in a forseighted manner and fixed boundaries is definitely not > a part of this collection. While claiming this I have three reasons in > mind: > > 1.) Airport boundaries change. I'm subscribed to the monthly update of > the "Jeppesen Bottlang Airfield Manual" and from reading almost > every page in these updates I remember that I've seen changing > boundaries from time to time. I agree. Those boundaries are a limitation sometimes rather than an advantage. I understand they're usefull when dealing with Terragear though. > 2.) Maybe one day we'll see a modification maybe not only to the > Scenery format itself but also to the process of Scenery creation. > If you start adding 'proprietary' geometries into the terrain then > you are likely to waste this work one day because you'll probably > be unable to reverse-engineer the information on which your > detailed airport layout was based. That's something you cannot describe as bad practice though. Ok, adding proprietary geometry can be a waste of time if the global terrain changes in time and you want to have the old custom geometry too (that may be tricky). But a bad low detailed terrain geometry is even worse. I don't care if I cannot reverse enginner my new geometry if that's not _my_ new geometry. Nowadays we have few tools to modify the terrain. I am not a GIS expert but I am able to use 3d modelling softwares in a quick and effective way; I can modify a 3d mesh with very nice results, but that's useless if I cannot import it into the FGFS tile scheme. That's the point here. Being stuck to a lowres incorrect terrain geometry (even if that have the ability to be easily upgraded with a future nicer terrain database) is useless. I'd like to create my own airport area terrain geometry now, not in the future. > 3.) It's very likely that people not only want to create a detailed > arrangement of their local airfield entourage but of other places > of intersting geography as well. This would mean scattering fixed > boundaries around numerous places around the world - something that > definitely will get us into trouble over the time. That has been happening since earlier versions of MS-FS and has made a lot of people happy. People pay a lot of money for custom scenery addons. Just a few complained about not being able to use the old scenery addons with the new FS release, they simply buy a new addon upgrade when available if they want to. OpenSource gives FGFS more flexibility, we can think about new strategies in order to minimize this problem, but I don't like thinking we have to stay with the bad scenery when we can get more (even if that works with a single terrain database version only). Anyway, which software tools do you suggest me to use in order to get a more detailed/realistic terrain geometry? I am not talking about big areas, I'm just interested in a few airport areas. I'd like to have a clean taxiway/apron geometry. I'd like to correct a few roads which lead to (and into) the airport area. The other point is adding a few corrections to the terrain heights which are sometimes changing inside the airport boundaries. Not to mention (again) the taxiway lights, textures and ground markings (ILS, CAT II/III, STOP, H, etc...). That could be easily accomplished with any 3d modeller. Beside suggesting me (I hope you will do that anyway) new tools and techniques, do you think abandoning those high sofisticated and very user friendly software tools is really a good choice? Another personal note about the impact of high detailed terrain geometry in performances: that is not a problem! That is a false problem. I am sorry to hear people saying high resolution has to be avoided because computer hardware is not powerful enough. That is changing day by day. We get new and more powerfull hardware every day. If a user has not enough hardware power to render a high detailed scene he can grab the old resolution version, stop. I don't play Oblivion if I don't have enough power to let it render the scene, it's simple as that. Please stop with that old song. And do not think I have a high-end system inside my computer case, it's just an Athlon 2400+. FGFS users have generally more powerfull computers than I have. The correct approach is to try and find an equilibrium between performance and quality, it's not "make it low quality just in case user's computer is not powerfull enough". That's crap. Roberto |
From: alexis b. <xi...@g2...> - 2007-01-09 20:01:33
|
Roberto Inzerillo a =C3=A9crit : > Anyway, which software tools do you suggest me to use in order to get > a more detailed/realistic terrain geometry? I am not talking about > big areas, I'm just interested in a few airport areas. I'd like to > have a clean taxiway/apron geometry. I'd like to correct a few roads > which lead to (and into) the airport area. The other point is adding > a few corrections to the terrain heights which are sometimes changing > inside the airport boundaries. Not to mention (again) the taxiway > lights, textures and ground markings (ILS, CAT II/III, STOP, H, > etc...). I did use FGSD some month ago. That was my first try in enhancing an=20 airport and also change some particular shapes in the landscape. Last FGSD versions doesn't permit mesh editing, as manual editing isn't=20 the purpose anymore. In fact it was quite easy to edit an existng tile=20 with it. Fred could tell you wich version is for you. You could have a=20 try with it. I also did test tile generation after modifing an airport, the point is=20 to preserve nice boundaries between standard and custom tiles, and it's=20 with this problem that I stopped my investigations. Right now I prefer=20 having coherent tiles boundaries and good a distribution of the effort=20 than confidential custom shapes. I'm working again on an airport, KNID,=20 http://croo.murgl.org/fgfs/scenery/index.html and I plan to redraw the=20 taxiway and aprons, but I won't touch the overall terrain tile=20 definition. My concern is to see that airport included in the standard=20 scenery ;) good luck and fun, Alexis |
From: Georg V. <hel...@ar...> - 2007-01-09 21:30:20
|
alexis bory schrieb: > > I'm working again on an airport, KNID, > http://croo.murgl.org/fgfs/scenery/index.html and I plan to redraw the > taxiway and aprons, but I won't touch the overall terrain tile > definition. My concern is to see that airport included in the standard > scenery ;) > > good luck and fun, > > Alexis > Excellent work, especially the textures, real art! But someone like you, spending hundred hours to restore an old window (of this wonderful antique house), has the skills for such a task :-) Looking forward to this scenery. Regards Georg EDDW |
From: Roberto I. <ro...@gm...> - 2007-01-10 12:42:32
|
alexis bory ha scritto: > > I did use FGSD some month ago. That was my first try in enhancing an > airport and also change some particular shapes in the landscape. Hi Alexis, I used FGSD a lot in the past. I still do sometimes for positioning objects around. I think I know it good enough. I used the old version and the new one. But that's useless when it comes to modify the airport area. I.e. thanks for the suggestions but that doesn't help. I'd like to manually create an airport 3d mesh without the limitations FGSD poses. This could be achieved using a common 3d modling software, problem remains how to import the resultin mesh into FGFS scenery tile file system. > I'm working again on an airport, KNID, > http://croo.murgl.org/fgfs/scenery/index.html and I plan to redraw the > taxiway and aprons, but I won't touch the overall terrain tile > definition. My concern is to see that airport included in the standard > scenery ;) Nice work. Will you use TaxiDraw for that? Any alternative idea? Roberto |
From: Martin S. <Mar...@mg...> - 2007-01-07 12:58:13
|
Just for the record, two other 'shots' of the EDDK area: http://foxtrot.mgras.net/bitmap/FGFS/EDDK-contour_01.png http://foxtrot.mgras.net/bitmap/FGFS/EDDK-contour_02.png The second one shows the valley of the river Rhine in the west as well as the junction with the Mosel at Koblenz in the SW-corner. This is a nice example of QGIS showing different layers from different sources: The airfield locations from our Web Mapping Server at http://mapserver.flightgear.org/ and a local shapefile that contains the contour lines. Regards, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- |
From: Roberto I. <ro...@gm...> - 2007-01-09 09:33:42
|
Martin Spott ha scritto: > Just for the record, two other 'shots' of the EDDK area: > > http://foxtrot.mgras.net/bitmap/FGFS/EDDK-contour_01.png > http://foxtrot.mgras.net/bitmap/FGFS/EDDK-contour_02.png Btw, I'm very interseted in EDDK area. Those shots look very nice. Will that be translated to a public terrain release soon? What's the plan? Roberto |