Lex Darlog
У меня - животрепещущий вопрос: во всей игре - такая феноменальная™ запатентованная© шикарная® UV-развёртка с не менее потрясающей топологией, или это один такой экземпляр?
Минимизация швов? Реюз текстур? Оптимизация эдж-лупов? Да хотя бы - банально, ровная топология? (у основания ручки - вообще шик!)
Не, не слышали?
А потом - удивляемся, чо это у нас нынче колды по 100+ Гб весят.
Не знаю, как там у вас в блендерах, но в майе разворачивать пропсы без UVLayout (headus) или RizomUV (сам не пользовался) - себя не уважать. И если в блендере даже с плагинами такой результат - то либо моделлеру надо бы основательно так вкурить матчасть, либо - отличная анти-реклама блендера.
По играм юбиков разве не видно, что основной столп их корпоративной культуры - "а пох*й"?
Когда такой подход насквозь пронизывает разработку - ничего удивительного в сливах на сотни гигабайт. Ну и - да - если у тебя на удалёнке трудятся сотни рабов из менее благополучных стран, которых всех надо так или иначе подключать к пайплайну - суммарный траффик у компании будет такой, что и Тб на его фоне легко затеряется.
а откуда качать-то?
После того, что они там наворотили с русской локализацией - чисто из принципа хочется поднасрать.
Да с нынешними ценами на винты - не такая уж это и проблема. У меня дома стоят 1Тб + 3Тб. Купил, чтоб просто бэкапить данные.
А ты видел сорцы билда, или оцениваешь инструментарий по финальному продукту? Даже не так: по тизеру финального продукта.
Если сам прогер - то уж распарсить csv-шку (которая под это и создана) - вообще как два пальца. Если нет - то наверняка есть готовые тулы.
И куда проще - не самому разбираться с форматом всяких obj/fbx, а просто внутри какой-нибудь Майи/Гудини - прочитать csv-шку питоном и просто по одной точке построить меш самому, пользуясь уже теми командами, которые дают Майя/Гудя.
Таким образом затянуть геометрию в сцену редактора, а уже оттуда выгрузить в любой нужный формат стандартными средствами - куда как легче, чем изобретать собственный писальщик в стандартный формат файлов.
Алексей Полепчук, действительно, может, не будем понты гнуть? Хорош кидаться buzzword'ами, которые, как тебе кажется, должны произвести впечатление матёрого девелопера. Человек, который не знает, но интересуется, создаёт куда более приятное впечатление, чем тот, кто не знает, но делает вид, будто знает.
По пунктам:
1. при чём тут user generated content и формат исходников проекта? Тебе вообще понятна разница между сорцом и ассетом; ассетом в проекте и им же - в билде?
2. Каким образом участие или неучастие в ААА само по себе характеризует скилл в конкретной специальности? Что вообще эта претензия должна была значить? Сервер, что ли, прогается принципиально по-разному для какой-нить бездушной браузерки и условного ААА-онлайн проекта? Контент делается фундаментально по-другому? Для освоения мощностей ПК нужно какое-то особое мастерство, которое негде применить с немощным видеочипом телефона? Или, быть может, все разработчики проходят экспертизу какого-то Всевидящего Ока, которое всех Элитных представителей геймдева по разнарядке отправляет в ААА, а всех не-элитных - в мобилки?
3. Видеокарта не понимает джипег. Ну вот просто не понимает - и точка. Твоя "загруженная из сети" текстура всё равно должна быть преобразована в понятный устройству формат. dds, etc, pvrtc - знакомые названия? Либо - текстуру для отрисовки придётся распаковать в вообще несжатый truecolor адского веса... что, по сути, тоже есть преобразование в "понятный видюхе формат", но при этом беспощадно разбазаривая видеопамять. Жопеги, без конвертации - могут быть отрисованы только таким образом.
Если ты имел в виду стримминг текстур прям из сети - то:
а) именно в качестве стримминга (а не пред-загрузки бандлом) и именно из сети (а не с жётского диска) - это очень плохая идея.
б) даже если стримятся - они всё равно сжаты в формат целевой платформы. А зачастую - ещё и перепакованы в какой-нить индексированный архив для быстрого доступа.
4. Есть такая концепция, как non-destructive editing. По-хорошему, она предполагает linear workflow (вся обработка производится строго в линейном цветовом пространстве) в 16/32-битном float'е. Но этого даже фотошоп не умеет. Поэтому как самый минимум - мы хотя бы не поганим 8-битное изображение сжатием при каждом пересохранении. Исходник храним в psd, слоями. А в игру - выкидываем png, чтоб максимально снизить число рекомпрессий с потерями - до одной-единственной, в самом конце, в формат видеокарты.
Поправка: (нужно) в форматах со сжатием, но без потерь (lossless). То есть - да, PNG.
Если нужно 16/32-битные (на канал) тру-float данные и ты/студия в состоянии придумать свой энкодер, чтоб запихать текстуры в форматы, понятные видюхе - то EXR.
За жопеги, сданные в проект - художников бьют по рукам молотком.
Юнити (как, полагаю, и унрыл) - в любом случае пережимает текстуры под формат целевой платформы (который у каждой платформы - свой). Так что сдавать, а, тем более, править текстуры в жопеге - верный способ засрать качество просто на ровном месте.
Сам тоже на d9vk вышел. Поколупался с ним. Завёл на винде. Поколупаться пришлось знатно - но только из-за того, что проклятая нвидия опять чо-то незаметно поломала у себя в дровах (на сей раз - в вулканских).
Про плагины - хз, но у него ж есть апи для питона: зачем какие-то плагины? В самом дебаггере - есть все атрибуты меша (позиция/тангенс/нормаль/увихи), которые можно просто по ПКМ сохранить в CSV-файл. А через апи это можно сделать пакетно для всех нужных мешей. Уже CSV-файл - можно чем угодно распарсить и во что угодно выгрузить. Я, вот, намеревался питоном же строить меш в Гудине (там это очень просто) и уже там его чистить.
Одна загвоздка: после нескольких часов колупаний - я так и не смог найти то место, в которое шейдеру приходят матрицы трансформаций для каждого объекта. Там в констант-регистрах - какой-то прям лютый адок: прилетает 256 непонятных float-значений в виде массива - и ломай голову, как хочешь. Учитывая, что shader disassembly там очень такой себе - может реально проще оказаться восстанавливать эти матрицы самому, через позиции вертексов в исходном меше и в clip-space.
А ты раз предложил - не в курсе, как можно отдебажить DX9-игру RenderDoc'ом? Он не может в DX9, но может в вулкан.
И есть такое вот: https://github.com/disks86/VK9
Но почему-то даже вместе с dll-ками от VK9 игра RenderDoc'ом обнаруживается как DX-овская (а не вулкановская) и, соответственно, не дебажится.
У рендердока - удобный питоновский апи, в отличие от nsight. Что очень полезно при выдёргивании контента из тыщ мелких drawCall'ов, как в ME.
То ли ты меня не понял, то ли я тебя. Судя по докам, это скорее визуальный MonoBehavior, нежели префаб.
https://docs.unrealengine.com/en-US/Resources/ContentExamples/MouseInterface/BlueprintActors/index.html
1. "Из 671 сцены" действительно хорошие - уже на второй странице чередуются со стрёмными, а на 3-ей - заканчиваются вовсе.
2. Крутой арт всегда может вытащить хилые возможности двигла. И очень странно показывать сцены, просто выдернутые из игр на source, которые делала сама Valve. Как бы, я тоже могу показать тут демки от анрыла или Unity - но какое это имеет отношение к удобству разработки/функциональности, собственно, движка?
Предпоследнее, что ты скинул - это вообще, по факту, тупо анлит. Прекрасно выполненный артово, но технически - тупо анлит. Как и все фотосканы. Это никак не характеризует "преимущества" source.
На любом движке при достаточной доработке напильником можно добиться любого уровня графики.
Вопрос только в том, насколько это из коробки, насколько удобно и насколько легко расширяемо.
У source, по всем трём пунктам - минус.
Как анрыловские префабы зовутся? Я б обновил сведения о состоянии движка.
Когда дебажил Mass Effect — делал это нвидишным дебаггером (из VS) , при чём, древней версии. ME — на DX9. Крутые современные дебаггеры, увы, только с dx11/vulkan работают.
Анрыл vs Юнька - чистой воды холивар. Базирующийся, по большому счёту, на вкусовщине.
Как там в анрыле обстоят дела с аналогом префабов? :D
С VR-ом? С мобильным билдом до 100 мб на старые девайсы с SM 2.0, и чтоб не убивал батарею?
Medusa 219, я в курсе, что такое частицы. Я говорю о том, как их можно реализовать. И что разные способы подходят для разных сценариев.
Ну неразумно их делать на проце, если система - по факту, статична.
А если делать не процом - то нужен какой-никакой, но относительно простой механизм штамповки кастомных шейдеров. Именно штамповки, чтоб каждый из них собирался по-быстрому, а не воспринимался как целый "модуль к движку".
Шейдер - это контент, а не плагин.
Эм... ты, видимо, не понял, о чём я.
Спрайты (квады, ориентированные на камеру) - можно генерить на проце. А можно - шейдером, на видюхе. В крутом случае - прям генерить (в compute-шейдере). В более простом - использовать специально подготовленный меш, у которого каждый квад сжат в центр партикла, и "разжимается" просто в vertex-шейдере, ориентируясь на камеру.
Например, стандартные юнитёвые партиклы - считаются на проце. Поэтому ими неразумно делать системы, в которых счёт идёт на десятки тысяч частиц. Особенно - если сама система статична, и просто крутится в пространстве. Но можно написать простенький шейдерок, который со специальным мешем сделает то же самое условно-бесплатно для производительности. Т.е., прям конкретно случай с Галактикой на мостике Нормандии.
Я, возможно, сгущаю краски. Но добавление шейдеров через компиляцию их в DLL ( https://developer.valvesoftware.com/wiki/Shader_authoring/Quick_Start ) и обязательное наличие обёртки с лоулевельным кодом для графического апи (имеющего отношение к state change) как необходимой части шейдера, без которой ничего работать не будет ( https://developer.valvesoftware.com/wiki/Source_SDK_2013:_Your_First_Shader ), без наличия хоть какого-то визуального редактора - это, простите, адок.
Юнька тоже недружелюбна к эффектам в том смысле, что визуальный редактор шейдеров там появился вот только-только. Но это многие годы компенсировалось тем, что там шейдеры писать руками - в принципе довольно просто.
Если тебе для расширения инструментария необходимо сразу бухаться в максимально лоу-левельный код, при чём весь этот код - boilerplate и строго engine-specific, но таки требует обязательных мелких твиков в отдельных местах, да ещё и нуждается в ручной компиляции при любом обновлении - это значит лишь одно:
данная модель расширения - плохая.
Просто плохая, безо всяких "но".
Код на плюсах, если что, и в UE пишется. Плюсы сами по себе - не показатель неудобства.
Троллинг засчитан.
Понятно, что в базовом сценарии - затянуть можно. И я видел, например, модельку Тардис, над которой человек явно старался. ( https://steamcommunity.com/sharedfiles/filedetails/?id=966495722 )
Но ровно так же и видно, что несмотря на старания, побороть ограничения Сорса - ему не удалось.
Ну невозможно без кастомных шейдеров и современного инструментария для работы со светом сделать что-то приличное. Надо хотя бы каких-то красивых процедурных анимаций на фон, который будет придавать живости, но при этом не ждать fps. Хотя бы мигающие экраны, псевдо-волюметрики вокруг лампочек, переливающиеся звёзды... да и вообще партиклы звёзд на мостике. Их, если что, гораздо быстрее превращать из точек в спрайты именно шейдером.
Как безотказное средство - есть графический дебаггер. Выдирающий модельки прямо из графического апи.
Сам ассет, со скелетом и анимацией - им не выдрать. Но зато всё, что отрисовывается на твоём экране - может быть выдернуто хотя бы в статичном виде.
1. UE - развивается, про UE тут нигде даже упоминания не было. А если б и было - то только в качестве положительного примера.
2. А ты лично - работал с Frostbite? А с Luminous? А c REDengine? Простым смертным пощупать инхаузное двигло не удастся. Но по той инфе, которая просачивается из каких-нибудь докладов на GDC, понятно, что с точки зрения инструментария/юзабилити - в них всё прям очень плохо.
CDPR в таком докладе как-то хвалилась тем, какой у них великолепный тулсет для поиска человеческих ошибок в проекте. В качестве примера - привела лампочку, которую какой-то дизайнер случайно поставил в тестовой комнатке глубоко под картой, и она при этом "освещала" всю карту, чем садила FPS. И модельку курицы, которую так же сложили в какое-то ведро, а она весила какие-то неадекватные сотни тыщ полигонов. Они там гордо показывали таблички, иллюстрирующие, как же замечательно этот тул позволяет искать подобное по базе данных объектов... Вот только это значит, что допустить такую ошибку там - легче лёгкого. А выловить без подобного поиска по БД - практически невозможно.
Когда их художники, расхваливая дополнение "кровь и вино", с помпой хвастались тем, как же тщательно они оптимизировали контент - они случайно проболтались и описали, что, по сути, они впервые заатласировали текстуры всякой растительности. Это значит, что раньше они этого не делали. Это значит, что в оригинальной игре - всё прям очень плохо с батчингом.
Уверен, это не единственный фактор - но именно из таких вот факторов и сложилась производительность 3-го Ведьмака.
Человек пришёл из Unity, нормально ориентируется в Maya/Nuke/Houdini, спокойно относится к написанию собственных инструментов, но офигевает от того, какими инструментами valve предлагает пользоваться для вроде как инновационной технологии. SteamVR - активно партнёрится с HTC Vive, который преподносится как хай-энд от мира VR.
Но при этом девелоперам предлагается пилить нативные для SteamVR штуки на кое-как перепиленном инструментарии конца девяностых-начала нулевых.
Это как если бы Google, продвигая расширения для chrome, изобрела для них собственный язык на основе Pascal и предлагала писать их... в блокноте, потому что нормальной IDE - просто не выпустила.
Если Valve хочет, чтоб люди на голом энтузиазме заполняли её библиотеку "мастерской" - то мне решительно неясно, зачем заставлять таких людей пользоваться только Source'ом. Заведомо зная, насколько он куцый.
Действительно. Мой косяк. В потоке офигевания таки проморгал.
Что не отменяет, например, того факта, что хоть в сколько-то адекватные сроки - не получится просто взять и пустить одну текстуру скроллиться поверх другой.
Ещё более странно — работать с системой менеджмента ассетов, которая без танцев с бубном не допускает даже банального переименования файлов.
Я понимаю, что на это всегда можно ответить: "а тебе не нужно переименовывать, именуй сразу правильно". Но — камон — это же парадигма: "юзер должен подстраиваться под машину". От которой в современных движках — уже лет 10 как всеми силами пытаются уйти.
Я не уловил, каким образом использование гита должно решить проблему линковки ассетов по их путям, вместо id-шников из внутренней БД ассетов?
Называется "steam"
Технические подробности до банального просты:
с одной стороны, заранее подготовленными анимациямми поведение члена корректно не передать - потому что, как и указано мельком в статье, невозможно учесть все возможные конфигурации тела персонажа, не говоря уж об окружении.
С другой - симуляция члена по физике - это гремучая смесь из софтбоди-динамики, мускульных деформаций со скольжением кожи, физики волос (и нет, я не о тех волосах, о которых ты подумал: само базовое поведение члена первоначально легче всего аппроксимировать, считая его по физике волоса/верёвки), да ещё и с рассчётом коллизий, т.к. рядом болтаются два шарика, с которыми гарантированно будут взаимодействия.
Это может показаться шуткой, но в плане воплощения в 3D - МПХ - это вторая по сложности часть человеческого тела. Первая - лицо. Третья - область подмышек (из-за хитросплетения мышц и того же злосчастного скольжения и сжатия-растяжения кожи).
Женская же грудь - напротив, симулится элементарно. Это только софтбоди-динамика, которая конкретно в играх почти безупречно аппроксимируется рассчётом тканей.
Устройство софта побуждает пользователя к определённым привычкам. Так, легендарное стремление максистов всё делать через булианы - притча во языцех. А потом они приходят из своего архивиза в геймдев - и делают большие круглые глаза, не понимая, "а чо не так-то".
Так и тут. Я не пользуюсь блендером сам. Слышал, что вроде как там хороший моделлинг. Уж точно лучше, чем в майе, даже с новыми тулсетами. Вроде, даже лучше, чем в максе. Но я также слышал, что этот пакет - очень специфический, и в нём нет массы вещей, стандартных для всей остальной индустрии. Такие вот making-of'ы - отличный анти-шоукейз. Потому как - неясно: это у моделлера руки кривоваты (или же просто маловато опыта, а ТА не дал за такое по шапке), либо же - это в принципе типовой результат на выходе из блендера. Для мувиков - на это насрать. Но вот для геймдева - это явный минус.
Потому я и написал, что не знаю, но выглядит это - в любом случае, отталкивающе. В Майе всё дефолтное для работы с уви - тоже беспросветный мрак. Но это ж никто и не использует. Все поголовно используют либо UVLayout, либо - RizomUV.