Тогда можно просто рандомом накидать зон, рандомом поставить ключевые точки (боссы там, сундуки, etc) и А* через ключевые точки искать путь. Но это уже не столько генерация, сколько реализация геймдизайна, который вне рамок статьи, хотя просто упомянуть можно.
Дело не в "в случае круглых лабиринтов". Статья называется не "генерация мешей рантайм", а "процедурная генерация лабиринтов". Поэтому 90% статьи про генерацию мешей тут лишние и слишком сложные для примера.
При создании геометрии можно кроме вершин и трисов писать uv/uv2/uv3 для текстур и нормали в вершинах (хотя нормали можно и встроенным методом пересчитать).
Это точно статья про генерацию лабиринта, а не про генерацию мешей рантайм без поддержки текстурирования и освещения?
ИМХО, было бы лучше 90% статьи про геометрию заменить на простенькую расстановку префабов стен/пола
А в идеале ещё и сделать в генерации дополнительные поля, описывающие тип клетки, чтобы было понятнее, что тут можно добавлять вариативность визуала/будущих механик и как расширять генератор объектов.
И в стриминг ассетс не засунуть so, потому что внутри должны быть сериализованные данные из билда, поэтому в прямом виде только в ресурсах хранить, а в запакованном получатся бандлы в стриминге. Значит надо либо в каждой сцене хранить только используемый набор so и делать кучу сцен, либо выделять бандлами наборы из so+assets
Тут тоже есть проблемы с ассетами - достаточно добавить все эти so в сцену и получим загрузку всех связанных ассетов при открытии сцены. Тут либо в ресурсы пихать и загружать нужные so (вместе со связанными в них ассетами) либо в бандлы и грузить только нужные бандлы.
Куб, например, без них не сделаешь. Как и любую жесткую/острую грань. А без нормалей не сделать освещение. Плюс вертексное освещение дешевле попиксельного, что для мобилок актуально.
Для чего-то более крупного, чем прыжок монетки применять, редко когда удобно - анимации в коде делают программисты, а не дизайнеры/артисты, что часто является проблемой. Те же анимации записать и в таймлайн закинуть большинство юнити-артистов могут сделать, а вот твинер только программист поправит, который в данный момент может быть занят более важной штукой.
Ну тут да, в основном предостерегают от грубых ошибок, потому что специфика каждого движка своя. Я. например, могу немножко рассказать про плей канвас, с которым работал.
А как хорошо будет работать распаковка при подгрузке ресурсов "на лету", когда и так процессор с памятью заняты игрой, так ещё и декомпрессию проводить.
Ещё у Odin можно методы вытаскивать в инспектор для вызова кнопкой (с параметром даже), задавать атрибутами видимость полей в инспекторе (чтобы не писать кастомный эдитор для класса)
Ну тут надо различать, что инстансинг — это один меш с массивом матриц-трансформов, а батчинг — это один материал (меш любой).
А с остальным полностью согласен!
Тогда можно просто рандомом накидать зон, рандомом поставить ключевые точки (боссы там, сундуки, etc) и А* через ключевые точки искать путь. Но это уже не столько генерация, сколько реализация геймдизайна, который вне рамок статьи, хотя просто упомянуть можно.
Дело не в "в случае круглых лабиринтов". Статья называется не "генерация мешей рантайм", а "процедурная генерация лабиринтов". Поэтому 90% статьи про генерацию мешей тут лишние и слишком сложные для примера.
При создании геометрии можно кроме вершин и трисов писать uv/uv2/uv3 для текстур и нормали в вершинах (хотя нормали можно и встроенным методом пересчитать).
Это точно статья про генерацию лабиринта, а не про генерацию мешей рантайм без поддержки текстурирования и освещения?
ИМХО, было бы лучше 90% статьи про геометрию заменить на простенькую расстановку префабов стен/пола
А в идеале ещё и сделать в генерации дополнительные поля, описывающие тип клетки, чтобы было понятнее, что тут можно добавлять вариативность визуала/будущих механик и как расширять генератор объектов.
И в стриминг ассетс не засунуть so, потому что внутри должны быть сериализованные данные из билда, поэтому в прямом виде только в ресурсах хранить, а в запакованном получатся бандлы в стриминге. Значит надо либо в каждой сцене хранить только используемый набор so и делать кучу сцен, либо выделять бандлами наборы из so+assets
Тут тоже есть проблемы с ассетами - достаточно добавить все эти so в сцену и получим загрузку всех связанных ассетов при открытии сцены. Тут либо в ресурсы пихать и загружать нужные so (вместе со связанными в них ассетами) либо в бандлы и грузить только нужные бандлы.
другой тип шейдеров с расширением ".cginc" - Compute Shader
Но ведь это просто подключаемые библиотеки
Куб, например, без них не сделаешь. Как и любую жесткую/острую грань. А без нормалей не сделать освещение. Плюс вертексное освещение дешевле попиксельного, что для мобилок актуально.
Для этого придумали hard edge
L - единичный вектор нормали падающего света
Можно это вектор направления directional освещения?
Да, но внутри CGPROGRAM GLSL же
Для чего-то более крупного, чем прыжок монетки применять, редко когда удобно - анимации в коде делают программисты, а не дизайнеры/артисты, что часто является проблемой. Те же анимации записать и в таймлайн закинуть большинство юнити-артистов могут сделать, а вот твинер только программист поправит, который в данный момент может быть занят более важной штукой.
Ну тут да, в основном предостерегают от грубых ошибок, потому что специфика каждого движка своя. Я. например, могу немножко рассказать про плей канвас, с которым работал.
Основной тезис в том, что если результат сопоставим, то зачем платить больше?
Но ведь можно проще: color = lerp(color1, color2, step(pos.x, 0.5))
А как хорошо будет работать распаковка при подгрузке ресурсов "на лету", когда и так процессор с памятью заняты игрой, так ещё и декомпрессию проводить.
А с остальным полностью согласен!
Но ведь глобальные свойства — это uniform поля (которые могут быть в Properties), а не вот это вот.