MariesWiki
MariesLib · Enhancement

3D Spinning Icon Animations

Planned 0/6 tasks Updated 6 Oct 2026 2 min read

Idea from generifying Thermal Systems' Hub Home page (player-preview-box + info sections) into dev.marie.framework.ui.hub.EntityPreviewBox/ HubInfoPage: give item icons real 3D presence — a spinning render — instead of the flat 2D blit RenderContext#drawItem draws today. First call site in mind is Nourished's Diet Screen icons and the new nutrient "pod", with different animation styles rather than one fixed spin.

Why this lives here, not just in Nourished

RenderContext's contract deliberately keeps GuiGraphics/PoseStack out (see its class Javadoc) so it stays engine-agnostic. A real 3D spin needs PoseStack rotation, which only exists behind a concrete implementation — the same instanceof GuiGraphicsRenderContext gate EntityPreviewBox already uses for its own entity rendering. That's MariesLib's job (the HOW), the same way EntityPreviewBox ended up here instead of staying bespoke in Thermal Systems. Nourished would just call it with its own icons/styles (the WHAT).

Proposed shape (rough sketch, not final)

  • A standalone helper alongside EntityPreviewBox, e.g. dev.marie.framework.ui.hub.SpinningItemIcon (naming TBD) — given a RenderContext, bounds, an ItemStack, and animation parameters, the same calling shape as EntityPreviewBox.render(...).

  • "Different animations" needs a taxonomy before this is buildable, not just one fixed spin:

    • Rotation style — constant spin vs. idle wobble vs. spin-on-update/trigger
    • Speed/axis — per icon, per nutrient, or per mod-defined style
    • Trigger model — always-on continuous spin vs. a brief spin fired by a state change (e.g. a nutrient pod spinning when its value updates)
  • Needs per-icon animation state (current rotation angle, last-update timestamp) across frames — can't be purely stateless like drawItem. Options:

    • A small object the consuming screen owns and feeds a delta-time into
    • A tiny registry keyed by icon id inside the helper itself

    Which one fits better should come from the actual Diet Screen/nutrient pod call sites once they're sketched, not be guessed in the abstract.

Why not now

This is a materially different beast than the Home page/info-section extraction (a static layout move) — it needs real animation/timing design (frame-rate-independent rotation speed, per-context style selection) before it's a MarieLib candidate, not a copy-paste-and-parameterize job. Scope it as its own design pass once the Home page work settles, not bolted onto that extraction.

Acceptance criteria

  • Animation taxonomy decided (styles, triggers, per-icon/nutrient/mod configuration)
  • Rendering primitive exists in MariesLib (marie-editor or marie-ui, TBD) using PoseStack rotation behind the same instanceof GuiGraphicsRenderContext gate as EntityPreviewBox
  • Frame-rate independent (ties rotation to elapsed time, not frame count)
  • Nourished's Diet Screen icons use it
  • Nourished's nutrient pod icons use it
  • No regression to existing flat-icon rendering for any icon that doesn't opt into an animation style

More MariesLib enhancements