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

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

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

Страницы: 14 5 6 766 Следующая »
#60
15:47, 5 дек. 2009

L
>> у меня и так в native компилится (шейдер == класс). И тем не менее производительность упала : )
Ещё бы - если у тебя виртуальные функции, то лишние такты на вызов просто гарантированы. С другой стороны, просто C-callback'и как-то "немодно" выглядят.  А ещё я всё забываю, что там C# у тебя :) Но холиворов тут не будет :)

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

про multithreaded rendering никто не думал ? есть ли какие-то принципиальные проблемы рендерить в куски фрейм-буфера ?


@!!ex
>> Мы делаем JFF.
+1

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

#61
15:49, 5 дек. 2009

Я думал про МТ рендеринг. и писал об этом здесь. Времени пока нету сделать.

#62
16:09, 5 дек. 2009

Ясно. Но помоему это бесперспективно, так как через максимум 5 лет все это будет с теми же "эффектами, не доступными сейчас", но уже на железе, а аппаратное ускорение будет везде.

#63
16:13, 5 дек. 2009

Не знаю как для других... Для меня это возможность укрепить фундаментальные знания и подучить матчасть.

#64
16:37, 5 дек. 2009

Ну какбы да.  Я не собираюсь на этом софтрендере делать игру и тем более продавать ит.д. 
Мне просто нравится его писать и всё : ) 


А про МТ рендеринг. Хм.я даже х.з. как енто всё распаралелить о_О

#65
16:53, 5 дек. 2009

Вот сделал месяц назад:

http://www.gamedev.ru/code/forum/?id=126749 (http://webfile.ru/4136885)
Язык: С++
Фичи: B, C, D, E, F, G, I
Вывод финальной картинки на экран с помощью DirectDraw.

#66
18:39, 5 дек. 2009

Che@ter
Круто выглядит!

#67
21:06, 5 дек. 2009

 L 
> А про МТ рендеринг. Хм.я даже х.з. как енто всё распаралелить
Ну например распараллель рендер треугольников или растеризацию отдельных фрагментов.

Vinil
> про multithreaded rendering никто не думал ?
Ну какбэ у меня он есть. Не сильно оптимальный, но хоть какой-то буст есть.

#68
0:57, 6 дек. 2009

Vinil
> про multithreaded rendering никто не думал ?
У меня распаралелены некоторые части с помощью OpenMP,например кусок кода из drawTriangleWireframe:

    VertexOutput* outputs[6] = {
      output0,
      output1,
      output1,
      output2,
      output2,
      output0,
    };

        #pragma omp parallel for schedule(dynamic)
    for(int i = 0; i < 6; i += 2)
    {
      rasterizeLine(outputs[i+0],outputs[i+1]);
    }

#69
1:21, 6 дек. 2009

Igor'
Не-не-не. Странно. Я думал, что идея распараллеливания проще. А тут (поправьте, если ошибаюсь) пытаются либо распараллелить цикл отрисовки всех трегольников, либо отрисовку сканлайнов.

Короче, есть фрейм-буфер  FB[W на H пикселей], есть список Triangles[] треугольников (после frustum culling и т.д.) для отрисовки.

Всё, что я имел в виду - это рассмотрение "кусков" FB (например, если куска 4):  FB_0[W на H/4], FB_1[W на H/4], ... FB_3[W на H/4],  разделяющие буфер на четыре равные части. Само собой, это просто четыре пойнтера. может быть, можно и не вертикально делить, а вообще на некоторые тайлы.  Затем весь список треугольников Triangles[] рендерится в нескольких (в данном случае - в четырёх) потоках в FB_i.  Естественно, при 2D-отсечении в каждом из четырёх кусков ничего лишнего не будет. Разве такая техника очень сложна для реализации ? Просто запустить один и тот же процесс рендеринга в несколько областей фрейм-буфера.

Написать "заклинание" pragma omp parallel и надеяться, что оно даст прирост - это как-то странно по-моему.  Если "параллелить" на уровне  for each triangle in Triangles[] do render, то сами посудите, что произойдёт: скан-линии от разных треугольников могут перекрываться и будет куча проблем с записью/чтением z-буфера.

#70
2:33, 6 дек. 2009

Igor'
слушай,есть вопросег.

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

Вообщем, Я сначала получаю 3 вершины треуголника, прогоняю через вершинный шейдер.

Вот дальше и есть неоптимальность:
я нахожу  баундинг бокс для триангла и ДЛЯ КАЖДОГО пикселя бокса считаю барицентрицеские координаты.  Дальше дело техники - я проверяю, если хоть одна координата <0 то не обрабатываем пиксель (за ганицей треугольника он лежит).

У тебятоже весь баундинг бокс так рассчитывается или же есть быстрый способ проверить, находится ли точка внутри триангла?

#71
2:59, 6 дек. 2009

>> я нахожу баундинг бокс для триангла
какой баундинг-бокс ? т.е, зачем он вообще при рендеринге ?

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

вообще, неплохо бы аццкого растеризационного кода в студию, а то гадать тяжело.

#72
3:19, 6 дек. 2009

 L ,не я щас решил сделать через Edge & Span,через этот метод который ты описал очень затратно(у меня так раньше и было),так что не советую...

#73
10:15, 6 дек. 2009

Всё! Все заявленные технологии работают!

Sergio
> Mikle - около 38 кадров, порадовало освещение
Подозрительно мало. На AthlonX2 6000+ такая скорость сейчас, с фильтрацией, а та демка давала 63-65 fps.
Rean
Жду свет, пока твоя демка работает один в один с моей по скорости, если свет на моей тоже вырубить, проверял на двух компах, правда оба атлоны.
Fenix_alpha
У тебя включение фильтрации сильно смещает текстурные координаты.
namot
Скачал SDL.dll, а приложение (или винда) ругается, что она не для WindowsNT, хотя Яндекс утверждает обратное.

#74
11:38, 6 дек. 2009

Vinil
В рендерере одновременно присутствет только один треугольник, максимум буффер, но для беффера в 90% случаев такая оптимизация ник чему.
Как вариант использовать технику, которая используется при SLI:
вершины треугольника считаются в общем потоке.
буффер вывода делится на 4 части. Для каждоый части свой поток.
треугольник делится соотвественно тоже на 4 части.
каждый поток считает только ту часть треугольника, которая попадает в его зону.

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

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