Нужно понимать что Камера это не только рендер но и Culling, Filtering, Create Shaded Render Scene и прочие события. По этому такие штуки всегда лучше делать без участия камеры, постэффектом, Командами или тупо рендером в RT с последующим блитом в ScreenBuffer
В кейсе статьи просто RT c разрешением подогнанным под размер вокселя без биленейной фильтрации и с алайзингом.
а зачем создавать какойто плейн, когда можно поосто скопировать результат буфера в буфер кадра, через обычных Blit. И это не «крутая пиксельная графика» а просто рендер в пониженным разрешением. с таким же успехом можно понизить размер самого фрейм буфера через SetResolution и убрать у билинейность.
Размер важен только когда скачивается приложение из стора. Далее средний пользователь и знать не знает ничего про размер, даже как узнать его. По этому микреж такой, который сильно усложняет продакшн — в топку. Делаем до 100 мб, чтобы качало без вайфая, а остальное грузим бандлами. Сплитим бандлы по разрешению и лимиту оперативы пользователя. Ну естественно, оптимизация важна, особенно если из коробки юзаем GPGS или что-то там ещё. Бывает и в 100 мб не влезает.
Что вы тут навязываете программирование ради программирования. Нормальный код. Свою задачу выполняет. Что за предвзятость. Я когда начинал Unity именно по таким и учился.
Реализовал такой подход в проекте, однако есть один минус:
Если все хранить в одном файле (аля rus.xml) то добавление новых значений существенно усложняют жизнь локализаторам.
В итоге в новом проекте полностью поменял структуру.
Теперь каждая строка это отдельный ресурс который знает о себе какие либо специфичесике особенности касаемые каждого языка (выбираем от чего наследует) а так же на какие языки он переведен.
Была написана утилита которая делала выборку из доступных проекту ресурсов и выгружала все это в (Xls, doc, xml, json ) и парсила обратно.
В чем плюс: нам нужно перевести только то что не перевили для нового апдейта, или то что «будем преводить на португальский потом, сейчас переводчик заболел и апдейт будет без локализации на португальский нововведений», задаем параметры выгрузки, утилита сама формирует нужную доку с нужным языком по нужным изменениям с нужными ремарками. Шлем это переводчику, обратно переведенную доку парсим в проект и применяем изменения.
Плюс всего этого подхода еще и в том, что для любой svn/git видим изменения и историю по каждой строке.
Юзайте отдельный физический ресурс аля tag_id_rus.res для каждого лейбла проэкта. Пишите инструменты автоматизации.
В кейсе статьи просто RT c разрешением подогнанным под размер вокселя без биленейной фильтрации и с алайзингом.
Размер важен только когда скачивается приложение из стора. Далее средний пользователь и знать не знает ничего про размер, даже как узнать его. По этому микреж такой, который сильно усложняет продакшн — в топку. Делаем до 100 мб, чтобы качало без вайфая, а остальное грузим бандлами. Сплитим бандлы по разрешению и лимиту оперативы пользователя. Ну естественно, оптимизация важна, особенно если из коробки юзаем GPGS или что-то там ещё. Бывает и в 100 мб не влезает.
Если все хранить в одном файле (аля rus.xml) то добавление новых значений существенно усложняют жизнь локализаторам.
В итоге в новом проекте полностью поменял структуру.
Теперь каждая строка это отдельный ресурс который знает о себе какие либо специфичесике особенности касаемые каждого языка (выбираем от чего наследует) а так же на какие языки он переведен.
Была написана утилита которая делала выборку из доступных проекту ресурсов и выгружала все это в (Xls, doc, xml, json ) и парсила обратно.
В чем плюс: нам нужно перевести только то что не перевили для нового апдейта, или то что «будем преводить на португальский потом, сейчас переводчик заболел и апдейт будет без локализации на португальский нововведений», задаем параметры выгрузки, утилита сама формирует нужную доку с нужным языком по нужным изменениям с нужными ремарками. Шлем это переводчику, обратно переведенную доку парсим в проект и применяем изменения.
Плюс всего этого подхода еще и в том, что для любой svn/git видим изменения и историю по каждой строке.
Юзайте отдельный физический ресурс аля tag_id_rus.res для каждого лейбла проэкта. Пишите инструменты автоматизации.