BW4ever

Я его пока не качал. Вот здесь есть примеры этого?


Откуда, что следует? Я хотел сказать, что освещение точки объекта, на который упал луч при обратной трассировке определяется только прямым освещением этой точки источниками света плюс общее(ambien light).


Причем тут зеркальные поверхности(состовляющие отражения), когда о диффузной речь?


Да, я ошибся. Исправлю.

Ну ты запусти демку Nalu на 6800гт и посчитай, сколько там сотен кадров. Я так думаю, аж 0.2 наберётся.

Максимум два кадра. Чаще один и меньше. При элементарной билинейной фильтрации и разрешении 640*480.
Как думаешь, сколько понадобится времени, там, пню-4-3000, чтобы отрисовать 19-проходный кадр при разрешении 1280*960 и сглаживании 4x (т.е. количество семплов будет 2560*1920), куче постэффектов, составляющих часть этих 19-ти проходов, всяких там картах нормалей, картах блестяшности (куче накладываемых на полигон текстур), самозатенению и прочим красивостям? Да там только одно разрешение+сглаживание съест всю разницу в скорости.

rednameless
Ты говорил про 100 кадров в секунду на видяхе, когда в совтваре будет 2 минуты рендериться.


Говорю, что там не оптимизированно ничего. Они программировались не для рендеринга в реальном времени, а для эталонного(т.е. с максимальным качеством). Есть алгоритмы билинейной фильтрации в 20 тактов инструкций MMX.


Понятия не имею. Сколько? Оценим сверху. Пусть на пиксел будет требоваться 10 000 тактов(около 200-500 текстур с билинейной фильтрацией), то получается, что на 3GHz процессоре потребуется 16 секунд на растеризацию. Ну и не более 4 секунд на тесселяцию.

А ещё я говорил, что демку Nalu специально заточенную под 6800-ую серию, 6800жт тянет со скоростью кадров 20-25.

Это как-то противоречит? По моему, ежу понятно, что

1) сравнение про 100 фпс и 2 минуты чисто условное, отражающее лишь порядок скорости, а не абсолютную величину соотношения.
2) если Nalu рисуется со скоростью 4-5 раз меньше, чем 100 фпс, то очевидно можно в таком же переносном смысле говорить о том, что софтварно эти кадры будут рисоваться минут 10. Чисто так условно. может и не десять, может и всё те же две. Порядок, как видим, далеко не уходит.

Вот ведь как. Ежу - понятно, а Kola - нет. Следовательно, Kola - не ёж. Об этом можно со всей уверенностью говорить.



20 тактов на пиксель, что ли? Мощная скорость.
А как там насчёт алгоритмов затенения, карт нормалей, постобработки, исполнения пиксельных шейдеров, анизотропии 16х и т.п.? Ты не забывай - мы сейчас обсуждаем общий вопрос соотношения скоростей софтового рендеринга и хардварного. При этом если там и есть где-то билинейная фильтрация достаточно бытсрая, то это

1) ничего не решает
2) указывает на наличие "харварной" составляющей

Инструкции ММХ - это оптимизированные под обределённые задачи инструкции. Это не чистая математика. Отличать софтовый рендеринг только по тому, что его исполняет цпу, а не кто-то другой - как-то не тово. А то там можно в цпу вообще встроить графическое ядро, обозвать его расширенным набором инструкций GMX и говорить - посмотрите, какой у нас замечательный софтовый рендеринг!



Билинейная фильтрация, вообще-то - самый, наверное, простейший графический алгоритм. Ну, из тех, что реализуют видюхи. Не даром три-дэ ускорители начались именно с этого. Разница скорости в случае с полным отсутствием фильтрации - в пределах погрешности измерения. Жаль только остальные алгоритмы не так просты.

Даже в таком случае имеем:
20 секунд на кадр в софте.
20 раз по 20-25 за то же время в харде.
400-500-кратная разница.
Ну, это конечно совсем несерьёзная разница в скорости.
А вообще, если отрендерить какую-нибудь даже не очень сложную картинку в каком-нибудь хорошем софтварном рендерщике (они же должны иметь оптимизации, не правда ли?) с применением многопроходных эффектов, то диву даёшься - какая скорость. Я вот и половины проходов не дожидаюсь.

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

О чём тут спор был - никак не пойму....

НЕ только это. т.н. "глобальная модель освещения" включает в себя гораздо больше

при том, что ограничений диффузными поверхностями\прямым освещением нет
Добавлено спустя 6 минут, 43 секунды
rednameless

rednameless
У тебя получается разница в 4 порядка. Я же показал, что разница при оценке сверху(т.е. максимальная) может составлять только 2 порядка.


Где ты эти 2 минуты взял? Бенчмарк какой-то запускал или рассчитал каким-то образом?


Хорошо, применим другую оценку. В современных играх текстурирование/освещение полностью выполняется пиксельными шейдерами. Предположим, что возможности по обработке CPU не слабее одного юнита пиксельного шейдера. Получаем, что возможности по обработке GPU 16x500MHz в 2 раза лучше CPU 1x3000MHz. С учетом более узкой шины памяти, более медленной памяти и прочих ограничений можно умножить результат на 10-50.


Какая ещё математика? Какая разница оптимизированные/неоптимизированные? Вопрос про софтварный рендеринг - производится центральным процессором. Любой современный CPU включает инструкции MMX, SSE(2), 3DNow(2). Думаешь 3DMax(или где Nimnul рендерил свои картинки) не использует эти наборы инструкций?


А как ещё отличать, если вопрос был поставлен именно так? Или софтварный рендеринг, это только исполняющийся в инструкциях x86?:lol:


Если всё настолько быстро, что разница между 5 и 20 тактами на внутреннем цикле в пределах погрешности измерения, то да.


А как просты, сколько требуют тактов, скажем, в инструкциях PS?


Какую картинку, в каком хорошем софтварном рендерщике(который, несомненно, имеет оптимизации), каким методом рендеринга и с какими эффектами?


Хорошо, пусть 2 с половиной порядка. Значит не через 20 лет, а через 15 появятся соответствующие GPU, которые смогут выполнять трейсинг "фотонов". Я ж не претендую ни на какую серьезность в своей оценке. Щас сделают квантовый компьютер на лимон кубитов, можно будет "фотон" сразу во всех направлениях излучать.


Ты его начал, ты и должен знать...
Добавлено спустя 5 минут, 1 секунду
BW4ever
Что именно она ещё включает?


Зеркальные поверхности при рейтрейсинге обрабатываются проще, чем диффузные. С ними IMHO и так всё ясно. А каким образом вычисляется непрямое освещение при обратном рейтрейсинге?

Ты читаешь мои мысли. Я считал более сложно (прикидывая сколько фотонов нужно/операций надо провернуть) и пришел к тому же результату. Карты за год у меня становились в двое мощнее...
Это все субъективно, конечно.
Это может подтвердить природа и твои глаза!!!
Тогда не нужен (по идее) Z-буффер. Тут ссылка была, где паренек сам движок на сферах отлабал, он путево описал какие это перспективы сулит - мол динамично можно сцену менять все не пересчитывая...

Я с вами запутался в терминологии... Трассировка из сцены в камеру. Оно же круто.
Добавлено спустя 28 минут, 59 секунд
По поводу теней в думе (или еще где).
Буду признателен, если кто мувик выложит. А то факи 4e_alex по настройкам я не читал, да и 3-х у меня нет. Смелее.

Ну и зачем тогда было поднимать эту тему? Подождем 20 лет .

Третьих чего? Шейдеров? Они не нужны. Если FAQ не читал, то это можно всегда сделать, там вопрос про фонарики всего на несколько строк, легко находится поиском. Где удобнее смотреть тоже уже написал. Вперед, смотреть все самому.

Потому что альтернативные ( и технологически весьма перспективные) алгоритмы есть уже сейчас и их развивать надо. Более того, справедливо замечено, что аппаратная поддержка ускорила бы дело в 33-333 раза. А с учетом того, что отпадут многие "ненужные" задачи + можно уменьшить к-во фотонов (сложность с их числом растет нелинейно и очень круто, соответственно и падает при уменьшении) - значить зондировать почву нужно сейчас! Будет шуметь - ну и черт с ним!!! Зато красива!
++++++++
(пофантазирую) пользователи из драйвера, где нет вкладок ни АА, ни прочей фигни, тащут движочек к-ва фотонов вправо (или влево, но лучше вправо) и наслаждаются картинкой с легкой рябью и осознанием того, что каждый пиксел получил пару-тройку усредненных фотонов. Что они где-то, но летали. И сцена оживает...
ДАЕШЬ ФОТОН!!!
++++
Ну а если серьезно, я был бы очень рад, если бы АТИ/Нвидия не просто хвалились на презентациях, а давали свободу правом выбора в настройках драйвера самых экзотич. настроек, которые могли бы там быть. Начинать же когда -то надо.

Kola глобальная модель освещения включает в себя: отражение, преломление, пропускание, множество источников света с реальным и характеристиками(разные интенсивности \ телесные углы), зависимость отражения от структуры материала, особенности фотографической оптики(глубина резкости, фокуса, искажения объектива). туда же без проблем встраиваются мягкие тени(от множества источников), сглаживание. и все это при ОБРАТНОЙ трассировке. опять таки настоятельно рекомендую вышеназванный мною труд Роджерса(он является компиляцией очень многих работ), который должен быть в любой крупной тех. библиотеке.

СКАЧАЙ Realstorm Benchmark (3.7 mb) и ПОСМОТРИ 5 тест.
а пока все похоже на обсуждение одной книги на fenzin.org:

и в дальнейшем доказывать что-то субьектуKola смысла не вижу, так как на любой аргумент в ответ слышу - "я а ничего такого не вижу"

я не понял, ты о чем?

у меня вопрос - что важнее в графике развивать, количество миллионов полигонов + уведичение разрешения текстур до фотореалистичных или танец с бубном вокруг пресловутого "просчёта света"? мне кажется, что при 500000 полигонах в кадре (это средний уровень нынешних игр) и говорить и трассировке лучей не надо, пусть сначала доведут полигонов до 3-4 миллионов и разрешение текстур подымут так, чтоб игруху от видео не отличить!
и почему до сих пор не реализован антиалиасинг 12x и 16x?

Nimnul
Ну да. Она же прямая трассировка, она же трассировка "фотонов". Если я сам не запутался. Оно, конечно, круто. Только, чтобы фотонов достаточное количество попадало в камеру, нужно объектив(виртуальный) делать большим, из-за чего диапазон фокусировки получается маленьким. На твоих картинках "в фокусе" только передок машины.
Добавлено спустя 47 секунд
4e_alex
Ну надо же обсудить, все-таки.

это что за игры такие?
а вообще, доводите и поднимайте, но не заикайтесь про "фотореалистичность"

Nimnul
Кстати, а зачем для игровых применений делать именно трассировку в "объектив"? Можно прямой трассировкой получать lightmap'ы высокого разрешения с более правильным результатом, чем дает radiocity. Хотя с другой стороны IMHO потенциально можно получить быстрые мягкие тени с помощью стенсил буфера.

Фаркрай = 0,5, да и 3Д 2006 - 1,5млн. Но даже заикаться не стоит. Согласен.
Фотоны летят В твои глаза и попадают на сетчатку. Усредняясь на колбочках ты видишь цвет пиксела.

Ну достали - сказано же, что так задумано, типа на игрушку сблизи смотришь!
Добавлено спустя 1 минуту, 44 секунды
SerGee ты где-то прав, но дело в том что сейчас забили и на свет, и на полигоны с текстурами.
И сосредоточились целиком на шейдарах!!!

BW4ever
Всё это могут сделать на приемлемом уровне качества современные игровые движки(движек D3) используя шейдерные процедуры. Протяженные источкики света пока в реальном времени не рассчитываются, однако и при обратной трассировке(впрочем, как IMHO и при использовании стенсил-буфера) рассчет видимого телесного угла протяженного источника задача не тривиальная(в плане быстродействия), если это нужно сделать(по меньшей мере) для каждого пикселя.


А каким образом при обратной трассировке можно рассчитать вторичное освещение от матовых поверхностей? Делать предварительный рассчет освещения всей сцены с помощью радиосити?


Скачаю, как смогу.


Как бы это прокомментировать? Может быть сам тут напечатаешь абзац(раз у тебя эта книга есть), где говорится про разницу(или её отсутствие) прямой и обратной трассировке, или где говорится, как рассчитывается диффузно-рассеяное освещение?


Ну и не надо ему тогда ничего доказывать.

Kola С помощью стенсил буфера они быстрыми не будут, разве что при применении PSP.
Nimnul Очень смешно, бамп, параллакс и иже с ним - дополнительный эфект при просчете попиксельного освещения.
А то, что допустим в думе текстуры не самого большого разрешения... А что ты хотел, основная текстура, карта высот, спекулярная карта - уже много видеопамяти занято. Было бы повсеместно по 512 мб видеопамяти - получил бы текстуры высокого разрешения.

SerGee
Пока будут рисовать мультипликационные текстуры, видео можно не ждать. Это даже не вопрос разрешения текстур или количества полигонов в сцене, а вопрос подбора цветовой гаммы.

Nimnul
Можешь сделать так, чтобы вся сцена была в фокусе?
Добавлено спустя 7 минут, 21 секунду
Daemon
Просвяти, пожалуйста, на счет PSP. Реализовывать мягкие тени с помощью стенсил буфера, я подразумевал не с помощью массивов точечных источников, а с помощью примерного рассчета "видимого" телесного угла источника света в освещаемой точке. IMHO, можно это дело неплохо оптимизировать при определенных допущениях.

Kola Он менее дорогой, чем стенсил буфер сам по себе и имеет хардверную реализацию на GeForce6 и выше.
Всеравно нужно будет много проходов (скорее всего), заблуривать тени прийдеться (дабы не было артифактов), уж незнаю, насколько они получатся быстрыми.

Daemon
В каком плане менее дорогой? Качеством хуже? Алгоритм другой?


А что, если заблуривать сами значения стенсил буфера? Не просто так, конечно, а по расстоянию до источника и углу к повехности. В один проход можно управиться, наверное.

BW4ever
Посмотрел я RealStorm. Ну и? Мягкие тени делаются с помощью имитации протяженных источников большим количеством точечных - тоже мне способ. Вторичное(глобальное) освещение делается предварительным рассчетом радиосити для всей сцены(как в Quake, только в реальном времени).