alpilotx

Well, which ever way you choose, you will have to "pay a price" ... at some point it will be irrelevant, if you have 1.000.000 tiny forest polygons or 1.000.000 single objects ... OR, maybe in this case, the objects might even win ... as it might be more expensive to have those million polygons (while each of them still only contributes 1-2 trees!) than a million single objects ... At least the DSF size would suffer, and the DSF laod time too (while X-plane extrudes the trees from all forest polys). But in the end, when everything is loaded, the overall amount of objects will decide (and then its almost irrelevant where they come from) ... so, with "too many" objects, you will always be able to bring FPS to its knees ... Thats why we (and you here) already tell potential 3D building developers to make their stuff as easy as possible (because the simpler, the cheaper ... when it comes to FPS).

Hi Tony, Well, now you are going a bit too far with FOR forests (and I never told, that trees should ONLY be placed as forests ) ... if you only need a single object (or two), then there will be no difference if you place it as an object (as long as the object is a similarly simple one like the billboarded forest stuff). For a single (or two) tress, it might be even a tiny bit more expensive to use the forest mechanism! So, as a rule of thumb: if you need an area filled with lots of trees (well, at least more than lets say 5-10), or need a line of trees, or have a long line string (with many segments) where you want trees at the vertices: then use the FOR approachif you want single (or very few) trees placed at a given location, then use objects ....I am doing the same in my NZ Pro scenery. For real forests and tree lines, i use the FOR approach. For the single trees (the raw data has a few million such data points in New Zealand!) I use a randomized set of objects placed at the right location. ==> always using the most reasonable approach.

I don't exactly understand what you are asking about? What shall be affected by flatten? The "basement" of buildings is there to make them look more natural (and not seem like floating partly in the air), when parts of them would hang in the air because of sloped terrain. That works everywhere ... what ever the reason of sloping under them would be.

Looks much better! And its a good idea to make it "deep" (I usually go to 8-10m) .... it makes you safe even on steeper terrain (and you never lnow in advance, where those OSM objects end up in the X-Plane mesh world ). And the wider the object is, the deeper the basement should be (just plain trigonometry: the longer the "overhang", the higher it "floats").

Hi Tony, they look good ... BUT! I immediately see, that you "ignored" one of my advices: always give your buildings "deep" basements (they don't need to be detailed, just some "concrete" / "brick" walled box, stretching down 5-10m). This way, when the objects are placed on sloped terrain, they don't immediately look like they "halfway" float in the air. They look much more plausible that way .... I did this with all of my objects in the NZ Pro scenery and the "treelines and farms scenery" farm buildings (you can check them as "reference").

Just as a side note : with IP address blocking you almost always have "collateral damage" ... so, even though, a site might have nothing against you personally, it might have big issues with hackers / spammers etc. from a given IP range / domain / country (what ever level they choose as appropriate for blocking). And in that case, every "normal" user from the same IP range is banned (even if they didn't do anything bad). So, at least some of these "not understandable blocking" might be the side effect of fighting the "bad guys" on the net ... Its not always fair, neither perfect, but in some situations it might be the single most effective "weapon" (and as all weapons --> "collateral damage").

Aah, the indexing problem ... well, that is one of the very big pluses on the PostGIS side ... You get geometry indexing (GIST indexes) out of the box (otherwise it wouldn't qualify to call itself a GIS database ). But again, even though using PostGIS is nice, it ads some administrative overhead, which is not necessarily for the faint hearted (at least not for users who don't know much about databases).

Hi Tony, Yes, thats exactly what will take most of my time ... doing a halfway sane removal of parts of the tree lines, where it would collide with something else. Though, if you want to accomplish it in a finite time, you will always need to accept some compromises because some geometric operations are anything but cheap (when it comes to processing time - or you own sanity). Well, I will see how it works (but will take some time until I see first results :-) ) ... By the way, in what "language" are you coding / scripting your way? Most of my - current work - is done in PostGIS ... which already makes it less accessible for average users, as you need to run a PostGIS (effectively a PostgreSQL with PostGIS extension) database. But when its running, then PostGIS is a mighty powerful set of GIS functions, which helps to solve a lot of problems (but not necessarily always easy ) and one can work with a database approach (which I like, as I am used to big databases anyways). .... PostGIS is also my main tool to extract all the necessary data for Laminar and/or my HD Mesh Scenery v2 ... And it works quite nicely with a complete planet OSM export (as long as you can use a big and fast SSD to stoe the database on).

... yes, indeed I am currently not as active as at some other times (but really need some break from time to time, with family, real life etc. etc.) ... BUT I also have started work on my next little project. It wont be something entirely new, but it will be a welcome (I think, very welcome) update of a well know project. It will be the "X-Plane 10 Tree Lines and Farms v2" ... I will extend the coverage of the old project a bit, tune a bit here and there, and add a new (and I think this will be the most noticeable update) feature, namely tree lines along water features ... But don't ask me for timing, as i don't know. Something between a few weeks and a few months ...

Hi Tony Well, this is another approach I wanted to "recommend" since a long time .... namely, using some "external" (and not just OSM landclass info!) data as a "hint", when deciding about buildings which otherwise only have building=yes ... Indeed, landclass information can be a help .... sometimes ... sometimes not. It always depends on the data quality, resolution and what classification it brings (or brings not) .... For example in Europe, you will find information about industry areas in the CORINE landclass data (which I also use in all my X-Plane work since ages) .... Its not super detailed with its 100mresolution, but neither is it that bad (maybe combined with footprint extent, it might work halfway sanely) .... Or for example in smaller cities, which don't have detailed building infos either, one could use some "density" information to decide, where you would see "family" houses or a bit larger city blocks etc .... Just some ideas. PS: and by the way, I think (I know!) if you work with raster landclass data instead of polygon data (for lookups), you might get much faster results ... of course, the price you pay is, that raster data has an inherent "resolution" limit.

Thats what HD Mesh Scenery v2 is there for (other than seasons) ... To my knowledge there will neither be large scale scenery recuts (only maybe some smaller, very critical regions fixed), and definitely no seasons stuff (thats a very big pile of work, which won't happen overnight) ...

And a few more, important constraints on "auto-placed" buildings: they should always have a "basement" attached (a grey block etc.), which goes below the (0,0,0) origin! This way you will not have "floating" / "half floating" objects, when they are placed on sloped terrain!try to have as much objects as possible use as few as possible texture files (rather use a few 2048x2048 ones) ... always try to put as many texture elements in a file as possibleAnd about the size .... I think, you could avoid the need for "object size calculations", if there would be a naming scheme which has the dimensions already included. I think, its overall an important factor to have a sane naming scheme, which already "represents" the main characteristics of the building (footprint dimension, height in levels, color, type, main form, etc.). This can vastly improve possibilities to automate the scenery generation. The longer I think about it, the more I would say, that maybe it would be time to create an "own" new object library, which is focused on OSM scenery generation. Would have facades, a wast amount of default house types, a few other, more specific objects (like churches, petrol stations, wind turbines, light houses etc ... the classic OSM entities you would find on all maps) and also vegetation stuff (forests and single tree objects).

This is very interesting, and I am very happy that there are more and more "approaches" to OSM coming to life .... its always nice to have choices, as they usually open up different ways to go ... or to tweak / improve in different ways. Myself i was also thinking about an additional "feature", which PilotBalu was dreaming about a long time. Namely, to not translate every OSM building footprint as facades .... But instead only larger objects (in cities, industry etc.)! For all smaller / simpler (consisting of only 4-10-16-etc. line segments, being non complex, covering a small area etc.) footprints instead we could use objects, which would vastly improve the ability to customize / beautify the result (and even make more complex objects, like churches etc. possible, which is hard to do with facades only). PilotBalus (and others) idea was (and I thought about it ... and see it as a good idea) .... to categorize the footprints, and for the small / simple ones, do derive the - geometric - center point, derive its orientation (with some approximation, this could be done with quite simple analysis of the geometry), and maybe derive some "characteristic" from the footprint size and generic form. Then use all of this information to add objects in the X-Plane world instead of the facades. This could result in some fantastic stuff especially in rural areas, where the plain "facade" approach is not always "optimal" (whereas the facades are great in cities, and for all mor complex buildings of course!) .... Then there is one final thought .... which also results from the object approach. There is one thing, which all of this - and even th facade approach - is missing. Namely, the artwork (PilotBalu brought this up quite a few times - and not much happened). The object approach would work best, if we had a large library of simple (low polygon count), nice looking, and with good texture usage (where not each object needs its own texture file, but many objects take their "paint" from a few, large, texture files) building objects to choose from. I might even consider participating in such an initiative (I am not a master 3D modeler, but did already do some "easy" Blender work for some of my sceneries) ... What would also be cool, if the artwork used in all OMS approaches (being OSM2XP, PilotBalus facade sets, this new approach by tonywob etc.) could be put in some "open" library (like OpenSceneryX - or maybe we could even push for a more coordinated / massive extension of current v2 OpenSceneryX to cover more art assets for OSM needs), where everybody could use / reference them for their own OSM scripts (thus we would make it even easier for others to chip in) ... and hopefully even extend the artwork set over time. ... Well, just dreaming a bit ... but I think this might move forward all OSM ideas quite a bit (where I have a few "ideas" too ... but without artwork readily available, its often a long way).

And it looks more and more impressive! Keep up the good work!

But you see, the bid dilemma here!? For many years, people were all whining on and on, that X-plane needs some default airport scenery ... and so on, and so on .... Now it finally becomes reality (by the community approach with Lego bricks), and then again many are unhappy. But there is an easy switch: just diable all default airports in you Scenery_packs.ini (in Custom Scenery) by changing the line SCENERY_PACK Custom Scenery/Global Airports/to SCENERY_PACK_DISABLED Custom Scenery/Global Airports/Then it will not show again until you re-enable it (but of course, this will disable all default airports). In the long run, EXLUSIONs are the way to go ... even if its now a pain.

Guys, the problem is not really the INI, nor does it solves the "core" problem, neither is that the central meaning of the link: http://developer.x-plane.com/2013/11/an-exclusive-club/ The INI only specifies the priority of sceneries (layering). Which scenery should come first, second, etc. But, the main problem still remains: that each scenery should (but many don't do this until now) specify what kind of other scenery elements should be EXCLUDED within its premises (defined via. EXCLUSION zones), and which not. And the developer has quite a list of choices, what he wants to be excluded from lower layer scenery: http://scenery.x-plane.com/library.php?doc=dsf_xplane.php And that is what the link above is about. That scenery authors MUST to take care of this exclusion explicitly, because X-Plane can't tell on his own, what scenery elements should disappear and what not from lower layer scenery (and neither should X-Plane do that, because sometimes it is desirable to mix elements from different scenery layers)! As long as such exclusions are missing, you will always see mixing of scenery elements with elements from lower layer scenery.

This little free(donationware) script (now in Version 2) helps to transform most parts of DSF files of X-Plane 10 Global Scenery to the GML format. The GML file then can be opened with most modern GIS tools, like the open source tool QGIS, to visualize the internal data structure of the DSF. DISCLAIMER / IMPORTANT: this tool is only for technically versed / interested persons, who know: how to work with the command linehave basic knowledge of scripting languages (especially AWK)do know what GIS means, and how to work with GIS tolls!I will NOT give support/help of any type to people who obviously lack any of these skills! This tool is only for visualization purposes and will in no way help you edit the basic DSF structure! Currently it recognizes these DSF features (and their properties – you can read a lot on them and their use and properties under this link): terrain triangles (physical and overlay) this also means water (.TER)TERRAIN name of terrain type assignedFLAG physical or overlayforests (.FOR) polygons and linesTYPE forest name (FOR) used1. FLAGstrings (.STR)TYPE string name (STR) used1. FLAGbeaches (.BCH) only generic, no type identificationTYPE beach name (BCH) used1. FLAGlines (.LIN)TYPE line name (STR) used1. FLAGdraped polygon (.POL)TYPE polygon name (POL) used1. FLAGfacades (.FAC)TYPE facade name (FAC) used1. FLAGautogen blocks (.AGB)TYPE autogen block name (AGB) used1. FLAGautogen strings (.AGS)TYPE autogen string name (AGS) used1. FLAGautogen points (.AGP)TYPE autogen point (AGP) used1. FLAGnetworks (road, railroad, powerlines) these are currently only identified by their roads.net subtype numbers!SUBTYPE number of network segment (road, railroad, powerline)objects (.OBJ)TYPE object name (OBJ) usedORIENTATION rotation of the objectYou can see a few screenshots showcasing the usage of the resulting GML files in QGIS here: DSF-to-GML v2 script and QGIS It works on Linux, Windows and I think on Mac too. Infos and download is in the Tools / Scripts section of my web site: http://www.alpilotx.net/tools-scripts/xp10_dsf-to-gml_v2_script/

Yes, I definitely like it ! I hope you will do more videos of the HD Mesh Scenery v2!

Well, I would strongly recommend you contact the developer of the utility, as he is the most likely to give you some "answers" (I for example did never try this tool).

Then something might be wrong ... because usually it does ... Like for example when you do "DSFTool -dsf2text +57+011.dsf +57+011.txt", then you should get 3 files: +57+011.txt+57+011.txt.elevation.raw+57+011.txt.sea_level.rawOh, and please remember, that the DSF is usually implicitly 7zip-ed ... so, decompressing it beforehand might help (hmmm, but newer DSFTool versions should - as far as I know - do the decompressing on their own)!

Hmmm ... I think you should get everything needed (at least as an example) if you do convert a default mesh DSF to TXT ... In that case dsf2txt usually also spits out the different raw files. And then you see what it expects when you do it the other way around (text to dsf).

Correct. Default Global scenery vs. HD Mesh Scenery v2 ....

I have received many questions every now or then abut "whats the difference between default and HD". So I decided to start a new album in my Picasa collection. This time its all about comparing: default GlobalSceneryvs. HD Mesh Scenery v2I used my little trick to capture each scene with exactly the same camera perspective (so you can easily flip back and forth between the pictures and see what happens). I have already added a few regions like, NorwayAlpsCanada, BC (man was I impressed by the extreme differences there ... its an entirely new feeling ... really)... and will continue to add a few over the coming days (all depending on my time). So, head over there, and check them out: https://picasaweb.google.com/101666907909842492197/XPlane10HDMeshSceneryV2DefaultAndHDComparisons?authuser=0&feat=directlink And if there is someone new, who does still not know whats HD Mesh Scenery v2: http://www.alpilotx.net/downloads/x-plane-10-hd-scenery-mesh-v2/

This sounds like as if you don't have a really stable internet connection .... if it is disrupted every now or then, that could easily lead to broken files. In this situation, the BitTorrent approach might help, which can easily take care of "half finished" files (it just continues where it was stopped) ... Just google a little bit about it, and you might find it as a viable option in your case. You - and others - might also read the official "press release" from flightsim.com about the download issues (they were / are completely overwhelmed): http://www.flightsim.com/vbfs/content.php?14420-Slow-Downloads-Unprecedented-Demand

Yes, from what I see, you have some corrupted (half finished) downlaods ... effectively you can't use them. Either retry from flightsim.com or try the - in the meantime - other listed options on my download page!