Войти
ПрограммированиеФорумГрафика

Тест видимости. (2 стр)

Страницы: 1 2 3 4 5 6 Следующая »
#15
17:44, 28 апр. 2021

Mirrel
> разбей этот домик ещё на "кубики", либо в зависимости от расстояния на большее-меньшее кол-во (если это возможно), либо просто на несколько "кубиков", а потом рассматривай только те "кубики" которые попали в кадр.

Ну я примерно так и собираюсь действовать, только мне не нужна высокая точность. Это делается для устранения рендера миллионов полигонов если они все равно закрыты ближайшей стеной. Меня вполне устраивает аппроксимация здания одним кубиком ну или 3-4 если это каскадный небоскреб. Для устранения мелких огрехов можно делать этот кубик немного меньше чем реальная фигура, это практически уберет эффект про который писал MrShoor.
Сейчас я смотрю как это проще всего реализовать.


#16
17:52, 28 апр. 2021

san
А ты вообще проверял поможет ли тебе occlusion culling? Вроде говорил у тебя есть момент, когда камера сразу весь город охватывает, там ведь все видно будет.

#17
18:03, 28 апр. 2021

san
> Сейчас я смотрю как это проще всего реализовать.

самое простое это предикаты

#18
18:40, 28 апр. 2021

phridrich
> Вроде говорил у тебя есть момент, когда камера сразу весь город охватывает, там ведь все видно будет
Тут есть один нюанс - весь город виден когда камера взлетает выше домов, а на таком расстоянии рендерятся уже не исходные обьекты а низкополигональные лоды, по сути те же кубики. Мне такое отсечение нужно когда персонаж на уровне 2-3 этажа смотрит вдаль. В этом случае вид закрывают другие здания, но за ними еще есть много таких же и они еще сравнительно близко. Я не хочу плодить иерархию лодов а ограничиться одним на уровне кубика. Сами то здания простые, но вот окна и всякие карнизы, они очень тяжёлые, поскольку камера может подлетать близко к домам, текстурами там не обойтись. Реально карта AMD R9 Nano (самая слабая из моих, на уровне 970) уверенно тянет только миллион треугольников, а у меня сейчас порядка 5-6.

#19
19:18, 28 апр. 2021

san
"Сколько треугольников тянет" - это глупая метрика. Чтоб ты понимал, в твоей R9 Nano 4 растеризатора, обрабатывающих по треугольнику за такт на частоте 1 GHz (инфа отсюда). Итого она может обрабатывать 4 * 10e9 треугольников в секунду, или, иными словами, при целевом ФПС = 100 она "тянет 40 миллионов треугольников". Но на практике ты это значения вряд ли получишь, потому что ты ведь хочешь растеризировать их со сложными шейдерами, которые нагружают вычислительные устройства видеокарты гораздо сильнее, чем геометрия нагружает растеризаторы.
Occlusion culling - это непростая тема, в твоем случае может быть проще чем обычно, но все равно будут сложности. К тому же, от него не всегда бывает польза (хотя в твоем случае может и будет). Поэтому, прежде чем за него браться, лучше посмотреть как можно оптимизировать сам рендер треугольников. Например,
1) если у тебя forward rendering с тяжелым освещением - сделай deferred.
2) убедись что у тебя объекты рисуются внутри одного render pass'а.
3) сделай отрисовку через MDI.
4) попробуй отправлять объекты на рендер, отсортировав их в порядке возрастания расстояния до камеры.
Но перед этим всем, естественно, нужно запустить приложение на таргет железе и выяснить, а нужно ли вообще заниматься оптимизацией.

#20
19:31, 28 апр. 2021

phridrich
вы уверены что ТС задает вопрос из желания оптимизировать?

мне в свое время прямо такая штука нужна была для определения можно ли взаимодействиовать с объектом.

#21
(Правка: 21:00) 20:13, 28 апр. 2021

phridrich
> "Сколько треугольников тянет" - это глупая метрика. Чтоб ты понимал, в твоей R9 Nano 4 растеризатора, обрабатывающих по треугольнику за такт на частоте 1 GHz (инфа отсюда). Итого она может обрабатывать 4 * 10e9 треугольников в секунду, или, иными словами, при целевом ФПС = 100 она "тянет 40 миллионов треугольников".

Я не карту тестирую для рекламного проспекта, я говорю про то, на что она способна в моем конкретном случае. У меня на рендер сцены 6 миллионов треугольников на этой карте уходит примерно 10 мс. Т.е. на два глаза - 20 мс.  Это вылазит за 11 мс которые требуются для VR. Сортировку и фрустум кулинг я делаю, эти цифры уже с их учетом. Теперь нужно попробовать как-то уменьшить количество обрабатываемой геометрии, чем я и занимаюсь. На другой моей карте - Titan V все разумеется работает нормально, но мне нужно пройти верификацию Окулус, а там требование - 90 фпс на 970. Во всех режимах. Для двух глаз, как я сказал, т.е. это 180 фпс в пересчете на обычный экран.

Просто чтоб понятней было - вот домик:

house | Тест видимости.

Как можно заметить там 238 тысяч трианглов. Хотя по сути это кубик из 12 треугольников.
Таких домиков у меня будет под тысячу, не все конечно такие сложные, большинство намного проще, но и в простых 10-20.000 трианглов. В основном из-за окон.

#22
20:57, 28 апр. 2021

san
На что карта способна - определяется не только конкретным случаем, а еще и твоей реализацией. Вот она способна отрисовать тебе сцену за 10 мс, а вот ты делаешь deferred и MDI, и она уже внезапно способна за 5 мс, например. Причем эти оптимизации работают не только тогда, когда у тебя много геометрии закрыто, а вообще всегда, поэтому они в приоритете.
С occlusion culling'ом тебя тебя ждет достаточно увлекательное приключение. Хорошая статья на Interplay of Light, которую ты скинул, можно делать по ней. И там кстати MDI делается :)
От себя отмечу, что отставание глубины на 1 кадр (то есть брать результирующую глубину с предыдущего кадра и использовать для теста видимости) - это плохая идея если у тебя камера хоть немного двигается, так как ты почти гарантированно столкнешься с невидимостью объектов, которые не были видны на прошлом кадре, но стали видны на текущем. Так что придется для каждого объекта делать окклюдер-геометрию и растеризировать ее в отдельный таргет, и потом его использовать для теста видимости. И эта окклюдер геометрия - это не AABB объекта, это AABB, вписанный в объект (то есть его объем является подмножеством объема объекта), и я не уверен, что его можно посчитать автоматически, возможно придется делать их вручную для всех твоих домиков. Единственная хорошая новость - для прямоугольных зданий такие окклюдеры будут близки к самой геометрии, и в эффективности occlusion'а ты не сильно потеряешь.
Ну, и конечно ты можешь вместо окклюдеров повозиться с репроекцией глубины с прошлого кадра на текущий, но это еще сложнее будет.

#23
(Правка: 21:18) 21:07, 28 апр. 2021

phridrich
> С occlusion culling'ом тебя тебя ждет достаточно увлекательное приключение.
Ты знаешь, после того, как я умудрился пройти верификацию у Окулус с аппликацией которая генерировала 3D фракталы в реальном времени, я уже могу ничего не бояться. :)  По моему хуже задачи вообще невозможно придумать. Попробуй заставить аппликацию выдавать обновление экрана каждые 11 мс (а сцена непростая - с зеркалами, стеклом и т.п.) когда фоном крутится тред который на той же карте считает очень тяжелый шейдер который выполняется 100 мс и жрет все ресурсы.  Так что трудности меня не пугают, просто хотелось бы решить задачу малой кровью, а то там еще других проблем хватает.

P.S. На DX12 рендеринг практически всегда deferred. Там все команды записываются в очередь которая потом одним чохом выполняется. Другое дело что таких очередей может быть несколько, но это уже для специальных применений.

#24
(Правка: 21:43) 21:42, 28 апр. 2021

san
Во-первых, я бы не рекомендовал тебе раздувать эго и легкомысленно относится к нетривиальной задаче лишь потому что ты справился с другой нетривиальной задачей. Целесообразность гордости за практически нечитаемый код дубового реймаршинга, выполняющийся за 100мс, оставим за кадром, но завышенная самооценка - это всегда плохо, знаю по себе.
Во-вторых - я ведь по сути тебе и предлагаю начать с самой малой крови. Occlusion culling - это сложно (опять знаю по себе), сделать MDI и deferred намного легче.

По модельке - ну тут надо лоды с normal/parallax маппингами. Правда, тогда над артом надо поработать.

P. S. OMG, да не этот deferred.
Deferred shading

#25
23:33, 28 апр. 2021

phridrich
> Целесообразность гордости за практически нечитаемый код дубового реймаршинга, выполняющийся за 100мс, оставим за кадром, но завышенная самооценка - это всегда плохо,

Я конечно ценю помощь, но оставь менторский тон пожалуйста. Я не знаю на чем основано твое мнение о "практически нечитаемом коде дубового реймаршинга" но подозреваю что ты не видел ни самой аппликации ни тем более кода. А попытки сразу обосрать что-то не имея информации говорит скорее о ТВОЕЙ завышенной самооценке или просто незрелости. Подобное махание шашкой в сочетании с изречением банальностей выглядит по крайней мере неумно. Подозреваю что мой стаж программиста превышает твой возраст. То, что "это сложно, знаю по себе" значит только что данная задача превышала твою квалификацию в тот момент только и всего. Ну и пока кроме тривиальных вещей ты ничего полезного не сообщил.

#26
0:59, 29 апр. 2021

san
Ты мне скидывал шейдеры свои, не помнишь? :)
Я не говорю, что ты сделал какую-то каку, маршинг фракталов есть маршинг фракталов, но учитывая твой вроде как огромный опыт, я ожидал более качественный код и более замысловатый алгоритм маршинга.
> Подозреваю что мой стаж программиста превышает твой возраст.
Только проблема в том, что с этим стажем ты застрял в начале двухтысячных и до сих пор оперируешь понятиями типа "видеокарта тянет N треугольников".
> Ну и пока кроме тривиальных вещей ты ничего полезного не сообщил.
Я предложил реальные пути оптимизации рендера (deferred shading, MDI, мутки с render pass'ом), ты рассказываешь, что у тебя видеокарта не тянет. Я делал occlusion culling для production-ready проекта и рассказываю тонкости реализации, ты про него задаешь вопросы на форуме. Не видишь ничего полезного - значит не видишь, дело твое.

#27
(Правка: 6:09) 2:09, 29 апр. 2021

phridrich
>Я предложил реальные пути оптимизации рендера (deferred shading
Блин, да причем тут "deferred shading", речь идет о работе вертексного шейдера! Нет у меня пока вообще никакого ни лайтинга ни шейдинга.

>я ожидал более качественный код и более замысловатый алгоритм маршинга.
Если ты не разобрался в шейдере то это твои проблемы. Аппликация о которой я упомянул (Fractal Alchemist) вообще-то предназначена для того, что бы шейдер составлял сам юзер из готовых блоков. Алгоритм маршинга при рендере 3D фракталов вообще стандартный - с адаптивным шагом. Весь цикл рендера состоит из десяти строк. Ничего более "замысловатого" там придумывать нет нужды и никто этим не занимается.
Потом говорил я не о фракталах, а о стабильном (без замираний) рендере сложной сцены при одновременной полной загрузке карты крайне тяжелым компьют шейдером. Вот это задача действительно нетривиальная. Ты нигде не найдешь информации как перераспределять ресурсы GPU на стороне аппликации не залезая в драйвер (а туда тебя никто не пустит). Мне в конце концов удалось решить эту проблему, но упомянул я об этом с самоиронией, потому и смайлик поставил. Ты видимо это не понял.

>Я делал occlusion culling для production-ready проекта и рассказываю тонкости реализаци
Где эти "тонкости реализации", не покажешь в каком сообщении ты их раскрываешь? Все что ты написал в 22 посте достаточно очевидно и на тонкости реализации не тянет. Я сам предложил довольно простой алгоритм, там и тонкостей никаких нет. Народ дал ссылки на пару других решений, одно из них с мипами в депт текстуре, второе на предикатах. Ты же с завидным постоянством толкаешь модель освещения которая тут вообще ни к селу ни к городу.

>до сих пор оперируешь понятиями типа "видеокарта тянет N треугольников".
Видишь ли, если у меня на одной карте при выводе статической сцены из 5 миллионов треугольников (где нет никакого освещения, теней, физики и прочих прибамбасов) рендер вылазит за 11 мс, а та же сцена но урезанная до 1 миллиона треугольников выполняется за 6 мс, то это значит "карта не тянет такое количество треугольников", поскольку ничего кроме треугольников там нет. Какими бы "понятиями" я не "оперировал". Для VR выход за 11 мс это "карта не тянет". Такая аппликация бракуется на стадии верификации.

#28
8:49, 29 апр. 2021

san
> Нет у меня пока вообще никакого ни лайтинга ни шейдинга.
san
> сцены из 5 миллионов треугольников

...

#29
10:19, 29 апр. 2021

san
> Подозреваю что мой стаж программиста превышает твой возраст. То, что "это
> сложно, знаю по себе" значит только что данная задача превышала твою
> квалификацию в тот момент только и всего. Ну и пока кроме тривиальных вещей ты
> ничего полезного не сообщил.
Стаж то у тебя огого, уже наверное каждый знает об этом (даже тот, кто на геймдев не заходит и к геймдеву отношения никакого не имеет). Вот только банальные вещи типа что такое octree приходится разжевывать. Координаты мыши в луч перевести через обратную матрицу не можешь. Что такое оклюжн куллинг - не знаешь.
Так что по вопросам, которые ты тут задаешь я на вскиду дам стаж года 3 реальной разработки. Переходный этап между джуном и мидлом. Но самомнение у тебя конечно огого, у меня такого и через 10 лет не будет.

> Видишь ли, если у меня на одной карте при выводе статической сцены из 5
> миллионов треугольников (где нет никакого освещения, теней, физики и прочих
> прибамбасов) рендер вылазит за 11 мс
А вот скинь если не сложно свою модельку города (обещаю не распространять нигде). Мне просто дико интересно сколько у меня получится мс на вывод этих 5 миллионов. У меня есть стойкое чувство, что с 5 миллионами я уложусь в 11мс.

Страницы: 1 2 3 4 5 6 Следующая »
ПрограммированиеФорумГрафика