EN:

Ultimate Optimization Pack 1.0.0

Initial Release — Technical Changelog & Performance Audit

The first public release of Ultimate Optimization Pack introduces an independent client-side optimization suite for Minecraft Fabric.

The primary objective of version 1.0.0 is to reduce unnecessary rendering operations, minimize the processing overhead of secondary visual effects and improve overall system resource efficiency.

The mod consists of four primary optimization systems and an integrated performance monitoring module.

---

1. ENTITY CULLING

Implemented:

• Distance-based entity filtering (Distance Culling).
• Spatial visibility detection (Occlusion Culling).
• Voxel-based raycasting (Voxel Raycasting).
• Multiple Bounding Box sample-point checks.
• Visibility result caching.
• Individual render distance limits for different entity types.
• Exclusion rules for important game entities.

[+] Strength:

Combining two filtering techniques allows the system to exclude not only distant objects but also entities completely obstructed by opaque blocks.

Visibility caching reduces redundant calculations, while individual render distances provide more granular control over different entity categories.

[-] Weakness:

The primary limitation is the synchronous execution of spatial visibility checks. When a large number of entities are present, raycasting operations can introduce additional workload on the main client thread.

The current system also relies on a limited visibility-check budget and a relatively simple result-reuse mechanism.

[→] Planned Improvements — 2.0.0:

• Rework the Occlusion Culling architecture.
• Introduce asynchronous processing of prepared visibility data.
• Implement Temporal Coherence.
• Improve visibility cache invalidation.
• Optimize the VoxelRay algorithm.
• Research experimental GPU-based HZB Occlusion Culling.

---

2. BLOCK ENTITY CULLING

Implemented:

• Distance-based Block Entity filtering.
• Spatial visibility checks.
• Bounding Box processing for block entities.
• Visibility result caching.
• Exclusion rules for important objects, including beacons.
• Integration directly into the Block Entity render-state extraction stage.

[+] Strength:

Filtering occurs before the renderer fully processes an object's render state. This helps avoid unnecessary operations rather than simply skipping the final rendering call after the object has already been processed.

A dedicated Block Entity filtering system also makes it possible to optimize objects that are processed differently from regular entities.

[-] Weakness:

The algorithm shares an architecture similar to Entity Culling and inherits some of its limitations: synchronous visibility checks, a restricted computation budget and additional complexity when processing dynamically changing objects.

[→] Planned Improvements — 2.0.0:

• Improve spatial visibility filtering.
• Introduce adaptive result caching.
• Improve handling of dynamically changing Block Entities.
• Optimize repeated BlockState access.
• Improve animation and special visual-state handling.
• Introduce shared visibility infrastructure for Entity and Block Entity Culling.

---

3. PARTICLE LIMITER

Implemented:

• Maximum particle render distance.
• Particle density control.
• Maximum particle creation budget per game tick.
• Filtering before particle object creation.
• Exception handling for important visual effects.

[+] Strength:

One of the most effective design decisions in the first release is filtering particles before their actual creation.

Unnecessary particle objects are prevented from entering the subsequent processing pipeline, avoiding additional work in later particle update and rendering stages.

Preserving important visual effects also allows secondary visual elements to be limited without intentionally disabling essential gameplay feedback.

[-] Weakness:

The first release primarily uses static optimization parameters. It does not dynamically analyze current client performance or adjust particle limits according to Frame Time.

Additionally, ordinary particles are processed using a relatively simple priority model.

[→] Planned Improvements — 2.0.0:

• Dynamic Particle Budget.
• Adaptive particle limits based on current performance.
• Particle Priority System: Critical / High / Normal / Low.
• More granular per-particle-type limits.
• Gradual particle density recovery after performance improves.
• Expanded statistics for created and rejected particles.

---

4. DYNAMIC FPS

Implemented:

• Game window activity detection.
• Unfocused window detection.
• Minimized window detection.
• Automatic FPS limiting.
• Thread parking instead of continuous active waiting.

Default limits:

• 15 FPS when the window is unfocused.
• 5 FPS when the game is minimized.

[+] Strength:

This feature reduces unnecessary client activity when Minecraft is not actively being used.

Instead of continuously rendering at maximum frame rates, the mod regulates the client loop according to the current window state.

[-] Weakness:

The first release uses a relatively simple two-state model. It does not yet provide advanced FPS profiles, extensive user-defined state configurations or adaptive frame-rate management.

[→] Planned Improvements — 2.0.0:

• Expanded window-state management.
• Individually configurable FPS limits.
• Smoother restoration of the normal frame rate.
• Additional client-loop synchronization checks.
• Improved handling of transitions between active, unfocused and minimized states.

---

5. PERFORMANCE OVERLAY

Implemented:

• Real-time FPS monitoring.
• Average and worst frame time.
• 1% Low FPS measurement.
• Java Heap usage monitoring.
• Rendered and culled entity statistics.
• Block Entity Culling statistics.
• Particle Limiter statistics.
• Overlay visibility toggle using the F8 key.

[+] Strength:

The integrated Performance Overlay provides more than a standard FPS counter. It also exposes information about the internal operation of individual optimization systems.

This provides the foundation for Performance Telemetry — monitoring not only the final frame rate but also the activity of the optimization modules themselves.

[-] Weakness:

The current HUD provides a limited set of performance metrics. Text generation and temporary object allocations can also be optimized.

Additionally, the mod does not yet include a complete built-in performance benchmarking and comparison system.

[→] Planned Improvements — 2.0.0:

• Complete OverlayHud rework.
• Caching of prepared text strings.
• Reduction of temporary memory allocations.
• 0.1% Low FPS monitoring.
• P95 and P99 Frame Time metrics.
• Extended Garbage Collection statistics.
• Per-module execution time monitoring.
• Cache hit and miss statistics.
• Background task monitoring.
• Customizable HUD position and displayed metrics.

---

6. CORE ARCHITECTURE

Implemented:

• Independent optimization systems.
• Centralized module management.
• Error protection through the Guard system.
• Configuration management.
• /uop command system.
• Independent module activation and deactivation.
• Mixin integration with Minecraft client-side systems.

[+] Strength:

The mod already has a modular architecture. Its primary optimization systems perform separate tasks rather than functioning as an unrelated collection of settings.

Centralized management makes it possible to monitor module states and gradually expand functionality without combining the entire codebase into a single component.

[-] Weakness:

The first release requires stricter separation of responsibilities between the central controller, visibility algorithms, caching infrastructure and rendering integrations.

Additional work is also required to verify resource lifecycle management and module behavior when worlds are unloaded.

[→] Planned Improvements — 2.0.0:

• Core Architecture restructuring.
• Dedicated background task management.
• Unified Visibility infrastructure.
• Improved Guard system.
• Worker task queue management.
• Protection against memory leaks and stale references.
• More robust module lifecycle management.

---

7. CONFIGURATION & COMMANDS

Implemented:

• Centralized configuration file.
• Entity render distance settings.
• Particle limits.
• Entity and block entity exceptions.
• Dynamic FPS settings.
• Configuration reload without restarting the game.
• /uop command system.

[+] Strength:

Being able to modify optimization parameters without restarting Minecraft makes the mod more flexible and convenient to configure.

[-] Weakness:

The configuration system would benefit from more comprehensive parameter validation, configuration migration between versions and improved diagnostics for invalid values.

[→] Planned Improvements — 2.0.0:

• Updated configuration structure.
• Automatic migration of existing settings.
• Configuration value validation.
• More detailed diagnostic messages.
• Expanded command system.
• New Benchmark and Debug commands.

---

8. PERFORMANCE & BENCHMARKING

Implemented:

• Basic FPS monitoring.
• Performance statistics for the primary optimization systems.
• Individual counters for filtered objects.
• Integrated Performance Overlay.

[+] Strength:

The first release already provides the foundation for performance diagnostics. This allows the project to evolve using actual module statistics rather than relying entirely on assumptions.

[-] Weakness:

A complete system for reproducible performance comparisons is not yet available.

Consequently, it is not currently possible to establish a universal FPS improvement, accurately measure the impact of individual algorithms on frame time or compare their effectiveness across different hardware configurations.

[→] Planned Improvements — 2.0.0:

• Integrated Benchmark System.
• Vanilla / UOP performance comparison.
• Entity Stress, Block Entity Stress and Particle Stress test scenarios.
• Average FPS, Median FPS, 1% Low and 0.1% Low measurements.
• P95 and P99 Frame Time monitoring.
• Per-module CPU execution time profiling.
• JVM Garbage Collection activity monitoring.
• CSV export for benchmark results.

---

9. FIRST RELEASE SUMMARY

Ultimate Optimization Pack 1.0.0 establishes the foundation of an independent client-side Minecraft optimization suite.

Key Achievements:

1. Custom Entity Culling implementation.
2. Dedicated Block Entity Culling system.
3. Particle filtering before object creation.
4. Automatic background FPS limiting.
5. Integrated Performance Overlay.
6. Independent optimization module management.
7. Configuration and command-based control.

Main Technical Limitations:

1. Synchronous Occlusion Culling checks.
2. Limited visibility result reuse.
3. No adaptive particle budget.
4. Limited performance monitoring capabilities.
5. No comprehensive built-in benchmarking system.
6. Further optimization needed for temporary allocations and cache architecture.

10. DEVELOPMENT DIRECTION

The next release should not simply increase the number of available features.

The primary objective is to improve existing algorithms, reduce their computational overhead and make optimization results measurable.

Ultimate Optimization Pack 2.0.0 — Development Priorities:

• Advanced Entity & Block Entity Culling.
• Asynchronous Visibility Processing.
• Temporal Coherence.
• Experimental GPU HZB.
• Adaptive Particle Management.
• Improved JVM Memory Management.
• Advanced Performance Telemetry.
• Integrated Benchmark System.
• Improved Sodium Compatibility.

Final Vision:

Ultimate Optimization Pack 1.0.0 — the foundation of an independent client-side optimization engine.

Ultimate Optimization Pack 2.0.0 — the transition towards a more intelligent, adaptive and scalable system for managing Minecraft's rendering and computational workloads.

Support me on DonationAlerts

---

RU:

Ultimate Optimization Pack 1.0.0

Первый релиз — технический обзор и аудит производительности

Первая публичная версия Ultimate Optimization Pack представляет собой самостоятельный клиентский комплекс оптимизации для Minecraft Fabric.

Основная задача версии 1.0.0 — сокращение количества ненужных операций рендеринга, уменьшение нагрузки от второстепенных визуальных эффектов и повышение эффективности использования системных ресурсов.

Мод включает четыре основные системы оптимизации и интегрированный модуль мониторинга производительности.

---

1. ENTITY CULLING

Реализовано:

• Дистанционная фильтрация сущностей (Distance Culling).
• Пространственное определение видимости (Occlusion Culling).
• Воксельная трассировка лучей (Voxel Raycasting).
• Проверка нескольких контрольных точек Bounding Box.
• Кэширование результатов определения видимости.
• Индивидуальные ограничения дальности для разных типов сущностей.
• Система исключений для важных игровых объектов.

[+] Сильная сторона:

Использование двух уровней фильтрации позволяет исключать не только удалённые объекты, но и сущности, полностью скрытые за непрозрачными блоками.

Кэширование результатов сокращает количество повторных вычислений, а индивидуальная настройка дальности обеспечивает более гибкий контроль над разными категориями сущностей.

[-] Слабая сторона:

Основное ограничение заключается в синхронном выполнении пространственных проверок. При большом количестве сущностей трассировка лучей может создавать дополнительную нагрузку на основной клиентский поток.

Кроме того, текущая система использует ограниченный бюджет проверок видимости и сравнительно простую модель повторного использования результатов.

[→] Будет изменено в 2.0.0:

• Переработка архитектуры Occlusion Culling.
• Внедрение асинхронной обработки подготовленных данных видимости.
• Реализация Temporal Coherence.
• Улучшение инвалидации устаревшего кэша видимости.
• Оптимизация алгоритма VoxelRay.
• Исследование экспериментального GPU-based HZB Occlusion Culling.

---

2. BLOCK ENTITY CULLING

Реализовано:

• Дистанционная фильтрация блочных сущностей.
• Пространственные проверки видимости.
• Обработка Bounding Box блочных сущностей.
• Кэширование результатов проверок.
• Система исключений для важных объектов, включая маяки.
• Интеграция непосредственно в этап подготовки состояний рендеринга Block Entities.

[+] Сильная сторона:

Фильтрация выполняется до полноценной обработки состояния объекта рендерером. Это позволяет избежать части ненужных операций, а не просто пропустить финальный вызов отрисовки уже обработанного объекта.

Отдельная система фильтрации Block Entities также позволяет оптимизировать объекты, которые обрабатываются иначе, чем обычные сущности.

[-] Слабая сторона:

Алгоритм использует архитектуру, схожую с Entity Culling, и наследует некоторые её ограничения: синхронные проверки видимости, ограниченный бюджет вычислений и дополнительную сложность при обработке динамически изменяющихся объектов.

[→] Будет изменено в 2.0.0:

• Улучшение пространственной фильтрации.
• Внедрение адаптивного кэширования результатов.
• Улучшенная обработка динамически изменяющихся Block Entities.
• Оптимизация повторных обращений к BlockState.
• Более корректная обработка анимаций и специальных визуальных состояний.
• Создание общей инфраструктуры определения видимости для Entity и Block Entity Culling.

---

3. PARTICLE LIMITER

Реализовано:

• Ограничение максимальной дальности частиц.
• Контроль плотности создаваемых частиц.
• Ограничение количества частиц за один игровой тик.
• Фильтрация до создания объекта частицы.
• Исключения для важных игровых визуальных эффектов.

[+] Сильная сторона:

Одно из наиболее удачных архитектурных решений первой версии — фильтрация частиц ещё до их фактического создания.

Ненужные объекты частиц не попадают в последующий конвейер обработки, что позволяет избежать дополнительных операций на этапах обновления и отрисовки.

Сохранение важных визуальных эффектов также позволяет ограничивать второстепенные элементы без намеренного отключения значимой игровой обратной связи.

[-] Слабая сторона:

В первой версии преимущественно используется статическая система ограничений. Она не анализирует текущую производительность клиента и не адаптирует количество частиц в зависимости от Frame Time.

Кроме того, обычные частицы обрабатываются на основе сравнительно простой модели приоритетов.

[→] Будет изменено в 2.0.0:

• Dynamic Particle Budget.
• Адаптивное изменение лимитов частиц в зависимости от производительности.
• Система приоритетов Critical / High / Normal / Low.
• Более гибкие индивидуальные ограничения для разных типов частиц.
• Постепенное восстановление плотности частиц после снижения нагрузки.
• Расширенная статистика созданных и заблокированных частиц.

---

4. DYNAMIC FPS

Реализовано:

• Определение активности игрового окна.
• Обнаружение потери фокуса окном.
• Определение свёрнутого состояния окна.
• Автоматическое ограничение FPS.
• Использование механизма парковки потока вместо постоянного активного ожидания.

Стандартные ограничения:

• 15 FPS при неактивном окне.
• 5 FPS при свёрнутой игре.

[+] Сильная сторона:

Функция позволяет сократить ненужную активность клиента, когда Minecraft не используется.

Вместо постоянной отрисовки с максимальной частотой кадров мод регулирует частоту выполнения клиентского цикла в зависимости от текущего состояния окна.

[-] Слабая сторона:

Первая версия использует сравнительно простую двухсостояниевую модель. В ней пока отсутствуют расширенные профили ограничения FPS, гибкая настройка состояний окна и адаптивное управление частотой кадров.

[→] Будет изменено в 2.0.0:

• Расширенная система управления состояниями игрового окна.
• Индивидуально настраиваемые ограничения FPS.
• Более плавное возвращение к стандартной частоте кадров.
• Дополнительные проверки взаимодействия с клиентским циклом Minecraft.
• Улучшенная обработка переходов между активным, неактивным и свёрнутым состояниями.

---

5. PERFORMANCE OVERLAY

Реализовано:

• Мониторинг FPS в реальном времени.
• Среднее и максимальное время кадра.
• Измерение 1% Low FPS.
• Мониторинг использования Java Heap.
• Статистика отрисованных и скрытых сущностей.
• Статистика Block Entity Culling.
• Статистика Particle Limiter.
• Управление отображением оверлея клавишей F8.

[+] Сильная сторона:

Встроенный Performance Overlay предоставляет больше информации, чем обычный счётчик FPS. Он также отображает сведения о внутренней работе отдельных систем оптимизации.

Это создаёт основу для Performance Telemetry — мониторинга не только итоговой частоты кадров, но и активности самих модулей оптимизации.

[-] Слабая сторона:

Текущий HUD предоставляет ограниченный набор показателей производительности. Формирование текстовых данных и создание временных объектов также можно оптимизировать.

Кроме того, в моде пока отсутствует полноценная встроенная система сравнительного тестирования производительности.

[→] Будет изменено в 2.0.0:

• Полная переработка OverlayHud.
• Кэширование подготовленных текстовых строк.
• Сокращение временных аллокаций памяти.
• Мониторинг 0.1% Low FPS.
• Добавление показателей P95 и P99 Frame Time.
• Расширенная статистика Garbage Collection.
• Мониторинг времени выполнения отдельных модулей.
• Статистика попаданий и промахов кэша.
• Мониторинг фоновых задач.
• Настройка положения HUD и отображаемых показателей.

---

6. CORE ARCHITECTURE

Реализовано:

• Независимые системы оптимизации.
• Централизованное управление модулями.
• Защита от ошибок через систему Guard.
• Управление конфигурацией.
• Командная система /uop.
• Возможность независимого включения и отключения основных подсистем.
• Mixin-интеграция с клиентскими механизмами Minecraft.

[+] Сильная сторона:

Мод уже имеет модульную архитектуру. Его основные системы выполняют отдельные задачи, а не представляют собой простую коллекцию несвязанных настроек.

Централизованное управление позволяет отслеживать состояние подсистем и постепенно расширять функциональность без необходимости объединять весь код в один большой компонент.

[-] Слабая сторона:

Первой версии требуется более строгое разделение ответственности между центральным контроллером, алгоритмами определения видимости, системой кэширования и графическими интеграциями.

Также необходимо провести дополнительную проверку управления жизненным циклом ресурсов и поведения модулей при выгрузке миров.

[→] Будет изменено в 2.0.0:

• Реструктуризация Core Architecture.
• Отдельная система управления фоновыми задачами.
• Единая инфраструктура Visibility.
• Улучшение системы Guard.
• Контроль очередей Worker Thread.
• Защита от утечек памяти и устаревших ссылок.
• Более надёжное управление жизненным циклом модулей.

---

7. CONFIGURATION & COMMANDS

Реализовано:

• Единый конфигурационный файл.
• Настройки дальности отрисовки сущностей.
• Ограничения частиц.
• Исключения для сущностей и блочных сущностей.
• Настройки Dynamic FPS.
• Перезагрузка конфигурации без перезапуска игры.
• Командная система /uop.

[+] Сильная сторона:

Возможность изменять параметры оптимизации без перезапуска Minecraft делает мод более гибким и удобным в настройке.

[-] Слабая сторона:

Конфигурационная система нуждается в более полной проверке параметров, автоматической миграции настроек между версиями и расширенной диагностике некорректных значений.

[→] Будет изменено в 2.0.0:

• Обновлённая структура конфигурации.
• Автоматическая миграция существующих настроек.
• Проверка корректности значений.
• Более подробные диагностические сообщения.
• Расширение командной системы.
• Новые команды Benchmark и Debug.

---

8. PERFORMANCE & BENCHMARKING

Реализовано:

• Базовый мониторинг FPS.
• Статистика производительности основных систем оптимизации.
• Отдельные счётчики количества отфильтрованных объектов.
• Встроенный Performance Overlay.

[+] Сильная сторона:

Уже в первой версии существует основа для диагностики производительности. Это позволяет развивать проект, используя реальные показатели работы модулей, а не полагаясь исключительно на предположения.

[-] Слабая сторона:

Полноценная система воспроизводимого сравнительного тестирования пока отсутствует.

Поэтому нельзя объективно определить универсальный прирост FPS, точно измерить влияние отдельных алгоритмов на время кадра или сравнить их эффективность на различных конфигурациях компьютеров.

[→] Будет изменено в 2.0.0:

• Создание встроенной Benchmark System.
• Сравнение производительности Vanilla / UOP.
• Сценарии Entity Stress, Block Entity Stress и Particle Stress.
• Измерение Average FPS, Median FPS, 1% Low и 0.1% Low.
• Мониторинг P95 и P99 Frame Time.
• Профилирование CPU-времени отдельных модулей.
• Мониторинг активности JVM Garbage Collection.
• Экспорт результатов тестирования в CSV.

---

9. ИТОГ ПЕРВОГО РЕЛИЗА

Ultimate Optimization Pack 1.0.0 закладывает фундамент самостоятельного клиентского комплекса оптимизации Minecraft.

Основные достижения:

1. Собственная реализация Entity Culling.
2. Отдельная система Block Entity Culling.
3. Фильтрация частиц до создания объектов.
4. Автоматическое ограничение FPS в фоновом режиме.
5. Интегрированный Performance Overlay.
6. Независимое управление модулями оптимизации.
7. Управление через конфигурацию и команды.

Основные технические ограничения:

1. Синхронные проверки Occlusion Culling.
2. Ограниченная система повторного использования результатов видимости.
3. Отсутствие адаптивного бюджета частиц.
4. Ограниченные возможности мониторинга производительности.
5. Отсутствие полноценной встроенной системы Benchmark.
6. Необходимость дальнейшей оптимизации временных аллокаций и архитектуры кэширования.

10. НАПРАВЛЕНИЕ РАЗВИТИЯ

Следующая версия не должна просто увеличивать количество доступных функций.

Главная задача — улучшить существующие алгоритмы, сократить их собственную вычислительную стоимость и сделать результаты оптимизации измеряемыми.

Приоритеты разработки Ultimate Optimization Pack 2.0.0:

• Advanced Entity & Block Entity Culling.
• Asynchronous Visibility Processing.
• Temporal Coherence.
• Experimental GPU HZB.
• Adaptive Particle Management.
• Improved JVM Memory Management.
• Advanced Performance Telemetry.
• Integrated Benchmark System.
• Improved Sodium Compatibility.

Итоговая концепция:

Ultimate Optimization Pack 1.0.0 — фундамент собственного движка клиентской оптимизации.

Ultimate Optimization Pack 2.0.0 — переход к более интеллектуальной, адаптивной и масштабируемой системе управления графической и вычислительной нагрузкой Minecraft.

Поддержать меня на DonationAlerts