Тёмная тема
- innuendo
- Постоялец
Demiurg-HG
> И такой layout используется в UE4.
> RGBA16F — Emission RGB
Cомнитения меня терзают ...
> Проверено: из всех возможных — этот способ самый быстрый.
Ну кеширование стейтов не проблема же. Спорим, что не сильно ускорится после внедрения кеширования ? :)
Demiurg-HG
> Это стресс-тест, кроме всего прочего. Я мог бы слить все меши в один, но как известно, такого в реалии не бывает: в реалии будет куча разных мешей.
Так не бывало, когда под DirectX9 программировали. А сейчас очень даже есть смысл, ибо есть DrawIndexed и DrawIndexedInstanced у которых появились StartIndexLocation, BaseVertexLocation, StartInstanceLocation.
> Проверено: из всех возможных — этот способ самый быстрый.
Плохо проверял. Быстрее будет залить трансформации в один буфер, а потом VSSetConstantBuffers1 с pFirstConstant
> И такой layout используется в UE4.
Эмиссив в RGBA16f, а нормальки в RGBA? Не верю. Ни один программист в здарвом уме не будет так делать. Как минимум если абасраца как очень хочется отдельный эмиссив и в HDR - то берем RGBA, в альфу пишем множитель и получаем FFFF градаций интенсивности эмиссива. А самый адекватный вариант - покрасить эмиссив сразу в дифузку, а например в альфу у дифузки записать множитель, ибо вкладом дифузки в этом случае можно пренебречь.
А вот нормальками пренебрегать нельзя, ибо потом ползут ужасные градиенты на гладких поверхностях.
MrShoor
> а нормальки в RGBA? Не верю.
Он же поправился - нормали в RGB10A2
innuendo
> Он же поправился - нормали в RGB10A2
Ага, стало лучше ровно в 4 раза.
MrShoor
> Так не бывало, когда под DirectX9 программировали.
Поясни, не смог расшифровать.
MrShoor
> А сейчас очень даже есть смысл, ибо есть DrawIndexed и DrawIndexedInstanced у
> которых появились StartIndexLocation, BaseVertexLocation,
> StartInstanceLocation.
Все это было и в D3D 9 (кроме StartInstanceLocation).
Использовать инстансы и буферы массивов трансформаций — хороший способ, ни кто не спорит.
MrShoor
> Плохо проверял. Быстрее будет залить трансформации в один буфер, а потом
> VSSetConstantBuffers1 с pFirstConstant
Что-то ты не в ту степь.
У меня сейчас делается так (самый быстрый способ обновить буфер):
DeviceContext.MapSubresource( buffer, 0, MapMode.WriteDiscard, D3D11.MapFlags.None );
Другой вариант, который работает с константыми буферами:
DeviceContext.UpdateSubresource( ref data, buffer );
Все остальные варианты либо не работают, либо сильно медленнее.
MrShoor
> Плохо проверял. Быстрее будет залить трансформации в один буфер, а потом
> VSSetConstantBuffers1 с pFirstConstant
Возможно, но я предпочитаю оставаться в рамках D3D11.
MrShoor
> Эмиссив в RGBA16f, а нормальки в RGBA? Не верю. Ни один программист в здарвом
> уме не будет так делать.
В emissive можно еще пропихнуть отражение и еще кучу всяких полезных вещей, rim light например.
А нормали можно запаковать так, что даже в RGBA8 они будут отлично смотреться. См. презентации Крайтека про Cyrsis 2.
MrShoor
> ибо вкладом дифузки в этом случае можно пренебречь.
...и получить убогую картинку. Короче, в общем случае пренебрегать нельзя.
MrShoor
> А вот нормальками пренебрегать нельзя, ибо потом ползут ужасные градиенты на
> гладких поверхностях.
В Crysis 3 вообще записали нормаль в RG8, и ничего, живут как-то.
Если надо сжать буфер по самое не могу, то надо использовать сhroma subsampling.
В таком случае можно Diffuse Color + Specular Color + Roughness + Normal + HDR Emissive закодировать в три 32-битных MRT, и еще 8+2 бита останется.
Demiurg-HG
Все все все. Сдаюсь, все аргументы бетон, у тебя все замечательно.
MrShoor
> Все все все. Сдаюсь, все аргументы бетон, у тебя все замечательно.
Ты еще что-то про шейдер хотел сказать ;)
Demiurg-HG
> А нормали можно запаковать так, что даже в RGBA8 они будут отлично смотреться.
> С
А в RGB10A2 они плохо смотрятся ?
У меня по теме вопрос возник..
Там нужно чтобы тени были все рассчитаны до запуска CS
можно отправлять туда наверное лайты видимые в кадре - а не все..
Но всё равно чо с тенями делать - все эти демы с 1024 лайтами - там тени бросаются не от всех... А Если у меня тени бросятся от 128 лайтов - грубо! , это получается какого размера должен быть шадовмап атлас или текс. массив (причем максимум лееров надо еще смотреть, чтобы видео поддерживало - а на разных видео - он может быть разным) и сколько занимать это всё будет.....
Еще -
в классич теме вовлекались depthbounds + scissor test по каждому лайту... Здесь получается всё это не нужно
Смотрел дему от ати - там всё., но я еще не понял - зачем они мешают MSAA с этим всем.. Почему нельзя поссчитать без него, а потом поспроцессом сгладить - типа FXAA.
То есть тупо захотелось им сделать путь шейдерный для MSAA & not-msaa
У меня сейчас просто-деффердная техника - вот думаю - стоит её убирать или нет, ибо страх с шадовмапами пугает..
Таргет железо - модерн
The Andreyp
>А Если у меня тени бросятся от 128 лайтов - грубо
то лучше бы их запечь
или вот: http://www.cse.chalmers.se/~olaolss/get_file.php?filename=s2015_shadows.pdf
но как по мне, эффективность всего этого сомнительная
> Почему нельзя поссчитать без него, а потом поспроцессом сгладить - типа FXAA.
потому что FXAA выглядит убого
Mr F
> > Почему нельзя поссчитать без него, а потом поспроцессом сгладить - типа FXAA.
> потому что FXAA выглядит убого
Ну так дело же не в самом FXAA.
The Andreyp
> зачем они мешают MSAA с этим всем.. Почему нельзя поссчитать без
Потеряется инфа о освещении каждого семпла же
Тема в архиве.