-
-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[NeoForge 1.21.1] BiomesOPlenty lag spikes with dynamic resources #504
Comments
This is.... literally the worst case scenario for dynamic model loading, and probably impossible to fix. That said, you've piqued my interest, so I'll leave this open and see if it's possible to optimize to be remotely playable. The primary issue is that since they render the models from a block entity renderer, the main client thread has to do all the model loading (whereas normally, chunk meshing is done on background threads, so loading models does not impact in-game FPS). Do these blocks generate naturally in the world? |
Yes, they generate frequently (in 4x4x4-ish shapes) in the End Corruption biome, which based on this world map export I have appears to replace the End Highlands (vanilla) biome with a probability of ~1/6 (and since the End Highlands biome is the one with all the chorus fruit...). |
I've made a PR to BoP to try and improve this; sounds like they want to go with your suggestion of limiting it to vanilla blocks, anyways, so that in combination with my change should solve the problem. Hopefully this will get backported. |
NeoForge version: 21.1.90
ModernFix version: 5.20.0
Biomes O' Plenty version: 21.1.0.7
Bug Description
To elaborate on the title, observing "Anomalies" in Biomes O' Plenty's End Corruption biome causes lag spikes when dynamic resources is on. This probably can't be reproduced without a bunch of furniture mods etc. installed though (for block model fodder).
Reproduction Steps
setblock
abiomesoplenty:anomaly[type=volatile]
The Cause
The reason for these lag spikes becomes somewhat obvious once one knows what these "anomalies" do. Indeed, they take the appearance of random blocks in the registry with the
type
determining how frequent this happens. Normally this isn't a huge problem(unless you're Immersive Engineering, apparently)but it quickly becomes catastrophic with dynamic resources since (I assume) it triggers the baking of possibly many models per tick.Potential Solutions
I've attempted to fix this myself by using the following mixin to limit the blocks in question to vanilla ones, and it seems to work pretty well:
Other solutions of course include 'freezing' the anomalies so they keep whatever block they started with (although this would not entirely solve the problem and it would make the anomalies less... anomalous), and/or just making it their problem.
The text was updated successfully, but these errors were encountered: