Skip to content
View in the app

A better way to browse. Learn more.

The AVSIM Community

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Real Terrain

Featured Replies

>Can you mix it with Orlando's releases? I just installed all>of his from from FS2K2 and FS2K into FSCOF....including some>from Colorado. You can mix them, but you may not get the results you want!This is, unfortunately, a very interesting question. Both are constructed from 30m source data, converted to mesh using an LOD of 10. I've never done any testing to see how conflicts are handled in this situation. You certainly don't want Orlando's mesh (or any other high quality mesh) replaced by mesh constructed from lower quality data, such as the Colorado mesh, which was apparently constructed from SRTM data.In FS2002, when there are multiple active mesh files for the same area, having the same LOD, priority is given to the mesh constructed from the highest source data resolution. This works reasonably well, and it works whether the files are all in one folder or organized in several folders.Some boring details:We do not know what information the sim uses to determine the source resolution when it resolves these conflicts, or how accurate that information is (i.e., number of significant decimal places). When constructing mesh, the developer specifies this cell spacing, and this information is apparently stored in the bgl (mesh) file header. We have some knowledge about the structure of the header, but it does not include any information about this particular detail. So, if different source resolutions are stored in the two mesh files, and if that difference is large enough to be seen as different by the mesh engine, then one or the other will always be used consistently. (The probability of there being any difference at all depends on how the developer determines the spacing values he uses.) Otherwise, ????The situation for FS2004 may be a bit different. I've been investigating this issue and, at least on my machine, the sim behaves somewhat less predictably. But this is enough information for now. I'll follow up on the FS2004 story another time if others can replicate my experience.What you can do:In the meantime, you may have to compare some screenshots to see what happens. One with just Orlando's mesh active, one with just the new Colorado mesh, and one with both. This testing will be easier if any of the holes in the Colorado mesh (it's not bad, but there are some) fall in an area also covered by Orlando's mesh. These holes are easy to identify using the MS SDK Tmfviewer program to look at the mesh bgl file. They have an elevation of -32,767. Note their coordinates and use Map View to GoTo those coordinates. No screenshots will be necessary if you can use this approach.If you don't have the Colorado mesh yet, perhaps David has done some testing and can help us out here.Stevewww.fs-traveler.com

  • Replies 47
  • Views 5.1k
  • Created
  • Last Reply

Top Posters In This Topic

Does anyone know off hand if they actually cover the same coordinates? I just downloaded this pack, will look inside and see if it mentions them, compare to Orlando's. Thanks for the heads up...

Good point. Tmfviewer shows that the first file covers approximately 36-41N, 104-106W. I don't have the other one.

Info from Orlando's Colorado Springs FS2K release:Level of Detail (LOD): 10 Approximate area covered: 7967 sq. km. (3112 sq. miles) Corners of the area covered (WGS84): NW NE N 39.37000

I have not tested multiple terrain mesh files due to $$$$$All the high terrain mesh files cost $$$$$.Now I can understand how you, or I may want to warn those user who do use other, or higher terrain mesh files that there perhaps may a conflict. in fact to tell the truth I really never thought about it. I may have used an older SDK to produce the Terrain, But, I Created this file for those who would like to have a higher terrain mesh then the default Flight Simulator. I have in no way said this was a perfect, bug free add-on. This is a free download for flight simmers. But the fact remains that those who do not have payware Terrain Mesh, or do not have the Money for it, This is better then not having it. I am one of the poor folks who never can afford to get those cool add-ons, Like Lago, And Wilcopub. Also I have used the SMRT data, and I think in general for FREEWARE it looks great. I will try and help those who have trouble installing the files. Also this was my very first attempt to create something like this. So creating readme files, install files and everything is new, hey you got to start sometime right? This is MY Opinion. and in no way am I Moaning, or flaming, in fact I appreciate you all for discussing it. Thank You,David P Smith

he he if you really want to have fun, try downloading a aircraft that can at least do mach 1 and fly through them mountains!

Steve....I found out the answer on installing Mesh with the same LOD.It appears to me, after trying different methods, that when FS sees two mesh files with the same LOD, it will use the last one installed. This actually came up recently on another issue with two 38.4's that were side by side with a bit of an overlap. One had bad data at the edge and created a large lower elevation area. If you installed the good one first and then the bad one...this area appeared. But if you installed the one with the bad data and then the good one, it did not appear. So to answer the question of which LOD it will display....its whichever one you installed last. Hope this helps....

Thanks James,I have a few questions about your approach. I've been looking at a slightly different aspect of the conflict issue, but they are probably related. You may be verifying part of the problem I mentioned with FS2004.1) Was the testing done using FS2002 or FS2004? I assume it was FS2004.2) Were both files loaded in the same folder?I assume they were. I wonder if "installation" order is determining the order in the scenery.dat file, which might be determining priority. Have you tried just copying the files to a new folder and allowing a new scenery.dat file to be created with both present? Or editing the scenery.dat file to change the sequence? (What determines the order in which they are incuded in the scenery.dat file, and does this order actually determine the priority of the mesh in your case?)3) If they were installed in separate folders, did you try swapping the Priority levels to see if that changed the outcome? At this point in time, and on my machine, even with 90m and 10m source data, both at LOD 10, installed in separate folders in FS2004, conflict resolution seems to be random.I can "force" the 10m source mesh to show up by assigning it a lower priority level. This insures that the higher res source mesh is used whether the sim "decides" to resolve the conflict based on Priority or Source Resolution in any particular instance. If I assign a lower priority to the 90m source mesh, sometimes I get the 90m mesh, sometimes the 10m mesh. While this behavior may not be "random", I cannot yet predict which will appear in any given test.This approach is not very satisfying, although I seem to be able to insure that I see the higher resolution mesh. Order of installation is irrelevant here. Having to worry about the order of installation when mesh is installed in the same folder is entirely unmanageable.I've seen many claims in the past concerning how the priority was established in previous versions, including install sequence, file name sorting order, file dates, ... My testing showed none of these had any effect. Just LOD and source resolution mattered. (I didn't test cases where these were both the same.)But FS2004 may be different. If so, it is an issue affecting many of us and should be clarified. We have more work to do.Steve

Hi David, >I have not tested multiple terrain mesh files due to $$$$$>All the high terrain mesh files cost $$$$$.Well, most do. I understand your motivation.>Now I can understand how you, or I may want to warn those user who do >use other, or higher terrain mesh files that there perhaps may a >conflict. in fact to tell the truth I really never thought about it.Sometimes even Microsoft has problems getting their programs to play nicely together!This may be a larger problem with FS2004, and as more mesh becomes available, but we may be able to gain some control over it. I have more testing to do first, however.>I may have used an older SDK to produce the TerrainI believe that's the one Matthew recommends. In this situation, it is probably the best one to use because it is more forgiving when it encounters missing data values. > ... This is better then not having it.I agree. I'm just trying to provide some perspective, both for you and the users. You've made a good start, and your mesh is obviously welcome. I'm not a fan of installation programs, but your works very well, and allowed me to place the data precisely where I wanted it. (You may want to consider adding the coordinates of the mesh in the readme files.)Matthew's program and SRTM data offer a simple introduction to mesh development - if you only want to create isolated mesh files. But if you want multiple files to provide complete coverage for larger areas, a bit more work is required. If you view your two mesh files together in the SDK Tmfviewer, you will see a large gap between them where the default mesh will be used. This is a common problem for new developers, and learning how to eliminate that gap is probably the next essential step toward developing good mesh for others to use. I explain the problem in the Developer Tips section of my website, and will continue to help you in our e-mail conversations.Cheers,Steve

You are correct in that they are in the same folder. And I was not putting them in the Addon scenery folder, but in the main. And yes, I was letting the DB build each time, and that is how I determined the order. One of these days I will get around to probably putting them in the addon scenery folder. As my HD space seems to be shrinking daily, I am thinking of swapping out areas that I am not flying in. I seem to go through phases of where I fly. Will play in the Grand caynon for a week or so, then move on to somewhere else and explore its area. So I probably only use 10% of the mesh at a time during the week. My thoughts are that I will just remove the areas I am not flying in and then trade them out when I start going there. I have over 4 gigs of addon mesh by various authors for all around the world. Now that I have CD's for 75% of this, it will be easier to uninstall and then reinstall later. And for the 25% I do not have on disk, I will probably just burn them to a CD for storage.

>Good point. Tmfviewer shows that the first file covers>approximately 36-41N, 104-106W. I don't have the other one.>>Ok, I plotted on a sheet of paper Orlando's and this one....this new one at least (I don't know the coordinates of the other file) is a much larger chunk of land.....it only interferes with Orlando's Colorado Springs release though as his other three are further west. Need the cooordinates to the second file to see if it interferes. And between the two, which has more detail. (and the other would be more fps friendly since less detail) Or are they the same detail and maybe these two files cover all done by Orlando and a lot more.....

I have the second one now, more accurate coordinates are: [table][tr][td width=100] first: [/td][td]36.04-40.96N, 104.07-105.94W [/td][/tr][tr][td width=100]second: [/td][td]36.04-40.96N, 106.06-107.92W [/td][/tr][/table](there is a gap of 0.12 degrees between them)Detail and FPS should be about the same.

>I have the second one now, more accurate coordinates are: >[table][tr][td width=100] first: [/td][td]36.04-40.96N,>104.07-105.94W [/td][/tr]>[tr][td width=100]second: [/td][td]36.04-40.96N,>106.06-107.92W [/td][/tr][/table]>>(there is a gap of 0.12 degrees between them)>>Detail and FPS should be about the same.>>Ok, so there is total overlap over all of Orlando's except Telluride, which only the very eastern edge is covered by both. (107.2-107.9) So if detail is the same, sounds like it would be best to run these two, with Orlando's Telluride for addition western coverage, you would have a lot more Northern and Southern coverage also compared to just using Orlando's....So the question now, which should be over the top of the other? Is the transition or overlap between them seemless? Hmmmm....

Well if the LAST loaded mesh shows, to not see the holes, and gaps (I'm working on that) You would load Orlandos first, Then mine? Right?And I guess there is only one way to find out! :-hah David

I used the Mooney for a little more power. btw, I notice that adjusting the mag setting does not make any change on the guage...and a question for those who know Colorado. Is Tullride airport really on a sharp cliff face as it appears to be in the sim? Thanks..btw, David...this is great scenery. I am really impressed with its beauty and variations. I do get a few floating trees here and there, but maybe trees really float in Colorado...:-)Sherm

Create an account or sign in to comment

Account

Navigation

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.