Ваша ссылка про фичелевел явно показывает, что начиная с 10 фичелевела карты спокойно поддерживают non-power-of-2. (что в общем-то покрывает буквально все десктоп карты, которые сейчас выпускают, потому что с 2008-2009 года карты с 10 фичелевелом массово пошли примерно) Про сжатие я в курсе, я поэтому и написал что "кратно 4х4 - это не совсем степень двойки". С мипами повеселее, потому что каждый мип надо сжимать bcшкой, что ведет к тому, что вроде как обе стороны текстуры должны быть степенями двойки, чтобы не напороться на кривой некратный двум ресемплинг. Но это не догма, никакого выделения "как 1024x1024" для текстуры 1000x100 не будет, у вас просто мипы начиная с какого-то индекса будут немножко кривоваты (т.к. ресемплинг их немножко размоет), но с памятью ничего плохого не случится. В целом это никак не мешает делать текстуры 2:1 (и в общем-то иногда и делают)
С материалами не так, если у вас один uobj с шейдермапой, то он один раз будет скомпилирован и собран в соответствующие psoшки. Динамик инстансы да, рвут батчинг, но никаких дополнительных шейдеров не создают (хотя тут есть подводные камни в виде того, что вендоры в лице nvidia/amd могут для некоторых uniform параметров сами делать несколько специализаций и выбирать нужные шейдера в рантайме, но это настолько под капотом, что повлиять на это толком нельзя и увидеть без профилировщиков тоже) А вот обычные material instance кстати внезапно могут добавлять новые шейдера в шейдермапу (через статик свитчи в материалах)
Про лоды и треугольники - мелкие пропсы регулярно могут быть меньше косаря треугольников. Ну т.е. возьмите какую-нибудь бочку / биллборд на заднем плане, вы при всем желании не сделаете ее больше тысячи треугольников (не, ну конечно есть умельцы, но в нормальной игре у вас такого не будет). Ну и всякая трава, но она как раз не в счет, т.к. инстансится обычно.
С quad overdraw все тоже сложнее. Во первых есть подходы на visibility buffer, которые полностью игнорят этот ваш quad overdraw (привет, нанит, но нанит не единственный такой подход, есть еще call of duty, deus ex, horizon forbidden west с похожим подходом). Во вторых, если у вас 100 полигонов покрывают квад в 2х2 пикселя, то совершенно не факт что у вас будет 100 quad overdraw. Если треугольник настолько маленький, что не покрывает центр ни одного из 4 пикселей внутри квада, растеризатор не сгенерит для этого треугольника квад, и соответственно x100 овердро не будет. Будет сильно меньше (по кваду за каждый треугольник, покрывающий центр хотя бы одного пикселя в кваде). Хотя за вертексные преобразования и растеризацию вы все равно заплатите, поэтому делать так не надо конечно.
> То есть если у вас текстура например 1000х100 то в памяти она будет занимать столько же сколько и 1024х1024. Не буду говорить за мобильные платформы, т.к. не знаю как там дела обстоят, но на десктопах это не так. Память под текстуры выделяется не квадратами (ну там есть заморочки со свиззлом и с блочной компрессией, но обычно эти блоки небольшие, не больше 4х4). Проверить можно легко, завести такую текстуру и поглядеть, что скажет мемрепорт.
> Если материал используется в двух местах - будет его две копии в памяти и он будет 2 раза загружаться Если это один и тот же материал (всмысле один uobj) - то не будет дублирования. Если там 2 разных материала с копипастнутыми графами, то тогда да, будут две шейдермапы
> Во первых, если у вас есть меши - у них должны быть лоды В рамках разумного. Ниже определенного количества вертексов лоды не имеют смысла, если меш не инстанцируется/не батчится, потому что накладные расходы на сам дроколл начинают перевешивать все остальное. На десктопах этот порог относительно большой (несколько лет назад было несколько сотен поликов, с современными картами думаю побольше, но точно не замерял. Вангую ~тысячу). С тяжелыми материалами тоже вертексная нагрузка может быть незаметна на общем фоне. Ну и нанитные меши в пятерке лод чейна тоже не требуют (хотя в целом для них тоже можно их делать, чтобы использовать на платформах без поддержки нанита)
UE 4 кто-то пишет, и среди этих людей есть программисты графики
UE 4 великолепный движок, но далеко не ультимативное решение со множеством своих проблем и закидонов.
При использовании UE4 иногда все равно есть потребность в программировании графики, написать там кастомные шейдера для игры, подправить чего-то, корректно настроить существующий рендер, пофиксить багло в рендере и т.д.
Кастомные готовые движки других студий никто не отменял, заменять их на ue4 просто так без весомых причин никто не будет.
Куча существующих игр на разных движках требуют поддержки и багофикса
Некоторые игры требуют очень кастомных рендерных решений (см. Claybook, Dreams и т.д., где даже полигонов то нету).
Разъезжание границ довольно просто объясняется, если я правильно ситуацию понял. Для визуализации brep триангулируется, если 2 тела будут триангулироваться независимо друг от друга, то точки триангуляции будут немного отличаться, даже если контачащие поверхности абсолютно одинаковые. Происходит это потому что при триангуляции вершин и ребер нужно учитывать все соседние грани, а они на разных телах разные обычно. Плюс при визуализации этой триангуляции координаты точек обычно из даблов перегоняют во флоты, т.к. gpu гораздо быстрее с флотами работает, а над просмотрщиком моделей в координатах двойной точности не заморачиваются. А флоты начинают сами по себе «дрожать» при зуме, если зазумиться тысяч в 10 раз, т.к. при таком зуме матрица проекции уже «плохая», если в одинарной точности считать.
Залепухи и прочий ремонт плохой геометрии очень хорошо работает, если хорошо понятно, где его лепить. Иногда ошибки проявляются слишком далеко от места, которое их вызвало, и автоматика не справляется. Особенно много проблем получается, если рядом с плохим куском находится какая-то мелкая деталь, тогда «плохая» топология может сожрать всю мелкоту рядом. Иногда такой результат устраивает, иногда нет.
Я согласен, что в лоб по рабочей сборке сетку строить это так себе вариант, но так делают довольно часто (ну вернее пытаются, потом ловят ошибки булевых операций/мешера, а дальше либо упрощают сборку, либо пишут в саппорт). Причин не знаю, возможно это просто быстрее для проверки каких-то внезапных идей. Но даже на простых сборках очень легко словить ошибки булевых операций из-за флотовых погрешностей, т.к. они могут сломаться даже от такой простой вещи, как попытка присоединить цилиндрическую трубу к изогнутой трубе такого же радиуса стык в стык. (потому что корректное точное нахождение пересечений цилиндра и тора почти одинаковых радиусов в арифметике с плавающей точкой тянет на докторскую, если честно)
Про сантиметры, метры и относительные размеры принципиально согласен, но все известные мне геометрические ядра работают с фиксированной минимальной абсолютной точностью (ну вернее как, есть ядра, которые внутри как черный ящик и не говорят про свою точность вообще ничего, поэтому за всех говорить не буду). На этапе мешера возможно это уже меньшую роль играет, утверждать не могу.
P.S. Основная мысль была в том, когда речь начинает идти о вычислениях с сотнями тысяч шагов, зависящими от результатов друг друга, определенно о погрешностях флотовых вычислений стоит задумываться и хотя бы пытаться прикинуть их порядок. Особенно, когда алгоритмы принимают дискретные решения на базе этих вычислений (как те же булеаны)
Имеется ввиду CFD, там общий процесс выглядит как «собрать из деталей CAD-сборки b-rep модель для анализа -> построить сетку на модели -> численный анализ на сетке» Первый этап либо делается вручную, либо отдается автоматике, которая просто мержит все активные детали в сборке. И вот уже на этом первом этапе уже можно всю точность растерять. Потом на этой модели будет строиться сетка, но какой в этом толк, если исходная модель уже со значительной погрешностью построена. Да и в принципе строить сетку на моделях, где кривые пересечения поверхностей отстоят от самих поверхностей на сантиметры — само по себе занятие не из простых. Скалирование моделей не сильно помогает, т.к. погрешность будет обусловлена постепенной потерей значащих битов в мантиссе.
Ошибки имеют свойство быстро накапливаться до таких состояний, когда игнорировать их не получается. Например, это чуть ли не основная причина, почему в CAD системах на данный момент нет по настоящему робастных булевых операций, хотя внутренняя точность самих моделей может достигать пары десятков нанометров. Реальный пример из практики — флотовые ошибки в булевых операциях приводили к тому, что при точности исходных деталей в CAD 1.0e-10 метров (ну т.е. десятая доля нанометра, никто такой точности детали даже произвести не сможет) погрешности в расчетной сетке составляли уже несколько сантиметров, что было абсолютно неприемлимо.
Тем более, если у вас вычисления на сотни тысяч операций, очень легко внезапно получить погрешность одного порядка с результатом.
Если бы одного луча на пиксель хватало для получения нормальной картинки — то да, это было бы не сильно медленнее. Но для того, чтобы результат выглядел хоть как-то приемлимо, требуются десятки лучей на пиксель, причем количество этих лучей сильно от поверхности зависит. Всякие денойзеры и разные методы сэмплирования (importance sampling вообще сейчас повсеместно применяется, например) помогают уменьшить количество требуемых для сходимости лучей до приемлимого уровня, но это все равно очень дорого. Плюс еще и любой рейтрейсинг очень недружелюбен к кэшам, т.к. лучи на соседних пикселях (да даже в пределах одного пикселя) могут пойти трейсить вообще разные части сцены. А гпушки крайне не любят плохую работу с кэшом. Растерный пайплайн гораздо больше под внутреннее железо подходит все-таки, его больше 20 лет на это затачивали.
Сейчас в общем-то плюс минус так и делают (через кубические карты + ssr), основная проблема это нормально свести запеченые отражения с реалтаймовыми так, чтобы объекты не «парили», чтобы свет совпадал, и т.д.
Конкретно у подхода «трассировать только динамику» есть как минимум одна ключевая проблема: что делать, если динамический объект частично перекрывается статическим? Например, человек стоит за деревом. Если трассировка не будет учитывать статику, то отражение человека будет выглядеть так, словно он стоит перед деревом, а не за ним.
Да, про варианты с построением вручную не подумал. Правда, если, допустим, кривые строить из какой-то cad модели, а не «из головы», то все равно придется иметь дело с нюрбсом, как минимум, для перевода в циркулярные кривые. Кады внутри ядра редко чем-то кроме nurbs и канонических кривых пользуются (иногда добавляются uv-кривые на поверхностях). По крайней мере в нескольких популярных ядрах (parasolid, granite, acis) ничего необычного не видел.
Про недостатки я скорее имел ввиду вырожденные случаи (ту же прямую) и то, что кривая за выпуклую оболочку контрольных точек выходит. Хотя nurbs с отрицательными весами тоже выходить может, если подумать.
Интересный метод для построения кривых. Правда, я не совсем понял, в чем состоит преимущество относительно rational bezier и NURBS. Конические сечения ими нормально представляются, порядок у них повышается легко, плюс есть много полезных свойств (например, легкая вставка узла в кривую без изменения ее формы для nurbs). Из статьи выглядит, что циркулярные кривые весьма неудобны для построения и обладают набором серьезных недостатков, но, возможно, есть варианты применения, где они будут удобнее того же nurbs?
Блок — это 32/64 близко расположенных пикселя. Шейдер в пределах блока выполняется в локстепе, т.е. каждая инструкция выполняется одновременно для всех элементов блока (варпы в терминологии нвидии, волны у амд). Если на ифе в пределах одного блока идет разделение внутри элементов блока, то часть потоков маскируется, выполняется условие, потом маскировка потоков инвертируется и выполняется else. Так да, выигрыша не будет. Но если весь блок целиком зашел в одну ветку (или не зашел), то ждать ничего не требуется. Плюс если речь идет о сэмплировании текстуры, то там может быть выгодно, даже если не все элементы игнорируют ветку. Причина в том, что разные пиксели читают разные пиксели текстуры. Текстурный блок собирает все запрошенные блоком пиксели в один запрос, и количество запрошенной памяти может быть разным, в зависимости от того, запрошено 32 сэмпла или 1-2.
TL;DR: Такое надо замерять, но в случае обращения к текстурам обычно очень выгодно.
Безотносительно художественной ценности, ни о каких «два-три раза» речи не идет, весь постпроцессинг в играх в худшем случае процентов 20-30 времени кадра занимает. И то, как минимум половина таких проходов нужна обязательно (тонмэппинг, генерация моушн векторов, антиалиасинг, цветокоррекция). Моушн блюр, абберация, виньетка, доф и тому подобные эффекты в сумме может быть процентов 10 времени кадра наберут от силы.
А рассматривать внимательно размытый объект в углу скорее всего действительно не будут, если можно камеру навести так, чтобы он в центре был. А в сюжетных играх вообще очень много работы уходит на то, чтобы направлять взгляд игрока туда, куда нужно дизайнеру, и тот же доф может быть вполне в этом полезен.
Откуда инфа, что это point cloud'ы? По видео больше на обычные мешлеты похоже. Когда последний раз смотрел, алгоритмы по генерации мешей из облаков были все еще недостаточно быстрые для игр (но достаточно быстрые для сигграфовских презентаций, чтобы можно было без зазрения совести добавлять слово realtime в заголовок) и давали артефакты (дырки) при приближении, но может сейчас уже дела получше стали
Раньше так и было, но сейчас количество требуемого контента для одного AAA тайтла настолько огромно, что нужно находить баланс между стоимостью производства контента и быстротой конечного результата. Яркий пример — pbr, на старой глоссовой модели без сохранения энергии можно добиться ровно такого же визуального результата, при этом работать это будет быстрее. Только время, требуемое для создания такого же количества контента будет сильно больше, потому что нужны будут разные материалы под разные условия освещения и никогда не будет гарантий, что не придется заново перенастраивать освещение на старых локациях в связи с тем, что появился какой-то новый материал, который криво выглядит на старом свете.
С запеканием освещения похожие проблемы, время итерации художников по освещению на запекаемом освещении несравнимо больше, чем при динамической системе освещения.
В остальном согласен, сама по себе физическая корректность и максимальный реализм в играх не нужны, требуется иллюзия реализма, и то не во всех играх.
Ну хайпольки таки и без текстур весят дофига. Если каждый камешек будет по 20 лямов треугольников, то будет тяжко. Это ж получается 60 миллионов индексов. В 2 байта на индекс просто так не влезем, придется либо по 4 байта на индекс, либо в мешлеты паковать (как скорее всего и делается). Но даже по 2 байта на индекс получается 120 мегабайт только на индексы. Окей, индексы хорошо жмутся, останется там скажем 20 мегабайт. Остаются вертексы. Для модели на 20 лямов треугольников хорошим показателем будет 20 лямов вертексов, у каждого 12 байт позиция, 12 байт нормаль, 8 байт текстурные координаты. Даже если в халфах хранить, все равно 16 байт в лучшем случае на вертекс, это 320 мегабайт. Как ни сжимай, все равно много выходит что-то. Может конечно ошибся в подсчетах, но все равно хранить хайпольки для всего подряд выглядит не самым разумным решением. А там еще хотят 8к текстуры использовать.
в 2 раза меньше даблов в один векторный регистр помещается, чем флотов.
А если их еще зачем-то понадобится в гпу пихать, то там до недавних пор дабловая арифметика была в 2 раза медленнее флотовой. Сейчас возможно тоже, но тут не уверен.
дорогая версия на шейдертое дает у меня на 1080ti 35 фпс на 800х400, это 30 миллисекунд чисто на облако на данном разрешении. Для геймдева бюджет на такое облако будет пара миллисекунд максимум, и разрешение должно быть выше (хотя облако в общем-то можно считать на низком разрешении и потом апскейлить). Ограниченно применять можно, но нужно долго оптимизировать и растягивать на много кадров (через репроекции с предыдущих кадров и т.д.)
Шейдеры в рантайме много где собираются (почти везде на пк в общем-то), это не эксклюзивная фича dxvk, если я правильно понимаю что имеется ввиду. Решейд, насколько мне известно, тоже не пересобирает шейдеры, он просто инжектится в процесс и добавляет дополнительные дроколлы со своими шейдерами.
Ваша ссылка про фичелевел явно показывает, что начиная с 10 фичелевела карты спокойно поддерживают non-power-of-2. (что в общем-то покрывает буквально все десктоп карты, которые сейчас выпускают, потому что с 2008-2009 года карты с 10 фичелевелом массово пошли примерно)
Про сжатие я в курсе, я поэтому и написал что "кратно 4х4 - это не совсем степень двойки". С мипами повеселее, потому что каждый мип надо сжимать bcшкой, что ведет к тому, что вроде как обе стороны текстуры должны быть степенями двойки, чтобы не напороться на кривой некратный двум ресемплинг. Но это не догма, никакого выделения "как 1024x1024" для текстуры 1000x100 не будет, у вас просто мипы начиная с какого-то индекса будут немножко кривоваты (т.к. ресемплинг их немножко размоет), но с памятью ничего плохого не случится. В целом это никак не мешает делать текстуры 2:1 (и в общем-то иногда и делают)
С материалами не так, если у вас один uobj с шейдермапой, то он один раз будет скомпилирован и собран в соответствующие psoшки. Динамик инстансы да, рвут батчинг, но никаких дополнительных шейдеров не создают (хотя тут есть подводные камни в виде того, что вендоры в лице nvidia/amd могут для некоторых uniform параметров сами делать несколько специализаций и выбирать нужные шейдера в рантайме, но это настолько под капотом, что повлиять на это толком нельзя и увидеть без профилировщиков тоже)
А вот обычные material instance кстати внезапно могут добавлять новые шейдера в шейдермапу (через статик свитчи в материалах)
Про лоды и треугольники - мелкие пропсы регулярно могут быть меньше косаря треугольников. Ну т.е. возьмите какую-нибудь бочку / биллборд на заднем плане, вы при всем желании не сделаете ее больше тысячи треугольников (не, ну конечно есть умельцы, но в нормальной игре у вас такого не будет). Ну и всякая трава, но она как раз не в счет, т.к. инстансится обычно.
С quad overdraw все тоже сложнее. Во первых есть подходы на visibility buffer, которые полностью игнорят этот ваш quad overdraw (привет, нанит, но нанит не единственный такой подход, есть еще call of duty, deus ex, horizon forbidden west с похожим подходом). Во вторых, если у вас 100 полигонов покрывают квад в 2х2 пикселя, то совершенно не факт что у вас будет 100 quad overdraw. Если треугольник настолько маленький, что не покрывает центр ни одного из 4 пикселей внутри квада, растеризатор не сгенерит для этого треугольника квад, и соответственно x100 овердро не будет. Будет сильно меньше (по кваду за каждый треугольник, покрывающий центр хотя бы одного пикселя в кваде). Хотя за вертексные преобразования и растеризацию вы все равно заплатите, поэтому делать так не надо конечно.
> То есть если у вас текстура например 1000х100 то в памяти она будет занимать столько же сколько и 1024х1024.
Не буду говорить за мобильные платформы, т.к. не знаю как там дела обстоят, но на десктопах это не так. Память под текстуры выделяется не квадратами (ну там есть заморочки со свиззлом и с блочной компрессией, но обычно эти блоки небольшие, не больше 4х4). Проверить можно легко, завести такую текстуру и поглядеть, что скажет мемрепорт.
> Если материал используется в двух местах - будет его две копии в памяти и он будет 2 раза загружаться
Если это один и тот же материал (всмысле один uobj) - то не будет дублирования. Если там 2 разных материала с копипастнутыми графами, то тогда да, будут две шейдермапы
> Во первых, если у вас есть меши - у них должны быть лоды
В рамках разумного. Ниже определенного количества вертексов лоды не имеют смысла, если меш не инстанцируется/не батчится, потому что накладные расходы на сам дроколл начинают перевешивать все остальное. На десктопах этот порог относительно большой (несколько лет назад было несколько сотен поликов, с современными картами думаю побольше, но точно не замерял. Вангую ~тысячу). С тяжелыми материалами тоже вертексная нагрузка может быть незаметна на общем фоне. Ну и нанитные меши в пятерке лод чейна тоже не требуют (хотя в целом для них тоже можно их делать, чтобы использовать на платформах без поддержки нанита)
UE 4 кто-то пишет, и среди этих людей есть программисты графики
UE 4 великолепный движок, но далеко не ультимативное решение со множеством своих проблем и закидонов.
При использовании UE4 иногда все равно есть потребность в программировании графики, написать там кастомные шейдера для игры, подправить чего-то, корректно настроить существующий рендер, пофиксить багло в рендере и т.д.
Кастомные готовые движки других студий никто не отменял, заменять их на ue4 просто так без весомых причин никто не будет.
Куча существующих игр на разных движках требуют поддержки и багофикса
Некоторые игры требуют очень кастомных рендерных решений (см. Claybook, Dreams и т.д., где даже полигонов то нету).
Залепухи и прочий ремонт плохой геометрии очень хорошо работает, если хорошо понятно, где его лепить. Иногда ошибки проявляются слишком далеко от места, которое их вызвало, и автоматика не справляется. Особенно много проблем получается, если рядом с плохим куском находится какая-то мелкая деталь, тогда «плохая» топология может сожрать всю мелкоту рядом. Иногда такой результат устраивает, иногда нет.
Про сантиметры, метры и относительные размеры принципиально согласен, но все известные мне геометрические ядра работают с фиксированной минимальной абсолютной точностью (ну вернее как, есть ядра, которые внутри как черный ящик и не говорят про свою точность вообще ничего, поэтому за всех говорить не буду). На этапе мешера возможно это уже меньшую роль играет, утверждать не могу.
P.S. Основная мысль была в том, когда речь начинает идти о вычислениях с сотнями тысяч шагов, зависящими от результатов друг друга, определенно о погрешностях флотовых вычислений стоит задумываться и хотя бы пытаться прикинуть их порядок. Особенно, когда алгоритмы принимают дискретные решения на базе этих вычислений (как те же булеаны)
Тем более, если у вас вычисления на сотни тысяч операций, очень легко внезапно получить погрешность одного порядка с результатом.
Конкретно у подхода «трассировать только динамику» есть как минимум одна ключевая проблема: что делать, если динамический объект частично перекрывается статическим? Например, человек стоит за деревом. Если трассировка не будет учитывать статику, то отражение человека будет выглядеть так, словно он стоит перед деревом, а не за ним.
fortran-lang.org
Про недостатки я скорее имел ввиду вырожденные случаи (ту же прямую) и то, что кривая за выпуклую оболочку контрольных точек выходит. Хотя nurbs с отрицательными весами тоже выходить может, если подумать.
TL;DR: Такое надо замерять, но в случае обращения к текстурам обычно очень выгодно.
А рассматривать внимательно размытый объект в углу скорее всего действительно не будут, если можно камеру навести так, чтобы он в центре был. А в сюжетных играх вообще очень много работы уходит на то, чтобы направлять взгляд игрока туда, куда нужно дизайнеру, и тот же доф может быть вполне в этом полезен.
С запеканием освещения похожие проблемы, время итерации художников по освещению на запекаемом освещении несравнимо больше, чем при динамической системе освещения.
В остальном согласен, сама по себе физическая корректность и максимальный реализм в играх не нужны, требуется иллюзия реализма, и то не во всех играх.
А если их еще зачем-то понадобится в гпу пихать, то там до недавних пор дабловая арифметика была в 2 раза медленнее флотовой. Сейчас возможно тоже, но тут не уверен.