Custom block geometries > 1 block wide/tall no longer render
When creating custom blocks that use a custom geometry that contains a model larger than 16x16x16 pixels, aka one Minecraft block, the geometry causes errors and forces the block to appear as the "update" block.
Here is the error message:
[Blocks][error]-geometry.testblock contains 1 boxes outside the error bounds of (-0.01, -0.01, -0.01) to (1.01, 1.01, 1.01)
Additional info by Lord of Nubs
This problem did not exist in previous updates if a block was larger than 16x16x16 (unit cube) or had a bone that exceeded the 16x16x16 bounds by as little as 0.001 pixel; the geometry file would continue to load normally, but an error message would appear (which is preferred to this new way of handling larger geometry files)
This new method breaks MANY addons... it would be great if creators had the option (like in previous versions.) and weren't forced into making blocks use separate geos (if larger than 16x16x16).
It should also be noted that several vanilla blocks break the bounds, including (but not limited to) lecterns, spore blossom, walls/fences, and open shulkers boxes.
If intentional, it seems unfair that vanilla blocks are able to break these bounds while modded blocks cannot.
There was also no mention of the change in the changelog, or a reason as to why the change was made.The current warning bounds are also incorrect (reports -0.1,-0.1,-0.1 to 1.1,1.1,1.1, when in practice this extra space is not included; actual bounds are (0,0,0) to 1.1,1.1,1.1. (1,1,1). Prior to this update, the warning was (-0.5,-0.5,-0.5) to (1.5,1.5,1.5), which makes much more sense. (Given the fact that vanilla some blocks break the 1, 1, 1 format by half a block at most)
As a final note, custom block geometries on Java Edition can be as large as 3x3x3 (blocks, not pixels). This was how bedrock was before this update...
Linked Issues
is duplicated by10
MCPE-152256Data driven blocks' geometries reaching outside 16x16x16 are brokenDuplicateMCPE-152267Custom blocks that taller than 16x16x16 are not renderingDuplicateMCPE-152330Blocks With Custom Models using custom block states do not workDuplicateMCPE-152605Addons don't work. DuplicateMCPE-152643Addons blocksDuplicateMCPE-152858Addons Bugs with updateDuplicateMCPE-152903Block Geometry ErrorDuplicateMCPE-152906Experimental World Addon Textures Broken For Most add-on blocksDuplicateMCPE-162538custom block geometries now turn into updates blocks if too bigDuplicateMCPE-162746custom blocks models added by addons dont renderDuplicateAttachments16
Created Issue:
Custom block geometries cause blocks to break
When creating custom blocks that use a custom geometry that contains a model larger than 16x16x16 pixels, aka one Minecraft block, the geometry causes errors and forces the block to appear as the "update" block
When creating custom blocks that use a custom geometry that contains a model larger than 16x16x16 pixels, aka one Minecraft block, the geometry causes errors and forces the block to appear as the "update" block.
Here is the error message:
[Blocks] [error] -geometry.testblock contains 1 boxes outside the error bounds of (-0.01, -0.01, -0.01) to (1.01, 1.01, 1.01)
![[Mod] tryashtar](../../../data/avatars/users/41963.png){kind=small}
When creating custom blocks that use a custom geometry that contains a model larger than 16x16x16 pixels, aka one Minecraft block, the geometry causes errors and forces the block to appear as the "update" block.
Here is the error message:
[Blocks][error]-geometry.testblock contains 1 boxes outside the error bounds of (-0.01, -0.01, -0.01) to (1.01, 1.01, 1.01)
Additional info by Lord of Nubs
This problem did not exist in previous updates if a block was larger than 16x16x16 (unit cube) or had a bone that exceeded the 16x16x16 bounds by as little as 0.001 pixel; the geometry file would continue to load normally, but an error message would appear (which is preferred to this new way of handling larger geometry files)
This new method breaks MANY addons... it would be great if creators had the option (like in previous versions.) and weren't forced into making blocks use separate geos (if larger than 16x16x16).
It should also be noted that several vanilla blocks break the bounds, including (but not limited to) lecterns, spore blossom, walls/fences, and open shulkers boxes.
If intentional, it seems unfair that vanilla blocks are able to break these bounds while modded blocks cannot.
There was also no mention of the change in the changelog, or a reason as to why the change was made.The current warning bounds are also incorrect (reports -0.1,-0.1,-0.1 to 1.1,1.1,1.1, when in practice this extra space is not included; actual bounds are (0,0,0) to 1.1,1.1,1.1. (1,1,1). Prior to this update, the warning was (-0.5,-0.5,-0.5) to (1.5,1.5,1.5), which makes much more sense. (Given the fact that vanilla some blocks break the 1, 1, 1 format by half a block at most)
As a final note, custom block geometries on Java Edition can be as large as 3x3x3 (blocks, not pixels). This was how bedrock was before this update...
![[Mod] GoldenHelmet](../../../data/avatars/users/18951.svg){kind=small}
Custom block geometriescauseblocks to breakCustom block geometries > 1 block wide/tall no longer render
![[Mod] OcelotOnesie](../../../data/avatars/users/43220.png){kind=small}
is duplicated by
is duplicated by
is duplicated by
Screenshot 2022-01-22 193623.png
When creating custom blocks that use a custom geometry that contains a model larger than 16x16x16 pixels, aka one Minecraft block, the geometry causes errors and forces the block to appear as the "update" block.
Here is the error message:
[Blocks][error]-geometry.testblock contains 1 boxes outside the error bounds of (-0.01, -0.01, -0.01) to (1.01, 1.01, 1.01)
Additional info by Lord of Nubs
This problem did not exist in previous updates if a block was larger than 16x16x16 (unit cube) or had a bone that exceeded the 16x16x16 bounds by as little as 0.001 pixel; the geometry file would continue to load normally, but an error message would appear (which is preferred to this new way of handling larger geometry files)
This new method breaks MANY addons... it would be great if creators had the option (like in previous versions.) and weren't forced into making blocks use separate geos (if larger than 16x16x16).
It should also be noted that several vanilla blocks break the bounds, including (but not limited to) lecterns, spore blossom, walls/fences, and open shulkers boxes.
If intentional, it seems unfair that vanilla blocks are able to break these bounds while modded blocks cannot.
There was also no mention of the change in the changelog, or a reason as to why the change was made.The current warning bounds are also incorrect (reports -0.1,-0.1,-0.1 to 1.1,1.1,1.1, when in practice this extra space is not included; actual bounds are (0,0,0) to 1.1,1.1,1.1. (1,1,1). Prior to this update, the warning was (-0.5,-0.5,-0.5) to (1.5,1.5,1.5), which makes much more sense. (Given the fact that vanilla some blocks break the 1, 1, 1 format by half a block at most)
As a final note, custom block geometries on Java Edition can be as large as 3x3x3 (blocks, not pixels). This was how bedrock was before this update...
When creating custom blocks that use a custom geometry that contains a model larger than 16x16x16 pixels, aka one Minecraft block, the geometry causes errors and forces the block to appear as the "update" block.
Here is the error message:
[Blocks][error]-geometry.testblock contains 1 boxes outside the error bounds of (-0.01, -0.01, -0.01) to (1.01, 1.01, 1.01)
Additional info by Lord of Nubs
This problem did not exist in previous updates if a block was larger than 16x16x16 (unit cube) or had a bone that exceeded the 16x16x16 bounds by as little as 0.001 pixel; the geometry file would continue to load normally, but an error message would appear (which is preferred to this new way of handling larger geometry files)
This new method breaks MANY addons... it would be great if creators had the option (like in previous versions.) and weren't forced into making blocks use separate geos (if larger than 16x16x16).
It should also be noted that several vanilla blocks break the bounds, including (but not limited to) lecterns, spore blossom, walls/fences, and open shulkers boxes.
If intentional, it seems unfair that vanilla blocks are able to break these bounds while modded blocks cannot.
There was also no mention of the change in the changelog, or a reason as to why the change was made.The current warning bounds are also incorrect (reports -0.1,-0.1,-0.1 to 1.1,1.1,1.1, when in practice this extra space is not included; actual bounds are (0,0,0) to 1.1,1.1,1.1. (1,1,1). Prior to this update, the warning was (-0.5,-0.5,-0.5) to (1.5,1.5,1.5), which makes much more sense. (Given the fact that vanilla some blocks break the 1, 1, 1 format by half a block at most)
As a final note, custom block geometries on Java Edition can be as large as 3x3x3 (blocks, not pixels). This was how bedrock was before this update...
![[MCQA] v-weszaj](../../../data/avatars/users/18941.svg){kind=small}
is duplicated by
is duplicated by
![[Bot] Arisa](../../../data/avatars/users/43007.png){kind=small}
When creating custom blocks that use a custom geometry that contains a model larger than 16x16x16 pixels, aka one Minecraft block, the geometry causes errors and forces the block to appear as the "update" block.
Here is the error message:
[Blocks][error]-geometry.testblock contains 1 boxes outside the error bounds of (-0.01, -0.01, -0.01) to (1.01, 1.01, 1.01)
Additional info by Lord of Nubs
This problem did not exist in previous updates if a block was larger than 16x16x16 (unit cube) or had a bone that exceeded the 16x16x16 bounds by as little as 0.001 pixel; the geometry file would continue to load normally, but an error message would appear (which is preferred to this new way of handling larger geometry files)
This new method breaks MANY addons... it would be great if creators had the option (like in previous versions.) and weren't forced into making blocks use separate geos (if larger than 16x16x16).
It should also be noted that several vanilla blocks break the bounds, including (but not limited to) lecterns, spore blossom, walls/fences, and open shulkers boxes.
If intentional, it seems unfair that vanilla blocks are able to break these bounds while modded blocks cannot.
There was also no mention of the change in the changelog, or a reason as to why the change was made.The current warning bounds are also incorrect (reports -0.1,-0.1,-0.1 to 1.1,1.1,1.1, when in practice this extra space is not included; actual bounds are (0,0,0) to 1.1,1.1,1.1. (1,1,1). Prior to this update, the warning was (-0.5,-0.5,-0.5) to (1.5,1.5,1.5), which makes much more sense. (Given the fact that vanilla some blocks break the 1, 1, 1 format by half a block at most)
As a final note, custom block geometries on Java Edition can be as large as 3x3x3 (blocks, not pixels). This was how bedrock was before this update...
When creating custom blocks that use a custom geometry that contains a model larger than 16x16x16 pixels, aka one Minecraft block, the geometry causes errors and forces the block to appear as the "update" block.
Here is the error message:
[Blocks][error]-geometry.testblock contains 1 boxes outside the error bounds of (-0.01, -0.01, -0.01) to (1.01, 1.01, 1.01)
Additional info by Lord of Nubs
This problem did not exist in previous updates if a block was larger than 16x16x16 (unit cube) or had a bone that exceeded the 16x16x16 bounds by as little as 0.001 pixel; the geometry file would continue to load normally, but an error message would appear (which is preferred to this new way of handling larger geometry files)
This new method breaks MANY addons... it would be great if creators had the option (like in previous versions.) and weren't forced into making blocks use separate geos (if larger than 16x16x16).
It should also be noted that several vanilla blocks break the bounds, including (but not limited to) lecterns, spore blossom, walls/fences, and open shulkers boxes.
If intentional, it seems unfair that vanilla blocks are able to break these bounds while modded blocks cannot.
There was also no mention of the change in the changelog, or a reason as to why the change was made.The current warning bounds are also incorrect (reports -0.1,-0.1,-0.1 to 1.1,1.1,1.1, when in practice this extra space is not included; actual bounds are (0,0,0) to 1.1,1.1,1.1. (1,1,1). Prior to this update, the warning was (-0.5,-0.5,-0.5) to (1.5,1.5,1.5), which makes much more sense. (Given the fact that vanilla some blocks break the 1, 1, 1 format by half a block at most)
As a final note, custom block geometries on Java Edition can be as large as 3x3x3 (blocks, not pixels). This was how bedrock was before this update...
When creating custom blocks that use a custom geometry that contains a model larger than 16x16x16 pixels, aka one Minecraft block, the geometry causes errors and forces the block to appear as the "update" block.
Here is the error message:
[Blocks][error]-geometry.testblock contains 1 boxes outside the error bounds of (-0.01, -0.01, -0.01) to (1.01, 1.01, 1.01)
Additional info by Lord of Nubs
This problem did not exist in previous updates if a block was larger than 16x16x16 (unit cube) or had a bone that exceeded the 16x16x16 bounds by as little as 0.001 pixel; the geometry file would continue to load normally, but an error message would appear (which is preferred to this new way of handling larger geometry files)
This new method breaks MANY addons... it would be great if creators had the option (like in previous versions.) and weren't forced into making blocks use separate geos (if larger than 16x16x16).
It should also be noted that several vanilla blocks break the bounds, including (but not limited to) lecterns, spore blossom, walls/fences, and open shulkers boxes.
If intentional, it seems unfair that vanilla blocks are able to break these bounds while modded blocks cannot.
There was also no mention of the change in the changelog, or a reason as to why the change was made.The current warning bounds are also incorrect (reports -0.1,-0.1,-0.1 to 1.1,1.1,1.1, when in practice this extra space is not included; actual bounds are (0,0,0) to 1.1,1.1,1.1. (1,1,1). Prior to this update, the warning was (-0.5,-0.5,-0.5) to (1.5,1.5,1.5), which makes much more sense. (Given the fact that vanilla some blocks break the 1, 1, 1 format by half a block at most)
As a final note, custom block geometries on Java Edition can be as large as 3x3x3 (blocks, not pixels). This was how bedrock was before this update...
When creating custom blocks that use a custom geometry that contains a model larger than 16x16x16 pixels, aka one Minecraft block, the geometry causes errors and forces the block to appear as the "update" block.
Here is the error message:
[Blocks][error]-geometry.testblock contains 1 boxes outside the error bounds of (-0.01, -0.01, -0.01) to (1.01, 1.01, 1.01)
Additional info by Lord of Nubs
This problem did not exist in previous updates if a block was larger than 16x16x16 (unit cube) or had a bone that exceeded the 16x16x16 bounds by as little as 0.001 pixel; the geometry file would continue to load normally, but an error message would appear (which is preferred to this new way of handling larger geometry files)
This new method breaks MANY addons... it would be great if creators had the option (like in previous versions.) and weren't forced into making blocks use separate geos (if larger than 16x16x16).
It should also be noted that several vanilla blocks break the bounds, including (but not limited to) lecterns, spore blossom, walls/fences, and open shulkers boxes.
If intentional, it seems unfair that vanilla blocks are able to break these bounds while modded blocks cannot.
There was also no mention of the change in the changelog, or a reason as to why the change was made.The current warning bounds are also incorrect (reports -0.1,-0.1,-0.1 to 1.1,1.1,1.1, when in practice this extra space is not included; actual bounds are (0,0,0) to 1.1,1.1,1.1. (1,1,1). Prior to this update, the warning was (-0.5,-0.5,-0.5) to (1.5,1.5,1.5), which makes much more sense. (Given the fact that vanilla some blocks break the 1, 1, 1 format by half a block at most)
As a final note, custom block geometries on Java Edition can be as large as 3x3x3 (blocks, not pixels). This was how bedrock was before this update...
is duplicated by
Tried the above BlockGeoFi mcpack. Doesn't fix anything for me. From what I gather, it needs something from the marketplace to work?
EDIT: Correction, I was able to get it to fix some... but not others.
is duplicated by
is duplicated by
I truly hope this will be fixed soon. It broke a big amount of my blocks at this moment since 1.18.10.
Some of them are even blocks that I can not make into 16x16x16 blocks, meaning that my project is on hold till this will be fixed.Like said above, before it was not a problem to have block that are bigger then a 16x16x16 block and the loaded and worked fine.
A error message is something I can understand, but limiting players to not make their models bigger then 16x16x16 doesnt seem to be fair specially as it worked for months.
is duplicated by
relates to
is duplicated by
is duplicated by
is duplicated by
![[Mod] Jarl-Penguin](../../../data/avatars/users/92849.png){kind=small}
Thank you for your report!
We're tracking this issue in MCPE-152191, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
Thank you for your report!
We're tracking this issue in MCPE-152191, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
Thank you for your report!
We're tracking this issue in MCPE-152191, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
Does MCPE-152191 describe your issue?
Please search before reporting, as this duplicates MCPE-152191
Thank you for your report!
We're tracking this issue in MCPE-152191, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
– I am a bot. This action was performed automatically! The ticket was resolved by one of our moderators, and I left this message to give more information to you.
Thank you for your report!
We're tracking this issue in MCPE-152191, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
Thank you for your report!
We're tracking this issue in MCPE-152191, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
– I am a bot. This action was performed automatically! The ticket was resolved by one of our moderators, and I left this message to give more information to you.
Thank you for your report!
We're tracking this issue in MCPE-152191, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
Thank you for your report!
We're tracking this issue in MCPE-152191, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
– I am a bot. This action was performed automatically! The ticket was resolved by one of our moderators, and I left this message to give more information to you.
Does MCPE-152191 describe your issue?
If not, then your report does not contain enough information to fully understand or reproduce the problem.
Please include a numbered list of steps along with the Observed and Expected results by Editing the Description above as shown here:
Steps to Reproduce:
1. (list every step exactly, so someone else can reproduce the issue, and try following your list to make sure you can still reproduce the issue yourself)
2.
3.
Observed Results:
(briefly describe what actually happens, including exact message(s) shown)
Expected Results:
(briefly describe what should happen)
(add screenshots or video to help explain the issue)
This report has been temporarily closed as Awaiting Response. It will automatically reopen when you add information. Please follow the format shown and include all sections (steps, observed, expected). Reports that do not contain all of the requested information and complete steps to reproduce the issue may be closed as Incomplete. For more information please read the Bug Tracker Guidelines.
You may find this Report Creation Form helpful for any future reports you create.
![[Mod] EVGENSYPERPRO](../../../data/avatars/users/92853.png){kind=small}
Thank you for your report!
We're tracking this issue in MCPE-152191, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
Does MCPE-152191 describe your issue?
If not, then your report does not contain enough information to fully understand or reproduce the problem.
Please include a numbered list of steps along with the Observed and Expected results by Editing the Description above as shown here:
Steps to Reproduce:
1. (list every step exactly, so someone else can reproduce the issue, and try following your list to make sure you can still reproduce the issue yourself)
2.
3.
Observed Results:
(briefly describe what you see happen, including any message(s) shown)
Expected Results:
(briefly describe what should happen)
(add screenshots or video to help explain the issue)
This report has been temporarily closed as Awaiting Response. It will automatically reopen when you add information. Please follow the format shown and include all sections (steps, observed, expected). Reports that do not contain all of the requested information and complete steps to reproduce the issue may be closed as Incomplete. For more information please read the Bug Tracker Guidelines.
You may find this Report Creation Form helpful for any future reports you create.
I can't test it anymore because you guys killed > 3x3x3 blocks. The block geos in the screenshots get rejected by the game despite once being able to use them.
See: MCPE-152191
This problem did not exist in previous updates if a block was larger than 16x16x16 (unit cube) or had a bone that exceeded the 16x16x16 bounds by as little as 0.001 pixel; the geometry file would continue to load normally, but an error message would appear (which is preferred to this new way of handling larger geometry files)
This new method breaks MANY addons... it would be great if creators had the option (like in previous versions.) and weren't forced into making blocks use separate geos (if larger than 16x16x16).
It should also be noted that several vanilla blocks break the bounds, including (but not limited to) lecterns, spore blossom, walls/fences, and open shulkers boxes.
If intentional, it seems unfair that vanilla blocks are able to break these bounds while modded blocks cannot.
There was also no mention of the change in the changelog, or a reason as to why the change was made.
The current warning bounds are also incorrect (reports -0.1,-0.1,-0.1 to 1.1,1.1,1.1, when in practice this extra space is not included; actual bounds are (0,0,0) to 1.1,1.1,1.1. (1,1,1). Prior to this update, the warning was (-0.5,-0.5,-0.5) to (1.5,1.5,1.5), which makes much more sense. (Given the fact that vanilla some blocks break the 1, 1, 1 format by half a block at most)
As a final note, custom block geometries on Java Edition can be as large as 3x3x3 (blocks, not pixels). This was how bedrock was before this update...
Example of an addon that is broken by this change: https://mcpedl.com/fauna-and-flora/
Direct download link: https://www.mediafire.com/file/8aoupx5ogvkwtj2/Fauna_And_Flora_Addon.mcaddon/file
I'm receiving the same error. I made a statue of a cat that is outside the 16 X 16 X 16 bounds. It worked yesterday and now says the texture needs to be updated and that it is outside the bounds.
I am also having this error since my game updated to 1.18.10 yesterday, models that worked just fine before are now wrecked. I dearly hope this was caused by a programming oversight and is neither intentional nor permanent.
Edit: I have now added example screenshots.
This needs to be fixed ASAP this has crippled my realm, My ATM, Slot Machines, Custom Crafting Tables, My giant custom block map all broken now
Two of my addons with broken 3d models.
This crippled my server. Most custom blocks do not render anymore. Many custom blocks that that have worked for well over a year are broken now.
This is an example of a custom head, which simulates a player head model, which contains a first 8x8 cube centered on the block space, and a second cube which is a copy of the first but inflate 0.5 so it can have the second layer of what player skins heads have.
That second layer clips a bit on the ground so it is displayed accordingly to where it would be if it was on the player head, and if I were to move it up so it does not clip it would look as that second skin layer would be offset and not according to the player model, or if moved the whole block up, it would be floating for skins which do not have the outer layer.
This is another exaple of what this issue breaks, as stated on Lord Nubs comment, to be in parity with Java Edition and how the vanilla game behaves I think it should be extended to 3x3x3 max size, or the equivalent of bounds from (-1.0,-1.0,-1.0) to (2.0,2.0,2.0)
custom_head.geo.json
I found this message in the latest beta for bedrock. Would this mean that this bug is intentional because of "engine limitations"?
As stated the author, a lot of Vanilla blocks are outside the box, there is no "engine limitation",otherwise these blocks would not render anymore as well
Yeah, "engine limitation" is a straight up lie. These models used to render perfectly fine. Starting to feel like a BS cover to kneecap modding support to favor the marketplace. Gets even more suspicious when you look and see none of the marketplace stuff broken.
Engine limitations?
Attached another example of geometry that used to work perfectly but got ruined. banquet_chair.geo.json
This whole change is just awful. Ruins vanilla parity, breaks tons of mods, cites "engine limitations" when that's obviously not true. It's one thing to limit it to something reasonable, like 3x3 (like vanilla, allowing geo to pass into the neighbouring blocks, but no further), but... not like this.
If Mojang is dead set in this, a large segment of the modding community is going to die off quickly. Please, fix this.
update the affect platform to Multiple, since it happen on Mobile as well, and might happen on console too
Hi guys, I surfed the web a bit and found a texture pack that fixes the problem
Download: BlockGeoFi.mcpack
That pack works for now, but the fact that it works, seems to make the excuse of "engine limitation" even more suspicious. It should be fixed proper.
Hey Everyone! I opened up the pack that fixes the geometry problem. Looks like all they did was change the engine number in the manifest.json so that it is before 1.18.1. So try that. Should work.
I really hope Mojang fixes this. Multiple of my packs require this to work.
@Paul Ellsworth the pack does not fix the issue because of the min engine version. It is because it uses a marketplace pack's uuid which has been whitelisted to have the engine version locked. Normal creators do not have access to this. So setting your pack to the same uuid as the linked pack will fix the issue regardless of min engine version, and setting min engine version will not fix the issue.
I would also like to add that this limitation even breaks the use of Mojang's own geometries in a custom block definition... even tiny things like geometry.player_head since they often have a pivot or one point that trails over the line. So this limitation... if it is truly about performance... makes very little sense if Mojang's own vanilla resources routinely violate it.
Since this is a intentional change I'm not sure why this bug report is marked as confirmed anymore.
Because it is an extremely terrible change.
The game keeps rendering my models as 16x16x16 cubes with the texture file on all sides, completely ignoring the geometry
They should just get rid of the stupid arbitrary UUID whitelist for this (making things as they used to be), and fix this while they're at it: https://bugs.mojang.com/browse/MCPE-144060
In 1.19.20, They increased the limit of geometry, so you can now have models slightly larger than the block, I think you can now extend to around an extra half a block so 24x24x24 more or less
Maximum size seems 30x30x30 in 1.19.20
Yes this has also happened to myself. its a unnecessary thing. its in their 1.19.30 changelog and its silly. Because mainly if you have more blocks. the game will lag. so having larger geos helps. though not working its rather bs
1.9.30 made it so not even the geo fix does anything to fix's it, if i could go back a update like java, i would. it also makes no sence since some blocks like the lectern is more than a 16x16x16 cube
Yeah, matters have got worse since the geofix no longer works, and now it's falsely blocking models that don't go outside the 3x3 block range. Honestly, instead of blocking the models, it should just give a warning, saying "you might experience visual artifacts".
PLEASE restore it to the original 3x3 block bounds, at the very least. If there's anything going out of bounds, print a warning that you may see artifacts, but allow them to work.
I pretty much haven't played Minecraft ever since this was broken. I have no reason to anymore, my worlds and mods that I have sunken hundreds, if not thousands of hours into are broken, and Mojang's silence on this is more than disappointing.
Please, just remove this arbitrary limitation. I know about, and can deal with the shading side effects. Print a warning in the log if need be, but don't forbid them. Or, fix the shading issues, like mentioned in: https://bugs.mojang.com/browse/MCPE-159848
I'm having a similar issue however in my case the custom block appearing invisible and has the particles from the Update block when broken.
This happened in 1.20.15
Seems to be resolved since 1.19.40 https://learn.microsoft.com/en-us/minecraft/creator/documents/customblockoversized
It has not. You are limited to 30 pixels, which isn't even 3x3 blocks (that's 48px). It used to be much, much larger than that, even.
it is not fixed in 1.20.40
Changes made in 1.20.40 seem to have exacerbated this problem and has reduced the amount of block scaling freedom to an even further degree. Mojang at this point seems to be actively looking for ways to limit mod creators and players from having fun. Oldest son quit the game when the initial changes were made and now my youngest son's world has been damaged by arbitrary block geometry ""fixes"" as well. Absurd how a game that encourages so much freedom can simultaneously deny any of it to people who want to use custom addons.
seriously, what is the point of making addons when your limited on what you can do, just remove the limit and make it so it warns you about lag.
Affects 1.21.2
Affects release 1.21.21 and 1.21.30.23 Preview