1.20.1 Shader Crashing
Tsunai001 opened this issue ยท 7 comments
When creating a fresh installation with only iris, sodium, brute force rendering culling on Fabric 1.20.1, with the latest 0.5.8 patch, it runs flawlessly adding an extra 50-200 frames with default settings, but as soon as shaders are toggled, it crashes immediately. Logs say its because of Iris and BFRC as suspected but this is confusing as you said they were compatible. This crashes even in areas with low entity counts so i suspect purely a rendering issue with culling and shaders trying to render a transparent model or summin idk. I also tried 3 older versions, 2 of them dropped my frames to 40-20 (had 500 before), while the other crashed the same and while opening the config. FYI, it crashes both server and singleplayer. Would you be able to look into this please?
Oh, it seems that this is not compatible with the latest version of Iris. Firstly, thank you for your feedback. I didn't realize that Iris was updated last week. My development project and formal environment testing are both using version 1.6.17 of Iris, and there have been some interface changes in version 1.7.0, leading to crashes. I will address this later.
Oh, it seems that this is not compatible with the latest version of Iris. Firstly, thank you for your feedback. I didn't realize that Iris was updated last week. My development project and formal environment testing are both using version 1.6.17 of Iris, and there have been some interface changes in version 1.7.0, leading to crashes. I will address this later.
Ok thank you, Ill downgrade to 1.6.17 and get back to you :)
Oh, it seems that this is not compatible with the latest version of Iris. Firstly, thank you for your feedback. I didn't realize that Iris was updated last week. My development project and formal environment testing are both using version 1.6.17 of Iris, and there have been some interface changes in version 1.7.0, leading to crashes. I will address this later.
Ok thank you, Ill downgrade to 1.6.17 and get back to you :)
Yep Works perfectly now, I play on a server with tones of custom entities, Thank you heaps. Also I had a question, does this mod cull vertical chunks for example caves being rendered when not in sight? and how does this work for mob farms that are not directly visible nor in same chunk?
Oh, it seems that this is not compatible with the latest version of Iris. Firstly, thank you for your feedback. I didn't realize that Iris was updated last week. My development project and formal environment testing are both using version 1.6.17 of Iris, and there have been some interface changes in version 1.7.0, leading to crashes. I will address this later.
Ok thank you, Ill downgrade to 1.6.17 and get back to you :)
Yep Works perfectly now, I play on a server with tones of custom entities, Thank you heaps. Also I had a question, does this mod cull vertical chunks for example caves being rendered when not in sight? and how does this work for mob farms that are not directly visible nor in same chunk?
In Minecraft, Render Chunk is vertically partitioned, with a granularity smaller than logical Chunk calculations, at a size of 16x16x16. This means that rendering chunks can perform vertical occlusion culling.
In the vanilla Minecraft chunk rendering, Mojang only performs culling calculations based on the Frustum, meaning all chunks within the view will be rendered, even if fully occluded.
However, Sodium performs visibility checks for chunk occlusion. While I haven't fully interpreted Sodium's culling process, I roughly judge it to be similar to portal culling calculations. It treats chunks surrounded entirely by solid blocks as walls, i.e., boundaries, while chunks surrounded by non-full blocks are considered windows with connectivity. Starting from the camera position, only chunks with connectivity are included in the search loop, while "wall" chunks are considered occluders and not subjected to further computation. This method is efficient enough and already capable of culling disconnected caves.
The depth buffer culling I use leverages the rendering features of the GPU. When rendering objects, the GPU calculates a depth buffer value, also known as the Z-buffer. This Z value represents the distance of each vertex of the object model from the camera. The Z-buffer is a tool used by rendering APIs to determine occlusion. If two objects occlude each other, the pixels rendered on the screen will belong to the nearest object to the camera.
Using the Z-buffer for chunk culling is similar to how rendering APIs perform occlusion culling. I consider the ground, terrain, and walls closest to the player as occluders, making this occlusion check more "visual." If you are inside a building, chunks occluded by building walls will not be rendered. In other words, Z-buffer culling is capable of culling other areas in the building or underground caves. If your building area contains many mechanical or magical blocks (entity blocks), simply blocking them with walls can prevent these objects from being added to the rendering queue.
Oh, it seems that this is not compatible with the latest version of Iris. Firstly, thank you for your feedback. I didn't realize that Iris was updated last week. My development project and formal environment testing are both using version 1.6.17 of Iris, and there have been some interface changes in version 1.7.0, leading to crashes. I will address this later.
Ok thank you, Ill downgrade to 1.6.17 and get back to you :)
Yep Works perfectly now, I play on a server with tones of custom entities, Thank you heaps. Also I had a question, does this mod cull vertical chunks for example caves being rendered when not in sight? and how does this work for mob farms that are not directly visible nor in same chunk?
In Minecraft, Render Chunk is vertically partitioned, with a granularity smaller than logical Chunk calculations, at a size of 16x16x16. This means that rendering chunks can perform vertical occlusion culling.
In the vanilla Minecraft chunk rendering, Mojang only performs culling calculations based on the Frustum, meaning all chunks within the view will be rendered, even if fully occluded.
However, Sodium performs visibility checks for chunk occlusion. While I haven't fully interpreted Sodium's culling process, I roughly judge it to be similar to portal culling calculations. It treats chunks surrounded entirely by solid blocks as walls, i.e., boundaries, while chunks surrounded by non-full blocks are considered windows with connectivity. Starting from the camera position, only chunks with connectivity are included in the search loop, while "wall" chunks are considered occluders and not subjected to further computation. This method is efficient enough and already capable of culling disconnected caves.
The depth buffer culling I use leverages the rendering features of the GPU. When rendering objects, the GPU calculates a depth buffer value, also known as the Z-buffer. This Z value represents the distance of each vertex of the object model from the camera. The Z-buffer is a tool used by rendering APIs to determine occlusion. If two objects occlude each other, the pixels rendered on the screen will belong to the nearest object to the camera.
Using the Z-buffer for chunk culling is similar to how rendering APIs perform occlusion culling. I consider the ground, terrain, and walls closest to the player as occluders, making this occlusion check more "visual." If you are inside a building, chunks occluded by building walls will not be rendered. In other words, Z-buffer culling is capable of culling other areas in the building or underground caves. If your building area contains many mechanical or magical blocks (entity blocks), simply blocking them with walls can prevent these objects from being added to the rendering queue.
thank you for taking the time to explain, im glad it culls caves aswell, i try to directly cull specific lush cave particles like spores, dust, and glow squid emission etc. Ive found that when using freecam (spectator) i fear that the amount of caves visible are still being rendered, oc theres no way to visibly check but i do seem to see performance boosts and am grateful
Oh, it seems that this is not compatible with the latest version of Iris. Firstly, thank you for your feedback. I didn't realize that Iris was updated last week. My development project and formal environment testing are both using version 1.6.17 of Iris, and there have been some interface changes in version 1.7.0, leading to crashes. I will address this later.
Ok thank you, Ill downgrade to 1.6.17 and get back to you :)
Yep Works perfectly now, I play on a server with tones of custom entities, Thank you heaps. Also I had a question, does this mod cull vertical chunks for example caves being rendered when not in sight? and how does this work for mob farms that are not directly visible nor in same chunk?
In Minecraft, Render Chunk is vertically partitioned, with a granularity smaller than logical Chunk calculations, at a size of 16x16x16. This means that rendering chunks can perform vertical occlusion culling.
In the vanilla Minecraft chunk rendering, Mojang only performs culling calculations based on the Frustum, meaning all chunks within the view will be rendered, even if fully occluded.
However, Sodium performs visibility checks for chunk occlusion. While I haven't fully interpreted Sodium's culling process, I roughly judge it to be similar to portal culling calculations. It treats chunks surrounded entirely by solid blocks as walls, i.e., boundaries, while chunks surrounded by non-full blocks are considered windows with connectivity. Starting from the camera position, only chunks with connectivity are included in the search loop, while "wall" chunks are considered occluders and not subjected to further computation. This method is efficient enough and already capable of culling disconnected caves.
The depth buffer culling I use leverages the rendering features of the GPU. When rendering objects, the GPU calculates a depth buffer value, also known as the Z-buffer. This Z value represents the distance of each vertex of the object model from the camera. The Z-buffer is a tool used by rendering APIs to determine occlusion. If two objects occlude each other, the pixels rendered on the screen will belong to the nearest object to the camera.
Using the Z-buffer for chunk culling is similar to how rendering APIs perform occlusion culling. I consider the ground, terrain, and walls closest to the player as occluders, making this occlusion check more "visual." If you are inside a building, chunks occluded by building walls will not be rendered. In other words, Z-buffer culling is capable of culling other areas in the building or underground caves. If your building area contains many mechanical or magical blocks (entity blocks), simply blocking them with walls can prevent these objects from being added to the rendering queue.thank you for taking the time to explain, im glad it culls caves aswell, i try to directly cull specific lush cave particles like spores, dust, and glow squid emission etc. Ive found that when using freecam (spectator) i fear that the amount of caves visible are still being rendered, oc theres no way to visibly check but i do seem to see performance boosts and am grateful
Just now I took a few screenshots using the development environment, you can refer to the culling effect. To prevent issues with chunk culling, I've applied a certain offset to the distance calculation for chunks. Therefore, even if nearby chunks are occluded, they won't be culled. However, entity blocks can still be culled normally.