GregoryAM-SP
Overviewer 1.20.2 / MC 1.20 | Cropped Render cut off at southern border
Initially reported in the old project, this issue seems to persist in this updated version too.
Issue Description:
When using the crop feature, the bottom row of images is not displayed / rendered.
This issue starts happening with renders that have a configured render-depth of roughly -50 or less.
regular renders are unaffected by this issue.
Example:
Settings used for this render:
'dimension': 'overworld', 'center': [0,64,0], 'crop': (-160,-160,143,143)
Current Workaround: create a cropped copy of the world, then render this copy without the setting. As such impact is low / trivial, however it would be nice to cut out that middle step.
I'll take a look at this! Thank you for bringing this up, as I haven't gone through every configuration setting available on Overviewer.
@HowDenKing, So I looked into this. I was able to reproduce the issue.
However, every attempt at modifying the Crop feature yielded no positive results; only map breaking results. I even went through the documentation for Overviewer to see if there was a possible fix using other methods, and I was unable to locate one.
Can you provide the work around in a step-by-step comment?
Do you just remove the crop feature after using it in your initial render?
Was worth a shot. Thank you for attempting to solve it, though.
Can you provide the work around in a step-by-step comment? Do you just remove the crop feature after using it in your initial render?
- I make a copy of the world folder, making sure only the region files I wish to render exist in this copy.
- then add this copy as a new world definition to my overviewer configuration.
/edit: I forgot to mention I copy the region with mcaselector.
It is the same process as how one would remove excess chunks.
@HowDenKing, So I looked into this. I was able to reproduce the issue.
However, every attempt at modifying the Crop feature yielded no positive results; only map breaking results. I even went through the documentation for Overviewer to see if there was a possible fix using other methods, and I was unable to locate one.
Can you provide the work around in a step-by-step comment?
Do you just remove the crop feature after using it in your initial render?
Are you using any external softwares? Such as MCA Selector? Saw your edit come in and mention this.
@HowDenKing, https://github.com/GregoryAM-SP/The-Minecraft-Overviewer/releases/tag/v1.20.3
This fixes the issue you were having.
Edit: You shouldn't have to rely on creating copies anymore. 👍
I've ended up doing some digging into this since the fix to this issue has caused another issue reported in #90.
I reverted the changes made to fix this issue in a local branch, and was able to reproduce the issue using the crop bounds reported:
Looking at the developer tools to highlight the individual rendered tiles, it becomes apparent that this is nothing to do with the in-world coordinates based crop. This is an issue with the lowest tile not rendering correctly:
Overviewer needs to figure out how many zoom levels it needs to render a map, and it does this using two functions.
_find_chunk_range() iterates over all chunks in the RegionSet (either a normal RegionSet, a CroppedRegionSet, or one of the other subclasses). It converts the coordinates of the chunk into a tile position, and then notes the max and min for the tile rows and columns.
https://github.com/GregoryAM-SP/The-Minecraft-Overviewer/blob/24b9ec63f19168b17fa8e4b96c3966fedb4b8360/overviewer_core/tileset.py#L636-L651
_set_map_size() uses the bounds found by _find_chunk_range() and determines the smallest power of 2 which will fit all the tiles required to render the current RegionSet.
https://github.com/GregoryAM-SP/The-Minecraft-Overviewer/blob/24b9ec63f19168b17fa8e4b96c3966fedb4b8360/overviewer_core/tileset.py#L653-L682
There's a discrepancy here though - figuring out what will fit in an (x,z) system is easy because we use the chunk (x,z) to calculate rows and columns as a 2D coordinate system. However, not only is there a third dimension to consider - y - we're rendering this isometrically so it has additional y height. We've got a fudge factor built in here already of 32 blocks and the comment specifically calls out that chunks are really tall. This code hasn't been touched since 2012, so it far predates the changes to world height in 1.17.
This is going to be a rather rare occurrence - there is a very limited number of RegionSet sizes which will trigger this bug in a way that causes the bottom of the world to drop below a zoom level boundary. Since the boundaries are exponentially defined, they will cluster around the smallest RegionSet sizes, and the easiest way to get a small RegionSet is to have a CroppedRegionSet. You should be able to trigger this bug with a larger map without cropping, but only if that larger map is unfortunately sized to be just within the bounds of a zoom level increase.
The correct fix for this is likely to bump that fudge factor such that a larger chunk height is accounted for - bumping this to 64 should adequately account for this, and indeed it appears to without needing to mess with the crop bounds:
Funnily enough, the render log even shows that we've had to bump up a zoom level during the render:
*******************************************************************************
2025-05-20 20:30:26 W Your map seems to have expanded beyond its previous bounds.
**********************************************************************
2025-05-20 20:30:26 W Doing some tile re-arrangements... just a sec...
It looks like the fudge factor is only present at the bottom of the world. On the assumption that a fudge factor of 32 protects y=64 down to y=0, it's likely that a fudge factor of 64 will protect y=64 down to y=-64. I suspect that this will also protect a similar distance upwards, so up to y=(64+128) or y=192. Since the world can have blocks up to y=320, I'm slightly concerned this issue may also affect the top of maps. However, most people won't have solid areas of blocks at the build limit in the overworld that could highlight this issue so I'm not going to bother trying to recreate it.
Onto the impact of this change - the initial change implemented to resolve this bug will have changed the bounds for every cropped regionset that anyone has. If people have made subsequent changes to the crop bounds to account for this, they will need to undo those changes to their config. Since the crop margin was defined at 5 chunks, this will mean a change of 5 * 16 = 80 blocks on each coordinate.
