Add Preview Simulation Size setting

[Zehir]

Note: see This Comment for a description of the final result.

Description

This PR improves the preview for map generation by adapting it to the world aspect ratio.
It also adds a new setting to define a base texture scale for the preview.

Preview examples:

• Square map
  

• Horizontal rectangular map
  

• Vertical rectangular map (large preview, but this layout is uncommon)
  

This PR also update the demo to add a fiew nodes to configure the FloorWalker node depending of the preview size so we don't get a blank map on lower resolution

[Zehir]

It's ready for review but I don't know, I have mixed feeling about the resolution calculation.
The goal is to match the shape of the world for the preview and it's working great.
The problem is that the walker node give similar result but not exactly.

Here the resolution is set to 64 and the world size is 80,45 so the center is not the same and the result is not exactly the same.

When setting the resolution to 80 in the editor setting I get the same result.

[Zehir]

Closed by mistake

[BenjaTK]

I'm not really sure what the resolution setting does. I like the idea of having it adjust to the aspect ratio of the map, but also the way I implemented it was just to have a bit of an idea of what you were generating, independent of world size. It was clamped to 64x64 for performance reasons mostly.

[Zehir]

The setting is to set the resolution for the X axis instead of the static 64.
I also limited the ration to 2 as avoid to long node

[cullumi]

So for the walker @Zehir, I believe the noise salt is based on the position; this helps it be determinate (same starting position, same settings, same result), but it also means that a slight change (even by one single tile) can create a totally different result. I suspect it's different because the center coordinate for a 64x64 resolution is different than for an 80x45 resolution. You could potentially offset the preview grid such that that initial coordinate matches?

[Zehir]

I am not sure how to do that, maybe insead of running the generation a second time for the preview to just use the data from the main generation and use the complete data

[cullumi]

I am not sure how to do that, maybe insead of running the generation a second time for the preview to just use the data from the main generation and use the complete data

I can try and see if I can't get a proof of concept running later tonight.

[Zehir]

Sure @cullumi , feel free to PR on my PR or just do an other PR

[BenjaTK]

So what's the verdict, then? Should I merge this or not?

[Zehir]

I don't know if @cullumi had time to test something but I resolved the merge conflicts

[cullumi]

Hey there @Zehir, I managed to figure out the source of the walker behaving oddly in the graph preview-- it's simulated generation was restricted to the bounds of the preview resolution, so it could not generate the same results (by nature of how walkers work).

I've committed changes that add a _get_preview_simulation_size value (+ an enum) to specify on a per-node resource basis whether the World Size or the Preview Resolution should be used.

Now, technically this does mean that the preview for the walker may be less performant in some cases; but this is kind of the only way to preview it accurately.

Lemme know what you think 👍

[Zehir]

Looking good, just 2 comments @cullumi

[BenjaTK]

The thing about this change is if the world size is big then the preview is going to be big too, and that's going to cause problems with performance. I think previews should be kept the same size throughout. They're just that, previews, to kinda see what the generation is doing but not made to match the actual generation.

[cullumi]

The thing about this change is if the world size is big then the preview is going to be big too, and that's going to cause problems with performance. I think previews should be kept the same size throughout. They're just that, previews, to kinda see what the generation is doing but not made to match the actual generation.

To clarify, the changes I made don't actually increase the size of the preview as displayed, only the bounds of the data being generated in the background.

It may create performance issues in rather extreme situations, which is the hiccup on this one for me. There are ways to find a balance I suspect, but none that will produce a preview guaranteed to be accurate without doing this.

Perhaps the preview could use a sort od "accuracy level" drop down?

But all-in-all the actual preview texture stays at the same resolution here.

I suspect this is a dilemma that will come up with a lot of more "simulation-based" generators, so it'll be good to make a decision on how to handle it.

[BenjaTK]

The thing about this change is if the world size is big then the preview is going to be big too, and that's going to cause problems with performance. I think previews should be kept the same size throughout. They're just that, previews, to kinda see what the generation is doing but not made to match the actual generation.

To clarify, the changes I made don't actually increase the size of the preview as displayed, only the bounds of the data being generated in the background.

It may create performance issues in rather extreme situations, which is the hiccup on this one for me. There are ways to find a balance I suspect, but none that will produce a preview guaranteed to be accurate without doing this.

Perhaps the preview could use a sort od "accuracy level" drop down?

But all-in-all the actual preview texture stays at the same resolution here.

I suspect this is a dilemma that will come up with a lot of more "simulation-based" generators, so it'll be good to make a decision on how to handle it.

That's what I mean, when generating it'll do the whole world size both times: for the preview, and for the actual generation. That's why I originally limited the preview to 64x64.

[Zehir]

What do we do with this PR ? Do I resolve the conflicts or I wait for an merge or close signal ?

[cullumi]

Hey @BenjaTK, In order to account for the performance issues we discussed, I've introduced a new setting to GaeaEditorSettings-- max_simulation_size. It's default value is 128, meaning each dimension is capped at 128* for Preview Textures. Hopefully these last couple tweaks can bring this PR over the finish line.

I also put the editor settings related to Previews into their own sub-category (Called "Previews").

Figured this would be a solid compromise between performance and making the preview for the walker actually yield comprehensible results.

Additionally, I modified Preview Texture to offset the preview based on the difference between the preview size and resolution (so that the preview texture is actually centered on it's data).

*I had found that a world size in the 100 range yielded decent performance, while something on the scale of 500 would cause the editor to hang for quite a while.

[BenjaTK]

Hey @BenjaTK, In order to account for the performance issues we discussed, I've introduced a new setting to GaeaEditorSettings-- max_simulation_size. It's default value is 128, meaning each dimension is capped at 128* for Preview Textures. Hopefully these last couple tweaks can bring this PR over the finish line.

I also put the editor settings related to Previews into their own sub-category (Called "Previews").

Figured this would be a solid compromise between performance and making the preview for the walker actually yield comprehensible results.

Additionally, I modified Preview Texture to offset the preview based on the difference between the preview size and resolution (so that the preview texture is actually centered on it's data).

*I had found that a world size in the 100 range yielded decent performance, while something on the scale of 500 would cause the editor to hang for quite a while.

Looks good, I like it. What does preview resolution do now? (Also, please remember to rebase instead of using a merge commit to merge the base branch)

[cullumi]

I realize it's been nearly a month, but the preview resolution is the size of the actual preview texture (think of it like a "viewport" or "camera" size, basically).

[BenjaTK]

I know it's been a long time but I'm honestly still not sure about this or how it works exactly lol

[Zehir]

The idea was to have a preview closer to the generation when you have a non square map.
@cullumi what you want to do ?

[cullumi]

I'll give it another once over performance-wise tonight and merge it in, most likely.

[Zehir]

I'll give it another once over performance-wise tonight and merge it in, most likely.

Do you want me to rebase it to latest commit and resolve conflicts first ?

[cullumi]

Rebased with latest changes from 2.0, tests pass. Ready to merge.