Sodium conflict with Fastpaintings
tydn12 opened this issue ยท 9 comments
Bug Description
Fastpaintings painting doesn't render fully when using sodium.
Reproduction Steps
place 4x4 painting on a wall, where y level is a multiple of 16. Eg. y=144,y=160 (in my testing).
Log File
Crash Report
Fastpaintings seems to convert paintings into some other form, which seems to conflict with how sodium renders things. It would be important to understand exactly what its doing to debug this, but my hunch is that either its generating blocks models that are larger than allowed. Block models in Minecraft are only allowed to be at most 3x3 blocks large, which a 4x4 painting would exceed.
There's a corresponding issue on the fastpaintings repo. This has been an issue since December 2023, but I don't know whether it worked at some point in the mean time. Apparently at some point embeddium fixed this issue, I don't know what they do to get around it, or if it's also broken again.
Reading some of our discord messages indicates that they do in fact simply generate a very large block model (16x16x1 in fact), which is illegal and only works on vanilla by chance. I'll wait for JellySquid to say something on the matter, but the implementation may simply be flawed and require changes to comply with the model extent constraints. A compatible solution would be to split the model into 3x3 (or 1x1) sized pieces, which is fairly easy to do by fiddling with the UVs and how the model pieces are generated.
The mod simply turns them into blocks. The models are not bigger than allowed at all. Each is 1 block wide at most
Sodium only copies world data up to +/- 2 blocks away from the chunk (a total volume of 20x20x20.) This may be causing the issue if the renderer for a block on the edge of a chunk is trying to access data that is too far away.
Probably it would be sufficient to validate this theory by increasing the constants named here but it will have some performance impact.
if the blocks were actually in the chunks they visually reside in this would not be an issue. Are the block models generated with large offsets to generate them from the chunk the painting is in?
That must be what is happening because the render data they use comes from a master block entity that holds the data
Each block model is self contained in its own block space. There's no offset in the models
There was a draft patch set to increase the size of the sliced area to be as large as possible, but it was found that copying so much more data was >10x slower. Since that overhead is on the main render thread's critical path it was determined to be too expensive.
Maybe we could increase this to +/- 4 blocks to help deal with cases like this, but it won't be sufficient to solve problems with mods like BetterEnd.