[SU12] Information about terraforming

Hello everyone.

Here's some more information about what changed regarding terraforming with SU12.

A new terraforming technique was developed. Its aim is get rid of the staircase effect we have on slopes.
Basically, pre SU12 terraformers had their own dedicated elevation map with a lower resolution than what the actual terrain allowed. With SU12 it now handles elevation at native terrain resolution so we are no longer limited by the elevation map.
Pictures are worth a thousand words so here's an example of how it improves the end result:

Obviously, as introducing this change can cause regressions on your sceneries, this is versioned and existing packages will still use the old terraforming technique.
However, when opening your source project with the Scenery Editor and saving it, your terraforming shapes will be switched to the new version and new terraforming will apply. This is not configurable.
Some changes can be expected and require modifications on your side.

The changes we had anticipated were for example scenery objects floating above the ground after its shape had changed.
There seems to be an additional case we haven't anticipated and is the result of a misunderstanding of how stacked terraformers work in MSFS.
This is the problem shown here: Terraforming Broken? SU12 - MSFS DevSupport (flightsimulator.com)

When stacking terraforming rectangles, the falloff will only be used for the lowest priority rectangle.
All rectangles on top will have their falloff behave as if it was set to 0 and give the sharpest transition.
As I mentioned earlier, this sharpest transition, given the old elevation map resolution was low, was giving fairly smooth slopes. Smooth enough for some scenery developers to use it as is for smooth areas.
Now as terraforming works at higher resolution, this same sharp transition is way more visible.

We are reviewing what's the best way to address this problem and will come back on the subject later.

Regards,
Asobo / Sylvain

FlyingRaccoon ♦♦ commented · Mar 24 at 05:29 PM

Hello.

For the developers who end up having a lot of modifications to do on their scenery project before having an equivalent to what they had with old terraforming technique, we can only provide a workaround for now:

Keep editing your scenery with the Options - Ground - Old terraforming method checked so you can see what the end result will be.
Save your scenery and leave the Scenery Editor: this will save the scenery XML file with the new terraforming parameters
Open your scenery XML file and:
- set all the <Rectangle> component's Precision parameters from "True" to "False"
- set all your <Polygon> elements "PreciseTerraforming" attribute's value from 1 to 0
Build you package.

The resulting package will then handle terraforming as it used to in previous game versions.
You will have to repeat this operation every time the scenery is saved through the Scenery Editor (that also inclues just opening the BGL asset group in the Scenery Editor before a Build&Export).

Regards,
Sylvain

1 ·

1679678996527.png (233.8 KiB)

Photosbykev FlyingRaccoon ♦♦ commented · Mar 24 at 08:51 PM

This workaround basically enables the developer to undo the terraforming mess that the SU12 update has created on hundreds of scenery projects and is a short-term fix at best.

I agree that progress must be made to keep the flight sim improving week to week and terraforming is a large part of those improvements for scenery developers.

However, to release an 'improved' terraforming process with no way of smoothly migrating old scenery data into the new terraforming process except for hundreds of hours of additional work by the developers is not acceptable.

The workaround is just a stopgap sticking plaster that doesn't address the root problem. The adoption of a new terraforming process to take advantage of the higher resolution that is available needs proven and fully tested developer tools.

These tools can then be used to bring our existing scenery into the new process without many many hours of wasted time.

Kev

3 ·

attben FlyingRaccoon ♦♦ commented · Mar 24 at 07:35 PM

Hm. Apologies but i think your tools are so hard to use already when compared to every other game engine i've worked with, throwing stuff like this in every so often makes it really hard especially for independent solo developers and is a massive waste of time.

2 ·

Ensi_Ferrum FlyingRaccoon ♦♦ commented · Mar 25 at 10:58 AM

Being a software developer myself I am a bit puzzled with this approach.
First, I do not develop for FS-2020. Just because of time. But I often have a look here.
Second, in my current project I sometimes have a similar problem. We use a data-model in which we store some (lots of) settings the user can alter on his hardware. And we save this data-model as an XML file, so it can be reloaded at a later time again.
When I change anything on that particular data-model, the very first thing I do is writing a converter which brings the old XML files to the new version of the data-model!

Question: Why do you not provide such a converter for the 3rd-party-devs?

You know your data model better than anyone else, I think. So it should be easy for you give them such a service.

I can very well understand the displeasure of @Photosbykev and @attben