Render.ru

Entropy GI test

#1
Источников света ваапче нет. Только полусфера с constant шейдером
и пер вертекс колором.
Объект - 110784 полигона.
На PIII 2х933 512 мб.
при
nsamples 256 - 18 мин.
http://www.geocities.com/andrewvk107/CFS2/Pict1.jpg
nsamples 128 - 8 мин.
http://www.geocities.com/andrewvk107/CFS2/Pict2.jpg

в обоих случаях были
maxerror 0.2
maxpixeldist 10

Весело однако. Объекты "попроще" просто летают.
А как резво ГИ рулит менталрей?
 
#2
У меня жутко тормозит....я, как всегда, устроил "crash-test" - нагенерил пять тыщ кубиков и включил GI.....:
nsamples 256
maxerror 0.2
maxpixeldist 20

После сорока минут рендер был вырублен, ни одного бакета не отрендерилось :(

Другой тест - простой nurbs plane, шарик, и второй Plane в качестве лампочки - около 20 минут(точно не засекал), при этом жуткие пятнп на всех обьектах..... :(
 
#4
А на какой тачке и что за лампочка
(всмысле просто constant shader или Area Light)
У меня дома на PIII 866 256 Mb
1000 кубиков + Plane + Sky + Directional Light (кажется даже с RT Shadow)
картинку 320х240 считало минут 15-20 точно непомню
Правда я сижу в Houdini...помниться во времена BMRT2.6 у меня так и
неполучилось просчитать хоть что либо с MonteCarlo под MTORом
а в Houdini как два пальца обосвальт.
 
#5
Решил перерендерить сцену из премьеровского ролика. В прмане с источниками света (и тенями) для разрешения 768 считалось 30 минут. Для энтропи только с источниками без теней минут 7, с рейтрейс тенями отожрал более 2 гигов и за день не досчитался (у меня гиг - потому почти все время свопал); с шедоу мапами на источниках света, без текстур, только дисплейс, мейт материал с ГИ 0.25, 15, 32 - отожрал 1,5 гига и за выходные четверть картинки. Без материала я делал потому, что хотел использовать сгенеренный ГИ-файл для текстурного рендера. Кстати фича действительно великолепно работает (если есть возможность отрендерить файл хотя бы один раз;-)
Мой вывод - для сложного продакшна годится только как замена пиксаровского рендерера, со всеми старыми триками. И редко редко, например когда потребуется внедрить рейтрейс или трейсовую шедоу (.... короче почти никогда :)) можно воспользоваться фичами ентропии. Но пока ентропи не поддержит shadow дисплей сервер, со слимом его грустно пользовать. Еще не хватает DoF, но зато дисплейс просто зверский: быстрый и без ограничений. Кстати со слимовскими темплами работает хорошо, надо только подправить рамповые темплы и walias.h
 
#6
2Andrew:
А на какой тачке и что за лампочка
(всмысле просто constant shader или Area Light)

Dual P4 1700, constant shader.
Собственно пятна - из-за недостаточного сэмплинга......но если он столько времени считает с _таким_ качеством, то сколько же будет с нормальным?
Плюс эти пятна меня очень сильно смущают.....есть мнение, что на анимации будет жуткий GI'шный нойз...

Правда я сижу в Houdini...помниться во времена BMRT2.6 у меня так и
неполучилось просчитать хоть что либо с MonteCarlo под MTORом
а в Houdini как два пальца обосвальт.

Wow....Houdini? Я думал, что у нас никто не занимается им.....много накопал? ;)
 
#7
Houdini? Я думал, что у нас никто не занимается им.....много накопал? ;)

Если и занимаються то единицы...остальные (и я в т.ч.) копают.
А там копать неперекопать. Ораловский пакет.
Есть "гудини" и есть "все остальные пакеты"
Общее меж ними - конечная цель.
Меня в нем собсно заинтересовал VEX (некий язык для манипуляций
с вершинами объекта, каналами анимации, пикселями картинки
, шейдинга (практически BMRTшный вариант SL ) )
Интегрированый композер (интегрированый всмысле не "шоб был"
а завязаный (в том числе псевдообратными связями) с моделером, материалами,
анимацией, патиклами)
Патикловые системы просто чума. Майские патиклы и рядом не лежали.
Хреново в нем одно - хочеш заколбасить патикловую систему и через
10 минут "забываеш" что хотел сделать и начинаеш просто играться.
Моделить в нем очень небыстро (неудобно) но говорят в пятерке
будет полноценный ручной моделер и поддержка менталрея.
Очевидцы пятой беты говорят типа наконец то можно перестать скакать
между майкой и гудини.
Вобщем в двух словах его не опишеш.
Копать надо однако.
 
#8
2Jinn: "Еще не хватает DoF, но зато дисплейс просто зверский: быстрый и без ограничений. Кстати со слимовскими темплами работает хорошо, надо только подправить рамповые темплы и walias.h"

DOF есть, но какой-то странный...сделал двухнодовую камеру, повесил distance node на неё, с дистанса взял расстояние меж камерой и look-at и пихнул в camera Focus distance.....рендер в Entropy....фик. DOF'а нет.

Проверил RIB - "DepthOfField" со всеми моими параметрами присутствует.

Намедни поставил считаться тест на ночь, случайно(!;) оставил DOF включённым, так обьекты, которые выплывают прямо из-под камеры и близко от неё все в дефокусе!!! Такое ощущение, что у Entropy какая-то путаница со scene unit'ами... :(
 
#9
Вообще у них в доках написано что DOFа в этой версии нет. Может они так написали потому что он кривой? Моушн блюр есть и мне кажется что принцип должен быть похож на пиксаровский, так что и DOF по идее должен быть.... ИМХО
 
#11
в каких файлах и что править?
Если за качество/скорость то:
Attribute "indirect" "float maxerror" [0.15]
Attribute "indirect" "float maxpixeldist" [10]
Attribute "indirect" "integer nsamples" [128]
 
#12
>Кстати со слимовскими темплами работает хорошо, надо только подправить > рамповые темплы и walias.h

что именно подправить?
 
#13
Ентропи не любит отритцательные логарифмы :) Я просто поставил проверку на отритцательные и нулевые значения в файле walias.h (а больше ни где логарифм не берется)
В рамповых темплах рендерман юзает функцию spline с аргументом "solvecatrom" что по сути является обратной функцией к splin("catrom"....). Кстати в риспеке я не нашел описания этого аргумента. Ентропия соответственно не понимает этого аргумента и вроде не имеет обратной функции. Так как не было времени разбираться с catrom-ом я написал упрощенное линейное решение:
/* solvespline.h */
#ifndef _H_solvespline
#define _H_solvespline

float solvespline ( varying float val; float k0, k1, k2, k3, k4, k5,
k6, k7, k8, k9, k10, k11,
k12, k13, k14, k15,
k16, k17, k18, k19, k20, k21,
k22, k23, k24, k25, k26, k27,
k28, k29, k30, k31 )
{
float ind = 1, result = 0;
float arr[32] = {k0, k1, k2, k3, k4, k5,
k6, k7, k8, k9, k10, k11,
k12, k13, k14, k15,
k16, k17, k18, k19, k20, k21,
k22, k23, k24, k25, k26, k27,
k28, k29, k30, k31 };
for (ind = 1; ind< 30 ; ind+=1 ){
if (arr[ind] >= arr[ind+1]) {
if (val<= arr[ind] && val>= arr[ind+1]) {
result = (ind -1 + (float(arr[ind])-val)/float(arr[ind] - arr[ind+1]))/29.0;
break;
}
} else {
if (val>= arr[ind] && val<= arr[ind+1]) {
result = (ind -1 + (val - float(arr[ind]))/float(arr[ind+1] - arr[ind]))/29.0;
break;
}
}
}
return result;
}
#endif

и подставил во все темплы :

#ifdef ENTROPY
#include "solvespline.h"
#endif
...........
#ifndef ENTROPY
k = float spline( "solvecatrom", .......
#else
k = solvespline( ...........
#endif

То что это линейная интерполяция практически не видно даже при одной двух точках на сплайне. Хтоя если кто-то напишет catrom-овское решение, будет круто :)

Кстати в первом релизе был глюк - float ind я вначале описал как float i, так я час промучался - не работало ни фига... Потом я написал уже ind, и все заработало, более того после перезагрузки компа стало работать и с i !!!! Шайтан :) А еще с первым были глюки когда включаешь ГИ и используешь слимовские лайты, во втором этого вроде нет.
 
#14
А тебе удалось подшить ентропию к слиму как это было с BMRT
или тоже "entropy -d %1" и блин окошки...окошки...окошки
 
#15
К сожалению именно так :(( У них в доках написано, что должон быть пример порта из ихних диспсерверов в слимовый, но нету его :( Там есть еще один глюк (или фича ;) - во фрейм буфере (iv) вызываемом из под альфреда, почему-то используется гамма не 1. Чтоб этого избежать надо в системные энвайронменты прописать переменную GAMMA со значением 1 и перегрузить комп
 
#16
Ай, молодец, ай, шайтан!!!!

Я *** об этом в форуме просил *СТОЛЬКО* времени... И наконец хоть кто-то услышал этот крик...

p.s. Сделать именно решатель catmull rom просто в SL может и не получиться...
 
Сверху