When a render type other than RenderLayer#LINES (and that does not have a fixed buffer) is used to render something in the WorldRenderEvents#BLOCK_OUTLINE event, this causes a crash.
To replicate the crash, simply add the following subsciber to the event:
WorldRenderEvents.BLOCK_OUTLINE.register((worldRenderContext, blockOutlineContext) -> {
worldRenderContext.consumers().getBuffer(RenderLayer.getEndPortal());
return true;
});
Here is a log of such a crash (although with mojmaps): https://gist.github.com/SuperMartijn642/2a6ba4977d6c172b01f2137d4f8dec30
The current flow for the WorldRenderEvents#BLOCK_OUTLINE is as follows:
WorldRenderer#render requests a buffer for RenderLayer#LINES.
WorldRenderer#render calls WorldRenderer#drawBlockOutline with the requested buffer.
- Fabric's
WorldRendererMixin#onDrawBlockOutline mixin fires the WorldRenderEvents#BLOCK_OUTLINE.
- Fabric's
WorldRendererMixin#onDrawBlockOutline mixin requests a buffer for RenderLayer#LINES.
WorldRenderer#drawBlockOutline renders the block's outline with the buffer passed to it.
If a mod requests a buffer for a render type other than RenderLayer#LINES during the WorldRenderEvents#BLOCK_OUTLINE event, that causes the original buffer for RenderLayer#LINES to be ended. If simply left as is, this would cause a crash in step 5 when vertices are submitted to the original buffer.
To combat this, step 4 requests a buffer for RenderLayer#LINES again.
In 1.20.6, VertexConsumerProvider#Immediate simply held one buffer object which gets reset whenever the requested render type is different from the last. Hence, the buffer requested in step 1 would be reset by step 4.
In 1.21, VertexConsumerProvider#Immediate now creates a new BufferBuilder instance every time the requested render type is different from the last. Hence, the buffer requested in step 1 is never reset, rather step 4 causes a new BufferBuilder to be created. As step 5 still uses the buffer object requested in step 1, this leads to a crash.
The WorldRendererMixin#onDrawBlockOutline mixin for context:
https://github.com/FabricMC/fabric/blob/e43d74f64b242dfb86920343808cc6616bfb1441/fabric-rendering-v1/src/client/java/net/fabricmc/fabric/mixin/client/rendering/WorldRendererMixin.java#L114-L131
When a render type other than
RenderLayer#LINES(and that does not have a fixed buffer) is used to render something in theWorldRenderEvents#BLOCK_OUTLINEevent, this causes a crash.To replicate the crash, simply add the following subsciber to the event:
Here is a log of such a crash (although with mojmaps): https://gist.github.com/SuperMartijn642/2a6ba4977d6c172b01f2137d4f8dec30
The current flow for the
WorldRenderEvents#BLOCK_OUTLINEis as follows:WorldRenderer#renderrequests a buffer forRenderLayer#LINES.WorldRenderer#rendercallsWorldRenderer#drawBlockOutlinewith the requested buffer.WorldRendererMixin#onDrawBlockOutlinemixin fires theWorldRenderEvents#BLOCK_OUTLINE.WorldRendererMixin#onDrawBlockOutlinemixin requests a buffer forRenderLayer#LINES.WorldRenderer#drawBlockOutlinerenders the block's outline with the buffer passed to it.If a mod requests a buffer for a render type other than
RenderLayer#LINESduring theWorldRenderEvents#BLOCK_OUTLINEevent, that causes the original buffer forRenderLayer#LINESto be ended. If simply left as is, this would cause a crash in step 5 when vertices are submitted to the original buffer.To combat this, step 4 requests a buffer for
RenderLayer#LINESagain.In 1.20.6,
VertexConsumerProvider#Immediatesimply held one buffer object which gets reset whenever the requested render type is different from the last. Hence, the buffer requested in step 1 would be reset by step 4.In 1.21,
VertexConsumerProvider#Immediatenow creates a newBufferBuilderinstance every time the requested render type is different from the last. Hence, the buffer requested in step 1 is never reset, rather step 4 causes a newBufferBuilderto be created. As step 5 still uses the buffer object requested in step 1, this leads to a crash.The
WorldRendererMixin#onDrawBlockOutlinemixin for context:https://github.com/FabricMC/fabric/blob/e43d74f64b242dfb86920343808cc6616bfb1441/fabric-rendering-v1/src/client/java/net/fabricmc/fabric/mixin/client/rendering/WorldRendererMixin.java#L114-L131