Default Base Values?

[Colins2]

In the manual, page 36/37 you suggest that we can use elevation_step: 0.05 or even 0.01 as in Courcheval. Can you really get down to 5cm or even 1cm, or is this a typo? 0.5m / 0.1m would seem more realistic. I used 0.25m on a mountain airstrip and the results were very good. Colin

[nofaceinbook]

Yes. You can really get down to 1 cm and even further down (but no need to do so). However, in order to match full meters of existing default mesh, 0.05 and 0.01 meters are not good. They can lead to visible edges in the mesh caused by not exact matches. For exact matches a divisor of 655535 has to be used. So good values for scale are: [1, 1/3, 1/5, 1/15, 1/17, 1/51, 1/85, 1/255, 1/257] e.g. 1/17 = 0.058823529411764705 instead of 0.05. New version of MUXP will use such values as default and not 0.05.

[Colins2]

OK, thanks for the explanation. I'll change the one I made to 0.33 instead of 0.25 and see how it looks. One thing I am not quite sure of is where to put the elevation .dsf. I have read the manual several times now but I must be missing something. I am working on areas in Papua New Guinea so most of the airports and mountain strips are just not present. I am concentrating mainly on one tile, -6+145, but there will be several airfields each with their own .dsf file in separate folders. Where is the best place for me to put the dsf that I have created with modified dem data before running muxp? Obviously it has to be somewhere in the custom scenery folder for X-Plane to find it.

On Sun, 20 Dec 2020 at 17:09, schmax notifications@github.com wrote:

Yes. You can really get down to 1 cm and even further down (but no need to do so). However, in order to match full meters of existing default mesh, 0.05 and 0.01 meters are not good. They can lead to visible edges in the mesh caused by not exact matches. For exact matches a divisor of 655535 has to be used. So good values for scale are: [1, 1/3, 1/5, 1/15, 1/17, 1/51, 1/85, 1/255, 1/257] e.g. 1/17 = 0.058823529411764705 instead of 0.05. New version of MUXP will use such values as default and not 0.05.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nofaceinbook/muxp/issues/56#issuecomment-748587556, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJQF55K3M67G4GVCKQP6YNTSVXEM3ANCNFSM4VC2SI3A .

[nofaceinbook]

Are you talking about the normal dsf files that just hold information about airport scenery (just few KB large) or do these airports really have their own mesh (several MB large, in a separate folder in Custom Scenery). If the later one is the case, then you should disable this mesh in scenery_packs.ini file. But I assume first is true. Then you don't have to worry. Elevations are taken from the first mesh dsf file in the order of scnery_packs.ini.

You should really use lower values than 0.33. E.g. 1/17. Otherwise you might see huge steps when cutting a runway profile.

[nofaceinbook]

Or do you mean you created for all of your airports a separate mesh dsf file? Sorry, in that case you did chose the wrong approach. X-Plane can only handle one mesh tile. That is why MUXP is important to merge all elevation changes in one file. You need to integrate all your changes with MUXP in the same dsf file but always on a different area for the airport. Hope this helps.

[Colins2]

Re. dsf files. I edit the raster dem info in the dsf before processing with muxp where necessary. This is more to assist blending in with surrounding elevations on the sides of the runway. Muxp creates a lovely runway with the data from Google Earth but sometimes the edges are too steep. I have studied what you did with LFLJ but I can't seem to get the results I want. Also, I am working with small runways, most around 500m, in very mountainous terrain. Eventually, the mesh dsf could have 20 or more modified patches for small airports.

Can I put 1/17 as a step value or must I put the decimal?

On Sun, 20 Dec 2020 at 18:44, schmax notifications@github.com wrote:

Are you talking about the normal dsf files that just hold information about airport scenery (just few KB large) or do these airports really have their own mesh (several MB large, in a separate folder in Custom Scenery). If the later one is the case, then you should disable this mesh in scenery_packs.ini file. But I assume first is true. Then you don't have to worry. Elevations are taken from the first mesh dsf file in the order of scnery_packs.ini.

You should really use lower values than 0.33. E.g. 1/17. Otherwise you might see huge steps when cutting a runway profile.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nofaceinbook/muxp/issues/56#issuecomment-748596795, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJQF55OKTGA3NANEUK7LXNTSVXPSBANCNFSM4VC2SI3A .

[nofaceinbook]

Well, never had more than 3 patches in one mesh for testing. But it should also work for 20. The only problem is, that you could not easily change the first patch after you applied 19 more. This would mean you need again go trough the whole update process. Perhaps I find time in future to allow such automatic updates in MUXP.

No, MUXP file only accept decimal values.

Against steep cuts you need to perform double cuts and elevation updates in the area between. The new MUXP version will do this for you. Hope I find time over Christmas holidays to document how this works.

[Colins2]

Yes, I realize that it would be necessary to apply the patches 1 by 1 but it doesn't take long for each one so I don't see that as a problem. It means more careful testing of each one first. I said 20 but I really don't have any definite idea. I am slowly wading through the data I can find and plotting them in GE first and gathering the runway data etc.They are mostly going to be really simple airstrips but the challenge is that most are built on the sides of hills / mountains. There isn't the 18° slope of Courchevel but they regularly get to 10 - 12° slopes. The elevation updates is why I wrote VFC, to try and get a reasonably accurate base mesh first, before running the data through Muxp. The creation of all the vector files is so that I can project them in QGis or GE along with the base mesh to get a better idea of what needs editing. Muxp's functions to read/write kml files makes a lot of it unnecessary now though and to be able to use GE as another sort of WED is brilliant! I look forward to the next Muxp version; it is already a superb program and really the only option we have at the moment to get realistic runways in mountainous areas. I have read the other sites you mention but they aren't much help.

Enjoy your Christmas, as much as possible this year!

On Sun, 20 Dec 2020 at 20:52, schmax notifications@github.com wrote:

Well, never had more than 3 patches in one mesh for testing. But it should also work for 20. The only problem is, that you could not easily change the first patch after you applied 19 more. This would mean you need again go trough the whole update process. Perhaps I find time in future to allow such automatic updates in MUXP.

No, MUXP file only accept decimal values.

Against steep cuts you need to perform double cuts and elevation updates in the area between. The new MUXP version will do this for you. Hope I find time over Christmas holidays to document how this works.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nofaceinbook/muxp/issues/56#issuecomment-748610582, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJQF55KUBHKABE54UK4BDV3SVX6QLANCNFSM4VC2SI3A .

[Colins2]

Query answered