Kirino Engine (WIP)

Minecraft rendering becomes difficult as implicit state and mixins couple rendering behavior. Our primary goal is to provide an explicit structure, overhaul most of Minecraft’s rendering in a future-proof manner, and provide a set of advanced rendering APIs to mod developers.

In terms of the fundamental changes we'd like to introduce:

• Introduce a set of engine infrastructure on top of Minecraft

  • Enable less mixin work through explicit lifecycles and entrypoint
  • Provide reusable services such as ECS, GL abstraction layer

• Replace direct GL draw calls by abstracted render commands and defer the rendering process

  • No more concerns about the manual GL state management inside TESR/Entity/Item classes
  • No more unbatched and unoptimized draw calls
  • Deferred command execution allows post render modification without mixins

• Modernize Minecraft rendering in general

  • Introduce immutable pipeline to hide GL state mutability
  • Introduce RenderPass/Subpass composition
  • Introduce explicit resource lifetime to prevent hidden synchronization

• Implement a terrain rendering rewrite with meshlets

  • Normal-based meshlet clustering creates foundation for better lighting, finer culling, GPU acceleration, and future visibility buffer techniques

Looking further ahead, we'd like to pay more attention to lifecycles, phases, and systems, rather than features, compatibility with legacy solutions, or similar concerns.

The project is highly WIP - contributions are welcome to help accelerate development!

Want a deeper look right away? Jump to "How Everything Works?"

Non-Goals

• Not a drop-in performance patch
• Not a strict compatibility target
• Not an object-centric rendering engine
• Not a finalized or frozen architecture
• Not a high-fidelity path tracing solution

Jump to "FAQs" for more details

Contributing

If you would like to contribute, please take a look at our Contributing Page and the Engine Overview to understand the project’s assumptions and architectural direction.

To keep discussions productive, please read the guidelines below.

Click to Expand

Clarification

Before proposing changes or opening discussions, please:

• Treat/Assume the current design choices as intentional and valid start points (that is, reason within the given assumption space)
• Base your reasoning on the assumptions implied by the existing docs
• Focus on internal consistency, trade-offs, and constructive outcomes

What a Good Proposal Looks Like

Good example:

1. Assume the staging buffer and resource management designs are valid and their stated (or implied) design principles are satisfied
2. Demonstrate how the staging buffer design creates tension within the resource management principles
3. Conclude that the staging buffer design may need some fix

This kind of proposal helps identify real issues while respecting the project’s intent.

What to Avoid

Less helpful examples:

• “Why ECS? Why GPU-driven? Why XXX?”
• “ECS isn’t useful; OOP might be faster based on my past tuning experience”

These questions re-open foundational decisions without engaging with the project’s assumption space.

If you believe core assumptions lead to issues, please demonstrate how it contradicts itself in this specific context.

Main Idea

Please don’t feel discouraged if your reasoning isn’t formal. This project values thoughtful discussion. If an idea is proposed in good faith, incomplete and informal reasoning is still welcome.

How Everything Works?

See the docs/ directory for a high-level overview of Kirino-Engine, where you can understand our implicit assumptions and build the mental model gradually.

Roadmap & Todos

View Project Board to track development progress, features and ideas.

FAQs

Click to Expand

• Why is Kirino-Engine different compared to OptiFine / Sodium / Iris?
  • Because Kirino-Engine wants to bring actual architectural level changes, and pays less attention to optimization and shaders

• Will Kirino-Engine be compatible with OptiFine / Sodium / Iris?
  • No, because Kirino-Engine replaces the whole rendering pipeline
  • But, Kirino-Engine isn't tightly coupled with rendering. A toggle is provided to disable the rendering part of the engine

• What can I expect as a player when it's out?
  • Performance wise: potentially smoother performance and FPS improvements
  • Shader wise: modern lighting techniques and better global illumination
  • Configurability: optional HDR, optional resolution up-scaling or down-scaling, optional post-processing, etc.
  • Ecosystem: easily extensible rendering pipeline for community mods and shaders

• What can I expect as a mod developer when it's out?
  • Clean rendering APIs that hide OpenGL completely
  • Versatile rendering APIs that focus on the concept of render commands
  • Constrained and explicit engine lifecycle
  • ECS runtime
  • Features like emissive blocks, PBR, fogs, decals, screen post-processing

Credits

Kirino-Engine is made possible thanks to the efforts of all contributors!

• tttsaurus - Core maintainer, architecture design, and overall project coordination
• Eerie - Feature development and algorithmic contributions
• ChaosStrikez - Code refactoring, call-site improvements, and algorithm fixes

License

This project is licensed under Mod Permissions License published by Jbredwards.