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

Software rendering - occlusion culling (3 стр)

Страницы: 1 2 3 4 5 Следующая »
#30
15:54, 16 сен. 2014

погодите, я правильно понял, что тред существует фактически из-за этой строчки?

Mephisto std
> Пайплайн движка таков, что очень тяжко отдельно отрисовывать сцену. Увышечки.

то есть из-за того, что орхетектура не даёт рендерить в offscreen buffer ты пишешь софтварный растеризатор? нормально всё?

далее ты называешь деревья оклюдерами. но у них же ветки, между веток видны другие объекты. дерево никогда не закрывает другое дерево на 100%, каков профит от такого оклюжена?


#31
16:11, 16 сен. 2014

Suslik
> погодите, я правильно понял, что тред существует фактически из-за этой строчки?
Нет, не правильно. Задача нужная и полезная.
Если не знаешь, зачем нужен software rendering for occlusion culling - ознакомься с сабжем, его
используют очень многие топовые движки

>то есть из-за того, что орхетектура не даёт рендерить в offscreen buffer ты пишешь софтварный растеризатор? нормально всё?
софтварный растеризатор работает в параллельном потоке и для низкого разрешения будет работать (и работает в том же Cryengine и куче других движков)
замечательно быстро

>далее ты называешь деревья оклюдерами. но у них же ветки, между веток видны другие объекты. дерево никогда не закрывает другое дерево на 100%, каков профит от такого оклюжена?
Деревья являются очень хорошим окклюдером, если их много. У меня их много.
Представь лес из 150к деревьев, на который камера смотрит с высоты человеческого роста. Что, все 149.5к деревьев будут просвечивать через остальные?
Но нужно не только для этого, лес также окклюдится террейном, объектами (например, огромной крепостью) и т.п.

то что тебе до сих пор был не нужен софтварный растеризатор еще не значит что он не нужен никому =)

#32
16:54, 16 сен. 2014

Mephisto std
> Что, все 149.5к деревьев будут просвечивать через остальные?
Да ну наф, такое решалось обычно билбордами и инстансингом, но не как твоим методам.
Вот ежели горы, дома и холмы в качестве оклудеров, тогда да.

#33
18:08, 16 сен. 2014

TheGrayWolf
> > Что, все 149.5к деревьев будут просвечивать через остальные?
> Да ну наф, такое решалось обычно билбордами и инстансингом, но не как твоим
> методам.
биллборды и инстансинг тоже присутствуют
Но все равно для достижения приличного качества картинки дистанция до биллбордов довольно высока,
и в эту дистанцию успешно влезают несколько тысяч деревьев

#34
18:39, 16 сен. 2014

ТС предлогает софтварно отрендерить сцену чтобы определить какие объекты следует отправить на рендер в видюху ?

#35
18:44, 16 сен. 2014

wawan
да, софтварно отрендерить ббоксы, сравинвая с z-bufferом предыдущего кадра, с репроекцией на текущую камеру

#36
5:45, 17 сен. 2014

Mephisto std
> Деревья являются очень хорошим окклюдером, если их много. У меня их много.
рука-лицо, что тут скажеш, если учесть что часто листва сделана как текстура с альфаканалом, то придется еще и сэмплить текстуру в растеризаторе,
ню-ню.

>Представь лес из 150к деревьев, на который камера смотрит с высоты человеческого роста. Что, все 149.5к деревьев будут просвечивать через остальные?
для леса важен правильный лод и инстансинг, нафига оклудить дерево которое на дальности 100м рисуется как 2 триангла, дороже получается, проще сбатчить и пачкой нарисовать сразу несколько сотен или тысяч.
если окклудить так сразу группами, темболее что для frustum culling & rendering так и так применяется spatial partition, теже grids хотябы, вот ячейки можно оклудить.

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

#37
9:21, 17 сен. 2014

Outlaw
плюсую.
НО! OC тоже нужен, но не для всей сцены!!
просто нужно выбирать правильно объекты для отсечения остальных объектов.
пускай это будут какие-то очень большие, не прозрачные объекты(холмы, большие здания, и т.д.).
таким образом можно будет по-любому получить нехилую оптимизацию.
А отсекать другие объекты так:
проецируем вершины AABB в проекционную плоскость, сравниваем глубину с буфером глубины, полученным ранее при софтварной растеризации больших объектов(или близкостоящих) и отрезаем, если весь aabb дальше буфера глубины.

#38
10:40, 17 сен. 2014

Outlaw
> рука-лицо, что тут скажеш, если учесть что часто листва сделана как текстура с альфаканалом, то придется еще и сэмплить текстуру в растеризаторе,
Лолка. Рендерить на окклюжен я буду только баундинг боксы. Сперва подумай, а потом пиши =) нахрена мне альфа в растеризаторе?

> нафига оклудить дерево которое на дальности 100м рисуется как 2 триангла
На 100м дерево - уже биллборд? Говно картинка.
Выкручивать лоды - это не метод. А то эдак можно вообще к хексену вернуться.

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

Void12
> А отсекать другие объекты так:
> проецируем вершины AABB в проекционную плоскость, сравниваем глубину с буфером глубины, полученным ранее при софтварной растеризации больших объектов(или близкостоящих) и отрезаем, если весь aabb дальше буфера глубины.
Ну метод который я хочу заюзать - это почти то же самое, только я использую не текстуру с буфером глубины, полученным ранее при софтварной растеризации, а буффер глубины, полученный при рендере сцены


Надоело всем доказывать что метод стоящий =) Вот тут про него прочитал
http://www.klayge.org/material/4_1/SSR/S2011_SecretsCryENGINE3Tech_0.pdf
9й слайд - и дальше.
Сначала ознакомьтесь а потом критикуйте,

Оффтоп: странный геймдевру стал. Задаёшь вопрос конкретный - а тебя вместо ответа пытаются убедить в том, что тебе эта штука вообще не нужна.
Я же не спрашивал "подскажите какую технологию лучше использовать", я спросил про даунсемплинг и reprojection. Слава богу хоть про даунсемплинг успели
поговорить пока не началась демагогия

#39
11:00, 17 сен. 2014

Mephisto std
> Оффтоп: странный геймдевру стал. Задаёшь вопрос конкретный - а тебя вместо
> ответа пытаются убедить в том, что тебе эта штука вообще не нужна.
> Я же не спрашивал "подскажите какую технологию лучше использовать", я спросил
> про даунсемплинг и reprojection. Слава богу хоть про даунсемплинг успели
> поговорить пока не началась демагогия
Удаляй таких смело и не парься, ты же постоялец из своей темы можешь выкинуть. Мне как то утверждали что я не умею выравненными данными пользоваться, хотя суть вопросы касалась дизассемблирования.

#40
11:03, 17 сен. 2014

Mephisto std
> Ну метод который я хочу заюзать

Я так понимаю, обычные HOQ не удовлетворили ? :)

#41
11:16, 17 сен. 2014

Mephisto std
> софтварный растеризатор работает в параллельном потоке и для низкого разрешения
> будет работать (и работает в том же Cryengine и куче других движков)
> замечательно быстро
Кстати для работы софтверного рестаризатора в паре с видеокартой не обязательно делать параллельный поток, главное чтобы он не загружал процессор больше того времени что расходует видеокарта на отрисовку. В общем то эту фичу получается использовать только для логики приложения, а для софт рендерера все равно приходится делать потоки. Но я не думал что в нем можно считать что то сложное - максимум теневую карту построить.

#42
11:29, 17 сен. 2014

innuendo
>Я так понимаю, обычные HOQ не удовлетворили ? :)
Эх, возможно, к ним и вернусь
Просто хотелось как в крайэнджине) хороший двиг, не грех и упереть чтонить

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

#43
11:37, 17 сен. 2014

Mephisto std
> Но, может, и можно чтонить придумать
Строить для следующего кадра в то время как рисуется текущий (от капитана очевидность), при 200 fps нормально. - можно даже не запариваться с предсказанием анимации (максимум камера). Обычно предсказание анимации это задержка отрисовки на кадр, то есть видеокарта рисует прошедший кадр используя модели загруженные в ее память, в то время как сцена в основной памяти уже построена для текущего времени, после чего все это вместе с совтверным просчетом отдается с ново в видеокарту, а в это время на софте рисуешь опять текущий. Подход а ля двойная буферизация. У тебя в любом случае так и получается - поскольку прежде чем построить сцену, ты обрабатываешь сигналы монипуляторов и триггеров логики, готовя сцену к новому рендеренгу (а заодно и строя софтверный кадр), а потом уже рисуешь видеокартой. Но как раз когда видеокарта отрисовывает кадр у тебя уже считается сцена для другого кадра, просто мы это обычно не засекаем! Такая тема наблюдается в режиме VSync off, конечно же когда он включен такого не происходит, но тут на помощь приходит параллельный поток. Смысл в том что в хорошей видеокарте все льется через буфер команд и без синхронизаций процессор уже успевает начать и закончить считать следующий цикл до того как все команды видеокарты выполняются, а когда начинаю выполнятся новые команды видеокарты после предыдущего не выполненного SwapBuffers то они просто стопорят основной проц. Чем меньше команд на конвеере видеокарты для большой сцены (чтобы не забить его полностью) тем больше времени у процессора для построения следующей сцены. Внутри команд аналога Finish не все так соответствует теории, и ожидание не всегда прописано именно там где вы ожидаете что оно будет, просто гарантируется что все отправленные команды до выполнения новых будут выполненны.

#44
12:12, 17 сен. 2014

Проще говоря команды завершающие отрисовку кадра абсолютно не гарантирую что команды на процессоре не будут выполнятся дальше без задержек на ожидание всех команд видеокарты - только если вы не вставили новую команду видеокарты.

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

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

Тема закрыта.