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

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

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

Страницы: 13 4 5 666 Следующая »
#45
0:43, 5 дек. 2009

JokerR
Превед-превед :)


#46
0:52, 5 дек. 2009

У меня весь конвеер на шейдерах, если чо.
Шейдеры как раз сделаны на том же языке в виде callback методов.
Решил что проще сделать сменные шейдеры, чем писать фиксированный конвеер с кучей ifов для разных стейтов.
Правда varying и uniform передаются в шейдер не очень правильным способом.... Но делал быстро, на коленке, не было времени наводить красоту.

#47
0:52, 5 дек. 2009

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

#48
2:19, 5 дек. 2009

Как появится время у себя доделаю FILL_SOLID и мож тоже сделаю такую же сцену,но не заносите в участники :),просто ради интереса сделаю...

@!!ex,+1 тоже также изначально начал делать,только у меня шейдеры пресдавлены ввиде классов :)

#49
2:54, 5 дек. 2009

софтвар это типа getpixel ,  setpixel ? или аналогичное ?
и все 3д фичи с нуля писать надо ?
если да то
больше делать нечего да ?
столько времени убить на софтварный рендеринг.

но все же молодцы ребята порадовали

п.с. в контер страйке 1.6 есть софтварный рендеринг вот там скорость пи пеац !!

#50
3:08, 5 дек. 2009

ну вообщето я какраз и делаю сейчас шейдеры. сделаны классами. FFP больше не будет

#51
9:17, 5 дек. 2009

OpenGL
Я бы вообще не брал на работу прогеров 3Д, которые не писали свой Software Render.
Самый лучший способ определить, понимает прогер графику или нет.
90% вопросов задаваемых на форме по графие - тупо от незнании технологии которую используешь.
Опять же, написави свой SR понимаешь какие места при рендере тормозят сильнее всего, а значит и в обычном программировании будешь делать более оптимальный код.

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

Контровый рендер летает в силу многих факторов, в частности использование буфферов в специальных форматах оптимальных по скорости.

#52
9:36, 5 дек. 2009

Я за чайник, предлагаю в качестве следующей фичи - корректные тени и самозатенение, пусть пока от направленного света.
А вообще хотелось бы увидеть полностью готовой старую сцену хоть у кого-то, а то мы и чайник не доделаем, переключимся ещё на что-нибудь.
Я доделал свет - раньше большой цилиндр пересвечивался в результате того, что нормали масштабировались вместе с цилиндром. См. ссылку в п.0. Осталась фильтрация.

#53
9:53, 5 дек. 2009

@!!ex
> Лично мне после реализации софтварного рендера многие вещи стали более
> понятными.
> Причем возникла идея как можно оптимизировать вывод графикив обычных движках...
> идея пришла после реализации своего рендера.
+7  согласен со всем вышесказаннаым

я за чайник с самозатенением ^__^

точнее, давайте бахнем плоскость ну скажем 4*4 и на ней чайник с баундом гдето 2*2.  и пусть на плоскости и на самом чайнике будут тени : )


фак.  сделал наконецто я шейдеры! Всё полностью работает. Нет много гемора теперь но производительность убивает xD  кубик размером 1*1*1 крутящийся с камерой  vEye = 0,2,-5  vat = 0  даёт 150 ФПС иэто даже без z-теста  (хотя все регистры интерполируются  чесна)

#54
13:15, 5 дек. 2009

OpenGL
> софтвар это типа getpixel , setpixel ?
> и все 3д фичи с нуля писать надо ?
Иногда бывает нужно. В середине 90-х как-то даже такой вопрос и не стоял - неважно, тренируешься ты или уже коммерческое пишешь. Последний раз я занялся таким, что называется "по приколу", когда захотелось под четвёртый QNX в одну древнюю программу вращающуюся Землю добавиться. Нету там ни X Server'а, под которым OpenGL заводится, ни чего-то ещё. В результате родился "монстр" килобайт на двадцать.

> столько времени убить на софтварный рендеринг.
Простенький растеризатор (с текстурированием и z-буфером) можно соорудить за пару вечеров, если не особо напрягаться - во время обучения очень даже полезно, тут же никто за коммерцией не гонится прямо сейчас.

Потом покумекать с перспективной корректностью (если она сразу не была сделана), потом добавить какую-то модель освещения, а затем дойти до того, что в растеризаторе стало слишком много состояний и настроек и решить (@!!ex)
>> что проще сделать сменные шейдеры, чем писать фиксированный конвеер с кучей ifов для разных стейтов.

Тем более, что уже пошёл разговор про тени и самозатенение (Mikle) - я так понимаю, тени предполагается делать на каком-то варианте шедоу-мапа, а не стенсильные ? В общем, вопрос про шейдеры был не шуткой. Если уж тут все люди серьёзно занимаются графикой и смотрят в будущее, то наверняка после нескольких лет юзания шейдер-моделов различных версий им всегда чего-то не хватало. То double-типов, то линковки шейдеров из разных файлов, то ...

Я так туманно сказал про шейдеры, а Fenix_Alpha сказал про конкретные варианты. Так вот, вариант 3 - по идее и есть базовый. Простые callback-функции, внутри которых в конечном итоге можно реализовать другие два варианта или так и писать на родном языке.

Наконец, про производительность. Есть один очевидный способ ускорения, который стоит заимплементить: рендеринг в несколько потоков в различные части фрейм-буфера. По идее, конфликтов с записью быть не должно и сам процесс рендеринга параллелится идеально.


В целом - молодцы. Продолжайте дальше, всем интересно :)

#55
15:04, 5 дек. 2009

Вообщем, сделал я полностью на шейдерах всё.

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

В новой демке ландшафт. Размером 64*64 (т.е. 4225 вершины,  8192 треугольника.)  FPS у меня без текстуры гдето 30, с текстурой 23, с билинейной фильтрацией 16.  Скажите, пожалуйста, какой у Вас ФПС?

п.с. На wireframe режим не ругаться!  Знаю что не совсем правильный но мне он так понравился таким какой он есть сча, что переделывать не хоцца xD

SoftGL10


п.п.с.  я в 0 пост её ессно не включил : )  Ибо не сделано там задание.

#56
15:23, 5 дек. 2009

>но мне неясно как добавить шейдеры, не убив при этом окончательно производительность
помойму однозначно надо делать компилятор в Native код (либо в Byte-Code и виртуальную машину с JIT)

#57
15:36, 5 дек. 2009

у меня и так в native компилится (шейдер == класс).  И тем не менее производительность упала : )

#58
15:39, 5 дек. 2009

Смотрел все демы с 0-го поса + вон ту, которая сверху.
Эх блин, ребята! Я говорю вам уже в какой раз - мертвая ваша идея, мертвая! у меня от силы 20-35 фпс было, у Л на макс настройках - 7. Зачем вы мучаетесь? Одно дело понять принципы софтрендера, другое дело - его писать всерьез. Вы не конкуренты Оглу и Директу.

Простите за мрачные мысли.

#59
15:45, 5 дек. 2009

"
Доктор: Вы мучаетесь извращениями?
Пациент: Что вы! Я ими наслаждаюсь
"(С) Старый баян

Мы делаем JFF.
Тем более скорость рендера как раз не важна. Софтверный рендеры живы в двух случаях:
1) Платформы без аппаратного ускорения(мобильники, браузеры)
2) Системы рендера НЕ реального времени(для Макса, например)

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

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