Войти
Urho3DФорумО СОЗДАНИИ ИГРОВОГО КОНТЕНТА

Карты нормалей (софт)

#0
15:14, 14 авг. 2017

Empty Place


#1
18:05, 14 авг. 2017

для быстро сообразить нормальку через веб: http://cpetry.github.io/NormalMap-Online/ :-)

#2
15:41, 15 авг. 2017

> так как они реально грузят видюху работой и нужно обходится диффузной текстурой там где это только возможно.
radio, это всё же лет на 10 устаревшая информация - стоит иметь ввиду. Они в самом деле грузят и работают медленней чем просто диффузка, но современные видюхи имеют многократный запас мощности и вполне в состоянии рендерить не только диффуз и нормаль, но и ещё много чего, и при этом с высоким фпс.

#3
2:52, 16 авг. 2017

> обойтись диффузной текстурой без визуального ущерба
Именно БЕЗ визуального ущерба - это почти невозможно, ИМХО - разве что для каких-то дальних моделей/импостеров, к которым игрок подойти не сможет.

> Неужто, Вам некуда девать лишнюю производительность железа?
radio, там разница (в фпс) на самом деле слабо различима не то что на глаз, а даже при точных замерах... Ну разве что Вы из тех людей, для которых реально важно что вместо 500 фпс на пустой сцене с 1 кубиком у Вас будет не 500 фпс, а 470 )))

Экономить на нормалях, ИМХО, имеет смысл только в одном случае - если для всех текстур памяти не хватает и стримминга при этом нет. Но для этого надо иметь минимум сотни моделей и минимум столько же текстур, и рассчитывать что у пользователя не больше 1-1.5 Гб видео, что в наши времена уже относительно нечасто бывает (большая часть видюх сейчас - минимум 2 Гб).

#4
6:59, 16 авг. 2017

radio
Можно же LOD использовать (я вот до сих пор не умею)

#5
11:36, 16 авг. 2017

radio
> Но, может потребоватся индивидуальный подход к каждому объекту.
Ну, мы в урхе может достучаться до материала объекта и отрубить лишнее.

> Даже в одном объекте КН может быть применима только к части его полигонов, что позволит обойтись меньшим ее размером.
Приведи пример такого случая. Мне кажется, код, который будет отрубать КН для отдельных полигонов, сожрёт ресурсов больше, чем если бы шейдер один раз прошёлся. Т.е. отрубать шейдеры ситуационно, это:
1. проверять постоянно условия (или события)
2. отключать/включать материалы
И это CPU, у которого ядер в разы меньше, чем у GPU :)

> Встречал даже когда у пользователь запускал одновременно 2 игры (сворачивая одну) и парралельно еще несколько программ работали в самой системе :)
Я у себя на рабочем лаптопе (который тут ранее описывал) запускал 2 квейка3, чтобы посмотреть, как сетка работает. И у меня обычно запущено сколько-то браузеров, несколько студий, туча фаров, графический редактор и блендер.

#6
12:58, 16 авг. 2017

radio
> Никакой магии не нужно.
> Это все делается на этапе моделирования (создание развертки и текстурирования)
А, ну, то есть, просто не указывать КН для каких-то областей? А, ну да, понял, ты говоришь про оптимизацию со стороны моделирования, ага. Но даст ли это прирост производительности? Наверно, при очень строгом подходе и тщательной разработке должно дать.
Кстати, там кроме нормалей ещё emissive есть и ещё какие-то. Всего шесть их, кажется.

> Сама модель объекта может иметь лоды для которых (если правильно понял) можно указать дистанцию на которой он включается.
Ну вот я с этим не знаком пока. А хорошо бы, если так.
Даже если не так, можно просто создавать одинаковые материалы с разными LOD-ами.

#7
13:25, 16 авг. 2017

radio
> Там в 3D редакторе как-то можно указать до экспорта
А, точно, вспомнил, я вроде видел это :)

#8
16:48, 16 авг. 2017

Так если делать на уровне ЛОДов (материалов) и нет стримминга - один фиг эти нормали будут занимать память. А вычислительно, как я уже сказал - они не жрут практически ничего.
Т.е. сделать это ЛОДами можно, но будет лишь хуже батчинг и никакого выигрыша - т.е. теоретически в итоге производительность может стать даже ниже ;-)

> Но, то что карты нормалей нагружают видюху сомнений быть не может.
radio, к чему сомнения? Можно же просто сделать тесты и убедиться что разница ну уровне 0.1% будет )))

#9
22:30, 16 авг. 2017

> А на уровне лодов объектов?
radio, в причём тут ЛОД объектов, если мы говорим о картах нормалей? Каждый ЛОД - объектов, материалов, текстур и т.д. - он свои цели преследует.

> Жрут и еще как.
Ну, против такого киллер-аргумента мне сказать нечего xD

> на слабом железе и разница раза в два и больше по просаживанию fps.
Я уже выше писал - это может быть ТОЛЬКО на слабом железе, особенно с мобильными/интеловскими видюхами, ТОЛЬКО при очень больших текстурах, и и то даже в эти условиях - разница будет максимум процентов 20. И то, я даже такой разницы не наблюдал ни разу, это скорее теория...
Причём, проблема тут вообще ни разу не в вычислениях - проблема именно в текстурных выборках.

> Особенно обратите внимание как в бюджет сцены они пытаются вписыватся
radio, у ААА-проектов - там СОВСЕМ другие проблемы. Типичный объём арта у них - от десятков Гигов и больше. Естественно, там проблемы именно контента выходят на первый план. Более того - большинство из ААА оптимизируется уже изначально с расчётом на приставки (даже при том, что потом всё равно для них, приставок, обычно отдельная версия контента делается). Но, опять же - проблема именно памяти, а не выч. мощности которая тратится именно на нормали - потому что там фигня полная, всего несколько умножений и всё...

> то игра оказывается одной из самых (если не самой) анти-оптимизированной.
И это тоже нормально - проблемы работы на потоке. Нет у них возможности каждый сантиметр игровой площади вылизывать - потому что этой самой площади у них обычно квадратные километры, а иногда даже десятки/сотни квадратных километров - т.е. не то что исправить все баги, а даже просто обнаружить их, при таких объёмах - задача почти непосильная ни для кого (с учётом, что и сам контент и уровни, его использующие, меняются практически ежедневно весь процесс разработки от старта до самого релиза).

#10
22:41, 16 авг. 2017

А если Вы посмотрите на текущий пайплайн, который, как правило, PBR, то увидите, что карты нормалей в текущих движках - это вообще какой-то супер-мизер на фоне прочих вычислений (от минимум 4-5 текстур в самых-самых простейших случаях, до, иногда десятка-полутора), тонны математики и биндинга разных данных между движком и материалом, да и сам PBR-шейдер, даже в самом костыльном случае - это десятки/сотни строк кода, трансформ карты нормалей, для сравнения - одна строка. Количество строк кода, конечно же, вообще ни капли не показатель, но я думаю, глупо ожидать, что при разнице объёма кода в сотни раз - именно эта 1 строчка трансформа номралей сжирает 50% от проиводительности.

Это я уже не говорю про всякие там тесселяции, параллаксы, тени, постэффекты и прочее и прочее, которые как раз зачастую сжирают более 50% бюджета - т.е. если выкинуть не только нормали, а вообще АБСОЛЮТНО ВСЁ - даже тогда типичный игровой двиг, в котором включены куча пост-эффектов (АО, блум, блур, ДОФ, ХДР и адаптация, теселяция, лучи бога и т.д.) не станет работать в два раза быстрее ))) Разве что станет за счёт того, что тени рендерить не будет - но в тенях и так, как правило, нормали и не рендерятся и не используются вообще.

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

#11
23:06, 16 авг. 2017

> FPS соответственно 5880 — 3420 (почти в два раза)
radio, я выше писал про эту болезнь.

> Выключаю карту нормалей переходом в wire-frame режим.
И вряд ли она выключается при этом.

> А если это не один кубик, а сцена которая вся в картах нормалей?
radio, то разница будет всё меньше и меньше - т.к. начнутся существенные потери на переключениях текстур, шейдеров, IB/VB, переключение рендер-таргетов, начнёт работать куллинг и depth-тест, ошибки предсказаний в шейдерах, начнёт по полной грузить Input-Assembler вершин, переключение растер- и прочих стейтов, и так далее, а карты нормалей сколько хавали - столько и будут хавать.

Ну для примера: включить даже на этом кубике тени + SSAO - фпс упадёт до максимум 150. И при вкл/выкл карты нормалей разница будет 149 фпс vs 150 fps. В реальной же игре, которая даёт 60-90 фпс, разница даже в 1 фпс вряд ли будет.

#12
23:25, 16 авг. 2017

> Дак, Вы писали также:
radio, так я же сразу оговорился, что есть такая болезнь, когда для людей имеет заначение 900 фпс vs 800 фпс. Просто эта болезнь автоматически означает полный отрыв о реальности - потому говорить о реальности в таких случаях, по понятным причинам, не приходится. И дальше, собственно, я достаточно подробно объяснил почему именно в реальных приложениях разницы не будет.

#13
23:28, 16 авг. 2017

Т.е. если Вы планируете делать игру, которая состоит именно РОВНО из одного кубика, она не имеет АИ, физики, звука и прочих объектов - да, тут нормали будут существенным ударом по производительности и пользователь не получит так нужных ему (а нужных ли?))) 5000 фпс.
А если Вы всё же планируете делать что-то более разумное - то там начинают играть роль 100500 факторов, которые Вы на данный момент не учитываете, и которые ОЧЕНЬ существенно (в сотни раз, без преувеличений) ударяют по производительности - в итоге то, что на кубике отъедает 2000 фпс - станет отъедать максимум 1 фпс. Почему именно так произойдёт - я уже тоже написал 2 сообщениями выше.

Urho3DФорумО СОЗДАНИИ ИГРОВОГО КОНТЕНТА

Тема в архиве.