Так о чем это я… БКК предназначен для того, чтобы “запечь” ландшафт и прочие объекты в монолитный меш с низким LOD и объединенной текстурой. Как только игрок покидает какую-то область, эта область подменяется на БКК и издалека кажется что ничего и не выгружалось. В теории… На практике как только у вас появится сколько нибудь большая область, БКК в лучшем случае просто кинет фатал на этапе запекания через час, либо, что вообще п*здец, кинет вам фатал после перезагрузки карты. При чем он кинет фатал даже если запекать только ландшафт. Что еще забавнее, это если у вас фатал после перезагрузки карты, то чтобы его поправить придется вслепую искать нужные файлы в папке карты, где находятся тысячи, десятки тысяч файлов с нечитаемыми именами. У вас же есть контроль версий, правда?
Unreal Engine - это не волшебный движок с кнопкой "Сделать збс", опенворлды на анриле имеют кучу проблем, ряд из которых остался со времен четверки.
1. HLOD в целом запекатеся нормально, но может выжрать тонну памяти и ресурсов (в зависимости от чанка). Если проект крупный, то этим вообще занимается отдельная выделенная машина, которая пересобирает дальние лоды. После чего на финальном этапе разработке игры их еще и ручками лучше перерисовать.
2. World Partition все еще имеет ряд болячек с World Composition, о котором я писал когда-то статейку + о ряде болячек рассказывают на выступлениях, посмотри последний Unreal Fest, в том числе от CDPR. Как это лечится? Берется движок и переписывается стриминг, регистрация экторов или вообще отказ от экторов для статики и т.д.
3. Да, не надо делать сложной логики на констракшене и BeginPlay особенно у того, что стримится, пачка экторов появляется одновременно и бьет по производительности. Нужно следить за тем, что делаешь.
4. Да, работа в редакторе и в билде разнится. Потому финальную производительность нужно смотреть только в билде, и билды нужны регулярные.
5. Да, систему сохранений надо писать самому, ровно как и разбираться с возможностью перемещать объекты между чанками и чтоб это сохранялось и т.д. На эту тему тоже когда-то рассказывал, как подобное делать.
6. Про люмены и наниты, они жрущие, причем как для разработчика так и для игрока, нужно собирать сцену с учетом таргет железа и следить за тем, что загружено единовременно, что и как влияет на производительность.
В общем внезапно да, если собираешь что-то более менее сложное, с движком нужно работать. Если нет возможности менять исходники, значит следить за ограничениями и стараться не делать чего-то, что за эти ограничения вылезает (не пихать кучу логики на спаун, следить за тем что стримится и когда, за распределением ресурсов, количестве экторов в радиусе стриминга и т.д.)
Короче, "библиотечные методы" анрила - это буквально технодемки, которые в проекте лучше не использовать.
Да, работа в редакторе и в билде разнится. Потому финальную производительность нужно смотреть только в билде, и билды нужны регулярные.
фига се у них конкурсы интересные
А мне и не нужна кнопка "Сделать збс", мне нужно чтобы инструмент работал так, как его продвигают. У меня он так не работает, и еще куча народа на форумах сталкиваются с тем же.
Как это лечится? Берется движок и переписывается стриминг, регистрация экторов или вообще отказ от экторов для статики и т.д.Так я и написал:
Стоковый Unreal Engine вообще не рассчитан на так называемый Open World
Короче надо работать. И походу за это денюшку разрабы и получают. Особенно хорошие, которые умеют делать игры с нормальным фпс.
Здравствуйте! "На эту тему тоже когда-то рассказывал, как подобное делать" - это где то в открытом доступе? Если у вас есть свой канал, можете дать на него ссылку?
Итак, теперь я понял две вещи:
1. К черту Анрыло
2. К черту опенворлды