Hytale Quietly Published an Official World Generation Performance Guide: How to Read the Performance Report, the Ten Step Optimization Checklist, and What Custom Biome Creators Should Fix Before Chapter 1

There is now an official Hytale guide to making custom world generation fast. It sits in the pre-release documentation under Creating Content, World Generation, Performance Optimization, and its subtitle is one sentence: "Living document about performance optimization in world-gen content." If you are building a biome, a terrain Density tree or a Prop Distribution to ship when Chapter 1 arrives on Monday 12 October 2026, it is the only official statement that exists on what is expensive and what is cheap. Two things first. This is not a server lag guide. Everything below is about the cost of generating world content: Density fields, Material Providers, Props and the Stages that produce them. It is not about tick rate on a live server with players on it. If that is your problem, read our write up of the third party Performance Saver plugin and its view radius controls instead. And we have run none of this. No benchmarks, no generated reports, no timings of our own anywhere in this article. Every figure comes from the official documentation. Where the page uses example numbers, those are the documentation's own worked example rather than a measurement of a real world, and we say so each time. The page opens by naming the tradeoff directly: The world generator is designed to give users absolute control so they can freely create the worlds they want. However, this also gives users the freedom to make extremely resource-intensive biomes. This means users must understand which features and approaches are more costly, and how to use them to get the best performance out of their world-gen content. The node editor will let you build a Density tree that is correct, beautiful and far too expensive to generate at scale, and nothing will stop you. If the vocabulary below is unfamiliar, our custom world generation guide and procedural generation overview cover what this page assumes you know. What Was Published, and the One Line That Acknowledges It The two Hytale documentation sites read differently in their version switchers. The public release docs are labelled Release and pinned to 0.6.8. The pre-release docs are labelled Pre-release and pinned to 0.7.0-pre.5, which lines up with Update 7 Part 5, dated 1 October 2026. There is no pre.6. We covered the 0.6.8 docs version arriving without patch notes attached here, so documentation moving ahead of the notes is not a new pattern. Both sites expose a static search index, which makes a page count straightforward. Stripping the per-section anchors and counting unique pages gives 307 pages on release 0.6.8 and 338 on pre-release 0.7.0-pre.5, with 39 existing only on the pre-release site and 8 only on the release site. The Performance Optimization page is one of those 39, as are the nine Graph Generator reference pages and the three that replaced the old world generation concepts page. None of it is described in the Update 7 patch notes. On the living Update 7 page, 368,657 bytes and last modified 1 October 2026, these strings occur zero times: GraphPass, Graph Generator, GraphGenerator, ContentPredicate, ContentSupplier, EdgeAction, EdgeSelector, GraphContent, NodeAction, NodeSelector, WorldStructure, PropRuntime, Directionality, PortalUpgrade, Performance Optimization, Sample Count, YSampled and CacheCellSize. There is one acknowledgement, in the Part 5 "Modder-Facing Changes" section under "World Generation". Verbatim, including the typo, which is Hypixel Studios own and not ours: Updated the public HyaleGenerator documentation, which can be found here under “pre-release”. "HyaleGenerator" occurs once on that page, and "HytaleGenerator", spelled correctly, occurs zero times. We are stating the fact and not guessing at a motive: the notes point at the documentation, and the contents of the change are not described in them. As context for why this went unnoticed, there is no Update 7 Part 6, the hotfix living page still tops out at 0.6.6 dated 14 September 2026, and the October 2026 news archive reads "No posts found for this month". Our coverage of the latest build is in the Update 7 Part 5 write up. One caveat applies to everything below. This is pre-release documentation pinned to 0.7.0-pre.5, describing the Chapter 1 build. It can change before Monday and after it, and the page says of itself: "This is a living document that is meant to be updated and fleshed out over time." Where the World-Gen Performance Report Lives The measurement tool has been in the game the whole time. Most people have never looked at it, because nothing told them it was there. World-gen prints a performance report to the logs at a few configurable sample-size intervals. Once a certain number of Chunks are generated, it averages the performance stats for all of them and prints a report. Three steps to find it, in the documentation's own words: "Right-click on your world in the world selection menu." "Open the world's folder." "Navigate to logs and open the latest log." No flag, no debug build, no developer mode. It has presumably been sitting in the logs of every custom world you have generated. The first rule of reading it: "We recommend using reports with a Sample Count of at least 500 for better accuracy." Sample Count is the number of Chunks generated and averaged into the report, so anything built from a handful of them is noise. Three further warnings separate a measurement from a story you tell yourself: Where you explore changes the numbers. Fly through an area made only of cheap Biomes and the report looks better than your world is. The documented fix is to explore more areas, and to use the same seed and location across asset changes when measuring an improvement. Your hardware is part of the measurement. "The computer's CPU and RAM specs and thermals impact these metrics directly. They must be accounted for when comparing reports." Thermals is the word to notice: a report taken after an hour of generation on a hot laptop is not comparable with one taken from cold. The first Chunk always lies. "The first Chunk after teleportation or world creation will take longer than average because it must initialize the context from zero. Following Chunks will see faster performance." The Metrics Worth Your Attention The report contains a great deal, and the page is explicit that only some of it is yours to influence. Sample Count. The number of Chunks generated and averaged in this report. Not a cost: it is your confidence level. Total. The total time it takes world-gen to generate and transfer the contents of a Chunk to the world. Partly yours, since transfer is not controlled by your assets. Content Generation. The time to generate the contents only, excluding transfer to the game world. This is the one: "the value you have most control over by optimizing world-gen assets". Static Bounds Initialization. The Static Stage context bounds initialization. Barely yours, since the page says it "isn't affected much by the assets". Dynamic Bounds Initialization. The Dynamic Stage context bounds initialization. Yours indirectly, through Context Precision. ExampleStage (Stage #). The time each Stage takes. Yours, through output size and the cost of the content itself. If you track one number across a change, track Content Generation. Dynamic Bounds Initialization has a single named cause, which points at a setting rather than a vague area of your asset: The Dynamic Bounds Initialization is affected by the overhead of the Chunk and Prop Context Precision options in the Runtime node. Stages, and Which Asset Each One Blames "Stages run sequentially, one after the other." Each gets its own line in the report, and the documentation maps each to the assets that drive its cost. This is the fastest route from a slow line in a log to the file you need to open. Stage What makes it expensive BiomeStage The World Structure's Biome map Density. Generated in 2D, so relatively cheap, but it becomes significant with larger output sizes. BiomeDistanceStage The World Structure's DefaultTransitionDistance and MaxBiomeEdgeDistance values. TerrainStage The same two values, because terrain in the transition area between Biomes is computed twice, once for each Biome. Plus each Biome's terrain Density and Material Provider. PropStage # The Prop Runtimes with that index inside each Biome. TintStage Each Biome's Tint Provider. EnvironmentStage Each Biome's Environment Provider. Notice how often DefaultTransitionDistance and MaxBiomeEdgeDistance appear. Two values in one asset drive three Stages, and one of them computes terrain twice in the overlap. That is the cheapest possible audit on an existing World Structure, and it is step three of the official checklist for that reason. Output Size: Why an Early Stage Pays for a Later One A Stage does not generate only the Chunk you asked for. It generates whatever area the Stages after it need as context, and the page states the direction of causation without ambiguity: The output size is determined by all the Stages with a number greater than this one. For example, Stage 2's output size is determined by Stages 3, 4, 5, 6, etc. Read that twice if you build Props. A demanding Prop Stage late in the sequence silently inflates the terrain, Materials and Biome map every earlier Stage must produce, so you can optimise a Density tree for a week and see nothing. The report exposes this in the Context Dependency section. Here is the documentation's own worked example, an illustration printed in the docs and not a measurement of any real world: ExampleStage (Stage 2): Maximum Possible Output Size (Buffer Column): {x=14, z=14} Maximum Possible Output Size (Chunk Column): {x=3.5, z=3.5} Average Actual Output Size (Buffer Column): {x=11.77, z=11.77} Average Actual Output Size (Chunk Column): {x=2.94, z=2.94} Total Buffers Generated: 18171 Maximum Possible Output Size is how large the area can get, Average Actual Output Size is the real output size over the sampled Chunks, and Total Buffers Generated is how many buffers the Stage generated across them. In the example the Stage can output a maximum of 3.5 by 3.5 Chunks and averages 2.94 by 2.94. The lever is the average: "Decreasing the Average Actual Output Size will improve a Stage's performance metric." To reduce it you reduce the required context size of the Stages following it. The page names the main contributor outright, the total size of Props in the Prop Stages, with DefaultTransitionDistance and MaxBiomeEdgeDistance as the other factors for BiomeStage. So the highest leverage question for a slow custom world is not "is my noise too expensive", it is "how large are my Props, and how many Stages are paying for them". Terrain, Part One: Focus Expensive Density by Leveraging Mix Density is calculated for every block in the world, which is the root of nearly every terrain cost. The first technique is to stop calculating it where the result cannot matter: limit the expensive parts of a Density configuration to the regions that require them, combining vertical and horizontal limiting to isolate an expensive field to the smallest region possible. Three applications are given: Above your terrain's maximum height. That area is entirely empty and does not need your terrain's Density calculated at all. Underground. Omit generating your surface Density field there. Local expensive features. Identify them, mask them with a cheap Density field, and use that mask to Mix in a cheaper field outside their active areas. The recipe for the first two is specific enough to action today: use Mix at the root of your Biomes to replace the area above the highest point of your terrain with a Constant Density of -1, and do the same underground with a Constant Density of 1. Negative values are empty space and positive values solid terrain, so those constants say "definitely air up here" and "definitely rock down there" without evaluating anything. Then the rule that will change the most node graphs: Prefer Mix over Sum, Min, or Max whenever you want to transition between different Density effects inside a Biome. Mix disables the fields where they don't need to be calculated, while the other approaches don't. Sum, Min and Max all have to evaluate both sides to produce an answer, and Mix can switch a branch off. If you have been using Min or Max as a blend because it looked right in the editor, that is a straight swap wherever Mix gives the same shape, and it is item five on the official checklist. Terrain, Part Two: Reduce Density Samples With YSampled The second technique reduces how many vertical samples a field takes. The node is YSampled, and the position is that calculating density fields for every coordinate is wasteful when it is not required. It works well for expensive fields where a higher sample resolution is not visually apparent, and less well for detailed fields, where the sampling distance may need to be reduced. The workflow is crude first, precise second. Put YSampled at the root of your Biome's Density as a first approach. If that produces undesired artifacts, add it more precisely to individual parts of your Density instead. Or go hybrid and Mix between the sampled and non-sampled versions of a field, based on how much detail each area needs: the non-sampled field around shores and the sampled field everywhere else when you need precision around the water level, or a PositionsCellNoise controlling the Mix when a field must be precise around a point of interest but can be rougher further away. The numbers are the most directly actionable thing on the page: We recommend a SampleDistance of 8 for the biggest performance improvement, and a SampleDistance of 2 in areas that require higher levels of detail. Eight for cheapness, two where detail matters, and the page invites you to experiment and measure other values rather than treating those as fixed. That is a documentation recommendation, not a benchmark of ours, and the only way to know what it does to your content is to run the report before and after on the same seed. Terrain, Part Three: Caching, and the 3D Warping Trap The Cache Density node remembers a limited number of recent coordinates and their Density values, removing recalculation when the same coordinate is requested consecutively. The page lists where it belongs, and one place where adding it is wasted effort: Not on SimplexNoise2d or CellNoise2d. Caching is already included automatically in those nodes. On the right side of YOverride nodes. This is item two of the official checklist, which suggests it is both common and commonly missed. As the Density child of the CellValue ReturnType, which depending on the PositionsCellNoise setup can benefit from larger Cache capacities. At the root of ChoiceDensity in the Density ReturnType, with the same caveat. Then the warning that is easy to miss and expensive to ignore: 3D domain warping Density nodes tend to invalidate the 2D caches of all their children, which can have a significant impact on performance. Use 2D warping instead of 3D where possible. Note how that one fails. A single 3D warp node high in your tree does not only cost its own evaluation, it can destroy the caching benefit of everything underneath it, including the automatic caching inside SimplexNoise2d and CellNoise2d. The damage is not local to the node you added, which is the kind of cost that is impossible to find by staring at a graph and easy to find in a report. It is why item one of the checklist exists. Materials: Push the Expensive Nodes to the Right Material operations run for every coordinate in the world, the same as Density, and the page notes this is particularly expensive when you use Density inside Material Provider nodes. The structural advice is about node tree layout: put expensive nodes as far to the right as possible, and nodes that limit the area as far to the left as possible. Left narrows the region, right does the costly work inside what survives. Two named providers do the narrowing. Simple Horizontal Material Provider reduces the height range for its children. Space and Depth Material Provider reduces the depth range for its children. Beyond those, two more approaches: FieldFunction with a cheap Density mask. Use the FieldFunction Material Provider with a cheap Density mask to limit an expensive Material Provider's effect to a specific area. The same masking idea as Mix, applied to Materials. The Terrain Density node. To reference the terrain's Density field for a Gradient inside a Material Provider, use the Terrain Density node rather than importing the root of your terrain's Density. It reuses the existing terrain Density buffers, which makes it much cheaper, and it outputs the interpolated fields between Biomes, which imported nodes do not. That second half is a correctness benefit as well: imported nodes will not give you smooth Biome borders. And the one specific cost figure here, which explains a lot of mysteriously slow Material Providers: A Density gradient can be very expensive, because it resolves the child Density four times for every position. Four resolutions per position, across the whole world. The advice follows: make sure you really need the gradient and cannot get a similar result without it, and where you do, mask out as much of it as possible. Steps eight and nine of the official checklist are those two points. Props and Runtimes: The Setting That Inflates Every Earlier Stage Props are where Output Size comes home, because Props are named as its main contributor right now. Three factors drive the performance impact of Props: the cost of generating their content, the cost of running their Scanners and Patterns, and the increase of the Output Size of prior Stages if the Props need to scan their content. That third one reaches backwards: a Prop that scans does not only pay for its own scan, it makes every Stage before it generate a larger region. Each Runtime also has a ContextPrecision setting, the named cause of the Dynamic Bounds Initialization metric above. The documentation gives a method rather than a value: set all the Runtimes to Biome to begin with, then test each Runtime individually with a different value and see whether it improves or hurts performance. One at a time, measured with the report. The rest is a set of rules about how Runtimes are organised: Keep each Runtime's horizontal size as small as possible, because that reduces the Output Size of prior Stages. A Runtime's size is equivalent to the largest Prop assigned to that index, so one oversized Prop sets the size for everything sharing it. Props with large horizontal patterns belong on the lowest Runtime possible. Each Runtime affects all the Runtimes below it, so moving large Props lower reduces how many Stages they impact. Put as many of a Biome's Props into a single Runtime as you can. This is the one people get backwards: "Runtimes should only be used when Props require context from other Props, not to sort Prop placement priority. Prop placement priority is determined by the order within each Runtime." If you have been adding Runtimes to control what places first, you have been paying for Stages you did not need. Keep Runtime indices consistent across a World Structure. "Make sure that all the Biomes in a World Structure are using the same Runtime indices, otherwise the world will end up with many more Runtimes than necessary." Each extra Runtime is an extra PropStage, paid everywhere in the world, because one Biome used an index nothing else uses. Break large Props into modular pieces where possible, assembled at the Prop Distribution level, to reduce horizontal size. Prepare the terrain near an important Prop to reduce the need for large complex Pattern and Scanner setups. The Official Checklist, All Ten Steps The page closes with "Useful Optimization Steps", described as roughly ordered from easier to more complex, each step linking to the section that explains it. There are ten, in order: Use 2D Density where possible, and 3D Density only when necessary. This includes preferring 2D domain warping over 3D. Put Cache nodes on the right side of all YOverride nodes. In your WorldStructure asset, make sure you're not using DefaultTransitionDistance and MaxBiomeEdgeDistance values that are greater than necessary. Replace the Density above your terrain's maximum height and underground with Constant values, using Mix. Prefer Mix over Sum, Min, or Max when transitioning between Density effects inside a Biome. Mask expensive terrain features with a cheap Density field, and Mix in a cheaper field outside their active areas. Use YSampled to reduce the number of vertical Density calculations. Limit expensive Material Providers to the smallest region possible. Reduce the Density gradient work inside your Material Providers. Optimize your Props' context size and performance. The ordering says something on its own. The first three are configuration audits that take minutes. Four to nine restructure a Density tree and then the Materials built on it. Step ten, the hardest and the last, is Props, which is where the documentation says the largest contributor to Output Size currently sits, so the easy wins and the biggest wins sit at opposite ends of the list. The Graph Generator Now Has a Real Node Reference The other half of the change is nine new pages under the Hytale Generator section. The Graph Generator itself is not new, and we want to be exact about that. The release 0.6.8 documentation already references the system throughout: its search index contains GraphPass 16 times, ContentPredicate 16, GraphContent 12, NodeAction 10, ContentSupplier 10, EdgeAction 8 and GraphGenerator 6, and the asset page at /assets/hytalegenerator/graphgenerators responds identically on both hosts. What changed is the documentation, not the system. A feature that shipped with thin asset-level coverage now has a proper node reference. The nine pages, with the official one line description each carries: Graph Generator: "Generates a field of interconnected nodes that carry content such as Density, Prop Distribution, Positions and Material Provider." Graph Pass: "Builds the graph step by step. Each pass reads and edits the whole graph." Graph Content: "The content a graph node carries, split by content type into named layers." Node Action: "Actions that run on graph nodes." Node Selector: "Defines a subset of nodes." Edge Action: "Actions that run on graph edges (connections between two nodes)." Edge Selector: "Defines a subset of edges." Content Predicate: "Tests the Content attached to a graph node." Content Supplier: "Resolves what Content to supply for a given context." The model: "The graph is built step by step by a list of Graph Passes. Each pass modifies the graph until it reaches its final form." The worked sequence given is three passes, where the first places some empty nodes, the second connects nodes that are close to each other, and the third puts content on the nodes. And the separation that matters for performance reasoning: Graph generation and content generation are two separate steps. Graph generation places the nodes, their connections and the content they carry. Content generation then builds the world content that players see. The page splits the total cost into building the graph, caching and retrieving it, and generating the content, and names three drivers of the last one: a larger Range on the content a node carries, a higher number of graph nodes per unit of space, and the content itself, for example expensive noise or expensive Props. The graph has its own report, separate from the world-gen one, and it is off by default: "Set PrintStats to true to see your own numbers. The Graph Generator then writes a performance report to the logs." StatsLabel, safe value "UNNAMED", names the generator in that report, and StatsPrintInterval, safe value 50, prints it after that many cells. The report gives per pass timings and a Context Bounds block per pass. In the documentation's own worked example, which is printed in the docs rather than measured from a real world, the cell is 100 blocks per axis and Pass 1 generates 380 blocks per axis, which the page notes is 55 times the volume of the cell. Work grows on all three axes, so, in its words, one large context requirement in a late pass can dominate the cost of every earlier pass. That is the same backwards-reaching structure as Output Size, in a different system. Several actions also move or place nodes at a distance computed while the graph generates, so they take a cap, named as MaxDistance, MaxOffsetExclusive or MaxProxyDistance. Set a cap to the smallest value still above the largest value its provider can return, because a cap that is too large makes every earlier pass generate more than it needs. CacheCellSize and CacheCapacity: Two Numbers With Real Consequences CacheCellSize is a decimal Vector3d where every component must be greater than 0, with a safe value of {"X": 320, "Y": 320, "Z": 320}. The Graph Generator splits the graph into a grid of cells and caches each one after generating it, and this sets how big one cell is. The documented starting point: A good general starting size for most applications is from {320, 320, 320} to {700, 320, 700}. Note that Y stays at 320 across that range while X and Z grow. Both failure directions are documented. Too small, and graph generation overhead is paid more often, lowering average content generation performance, while the cache covers a smaller total area because CacheCapacity counts cells and not volume, so cells are evicted and regenerated more often. Too large, and each cell takes longer to generate, content generation waits whenever it queries an uncached cell so performance becomes uneven, each cached cell costs more memory, and more of the generated graph area is never explored by players. Oversized cells do not necessarily make the average worse, they make it spikier, and a spiky average is what players feel as a hitch when they cross an invisible line. CacheCapacity is an integer of at least 1 with a safe value of 50, described as follows: "Sets how many cells can stay in memory at once." It does not affect graph delivery performance but it can affect content generation performance, and the downside of getting it wrong is stated bluntly: If the capacity is too small, then the graph gets generated a lot more times than necessary and can dramatically slow down content generation performance. Too large wastes memory for minimal benefit, made worse by a very large CacheCellSize or a graph with high node density. The recommendation is unambiguous: "A good starting value is 50." The two are not independent dials, because capacity counts cells rather than volume, and the page says the optimal cell size is found by tweaking and benchmarking. The Renamed Pages, and the Six That Now Return 404 Eight pages exist on the release documentation and not on the pre-release one. Most are renames, plural to singular: curves became curve, patterns became pattern, props became prop, scanners became scanner and material-providers became material-provider, all under /hytale-generator/. directionality is gone outright with no replacement page. The remaining two release-only pages are /assets/misc/chestconfig and /creating-content/world-generation/world-generation-concepts. The practical part is that the handling is not consistent. On the pre-release documentation all six of those /hytale-generator/ paths return a hard HTTP 404. No redirect, no suggestion. But /creating-content/world-generation/world-generation-concepts does not 404 there: it returns HTTP 301 with a location header pointing at /creating-content/world-generation/density-generation-concepts. So the concepts page was redirected properly and the six node pages were not. If you have bookmarks, a wiki or a tutorial linking to the old curves, patterns, props, scanners, material-providers or directionality pages, those links are dead on the pre-release site and need editing by hand. Our own June guide to the graph system and its nodes is in that category: several of its documentation links point at the old plural paths, and those pages now live at the singular ones. The old concepts page has been split into three, each with its own official description: Density Generation Concepts, "Explores how Density fields define the shape of Hytale's terrain."; Materials Generation Concepts, "Explores how materials are chosen for the terrain a Density field produces."; and Prop Generation Concepts, "Explores how Props place content in a limited region of the world." Those map onto the three technique sections of the Performance Optimization page, so read them first if you are coming to worldgen v2 fresh. What This Guide Does Not Fix It is not a server lag fix, and it will not help a vanilla server. Everything here is the cost of generating world content, not tick rate with players online. If you are not shipping custom world generation assets, there is nothing here for you: you cannot apply Mix at the root of a Biome you did not author. It is not the Performance Saver plugin, and the two are unrelated. That is a third party plugin dealing with runtime server behaviour, covered in our separate guide. This is engine documentation about asset design. It does not cover server configuration, which is tuning a server from the console and the maxViewRadius documentation, and it is not a launch day checklist, which is our Chapter 1 server preparation checklist. It says nothing about worldgen v1. These are v2 nodes. If you are still on v1, read what happens to existing v1 worlds, v1 remaining moddable and what Update 8 may do to v1 modding. Frequently Asked Questions Which number should I optimise, and how many Chunks do I need? Content Generation, which the page calls "the value you have most control over by optimizing world-gen assets". Total includes the time to transfer generated data to the world, which your assets do not control. Use a Sample Count of at least 500, which the documentation recommends for better accuracy. Is the Graph Generator new in Chapter 1? No. The documentation is new, the system is not. The release 0.6.8 documentation already references GraphPass, ContentPredicate, GraphContent, NodeAction, ContentSupplier, EdgeAction and GraphGenerator throughout, and the Graph Generator asset page responds the same way on both documentation hosts. What arrived is a nine page node reference for something that previously had thin asset-level coverage. My bookmark to the Hytale node documentation stopped working. Why? Six paths under /hytale-generator/ return a hard 404 on the pre-release site: curves, patterns, props, scanners, material-providers and directionality. Five were renamed from plural to singular and directionality is gone outright. The old world generation concepts page is the exception that was handled properly, returning a 301 to the density generation concepts page. What We Have Not Tested We have not run a single benchmark. No generated worlds, no performance reports of our own, no before and after timings. There is not one measurement of ours in this article. Every number above comes from the official documentation. The Sample Count of 500, the SampleDistance values of 8 and 2, the gradient resolving its child four times per position and the CacheCapacity of 50 are documentation recommendations, not results we reproduced. The example report figures are the documentation's own worked example. The Stage 2 output sizes of {x=11.77, z=11.77}, the Total Buffers Generated figure of 18171, the Pass 3 timings and the 100 block cell growing to 380 blocks of work are illustrations printed on the official pages, not measurements of a real world. We have not verified that the techniques produce improvements. They are the engine authors' recommendations, and only your own report, on a fixed seed and location, can answer whether they help your content. We have not seen the Chapter 1 build, and nobody outside the studio has. This documentation is pinned to 0.7.0-pre.5 and may not match what ships. We also make no claim about how many creators it affects. We are not claiming anything was hidden. One line in the Part 5 notes points at the documentation and the rest of the change is not described there. That is a fact about the notes, not a statement about intent. The Bottom Line If you ship custom world generation, three things are worth doing before Monday. Open your latest world log and find the performance report, because you already have one. Check the Runtime indices across the Biomes in your World Structure, since mismatched indices create Runtimes you pay for everywhere. And look for 3D domain warping you could do in 2D, which is item one on the official checklist and the one failure mode whose cost spreads to nodes you did not touch. Everything else rewards the same method: fixed seed, same location, at least 500 Chunks, one change at a time, and the report rather than your instincts deciding whether it worked. The documentation is candid that it is incomplete and will grow. Reading it now, three days out, is still a better position than the guesswork of last week.