[Bug] Seemingly forces Fancy rendering vs Fabulous

[Soaryn]

Version Info

• Minecraft, 1.20.4
• Moving Elevators, movingelevators-1.4.6-neoforge-mc1.20.4

Are you using OptiFine?: Not at all.

Description of the Bug Basically it seems like fabulous (more specifically additive blending) gets completely nuked and result in the same visual results as fancy rendering.

Steps to Reproduce Load up world with the mod installed.

Screenshots Unfortunately I don't have a public build of XyCraft available for you to toy with. Maybe in a week or so? The images below were both taken in Fabulous, though the first image WOULD be the result if rendering in Fancy.

The first is with elevators installed and XyCraft The second is without elevators.

[Rushmead]

A quick investigation makes it seem like the bufferSource.getBuffer call here is causing the issue when renderType is RenderType.translucent() https://github.com/SuperMartijn642/MovingElevators/blob/52b6337e6d81ff838c9b3ad88738f0f95169fb45/src/main/java/com/supermartijn642/movingelevators/elevator/ElevatorGroupRenderer.java#L51-L57

I don't understand the render pipeline enough to know why this is the case nor how to properly fix it however a band-aid would be to return early if the renderType is RenderType.translucent(). I tried this in a local version with both mods and it seemed to fix the issue and I was unable to find any blocks that this broke. I suggest there is probably a better solution, but I don't know what it is!

[SuperMartijn642]

Hmm rather odd. As far as I know, the only thing requesting the buffer for a render type would do is draw the last undrawn buffer. Basically if the last requested buffer is for a render type which doesn't have a dedicated buffer, requesting a buffer for a different render type will draw the last buffer if it wasn't drawn yet.

... a band-aid would be to return early if the renderType is RenderType.translucent().

That code submits the quads for blocks in moving elevators whenever the chunk geometry for a certain render type is submitted. Returning early for the translucent render type would prevent blocks such as stained glass from being rendered when the elevator is moving.

I could probably make it so MultiBufferSource#getBuffer is only called within the inner loop, so at least it is only requested when there's an elevator that actually needs to be rendered. (Probably how I should have done it to begin with, but oh well) Apart from that, I don't really have an idea why it would cause the effect shown above.

I am quite busy with school currently and haven't been able to work on mods for a while, so it will likely be a while before I can make any changes or look into it properly 😅

[embeddedt]

Educated guess: if your elevator renderer ends up indirectly calling clearRenderState on RenderType.translucent(), it will likely cause this bug in Fabulous mode. There was a similar issue with XyCraft & Embeddium caused by setupRenderState not being called before firing the RenderLevelStageEvent, fixed here: https://github.com/embeddedt/embeddium/commit/9bd08c4d30e33917720b792422bbc917c28a10b1

[SuperMartijn642]

I've now changed it so MultiBufferSource#getBuffer is only called when there's an elevator that actually needs to be rendered, thus at least the problem should only appear whenever there's a moving elevator nearby and not just whenever the mod is installed.

Educated guess: if your elevator renderer ends up indirectly calling clearRenderState on RenderType.translucent(), it will likely cause this bug in Fabulous mode.

Putting a breakpoint in clearRenderState, it seems it is not called in the code from Moving Elevators when handling the translucent render type, so likely something else going on. Moving Elevators only requests a buffer for the render type and submits vertices to it, but never ends/draws the buffer.

I don't really have a way to test/debug the issue, so I will likely wait for a release of XyCraft to properly fix the issue.

[embeddedt]

Another thing we found recently while debugging laggy rendering from another mod (Modern Industrialization) is that apparently MultiBufferSource should be used with the render types from Sheets (e.g. Sheets.cutoutBlockSheet(), Sheets.solidBlockSheet()), not the regular chunk render types like RenderType.cutout(). There should be a method in vanilla that converts between them that's used when rendering block items (check ItemBlockRenderTypes). Not doing this causes batching to not function properly for block rendering in that MultiBufferSource. Not sure if that's something you already handle or not.

[SuperMartijn642]

Ah did not know that, I always thought it had dedicated buffers for the chunk render types, but indeed it seems it actually has dedicated buffers for the render types in Sheets. Probably something I will need to update in most of my mods then 😓