alpilotx

Be very careful with unfounded and unproven accusations ... very careful! Badmouthing can be very dangerous!

I would go a bit further:

Amen In theory yes (as its always possible to edit data structures), in practice no (and I really mean NO ).

It has been postponed a few times for "different" reasons, but in the meantime things are developing quite well ... so, at the moment I expect the release to be in approximately 3-5 weeks.

Sorry, riccardo ... but a few questions / comments brought this thread "a bit" off topic ... And of course it will be free (just a s free as all my other work - like the previous v1 - was) ... I just like to call it donationware (but that means effectively: free).

After some sleep ... some "final" notes Tom, I still have the feeling that you have some way ahead of you in understanding some basic things of computer graphics (the way they are in 2013). Especially when I see a comment like this on Bens blog: "I guess the bottleneck if one can see it like that is the 2D triangle mesh right now. It seems that prevents more details." ... its not a bottleneck ... its the way current graphics hardware understands what you want it to do ... (heck, every other flight sim works - effectively - this way at its core! And with tessellation, it will be even less a bottleneck ... but I have written about it so much here, maybe you should re-read) ... ... but I definitely applaud, that you are study "3D design and animation" ... this should lead you in the right direction. I see that you are a visionary guy, who has a lot of great ideas and indeed, those ideas can move a lot of things forward in the long run. But this way of thinking is sometimes a bit hindering when you need to do real work in an existing environment, with given set of possibilities. And with "give possibilities" I mean things like: how does 3D graphics work at its core, and what can you do with it in a meaningful (and well performing way)? What does a given platform - like X-Plane - provide you (with all of its pros and cons), what can you achieve with it, and what is outside of its scope ... Then one has to always evaluate: if I want to improve / change something, does it makes sense withing the constraints of the platform? Can I improve the platform itself? How much does it "cost" to make that improvement? Will that improvement work on current and future hardware? Is that change something which is "nice in my head" but something which is very hard to "tell" a computer (or a graphics card!) without killing it (and having 0.1 FPS as a result). These are all things, which a developer (especially Ben Supnik) needs to consider all the time .... otherwise his work would easily become "Art for art's sake" (aka ''l'art pour l'art'' ... http://en.wikipedia.org/wiki/Art_for_art%27s_sake) .... where you create something beautiful, but something that just doesn't works on anyones computer. BUT ... this doesn't mean that Ben and Austin don't innvoate in their engine. They do it all the time (and I am part of the team for quite a few years and could see this happen behind the doors) .... but they cant just innovate all the time in one area, and forget a lot of other things they need to do. So they (and me too, by the way !) always need to allocate their resource wisely ... which can easily lead to the impression, that "they are not doing anything about this or that" (from ones own perspective) .... while in reality they are working on other important things which please another 1000 users (but maybe a feature which is less important to you). So, I agree, that there is "nothing that cannot be done" ... BUT, in real life it always means much more than just coming up with fancy ideas (which we all have more than enough) ... its always about weighing pros and cons, (work) resource allocation, cost benefit calculations, feasibility studies (what makes sense at the moment) etc. etc. etc. ... --- And yes, if you have added your missing lakes in OSM ... then you will see them very likely. Because THIS is the only way (well or any other digital form) to tell a computer what is there in real life! Because you can argue as long as you want with X-Plane, telling it "hey, show me that lake ... its there in real life!!!" .... it won't understand you. The only language it understands is data, data manipulation, algorithms etc. (but not "human language" arguing) ... ---

Sorry ... but I have spent now so much time on this (and even in PM with Roman) .... I need to take a break here (and now). I think ,most of the things are already more or less answered here (or "between the lines" ). PS: about the rotation: that is "automatic" and done by the shader (but of course, even a shader can be reprogrammed )

No, no battles here with the triangle mesh .... I have accepted it with all its pros and cons .... and it is anyways the usual way - in computer graphics - to represent terrain. So, nothing really unusual. It only seems annoying if you didn't completely understand how it works, why it works the way it works, why computer graphics likes to use it and why its still not as bad as you might think ! Texturing happens "on top" of the mesh and is not necessarily directly depending on it. The texture repetition is an absolutely basic "feature" of how texturing works in computer graphics. And not making it so repetitive is done by different shaders, which "procedurally" change something in the way the textures get "painted" on the mesh (for example by mixing two different textures ... or using tiling etc. ... we have both the COMPOSITE and TILING shader technique in use ... where applicable). Maybe you should read a little bit about how texturing in general terms works (in computer graphics, not just flight sims). That might help to better understand what is happening here. If a lake is missing or not has nothing to do with the version of X-Plane (I just want to make this clear, so people don't mix it up) .... but only with what is in the DSF scenery files. When you don't change them, then their look (at least what water features are "in" it) should not change. This is a plain data issue! All DSF Mesh scenery 8either the Global Scenery or my HD Mesh v1) is all based on old OSM data from summer 2011. So it only contains water features which were present at that time ... Now the new HD Mesh Scenery v2 (or any other, newer DSFs done by Laminar) will have at least my current / latest OSM data import from 2nd of October (2013) .... And any lakes / rivers / coastlines which have been added until that date, will show up (definitely in my HD Mesh Scenery v2). AND, to answer you other question ... this is the - supported - way how you add lakes / rivers etc. to X-Plane scenery. And I have told this many times in my forum threads over the last months so people had time to edit OSM during that time ... (and a few users did a lot of additions - a big thank you to them!) ... And whether OSM is good or bad ... thats another discussion. From my point of view, its still a fantastic source (even if it has its quirks etc.) So its quite sure, that it will remain one of the main data sources for X-Plane in the coming years. I can only repeat what I told above. Please read a little bit about texturing in general to understand that at least in its basic for its nothing X-Plane special, but a very basic "operation" in computer graphics (and even using shaders to improve the way how textures are applied is nothing special nowadays ... every game does it billion times). Understanding this makes it clear, what happens on the mountains (and everywhere else in the scenery) ... Guys, I really don't enjoy to repeat myself ... There are things which are done in a given way because its the economic and feasible way to achieve a halfway plausible look. There are always other possibilities, but none of them will happen by magic (and always needs a lot of work in some way). So, for example the decisions to use the rotating shaders in a way we use them is born from a necessity (as it makes mountains look much better than with non rotating shaders!) and from possibilities you are given by shaders (and what the target hardware can handle with good enough performance! ... this is something which many forget or can't even understand!). As a contrast, you can use photoscenery .... but you might know, that photoscenery has its own drawbacks too (so there is no super perfect solution .... orat least each solution has its own costs, advantages and disadvantages which need to be weighed up!). Again ... you can avoid misplaced textures when you create scenery by hand .... but now do that on a Global Level Good luck ... Yes, you guys have taken away quite some time from me today ... And I think I have answered most of those question above. About the "collaboration" .... well ... its a good thing. See OSM! Its a massively collaborative work, which helps X-Plane in a really good (and big way) .... And there are other projects in the X-Plane world, where you can collaborate with other users. its just that most people only talk about this - a lot - and rarely really do something about it.

Yes! of course the engine can do a lot ... but its very complex to artificially create a lot of content (we already do much more than you might imagine ) ... As I told in my previous posts: we have ideas about this too ... but none of them are trivial, nor will they happen in the near future (like including the road network structure etc.). Forest lines are a similar idea (do you know my "treeline farms" add-on scenery for Europe/USA ?? You find it on my website) ... which improves exactly this problem ... And another thought: you tell "If you look at Ukrainian fields" .... here you might see the problem. If I (I as a human!) look, then I see that ... but now tell a computer: these are Ukrainian fields, and they look this or that ... and now tell this for 100 different regions ... and define for all of them a unique look (create textures etc.). You see .... this is the problem with a Global Scenery where you want on the one side make everything look as good as possible (well, at least plausible) while on the other side you need to take care of complexity .... and balance the need for human power. If we had a staff like GTA5 has (many hundreds of artists etc.), then anything would go ... but we have to work with what we have at hand ... We try (and as I told you, we already do more of that than many of you might imagine ...) You mane water features (water fields ??? ) like lakes etc ... Then you don't know the other implications of this. Water is until now part of the base triangle mesh! And the more you refine the coastline, the more (and smaller and smaller) triangles you induce into the mesh .... which all "cost" extra. You will see, that in my HD Mesh Scenery v2 I already improve this (having used less vector simplification on the data) ... but even there you won't see super smooth coastlines (but definitely better than in the Global Scenery).

Well, it extremely depends on the landscape too (and as so many users tend to look primarily at their home region ... you often have people who are disappointed and a lot of them are very happy ... depending on how "interesting" their landscape is)! If the raw data - landclass / elevation / water features - gives you a diverse environment (like usually is the case in the mountains etc.) ... then its much easier to generate an interesting landscape out of it. Whereas when the raw data does not give you much variety (for example the landclass says "grass" for 1000 square miles ... and the elevation is flat like a pan) then there it is very hard to make such a scenery look interesting (especially when you need to generate it automatically - which is the case when you model the entire planet). For these cases we have quite a few shader tricks (and even some tricks in the scenery generator) ... like a shader which tries to "mix"/alternate textures via some noise function (to make it less repetitive) ... etc. but even those can't make a big / flat / single landclass area "interesting". This is a complex topic which we work on since quite a long time ... but until now, we didn't have better solutions (yes, some better ideas we have ... but they are something for the future). In you first screenshot there are two of those "dull", repeating patterns ... the city ... which is really bad until now (but will be improved with 10.25/ 10.30), and the forest (I don't know how much tehy will improve ... but ok, its at least looks like a forest). In the second screenshot you complain about the "crop" textures ... again, a very complex issue, because the pattern of crop patterns can be extremely varying and its almost impossible to make this "perfect" by only using a few textures. So here we have to rely on some kind of "plausible" approximation but not have perfect approach .... Still, you can clearly recognize it as agriculture area. In this area there are some ideas for the distant future .... like using the pattern of roads (if they exist in the source data) to derive some more realistic agriculture patterns (but this is nothing you should expect in a year or two). Still, you always have to remember, that with a Global Scenery style "generic" approach, you always have to simplify and work with generic textures ... which can never result in a perfect representation of real world (like a photoscenery). On the other hand, the better (the more diverse) your raw geo data is, the better can this approach work ... (again, I recommend to compare some of the mountainous areas ... there I wouldn't say that the default terrain is "bad" ). PS: aah, and I see that your screenshots are from Ukraine! There we have another - raw data - problem .... until now I don't have detailed landclass data for that region and have to rely on the more coarse, 300m resolution global data. Whereas in USA, Europe, Alaska, NZ and now Canada I have 100m or better resolution landclass data .... which makes a very big difference!

Colin, do you know how a Global Scenery is generated? I mean, especially keeping in mind how big our planet is, how diverse it is, and how complex it would be to cater for every possible local specialty? The thing is, that we need to have ways to create it all in "automated" ways (without too much manual intervention), where we have to rely on existing (or usually improved / processed) data sources and complex algorithms to translate it in a - here comes the word Ben highlighted - plausible world. Everything else is NOT possible / feasible when you need to take care of an entire planet. BUT of course this doesn't stops anyone to create his own, regional sceneries, where he can take care of every tiny detail he wants to (the X-Plane engine and scenery system is open enough to give you almost every possibility you might dream of - but its of course a lot work, which doesn't comes via magic) Now for the trees / forests ... Their type is not decided by biogeographic zones (which we have quite a lot on our planet ... especially if one takes a regionalized and not generic approach). That would be too diverse, if one wanted to do it in a perfect way .... For example take the WWF Global 200 ecoregion classification ... yes, it divides out planet in 200 different ecoregions: http://en.wikipedia.org/wiki/Global_200 This would mean, we would need to handcraft for each of those regions an own set of different forest (sparse and dense versions of deciduous, mixed and coniferous forests etc. ) ... and try to make enough (different) textures of all possible trees there. Definitely not an easy task (I know, because I deed the XP8/9 forest sceneries and had help from a good friend with crafting all the textures and forests .... some info about that is still on my site: http://www.alpilotx.net/downloads/old-forest-downloads/ and http://www.alpilotx.net/documents/ ) ... so, thats why we go the plausible approach, and "only" work with climate zones for the forests (and for the ground textures too). These are derived from high res - real - climate data and are usually a combination of temperature and precipitation zones. This is then also the reason why you might see the same forests on Hawaii and Oregon ... obviously you have similar climates in the given location OR that texture was used in more than one of the climate sets (it might be understandable, that we did not - until now at least - try to reproduce thousands of different tree species )

This is a sentence (especially the last one) which I don't completely understand (what you mean) .... ???

I have answered this above in my long post for Tom .... yes there is such data, but no, at the moment it makes not so much sense to use it (but will quite probably make sense in the future) .... Only exception is the Pintadera approach, which artificially increases the mesh resolution in the DSF itself (and increases its size of course - thats what a "post processing" approach like tessellation will avoid): http://forums.x-plane.org/index.php?app=downloads&showfile=16417 Again: in theory yes, but it makes not much sense until now ... with tessellation, this will change. And just to put it in perspective: I would say, that my HD Mesh Scenery v2 is approximately at the detail level, where SRTM90 is used to its full potential (and then look at the size of HD Mesh DSFs ... so really, tessellation will be the solution in the future as it helps to avoid the otherwise necessary boundless growth of DSF file sizes). No, only one raster layer per DSF is supported. But you can "manipulate" that raster layer to your liking (in theory) .... and merge as many different sources in it as you would like (but of course, the final layer needs to have the resolution of the highest res source data you used in the merging ... otherwise you would lose detail). Good observation ... Yes, indeed its true, that XP10 is not using the raster DEM data only, but also still has some 3D points in the triangle mesh. This is needed, to make sure that lakes are made really flat (as their edges are calculated in advance via RF and fixed at the correct height). This is also an important part of my knw tiny algorithm which sanitizes the tiny rivers in narrow valleys (if we would only rely on fitting the triangle mesh to the raster data in XP, then that would introduce lots of water going steeply up and down on slopes etc. ) ... So, yes, XP10 allows a combination of both ... where the mesh has only 2D info, it will be adapted to the raster DEM data. Where it has 3D info, it will keep to that fixed elevation.

Yes, and no ... in theory X-plane could use higher res raster data, but with the current triangle density it wouldn't make sense. With tessellation it would make sense ..... Or if you use Pntadera (I already pointed you at this - they have a script which increases the DSF mesh resolution artificially): http://forums.x-plane.org/index.php?app=downloads&showfile=16417 The lobbying for Outerra is very old .... still its a much much more complex topic than most out there imagine (its definitely not as simple as buy it, drop it in, and be happy). And neither can Outerra do everything you might want in X-Plane (but X-Plane already has it) ... But don#t expect me to comment more on this issue (and no, there are absolutely no plans to use Outerra).

If you want to learn more about the X-Plane scenery, then the "best" way is (at least for me it was) to read the documentation (which is not so great and uptodate ... but still better than nothing ) and disassemble a few DSF files (DSFTool is your friend) and try to understand how its internals work (the above mentioned script on my website might be a help in this process too) ... But be prepared! You mind might get twisted quite a few times ... Quite simply: why bother with higher res raw mesh data, if the basic triangle mesh won't really utilize it (at least not before we get tessellation). The point is also, that X-Plane works very very differently here than FSX! FSX is rather like a GIS tool, which does lots of the raw data interpretation and transformation "on the fly" (when it loads the data) while X-Plane has most of the scenery really pre-built in the DSF (thats what the above mentioned RenderFarm tool does). Both approaches have their advantages / disadvantages. The FSX approach is far better for scenery developers, because they only need to add much lower level GIS data to the scenery and FSX does the rest of the work BUT at the cost, that FSX can't spend ages on bringing out the best of this data (or the users would need to wait 10 minutes before the scenery comes up) .... On the other side X-Plane does a lot of the complex data interpretation and mesh generation beforehand (RenderFarm), can spend a lot of time to try to bring out the best from the raw data (this makes it possible to generate an irregular mesh etc.) and only need to load almost "finished" data from the DSF. Of course, the downside of this is, that the data, already transformed in a final triangle mesh etc. etc. is far less accessible to 3rd parties (its not realy meant to be edited ... even if its possible and a few devs out there have tinkered with that ). Also remember, that the irregular mesh of X-Plane has the advantage, that - simply put - it "spends" more triangles where there is interesting stuff, and less, where the land is flat .... And than, hopefully one day we will get tessellation in X-Plane which would combine the best of all worlds ... it wouldn't be necessary to make the triangle mesh more detailed than necessary in the DSF file, while X-Plane would refine it (via tessellation) at load time and adapt it to the underlying elevation DEM data in much better quality (and then, it would make sense to put in higher res DEM - where available). Yes, of course. ... But why "waste" time on this (and one can waste extremely lot of time on this), when others have already done it? And not just algorithmically fill holes, but even replace the data with better raw data where ever possible (and its possible in alot of regions of the planet). Neither would your approach the problem of entirey missing SRTM90 data above 60N .... And viewfinderpanoramas.org already does all of this .... And their final quality in overall is everywhere at least the same as SRTM90 and in many places far better (believe me, I know it is this way .... have studied so many GBytes of elevation data over the years ) Yes, for many many place of the earth you can get better quality DEM (not just interpolated) .... an no, SRTM is by far not the only project to map the planets elevation. Many local governments or international organizations have smaller / large patches of elevation data done on their own (with different mapping approaches .... sometimes free, sometimes commercial etc. etc.). You might get a very small overview from here: http://vterrain.org/Elevation/global.html Aaah, yes, thats one of the newer textures I think ... and indeed, there is one which seems to become too blurred. Don't know why ... And no, I am not working on textures, but the guy who does them is a good friend of mine (I will let him know).

Tom, the most important thing which you maybe don't realize here is: I am - even if only as a freelancer - working "inside" Laminar since many years (you find my name in X-Plane). I have done most of the data work (preparations, rule systems etc.) for the default Global Scenery and my HD Mesh works are derivatives ... and now even many improvements over that work. And no, I do not work with meshtool, but with the Laminar internal scenery generator called "RenderFarm" (don't ask me why this is its name ... it was not me who named it ) ... So.... I do not change an existing Global Scenery mesh, neither do I change "manually" (or in post processing) its landclass use. But instead I work with RenderFarm, which generates genuine, new DSF scenery tiles from the wast amount of data I feed it. The areas where I do my improvements are (and this list is for sure far from complete): Improve the input landclass data (there are many different sources for different regions of the planet ... all with their many pros and contras ... and non of them easily adaptable to the DSF creation process).Tune / change the complex rule system which tells RenderFarm how to "translate" the raw data into scenery (especially how and which terrain types to apply where, depending on slope, climate and landclass information etc. etc.) ...Work on vector data (import better / new sources ... at the moment I work on fresh OSM data import)Sometimes even do a little hacking in RenderFarm itself (its written in C++ and usually its Ben Supnik who hacks it). ... Like I did with a new algorithm which makes the new, line river based small rivers look halfway sane in mountainous areas (its always a mess, when the line vectors don't match the elevation mesh exactly ... then rivers run up and down over hills etc.)So ... you see, this is all not easy work (but quite interesting - otherwise I wouldn't do it) and neither is it the way - at least thats my feeling when I read your comments - you think its done Now to some of your other questions: Yes, indeed, the denser elevation mesh - very simply put - only changes the 2D structure of the triangle mesh (it makes smaller triangles) .... But then you didn't understand my second description (might easily be my fault - I am not a native English speaker). Namely, how X-Plane itself combines at runtime (well, when it loads the DSF) the 2D triangle mesh with an added elevation raster layer (effectively the 90m DEM data) .... and turns the 2D triangle mesh into a 3D triangle mesh (in X-Plane 9 this was different ... there the mesh was saved directly in 3D). And thats why I told, that effectively the "resolution" of the irregular mesh is the "limiting factor" when it comes to representing elevation detail. Because X-Plane - at least until now - can only make it as detailed as the triangle sizes (in the DSF) allows it (so, if you would put in 30m or 10m raster DEM into the DSF, that would only waste space ... the triangle mesh couldn't use it). And this is the point, where tessellation can help in the future ... One more very important aspect of the triangle mesh is, that neither is it contiguous (its not one big triangle mesh) .... but rather comprised of myriads of small patches. Usually each patch can have one terrain type assigned to it ... and thats how you get all the different textures in the final look (and yes, its the RenderFram which makes those patches have the right size to - indirectly - represent landclass etc. as closely as possible). On my website you can see a screenshot which gives you a feeling how many different patches a DSF tile can have (its on the site of a tiny script I wrote, which allows you to translate DSFs in a form, which the tool QGIS can visualize - this tool can help you to see which terrain type is applied where in a given DSF): http://www.alpilotx.net/downloads/tools-scripts/ Second: about viewfinderpanorams.org. Well, there are many reasons to be better than the original SRTM data. Like for example many many holes and data errors in the original SRTM90 data. The limitation to only have data up to 60N (most of Norway / Sweden / Alaska etc. etc. would not be possible with only SRTM90). What viewfinderpanoramas.org (its effectively one guy - I had some conversations with him over time) does is, to get elevation data from many many different sources (if possible better sources than SRTM90) and merge it together to have one final dataset which has an overall good quality (in many areas far better than SRTM90 .... believe me or not ... you can have big quality differences even at the same resolution!), no holes, and a complete coverage of the planet ... which takes the burden off my shoulders to do similar things on my own (which I did for the first Global Scenery for XP10 ... and now I am happy that I will not need to do that anymore and still have better data). Then meshtool .... well, as we / I am not working with meshtool since a long time (well, never used it to be honest), and XP10 has a completely different terrain system (vastly improved since XP9 ... and meshtool is only really compatible with XP9 style terrain) you can forget about the "100" land uses ... if you look in the folder "Resources/default scenery/1000 world terrain/terrain10/" you will see that there are already over 3500 TER files (effectively each representing a possible, different terrain type .... usually a combination of slope / climate / landclass ... and a few other possible factors). Of course, you will never have a single DSF referencing all of them at once (always only a subset). And the textures ... neither are they just simply painted on the triangles. In XP10 there are many ways - via so called shaders - to apply the textures in many different ways. Like for example rotate them in the direction of the slope (used extensively in mountains), or combine two textures to make a more random look, or apply the from the "side" (rather than from top) when using them on very steep terrain like the cliff (its even called the "cliff shader") etc. etc. ... So, you see, even this part is far from trivial. And our texture artist is not just creating the textures, but also invests lots of time to parametrize all those terrain types to use the right shaders with the right parameters (there are quite a few parameters which can be tweaked) to get it all look as good as possible ... And no, this is not done by hand editing each TER file, but via big tables (we use OpenOfffice for that) which makes it halfway comfortable for him to do the parametrization ... By the way, I also wrote about some of these things in a very old interview, long time ago for xsimreviews (there are some old infos about the DSF, and scenery generation process ... but still, lots of that info - even if not all - still apply): http://xsimreviews.com/2011/12/10/developer-interview-andras-fabian-mr-x-terrain/

Hi PhM, Well lets put some things straight first. I have to admit, that I am NOT the one who works on the rendering engine, nor did I ever see that code from inside. What I have is a more generic understanding of how it works in general (and yes, I have some knowledge of OpenGL and computer graphics ... even though I don't code it) AND I have a very good understanding of the underlying data structures of the scenery (how it is) and especially how (and why) the scenery is generated from raw data (which is a quite complicated process on its own). I do also have - at least I think so - a very good idea of why many things are the way they are (need to be) at the moment (and also have some ideas about possible future improvements etc.) .... especially from the viewpoint that many things need to be as they are, because they make it possible to have the visual "effects" (how the scenery appears to the user in the end) we can have now (like for example the need for the the patchwork triangle mesh). This all of course does not mean, that it is the perfect / most state of the art rendering engine of all times (neither do I think that there exists such thing .... you always have different priorities, different approaches, different trade offs to take) ... but at least neither is it the worst (and of course it was also something growing over many many years, with some legacy here and there, new approaches added, old stuff thrown out etc. and some necessary backward compatibility being in the equation too!). The most important character behind it is Ben Supnik, and I can assure you, that he is quite likely someone who knows OpenGL and all its possible tricks in extremely great detail (I have talked to him a lot in the last years, and this gave me good faith in his abilities) ... so I would expect that he is the one who could discuss with you your OpenGL ideas the best. But maybe you might first consider reading trough his Blog to get a feeling on how that guy thinks, and what moves him to do things the way he does it (because with a big flight sim platform like X-Plane he needs to see much more than just some OpenGL tricks ...): http://developer.x-plane.com/ And finally ... Laminar (mostly Ben Supnik I think) is just in the process of modernizing / improving parts of the OpenGL code (likely coming in 10.30) .... hints are in the comments of his latest Blog post: http://developer.x-plane.com/2013/10/now-that-breaking-bad-is-over/#comments

Tom, I have the feeling that you are mixing a LOT of things here ... First you talk about textures, then about the mesh, the SRTM ... and I would like to know, which of them do you think affects what??? So, first: I did nowhere say, that we do not use SRTM data. Of course we use elevation data just like SRTM (earlier we used it directly, now indirectly) or where else would we/I get a planet wide elevation data coverage in a halfway consistent form (you always have to keep in mind, that most of my work is not just local, but has to work in very big regions - possibly on planetary scale)? For HD Mesh Scenery v2 (and all other Laminar work) it is now the planet wide coverage from viewfinderpanoramas.org (you might check that out - it is a mixture of SRTM and many other sources ... usually the best data available for a given region). And yes, that raw data is at 90m resolution. My previous post was about how the mesh looks like at all ... its an irregular triangle mesh network (effectively not even a contiguous mesh, but its comprised of myriads of overlapping little triangle mesh patches). Its irregularity depends on the structure of the underlying elevation data (the raw data which its derived from) ... where homogeneous landscape (with little elevation changes) gets fewer, large triangles, while a landscape (usually mountains) with many changes gets more, smaller triangles. This triangle mesh is - since XP10 - saved only in its 2D structure (saves some space etc.)! And additionally, each DSF file contains the elevation data in its raw, raster form. Then when the scenery is loaded, XP10 "puts" the 2D triangle mesh over the raster elevation data (like you would put a thin veil over a sand castle on the beach) ... which gives the triangle mesh its final, 3D structure. Its important to know, that effectively the "resolution" of the irregular triangle mesh (as it is in its 2D form in the DSF file) limits how detailed you will see it in 3D (even if you would put more detailed raster data under it) ... BUT there is one possible future remedy for this (it has been planned for a long time, and don't ask me when Laminar will implement it - but its planned): tessellation ... Which would dynamically break up the triangle mesh in much smaller pieces and thus would make it possible to much better "mimic" raw elevation data (without the need to have extremely high res tirangle mesh data to be stored in the DSF file) ... Aaah, and before I forget it: there is already a funny little tool fo X-Plane, which allows you to manually increase the triangle mesh resolution (which then gets stored in the DSF file): http://forums.x-plane.org/index.php?app=downloads&showfile=16417 You can read about the mesh and the underlying DEM data, and tessellation in Ben Supniks blog too: http://developer.x-plane.com/2011/08/dsf-gets-raster-data/ http://developer.x-plane.com/2013/04/dsf-mesh-formats-v9-vs-v10/ (or just search it for "tessellation") And finally: X-Plane 10.25 will ONLY improve the artwork. This means especially - and most importantly - improve a lot of the existing textures (the "pictures" which are painted on the existing 3D mesh!), bring lots of new textures and possibly some new autogen artwork. The new textures will also include some experimental new urban textures (which will be visible in some regions - depending on climate). X-Plane 10.25 WILL NOT change the scenery itself nor how it is rendered. New scenery, with higher resolution mesh and based on new OSM data will be available vial my HD Mesh Scenery v2 ...

Huh? Could you elaborate why this bothers you (because until now, nobody cared for this)? And I would say, the primitives (if you mean the multitude of triangle patches the scenery is comprised of) are not created with "maximizing OpenGL efficiency" in mind (especially as this is not so much a parformance cost factor on modern hardware anymore) but the needs of the visual representation of the landscape. And this needs a lot of such patches - usually per terrain type change ! - to reflect the landscape in as much naturally as possible .... (and yes, this is always a weighing of cost-benefit ... or what visuals you get at what performance hit).

Maybe you wait for the texture updates in 10.25 ... and horrible is extremely relative (be very careful in your wording), especially as we are talking about - kind of - artistic interpretation of real life phenomena (which always reflects the taste of the artist too). And I can assure you, that neither is it something done "overnight" ... (I know how much work went into them over the years) ... And maybe you have already read, that there is no such thing as "mesh resolution" in X-Plane when we are talking about an irregular mesh. Maybe this old screenshot from my HD Mesh 1 download page helps you to get a feeling of how / what changes (and HD Mesh Scenery v2 will even have a slightly denser mesh than v1):

Yes, in that the new urban textures still take the way of "no ortho when close to the ground" ... so, for those who like your interpretation, will still be happy with it. And for those, who like the LR interpretation will be delighted by the new "improvements", which will make cities definitely look like cities when flying at higher altitudes.

Hi John ... here I have a first teaser for you from Seattle (disclaimer: it might look like this later or not) ... the magic with the new urban textures is especially tweaked for the "distant view" which now looks much better than before.

Yes, this will be a complete replacement .... (and after it, you will - I think - not want to go back )

We do already go up to over 70N (Norway is completely covered and Alsaka too). This will be the case with my HD Mesh Scenery v2 too ... only in Canada I might be a bit selective, as there is a wast, extensive area north of 60N, which has not so much details and wouldn't profit much from HD Mesh. And about polar regions, no, I don#t have to extend up there ... and also the scenery engine - using a classic "WGS84 Geographic Lat/Lon" - would have quite some trouble the closer you come to the poles (which you can easily imagine, if you know a little bit about projection systems )

About South America: well, there are two important aspects here. First, it adds to the already extreme amount of scenery I try to distribute here (remember, that the announced coverage will already wigh in around 60-80 Gbytes!) ... South America would for sure add another 20-40 Gbytes.Second, yes, there is a data "problem" with South America : I do not have higher resolution, good quality landclass data for that region (until now) ... only the - for now - standard 300m res data I use worldwide (where I have no better data). Whereas Europe/USA/Alaska/(and from now on) Canada do all have good, highres landclass data. Now, of course its possible to do the HD mesh with low res landclass data too, its just that it makes much much less nice difference (and improvements) there ... also the OSM data - until now - is not at a level like in the above regions (again, much, better, etc. OSM data also helps to improve things).For this reason, I would NOT promise anything about South America. BUT, this doesn't mean that - like always - I don't continue to look for possible improvements! And when I find something which is worth the efforts, I will let you know (but at least until now, there is nothing to "talk" about) ...