Client lighting values and rendering occasionally bug out.
Moleculor opened this issue ยท 20 comments
First noticed this in Forge, but replicated both in Forge and Fabric. Essentially, stuff like this happens occasionally:
Please note the Client light level as compared to the Server light level. Especially when walking in light in this video:
Despite standing in visibly lit areas, client light level is still listed as 0, as well as listed as 0 in the buggily-lit areas.
This is in a 'clean' instance with just Minecraft 1.16.4, Fabric API 0.28.4 (I was told by Minecraft Player on Discord to not use anything higher than this), Immersive Portals v0.60 for Fabric, and REI.
-- System Details --
Details:
Minecraft Version: 1.16.4
Minecraft Version ID: 1.16.4
Operating System: Windows 10 (amd64) version 10.0
Java Version: 14.0.2, AdoptOpenJDK
Java VM Version: OpenJDK 64-Bit Server VM (mixed mode, sharing), AdoptOpenJDK
Memory: 4741178608 bytes (4521 MB) / 6442450944 bytes (6144 MB) up to 6442450944 bytes (6144 MB)
CPUs: 8
JVM Flags: 10 total; -XX:HeapDumpPath=MojangTricksIntelDriversForPerformance_javaw.exe_minecraft.exe.heapdump -Xmx6144m -Xms6144m -XX:HeapDumpPath=MojangTricksIntelDriversForPerformance_javaw.exe_minecraft.exe.heapdump -XX:+UseG1GC -XX:+UnlockExperimentalVMOptions -XX:G1NewSizePercent=20 -XX:G1ReservePercent=20 -XX:MaxGCPauseMillis=50 -XX:G1HeapRegionSize=32M
Fabric Mods:
autoconfig1u: Auto Config v1 Updated 3.3.1
cloth-basic-math: Cloth Basic Math 0.5.1
cloth-client-events-v0: Cloth Client Events v0 1.4.5
cloth-config2: Cloth Config v4 4.8.3
fabric: Fabric API 0.28.4+1.16
fabric-api-base: Fabric API Base 0.2.0+ab87788d3a
fabric-biome-api-v1: Fabric Biome API (v1) 3.1.0+2e23b97c3a
fabric-blockrenderlayer-v1: Fabric BlockRenderLayer Registration (v1) 1.1.4+6a2618f53a
fabric-command-api-v1: Fabric Command API (v1) 1.0.9+6a2618f53a
fabric-commands-v0: Fabric Commands (v0) 0.2.0+6a2618f53a
fabric-containers-v0: Fabric Containers (v0) 0.1.9+a03e98793a
fabric-content-registries-v0: Fabric Content Registries (v0) 0.2.0+e77439c73a
fabric-crash-report-info-v1: Fabric Crash Report Info (v1) 0.1.2+b7f9825d3a
fabric-dimensions-v1: fabric-dimensions-v1 2.0.1+9a6c75813a
fabric-events-interaction-v0: Fabric Events Interaction (v0) 0.4.1+6a2618f53a
fabric-events-lifecycle-v0: Fabric Events Lifecycle (v0) 0.2.0+6a2618f53a
fabric-game-rule-api-v1: Fabric Game Rule API (v1) 1.0.3+a4467d2a3a
fabric-item-api-v1: Fabric Item API (v1) 1.2.0+6a2618f53a
fabric-item-groups-v0: Fabric Item Groups (v0) 0.2.1+6a2618f53a
fabric-key-binding-api-v1: Fabric Key Binding API (v1) 1.0.1+730711c63a
fabric-keybindings-v0: Fabric Key Bindings (v0) 0.2.0+6a2618f53a
fabric-lifecycle-events-v1: Fabric Lifecycle Events (v1) 1.2.0+ffb68a873a
fabric-loot-tables-v1: Fabric Loot Tables (v1) 1.0.1+6a2618f53a
fabric-mining-levels-v0: Fabric Mining Levels (v0) 0.1.2+6a2618f53a
fabric-models-v0: Fabric Models (v0) 0.1.1+6a2618f53a
fabric-networking-api-v1: Fabric Networking API (v1) 1.0.0+4358fbc63a
fabric-networking-blockentity-v0: Fabric Networking Block Entity (v0) 0.2.7+a03e98793a
fabric-networking-v0: Fabric Networking (v0) 0.3.1+2a4333d33a
fabric-object-builder-api-v1: Fabric Object Builder API (v1) 1.9.2+6a2618f53a
fabric-object-builders-v0: Fabric Object Builders (v0) 0.7.1+6a2618f53a
fabric-particles-v1: fabric-particles-v1 0.2.2+6a2618f53a
fabric-registry-sync-v0: Fabric Registry Sync (v0) 0.7.3+be155ae23a
fabric-renderer-api-v1: Fabric Renderer API (v1) 0.3.3+6a2618f53a
fabric-renderer-indigo: Fabric Renderer - Indigo 0.4.3+6a2618f53a
fabric-renderer-registries-v1: Fabric Renderer Registries (v1) 2.2.0+6a2618f53a
fabric-rendering-data-attachment-v1: Fabric Rendering Data Attachment (v1) 0.1.4+6a2618f53a
fabric-rendering-fluids-v1: Fabric Rendering Fluids (v1) 0.1.12+6a2618f53a
fabric-rendering-v0: Fabric Rendering (v0) 1.1.1+6a2618f53a
fabric-rendering-v1: Fabric Rendering (v1) 1.4.0+6a2618f53a
fabric-resource-loader-v0: Fabric Resource Loader (v0) 0.4.0+552549d53a
fabric-screen-handler-api-v1: Fabric Screen Handler API (v1) 1.1.0+6a2618f53a
fabric-structure-api-v1: Fabric Structure API (v1) 1.1.1+f1d8af063a
fabric-tag-extensions-v0: Fabric Tag Extensions (v0) 1.1.0+e77439c73a
fabric-textures-v0: Fabric Textures (v0) 1.0.5+6a2618f53a
fabric-tool-attribute-api-v1: Fabric Tool Attribute API (v1) 1.2.5+6a2618f53a
fabricloader: Fabric Loader 0.11.0
imm_ptl_core: Immersive Portals Core 0.60
immersive_portals: Immersive Portals 0.60
java: OpenJDK 64-Bit Server VM 14
minecraft: Minecraft 1.16.4
modmenu: Mod Menu 1.14.6+build.31
roughlyenoughitems: Roughly Enough Items 5.8.10
roughlyenoughitems-api: REI (API) 5.8.10
roughlyenoughitems-default-plugin: REI (Default Plugin) 5.8.10
roughlyenoughitems-runtime: REI (Runtime) 5.8.10
Launched Version: 1.16.4
Backend library: LWJGL version 3.2.2 build 10
Backend API: GeForce RTX 2070/PCIe/SSE2 GL version 4.6.0 NVIDIA 461.09, NVIDIA Corporation
GL Caps: Using framebuffer using OpenGL 3.0
Using VBOs: Yes
Is Modded: Definitely; Client brand changed to 'fabric'
Type: Client (map_client.txt)
Graphics mode: fancy
Resource Packs: Fabric Mods
Current Language: English (US)
CPU: 8x Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz
As near as I can tell (and this is probably no more than a vaguely educated guess), it seems to be tied to rapidly turning to face the portal before or as you're stepping through it.
During my many attempts at replication, I got the vague sense that this might only occur if the portal was near a northern chunk border, but that could be dumb luck.
I cannot reproduce this issue.
Try to use the command /immersive_portals_debug smooth_unload_disable and then can you reproduce this?
The command /immersive_portals_debug smooth_unload_disable was unknown, so I'm guessing you may have meant whatever command it was that I found that was similar to that. So I ran /immersive_portals_debug smooth_chunk_unload_disable. Hopefully that was the command you wanted me to run?
If you put a torch in the wrong light area, will the light around it become normal?
If it does not, it probably means that the client light data of that section is not enabled.
Do you get this issue in this version? https://github.com/qouteall/ImmersivePortalsMod/releases/tag/v0.61-1.16
If the issue still exists, try to place a torch in the wrong light area, will the light around it become normal?
As you can see, the light immediately around the torch becomes normal, both when placing the torch and breaking it, but other areas within the same chunk that are not increased by the torch's light remain broken.
And this is with the linked version 0.61.
immersive-portals-0.62-mc1.16.4-fabric.zip
Try to use this version to reproduce the issue and upload the log. You don't need to show video this time.
After reproducing the bug, disable the last server side configuration "increase loading range gradually" and check whether the bug manifests with that that config disabled
You can also use this to check https://github.com/qouteall/ImmersivePortalsModForForge/releases/tag/v0.13-1.16
In Fabric with 0.62, bug reproduced: latest - Lighting 0.62 Fabric.log
Changing graduallyIncreaseLoadingRange to false to test again.
After flipping that config, reproducing the bug resulted in the most stunning reproduction of the bug yet.
So I know you said I didn't need video, but this video has a bit of an interesting thing: Placing torches would sometimes repair the lighting for where it was placed, but not always. Included for demonstrative purposes. I skip the reproduction process and go mostly straight to the broken lighting. The first half is more interesting than the last.
Since you weren't getting anything useful in the Fabric log, I decided I'd try the Forge build you provided to see if that did anything different. The linked issue above shows the result of that attempt.
Recreation of the issue in Forge with IPv0.13.
I don't see anything useful, but maybe you will.
immersive-portals-0.64-mc1.16.4-fabric.zip
Here is a new version to test.
- Check can you reproduce the bug in that version
- If you still can reproduce, then quit to main menu, enter the world, use command
/immersive_portals_debug light_logging_enable - Reproduce again and upload the log.
After turning the chunk visibility update interval shorter, I can reproduce this issue now.
Probably fixed https://github.com/qouteall/ImmersivePortalsMod/releases/tag/v0.65-1.16
It's because that, if a chunk unloads the client light system will mark its section positions as to-be-removed, but it will actually be removed during the light update. However if the player is not in overworld and no portal to overworld is being rendered the overworld lighting will not be updated. When the overworld chunk get reloaded that sections' positions are still marked removed so the lighting data get wrongly removed. I made it to always update the light regardless of portal rendering.
I'm struggling to reproduce the bug in 0.65. I don't promise that means it's fixed, since it'd usually take me a few tries to reproduce it and maybe I'm just unlucky, but you might have killed the bug.