И их решение логично. UE5 единственный вариант, если хочется самую навороченную графику. Но только если. Там куча своих проблем.

Поправка - будет, когда запилят редактор. По моим прикидкам пару лет ещё. К этому времени и остальные части движка менее сырыми будут. Вообще по ощущениям движок где-то между Unity и Godot. Там местами сложная внутрянка. Не только рендеринг, пайплайн ассетов ещё. Для простых игр это оверкил кстати. Яб позиционировал bevy как годную штуку для проектов средней сложности, которым хочется чего-то специфического.

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

В простом случае на самом деле кастомного меша уже будет достаточно. На этом этапе ты делаешь прототип. Получаешь рабочий мешинг и рабочий менеджер чанков.

Затем кастомный материал. Это на случай, если хочется greedy mesher с текстурками (хочется же). По факту просто вызвать pbr-шейдер с другими параметрами. При этом хорошо бы разобраться, как это должно работать на чистом wgpu. (окей, там могут быть другие варианты, но допустим)

После этого смотрим и думаем, чего нам не хватает для наших целей. Лоды для вокселей, ага. В данном случае нам скорее всего придётся разобраться, как меши работают внутри и написать свою систему, похожую на то, как работают меши, но чутка по другому. Тут уже надо вникать в нутро bevy и прям читать код bevy_render/bevy_pbr и прочего связанного. Это придётся сделать просто по той причине, что нам для задачи сама концепция мешей уже не подходит, что достаточно логично как по мне.

На самом деле грамотно сделанный копрокубинг уже начнёт упираться в размер флоата. В плане кроме рендеринга нужно ведь мир физики и прочего рабочий. Без ухищрений у тебя будет где-то не более 10 км (очень примерно).

Если не считать этого, тебе хватит greedy meshing и догадаться, что можно разбить всё на чанки и паковать позиции вершин в байт. То есть вообще говоря затыков то не много. Больше проблем с тем, как это хранить/генерить. (окей, ладно, AO/текстурки для копрокубов с greedy meshing было заёбисто делать). Но вообще тут главное понять принцип, что именно является затыком в производительности на этом этапе. А именно количество данных на куб и вообще пропускная способность.

Затем тебя будет волновать только цена фрагментных шейдеров. Всмысли нафаршированный PBR вообще говоря может быть тяжёлой штукой.

> Отлично! То есть надо делать не только свой проект, но и инструменты к нему.

Куча студий имеют свой движок на самом деле. Ну не знаю, Project Zomboid, No Man's Sky, Cyberpunk 2077 в качестве рандомных примеров разного уровня.

> А почему не пойти дальше и не сделать компилятор, операционку и всё такое прочее заодно?

А почему бы и нет. Только надо глубже, с проца. По крайней мене на уровне эмуляции. Как раз сейчас этим этапом занимаюсь. Просто потомушта почему бы и нет. Операционку свою я уже писал кстати. Не то, чтоб это необходимый путь для чего либо, но могу умею практикую, чё ты мне сделаешь.

> Уметь хорошо готовить ... — намного, намного предпочтительней, чем писать что угодно с нуля

Да. Никто с этим не спорит. Но если очень хочется, то можно как угодно делать. А иногда это даже нужно. Инструменты имеют свои ограничения. Если задачу решают доступные инструменты - используем их. Если не решают - используем что-то ещё или делаем своё. Или вообще меняем задачу на более простую.

> а движок взял да и скурвился

Если движок открытый, то всё, что ты теряешь - обновления и поддержку сообщества. А они скорее всего уже не так сильно нужны в середине. Движок то никуда не девается, просто перестаёт развиваться. Пользоваться им можно сколько угодно. Это то, что отличает открытые проекты и закрытые.

> Веб-фреймворк тоже написать несложно

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

> Только почему-то в

Не почему-то. А по той причине, что будет группа специально обученных конкретной хуйне. Без относительно качества этой хуйни кстати (то есть оно может быть и полным говном и охуеть какой конфеткой).

> В любом случае, писать велосипеды — это хорошо в рамках обучения и хобби.

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

> и про какую-никакую гарантию, что не произойдёт таких приколов

Обязательно произойдёт какая-то хуйня. Вопрос в том, рано это будет или поздно.