Как понять, что проблема связана именно с Unreal Engine, а не с приложением, окружением, сетью или зависимостями?

Шаг 1: Воспроизведение на чистом проекте

# Создаём пустой проект на той же версии движка
# UE_ROOT/Engine/Binaries/Linux/UnrealEditor-Linux-Debug MyEngine.uproject

# Или через CLI:
"$UE_ROOT/Engine/Build/BatchFiles/Linux/Build.sh" \
  ShaderCompileWorker Linux Development

# Если баг воспроизводится в чистом проекте -> проблема Engine
# Если нет -> проблема в ваших ассетах/коде

Методология диагностики: Engine vs. приложение

Ключевой принцип — бисекция: сужаем пространство гипотез, изолируя переменные одну за другой. Unreal Engine — это и runtime, и build-система, и asset pipeline, поэтому "проблема движка" может проявляться в трёх разных слоях.

Шаг 2: Проверка Engine changelog и известных issues

• Смотрим Engine/Extras/ReleaseNotes.md и issues.unrealengine.com — часто регрессия уже зарепорчена.
• Проверяем Engine/Source/Runtime/Engine/Private/CHANGELOG.txt (если собираем из исходников).
• Ищем в GitHub Epic Games репозитории по симптому: site:github.com/EpicGames <симптом>.

Шаг 3: Unreal Insights для runtime-проблем

# Запуск с трейсингом
./MyGame-Linux-Shipping \
  -trace=cpu,gpu,memory,loadtime,frame \
  -tracehost=127.0.0.1

# Открываем Unreal Insights
"$UE_ROOT/Engine/Binaries/Linux/UnrealInsights" \
  -OpenTraceFile=/tmp/MyTrace.utrace

В Insights смотрим: GT/RT frame budget, memory allocations, asset streaming events. Если проблема воспроизводится на разных машинах с разным кодом приложения, но одинаковой версией Engine — это Engine.

Шаг 4: Изоляция по слоям

• Build-проблема: запустите UBT -clean, удалите Intermediate/ и Binaries/, пересоберите. Если проблема исчезла — это артефакт инкрементальной сборки, а не Engine bug.
• Asset-проблема: создайте пустой уровень без ваших ассетов. Если runtime стабилен — проблема в конкретном ассете (часто Shader Complexity или неправильный LOD).
• Сетевая проблема: запустите -nullrhi (без рендера) — если crash исчезает, проблема в RHI, а не в game logic.
• Окружение: смените GPU driver, проверьте VRAM через stat Memory in-game консолью, запустите на другой ОС если возможно.

Шаг 5: Логи и символы

# Включаем verbose логирование
# DefaultEngine.ini
[Core.Log]
LogTemp=VeryVerbose
LogRHI=Verbose
LogRenderer=Verbose

# Crash дамп с символами (Development build)
# Saved/Crashes/CrashContext.runtime-xml
# Saved/Logs/MyGame.log

# Символы для Analysis
"$UE_ROOT/Engine/Binaries/Linux/CrashReportClient" \
  -Symbolize /path/to/crash.dmp

Подводные камни

• Shipping build отключает большинство проверок — баг воспроизводится только в Development/Debug; не делайте вывод что "в проде всё норм".
• DDC (Derived Data Cache) может хранить битые шейдеры — rm -rf ~/.local/share/UnrealEngine/Common/DerivedDataCache/ решает класс "только у меня" проблем.
• Engine bugs часто проявляются только на конкретном GPU vendor (AMD vs NVIDIA vs Intel) — воспроизводите на том же железе.
• Unreal Insights overhead ~5–10% CPU — не используйте full trace в production benchmark.
• Лог файл MyGame.log ротируется при старте — используйте -abslog=/path/to/fixed.log для сохранения в CI.
• Проблемы с репликацией часто выглядят как Engine bug, но являются неправильной настройкой NetCullDistanceSquared или bReplicates.
• Пустой проект для воспроизведения должен использовать точно ту же версию Engine (включая hotfix) — минорные патчи меняют поведение.

• Сразу обвинять Unreal Engine, не проверив соседние слои системы
• Чинить симптом без минимального воспроизведения и evidence
• Не учитывать версии, конфигурацию, окружение и recent changes

• Умеет локализовать проблему вокруг Unreal Engine
• Двигается от симптома к гипотезам и проверкам
• Отличает баг инструмента от ошибки использования или окружения