Войти
ПроектыФорумОцените

Hydra Renderer [GPU рендер для 3ds max, теперь на CUDA и OpenCL] (3 стр)

Страницы: 1 2 3 4 Следующая »
#30
10:15, 25 мар. 2015

Так у 2D текстур максимальный размер не тот, а укладывать по z кривой там ... оно конечно можно, но мне не хочется ерундой заниматься пока, может позже.
Пусть драйвер свой чинят.


#31
13:58, 25 мар. 2015

FROL
так ты им напиши bug report , нехай починят .

у тебя какая amd карта ?

кстати , на первичных лучах без теней сколько fps (в 1024x768) выдаёт на сцене "conference" твой трейсер ? у меня без tex1DFetch всего 100 fps на r9 280, а в results айла пишет что 680'ая выдаёт 400 млн. первичных лучей в секунду, чё то прям не верится .

#32
14:32, 25 мар. 2015

>так ты им напиши bug report
Да, надо бы. Там не только в AMD)

Сравниваю R9 280 против GTX680.

На первичных лучах всё относительно-неплохо: 250M лучей в секунду (без tex1DFetch будет 150).
Что кстати далеко не равно FPS, поскольку есть оверхед на другие кернелы и compute/graphics интероп.
Так что ты лучше меряй время выполнения кернела трейса отдельно, между двумя вызовами синхронизации (clFinish или cudaDeviceSynchronize).

Ну Айла чуть-чуть привирает, потому что его собственный код столько не выдает обычно и это можно легко проверить, т.к. он доступен.
Будет скорее всего около 350, но это на самом деле не далеко от 400. Если он разгоняет видеокарты для тестов то наверное да, будет 400.

А вообще время трейса первичных лучей как раз не очень интересно.
Гораздо интереснее вторичных и третичных (и тех и тех - диффузных), т.к. они обычно боттлнеком становятся (с 250M падает до 65M при переходе от первичных ко вторичным ... так что ускорять надо последние).

#33
14:34, 25 мар. 2015

Время трейса сильно зависит от качества BVH дерева, в первую очередь надо применять Early Split Clipping, тогда догонишь Aйлу :)

#34
15:18, 25 мар. 2015

FROL
так я слямзил Айловский код построения bvh :D но, код самого трейсера не самый оптимальный у меня, судя по всему.

интересно, а почему в luxmark nvidia 680 отстаёт радиков и находится на уровне ниже 580 gtx ?
geforce-gtx-680-review-benchmark


а как замутить плавные переходы между полигонами, чтоб треугольников не было видно ?

как здесь напр.,
Изображение

#35
15:35, 25 мар. 2015

xma
> а как замутить плавные переходы между полигонами, чтоб треугольников не было
> видно ?
Нормали в вершинах усреднить.

На счел люксмарк не знаю, надо разбираться что у них там.

#36
15:44, 25 мар. 2015

FROL
какие фишки планируете реализовать в платной версии hydra ?

#37
16:10, 25 мар. 2015

Посмотрим, пока сложно сказать. Скорее всего это инстансинг и работа с очень большим контентом (в основном текстуры) + возможно какие-то фичи по материалам, сетевой рендер.

Прошло более 5 лет
#38
14:35, 3 авг. 2020

кстате кто не смотрел выступление FROL'а - оказывается Hydra Renderer разрабатывается аж с 2007 года,

+ Показать

поэтому собственно даже RT демка 10 летней давности - была столь впечатляющей ..

+ Показать

в динамике особенно круто смотрится,

собственно я считаю что уровень графики такой не достигнут ещё до сих пор, даже на RTX картах - в реальных приложениях .. хотя самой RT производительности на таких несложных (по количеству полигонов) сценах - у RTX карт уже должно быть достаточно, не говоря уже про Ampere .. :D

хотелось бы увидеть игру с таким графоном, я бы может (а может и не только я) - замутили бы какую нить простенькую игрушку, если бы FROL моделью освещения поделился (этой демки) .. :D вроде же сейчас даже исходники Hydra Renderer - open source ..

FROL

кстате да, любопытно - почему решили открыть исходники Hydra Renderer ?

и почему не строите BVH дерево на GPGPU ? (а вместо этого используете intel embree)

ну и интересно, почему отказались ли от P2P рендеринга ?

#39
(Правка: 17:33) 17:33, 3 авг. 2020

xma
> кстате да, любопытно - почему решили открыть исходники Hydra Renderer ?
Это дало возможность заработать на интеграции рендера. Закрытый софт ИМХО сейчас никому не нужен, время не то.
Нужно было сразу вести разработку полностью открыто.

> и почему не строите BVH дерево на GPGPU ?
В оффлайн рендеринге главное качество самого дерева, а скорость построения не критична.
По-моему это вообще не нужно потому что сцена в подобных приложениях в любом случае почти всегда полностью на цпу генерируется клиенским приложением, и время построения как правило много меньше времени выгрузки сцены из приложения в движок. Эмбри подходит, но хотелось бы от него избавиться чтобы не зависеть от x64.

>ну и интересно, почему отказались ли от P2P рендеринга ?
Да не то чтобы бы отказались, просто не до него. Фич много, поддерживать всё это непросто.
А теперь так вообще вулкан ... на другое просто не остаётся времени.

#40
17:58, 3 авг. 2020

FROL
> Это дало возможность заработать на интеграции рендера.

а куда интегрировали ?

FROL
> Эмбри подходит, но хотелось бы от него избавиться чтобы не зависеть от x64.

но вы всё равно хотите BVH builder на мортон кодах или хотите полный sah считать ?

FROL
> Фич много, поддерживать всё это непросто.

т.е. двиг уже сейчас на самоокупаемости ?

#41
(Правка: 14:56) 14:54, 4 авг. 2020

xma
> а куда интегрировали ?
Был проект с LightCAD и ещё пара проектов с лабораторией компьютерной графики МГУ.
Не уверен что могу говорить детали, но по направлению это рендеринг для тренировки нейросетей.

>но вы всё равно хотите BVH builder на мортон кодах или хотите полный sah считать ?
У нас на самом деле есть и то и другое своё, не хватает времени довести до ума.
По сути там только много-поточность добавить осталось. Нохотелось бы ещё раз попробовать разные варианты травесала и форматов хранения бвх.

>т.е. двиг уже сейчас на самоокупаемости ?
В целом да. Другое дело что такие проекты как правило сами по себе довольно напряжные, а пользы для развития движка от них не много. Поэтом я не мгоу сказать что прям успешно. Средненько.

#42
15:11, 4 авг. 2020

FROL
интересно, у вас ускоряющая структура перестраивается только для динамики или вся сцена?
еще интересно было бы посмотреть (если есть) скрины отдельно прямой и вторичный свет.

#43
(Правка: 15:32) 15:31, 5 авг. 2020

Ruslan
> интересно, у вас ускоряющая структура перестраивается только для динамики или
> вся сцена?
Она двух-уровневая как и везде, для поддержки инстансинга. Перестраивается для отдельных объектов при их изменении.
Изменения отслеживает плагин и передаёт в жвижок через гидраапи посредством пару операций Open/Close

>>еще интересно было бы посмотреть (если есть) скрины отдельно прямой и вторичный свет.
Ты можешь легко получить первичный свет на любой сцене если поставишь плагин и укажешь число баунсов равное 1 (или 2, не помню уже).
Чтобы получить вторичный придётся конечно в коде покопаться. Мы можем добавить такую фичу в план, но планов там существенно больше чем успеваем сделать.

#44
15:55, 5 авг. 2020

FROL
ага ясно, вроде писали, что планировалась поддержка запекания света.
Удачи в разработке!

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