27 replies

Animation State Bleeding with GeckoLib Entities in FeatureRenderer

Hey peeps,

my mod renders animated shoulder hamsters using GeckoLib. The shoulder hamsters work just fine in vanilla. The implementation uses a

FeatureRenderer

FeatureRenderer

on the player model, which in turn renders several client-side "dummy"

GeoEntity

GeoEntity

instances—one for each shoulder/head slot. Each dummy entity has its own

AnimationController

AnimationController

with a unique name based on its instance ID.

The Issue: With Iris enabled, all shoulder pet dummies appear to share the same animation state, (but I think it's purely visual; watch the end of the video for a note on this) moving in perfect sync. Furthermore, their animations are hijacked by any in-world entity of the same type that is also being rendered. This animation bleeding does not occur without Iris.

My guess is that Iris's batched entity rendering is causing GeckoLib to reuse animation data across these dummy instances, despite their unique controller names.

Video: Here is a screen recording demonstrating the issue (vanilla vs. Iris comparison)

Does anyone know what could be causing this?

I'm happy to provide a minimal reproducible example .zip if needed. Thanks in advance!

These attached files provide a complete picture of the rendering and state management pipeline for the shoulder pets.

HamsterShoulderFeatureRenderer.java

HamsterShoulderFeatureRenderer.java

: The core class that manages the dummy entities and initiates their rendering. This is the most important file.
2.

ClientShoulderHamsterData.java

ClientShoulderHamsterData.java

: Shows how the animation state for each shoulder pet is managed and ticked independently on the client thread.
3.

ShoulderHamsterState.java

ShoulderHamsterState.java

: The state machine class that determines which animation should be playing for a single shoulder pet.
4.

HamsterEntity.java

HamsterEntity.java

: Specifically the

registerControllers

registerControllers

method, so they can see how the GeckoLib animation controller is set up.
5.

ShoulderHamsterRenderer.java

ShoulderHamsterRenderer.java

: The specialized

GeoEntityRenderer

GeoEntityRenderer

used for the dummy entities.

ClientShoulderHamsterData.java3.29KB

ShoulderHamsterState.java4.98KB

ShoulderHamsterRenderer.java2.07KB

HamsterShoulderFeatureRenderer.java9.7KB

HamsterEntity.java177.46KB

YouTubeAdorable Hamster Pets

iris shaders visual glitch

Adorable Hamster Pets - 70+ Variants, Shoulder Launching, Diamond Sniffing, Cheek Pouch Inventories, Unique Personalities, 30+ Animations, and much more! https://youtu.be/2KuEjC1ZkwE

Download here:
https://modrinth.com/mod/adorable-hamster-pets
https://www.curseforge.com/minecraft/mc-mods/adorable-hamster-pets

Join "The Cheek Pouch" Discord h...

Solution

SOLVED!

Ok so I knew the key clue was that the animations appeared correct on the pause screen. This confirmed that my underlying animation data and state machines were working perfectly, so the problem had to be purely a render-time issue.

The problem was specifically within GeckoLib's

AnimatableManager

AnimatableManager

. My guess is that when Iris's batch rendering processes multiple

GeoEntity

GeoEntity

instances in the same frame, the manager for the first entity would get its

lastUpdateTime

lastUpdateTime

set. When the renderer immediately moved to the next entity in the batch, the time delta since the last update was near-zero, causing GeckoLib to (correctly, from its perspective) skip the animation tick for that entity. This resulted in it being rendered with the stale bone data from the previously rendered entity.

The fix was to manually force GeckoLib's

AnimatableManager

AnimatableManager

to re-evaluate its state for each dummy entity right before its render call. By setting its

lastUpdateTime

lastUpdateTime

, I trick the manager into thinking a very long time has passed, guaranteeing it runs a full animation update and ignores any polluted state from other entities in the batch.

Jump to solution

TIP

The Iris Project•6mo ago•

27 replies

The Scarlet Fox

Animation State Bleeding with GeckoLib Entities in FeatureRenderer

Hey peeps,

my mod renders animated shoulder hamsters using GeckoLib. The shoulder hamsters work just fine in vanilla. The implementation uses a

FeatureRenderer

FeatureRenderer

on the player model, which in turn renders several client-side "dummy"

GeoEntity

GeoEntity

instances—one for each shoulder/head slot. Each dummy entity has its own

AnimationController

AnimationController

These attached files provide a complete picture of the rendering and state management pipeline for the shoulder pets.

HamsterShoulderFeatureRenderer.java

HamsterShoulderFeatureRenderer.java

: The core class that manages the dummy entities and initiates their rendering. This is the most important file.
2.

ClientShoulderHamsterData.java

ClientShoulderHamsterData.java

: Shows how the animation state for each shoulder pet is managed and ticked independently on the client thread.
3.

ShoulderHamsterState.java

ShoulderHamsterState.java

: The state machine class that determines which animation should be playing for a single shoulder pet.
4.

HamsterEntity.java

HamsterEntity.java

: Specifically the

registerControllers

registerControllers

method, so they can see how the GeckoLib animation controller is set up.
5.

ShoulderHamsterRenderer.java

ShoulderHamsterRenderer.java

: The specialized

GeoEntityRenderer

GeoEntityRenderer

used for the dummy entities.

ClientShoulderHamsterData.java3.29KB

ShoulderHamsterState.java4.98KB

ShoulderHamsterRenderer.java2.07KB

HamsterShoulderFeatureRenderer.java9.7KB

HamsterEntity.java177.46KB

YouTubeAdorable Hamster Pets

iris shaders visual glitch

Solution

SOLVED!

AnimatableManager

AnimatableManager

. My guess is that when Iris's batch rendering processes multiple

GeoEntity

GeoEntity

instances in the same frame, the manager for the first entity would get its

lastUpdateTime

lastUpdateTime

AnimatableManager

AnimatableManager

to re-evaluate its state for each dummy entity right before its render call. By setting its

lastUpdateTime

lastUpdateTime

, I trick the manager into thinking a very long time has passed, guaranteeing it runs a full animation update and ignores any polluted state from other entities in the batch.

Jump to solution

Animation State Bleeding with GeckoLib Entities in FeatureRenderer

These attached files provide a complete picture of the rendering and state management pipeline for the shoulder pets.

SOLVED!

Animation State Bleeding with GeckoLib Entities in FeatureRenderer

These attached files provide a complete picture of the rendering and state management pipeline for the shoulder pets.

SOLVED!

Similar Threads

Similar Threads

Similar Threads