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

::3D Software rendering contest [finished]:: (3 стр)

Advanced: Тема повышенной сложности или важная.

Страницы: 1 2 3 4 566 Следующая »
#30
20:48, 4 дек. 2009

Скачал все предложенные демки. Даю краткую рецензию (если что у меня Core2Duo E6550) :)
Rean - запускается (около 55 кадров)
namot - в архиве нету SDL.dll - провал! Запустил - тетя нормально крутится, а кубик как будто деформируется при повороте (текстуры?). Порадовала возможность вращать сцену
Mikle - около 38 кадров, порадовало освещение
Fenix - порадовала скорость - около 120 кадров
@llex - есть блендинг, а в общем складывается впечатление, что это только начало чего-то
L - прикольно - есть и освещение и прочие фичи. В целом понравилось больше всего. Правда на максимальных настройках около 7 кадров

#31
20:54, 4 дек. 2009

L
Ладно, убедил.
Еще ИМХО необходимо чтоб у всех участников контеста в своем рендере была возможность настраивать стэйты рендера. Потому что у кого-то, например, включена фильтрация текстур, у кого нет. И как их тогда сравнивать по ФПС?
Правка: тэги

#32
20:55, 4 дек. 2009

Fenix_alpha
> Тогда нельзя быть увереным в том, что рендер действительно софтварный и не
> юзает видеокарту.
По списку импорта легко определяется.

#33
20:59, 4 дек. 2009

X512
> Fenix_alpha
> > Тогда нельзя быть увереным в том, что рендер действительно софтварный и не
> > юзает видеокарту.
> По списку импорта легко определяется.

Если это OpenGl, то несложно подгрузить все функции динамически через WGLGetProcAddress и GetProcAddress.

#34
21:01, 4 дек. 2009

Fenix_alpha
Не знаю, как другие, а я потом выложу исходники.

#35
21:10, 4 дек. 2009

Fenix_alpha
> Если это OpenGl, то несложно подгрузить все функции динамически через
> WGLGetProcAddress и GetProcAddress.
В Dependency Walker все загруженные DLL тоже показываются.

#36
21:54, 4 дек. 2009

Sergio
> Правда на максимальных настройках около 7 кадров
ну там и геометрии много  : )  хотя, рендерер всёже не на макс оптимизирован : \


Fenix_alpha
> Еще ИМХО необходимо чтоб у всех участников контеста в своем рендере была
> возможность настраивать стэйты рендера.
ну, тогда мож вынести включение/выключение "фич" в файл?  У меня, как вы знаете, все фичи можна настраивать пря в окне проги. 

Mikle
> Не знаю, как другие, а я потом выложу исходники.
я тоже : )

#37
23:05, 4 дек. 2009

namot твоя демка у меня быстрее всех работает, как уже сказал Sergio твой растеризатор не делает перспективную коррекцию координат поэтому они "сползают" когда фейс не повёрнут к камере :( , ещё не плохо бы использовать текстуры в RGB цвете а у тебя они с палитрой. Твой код действительно для меня интересен так как на C++ я пока не пишу предпочитаю Си :)

#38
23:36, 4 дек. 2009

Коллеги !  Спасибо за интересный конкурс.

Есть только один вопрос-предложение. Сделает ли кто-нибудь там шейдеры ? Грубо говоря, какой-то кастомный опциональный процессор каждого пикселя/вертекса (ну, кому я объясняю ;)  ). 

И вообще, после "окультуривания" сырцов до простенького АПИ (GL-подобного) могут получиться небесполезные продукты, что-то проде MESA.

#39
23:51, 4 дек. 2009

Vinil
> Сделает ли кто-нибудь там шейдеры ?
Может кто-то и сделает, но мне неясно как добавить шейдеры, не убив при этом окончательно производительность.
ИМХО есть несколько вариантов добавления шейдеров:
1. Сделать шейдеры высокого уровня на основе какого-то скриптового языка (желательно с JIT-компиляцией).
2. Сделать шейдеры низкого уровня. (Самому написать интерпретатор и виртуальную машину для выполнения простейших инструкций)
3. Писать шейдеры на том же языке что и сам рендер. А обработку шейдера сделать в виде callback функций. В качестве параметров такие функции будут принимать разные атрибуты (положение, нормаль, текстурные координаты и т.д.). При рендере для каждой вершины будет вызываться вершинный callback, а при растеризации - пиксельный. Но тогда ни о какой динамической компиляции речь идти не может.
Но я считаю, что для софтварного рендера шейдеры не нужны. Будет сильно тормозить, а реализовать функциональность близкую к нормальным GAPI будет сложно.
Если уж очень приспичило делать шейдеры и их немного - лучше написать еще одну функцию растеризации треугольника, которая будет нужным способом рассчитывать цвет каждого фрагмента.
Опять же это только ИМХО.

#40
0:27, 5 дек. 2009

делать шейдеры заботясь о скорости это больше клон коммерческого Pixomatic 3 (D3D9 уровень)
кстати очень рекомендую почитать абраша все что найдется, тем кто не читал
если конечно такое чтение не рассматривается как спойлер :)

#41
0:29, 5 дек. 2009

Предлагаю тестить на чайнике классическом. Как вариант одного из. Надо же комплексно тестировать различные аспекты, как то:
- Трансформацию вершин
- Клипинг
- Филрейт
- Текстуринг
- etc

И согласен, что нужен рефеернсный рендер на DX

Update: Еще бы определить прописать в правилах ограничение или на отсутствие оного на использование нескольких ядер

#42
0:38, 5 дек. 2009

Sergio
> в архиве нету SDL.dll - провал! Запустил - тетя нормально крутится,
> а кубик как будто деформируется при повороте (текстуры?).
> Порадовала возможность вращать сцену

SDL лучше установить общесистемно, чем добавлять одно и то же в каждый архив. А кубик, это аффинное текстурирование.

xd1v0
Код там проблемный, отсечение и проецирование сделаны не удачно, клиппинг по znear не работает. Цвет в формате r3g3b2 скорее всего оставлю как есть, этот растеризатор должен давать хороший fps на ARM ~200МГц .

#43
0:38, 5 дек. 2009

Fenix_alpha
>ИМХО есть несколько вариантов добавления шейдеров:
есть только два (если хоть немного интересует скорость):
это твой третий вариант
и динамическая генерация кода из HLSL/GLSL/whatever

#44
0:39, 5 дек. 2009

viv
кисо куку :-D

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

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