Hello, and sorry for the incredibly lengthy almost essay of a bug report in advanced. I want to provide as much information as I can. A TL:DR is provided at the bottom.

A couple of days ago I had noticed that I was getting stutters whenever a block would break. This would result in multiple blocks breaking as the client would still tell the server I was holding down mouse. I opened up that F3+Shift pie graph to figure out what was hurting my render times. While this graph isn't very useful by any means I was able to tell that root.gameRenderer.level.terrain_setup.rebuildNear.buildNear was taking up a large portion of my rendering time.

I reached out to the pack developers of "Engimatica 6 EP - 6" and they recommended I toggle the flag in forge-client.toml alwaysSetupTerrainOffThread to true. While this lessened the precieved stutters the issue still remained, and it really only felt like a band-aid fix to a larger issue. Later on they suggested I use Spark to narrow down the issue. After learning the basics of Spark I thought the issue was CodeChickenCore but the dev tried removing CCC and dependent mods and said the issue still persisted, though their PC is powerful to mitigate the perceived stutter entirely.

After chatting in their discord about the issue someone mentioned that lighting seemed to play a noticeable impact in the performance issues. This lead me to create a setup of redstone lamps and powering them all at once to really push the lag. After having a much bigger sample size I was able to conclude that com.simibubi.create.foundation.block.render.ColoredVertexModel.getQuads() is accounting for 49.51% of the time rendering these updates. Of 14108 ms spent rendering 6928 ms of it was spent on that single function.

I'm not certain this IS Create at fault to be honest. I think this processing delay is deeper than that. However I'm not familiar with the inner-workings of java, forge, minecraft. Spark doesn't let me get any deeper into the stacktrace then that method. So I'm reaching out to you all in hopes of finding the rendering lag.

TL;DR:
Spark is saying that com.simibubi.create.foundation.block.render.ColoredVertexModel.getQuads() is taking up about 50% of my FPS stutters. I believe that this potentially deeper issue but I don't have the knowledge to track it down any further.

Useful information:
https://spark.lucko.me/#hs84YQbYU0
EnigmaticaModpacks/Enigmatica6#998

This issue has been marked as stale because it has been inactive for 3 weeks. It will be closed if it remains inactive for another 3 weeks.

This issue has been closed since it has been inactive for 3 weeks since it was marked as stale.

When a block in the world changes, Minecraft queues up tasks that generate 16x16x16 block "chunks" around the block that changes. This is done for efficiency, so that the block models are not requested for quads every frame, especially considering that thousands of blocks can be seen at once. This is why the stutter only occurs when a block changes.

Unfortunately, these "chunk rebuilds", as they're called, can sometimes be very inefficient. Lag can sometimes even be seen in vanilla, and it is especially noticeable in the Alt+F3 screen. Chunk rebuilds are usually fine with vanilla models, though, but if a light source is placed or removed and many blocks have a new light level because of it, the chunk rebuild suddenly takes 2x or 3x more time to complete (I do not know the reason for this). This is also amplified by the fact that custom models, like the ColoredVertexModel or the CTModel (connected textures) must use world context, such as position or adjacent block states, to correctly calculate their quads. Vanilla models do not do this and always emit the same quads that do not need to be recalculated.

The obvious solution is caching. Mods such as the ConnectedTexturesMod do caching for their connected texture models so that all quads do not need to be recalculated and the previously calculated ones can be returned instead. However, while caching could be a solution for Create's connected texture model, it will not work for the colored vertex model without changing its behavior. This is because the colored vertex model uses the unique block position to generate custom colors for each quad vertex. The colors are calculated from the position and are almost always unique, so a cache would not be very effective here as it would have to store new quads for every position, not to mention that storing such a quantity of quads would significantly increase memory usage.

To be fair, I have not thought of a solution to this problem for very long, but I am not aware of one currently. Looking at the code again though, I see that it may be possible to make some improvements. I don't know how big of an impact these changes will make or if they will break something else. It is also possible that there are performance mods out there that improve the efficiency of chunk rebuilds, but I am not aware of any.

In conclusion, I do not know of a solution to this exact problem right now. Other team members or someone else might, so I will try to ask around. If anyone reading this has ideas or notices incorrect information, also feel free to let me know.

I was wondering if anything was uncovered about this?

I know that 1.17 introduced some optimizations to pistons updating the world, it might have some insight. However, I'm not exactly code literate, so I unfortunately can't offer much advice. If you need someone to test stuff though, I'm happy to help. Thank you for the explanation!