You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The models work on a patch of a fixed size, so terrain is generated by laying windows of that size over a region. A region can only be generated if windows cover it exactly. Someone asking for terrain does not know that and should not have to.
Generation Orchestration is already the single point everything outside the core asks for terrain through, so this is where a request gets put into a shape that can be generated and where the answer gets cut back down to what was asked for.
For example, with windows 5 cells across and a request for a 3x3 region at the origin:
asked for 0,0 to 3,3
generated 0,0 to 5,5 expanded up to one whole window
handed back 0,0 to 3,3 cropped back out of the 5x5
Nothing below Orchestration ever sees the 3x3. The Sampler is handed the 5x5, which windows cover exactly, and everything about the original request is dealt with on either side of it.
Description
Have Generation Orchestration take a request of any size and shape it into a region that can be generated.
There are four parts to it. A request that makes no sense is refused before anything is generated. A request that can be generated is expanded up to a whole number of windows. The finished terrain is cropped back to the size that was asked for. And the Sampler refuses a region that was never expanded, so the assumption fails loudly rather than quietly if anything ever skips this.
Expanding must not shift where terrain comes from. The expanded region sits on the same world grid the windows do, so asking for the same area twice hands back the same terrain both times.
Do the expanding and the cropping together. They are inverses of each other and are far easier to check as a pair than apart.
Activity