Skip to content
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

Open
EnderTurret opened this issue Jan 1, 2025 · 3 comments
Open

Comments

@EnderTurret
Copy link

EnderTurret commented Jan 1, 2025

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

  1. Install ModernFix and Biomes O' Plenty
  2. Install a bunch of furniture mods, or your choice of any mod with a large number of blocks w/ custom models
  3. Turn dynamic resources on
  4. Enter a world and setblock a biomesoplenty:anomaly[type=volatile]
  5. Experience lag spikes

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:

@Mixin(AnomalyBlockEntity.class)
public abstract class MixinAnomalyBlockEntity {

	@ModifyReceiver(
			at = @At(value = "INVOKE", target = "Ljava/util/stream/Stream;map(Ljava/util/function/Function;)Ljava/util/stream/Stream;"),
			method = "*", // We're targeting a lambda in <init>
			require = 1)
	private Stream<Map.Entry<ResourceKey<Block>, Block>> limitToVanilla(Stream<Map.Entry<ResourceKey<Block>, Block>> original, Function<?, ?> mapper) {
		return original.filter(entry -> "minecraft".equals(entry.getKey().location().getNamespace()));
	}
}

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.

@embeddedt
Copy link
Owner

embeddedt commented Jan 2, 2025

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?

@EnderTurret
Copy link
Author

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...).

@embeddedt
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants