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

Минимальный мультиплатформенный рендерер (2 стр)

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

Страницы: 1 2 3 4 Следующая »
#15
13:42, 30 окт. 2014

Поддержу, нужны: камера, лайт (light), меши (геометрия), текстуры, материaлы, + для многопроходного  рендеринга то еще проходы (всмысле render pass).
Ну и рендер класс с методами типа: set camera, set light, draw mesh, clear, etc

p.s.
>Вопрос в минимальном количестве методов при максимальной эффективности по возможностям и производительности
это противоречащие друг другу требования как мне кажется.


#16
13:51, 30 окт. 2014

Нужны:
1. рендерер для каждого апи
2. текстуры
3. меши и модели

#17
13:52, 30 окт. 2014

Ataman
> А в простом случае достаточно my_fbo.Bind(); glEnable (GL_DEPTH_TEST). Или для
> эффективности if (some_ext_exist) { my_nv_specific_render_func(); }

Разбиение на мелкие сущности... Во-первых, этот самый my_fbo нужно создать как-то (явный конструктор или фабрика ). Во-вторых, даже при минимальном fbo нужно как-то создать текстуру ( и этот код должен быть независим от gapi ) чтобы fbo заработало.  И стейты, тоже не ахти как - и кеширование, и разнос стейтов по блокам в DX11

Outlaw
> > опрос в минимальном количестве методов при максимальной эффективности по
> > возможностям и производительности
> это противоречащие друг другу требования как мне кажется.

Есть такое понятие - минимакс

Void12
> 1. рендерер для каждого апи

Какой хитрый. Его интерфейс, пожалуйста

bazhenovc
> Посмотри в сторону BGFX, она очень удачно сделана в плане
> мультиплатформенности.

Вижу, нечто подобное, только поменьше методов - createTexture* 4 штуки лишние :)

#18
13:54, 30 окт. 2014

Учитывая сложность универсального решения, я считаю, что нужно опираться на высокоуровневую часть, например - сцена(мир), лайты, игровые сущности с атрибутами (тип материала, текстура).
А низкоуровневую часть писать для каждого API свою, не универсальную.
Гибкость обеспечивать настройками, которые определяются в высокоуровневой части (например, тип освещения, дистанции прорисовки, параметры лодов, где нужны тени, где не нужны, параметры партиклов, прозрачен ли объект, какие эффекты на объекте и прочее).

В высокоуровневой части для отрисовки должна быть только функция Render ( ссылка scene + набор параметров исходных, определяющих всю инфу для рисования).
А низкоуровненая часть в зависимости от API делает все по своему.

Кода придется писать конечно немало, но зато нет затыков на обеспечение универсальности (что сделать сейчас сложнее, чем во времена 3го квейка (без шейдеров)).

#19
14:01, 30 окт. 2014

innuendo
> Разбиение на мелкие сущности
Ну ты скажи для чего тебе. Только на десктоп (вин/мак), на телефоны, старые апи? В любом случае, если делать "эффективно", особенности платформы могут налагать ограничения и на пайплайн (деферред/форвард). Может быть вообще ограничится одним апи на платформу?

#20
14:04, 30 окт. 2014

Ataman
> Ну ты скажи для чего тебе. Только на десктоп (вин/мак), на телефоны, старые
> апи?

Пока десктопы, потом и мобилки планируется

> Может быть вообще ограничится одним апи на платформу?

Весь смысл, чтобы платформонезависимого кода было как можно больше - и чтобы обертки всего дела что внутри не тормозили - вот как-то  так


> особенности платформы могут налагать ограничения и на пайплайн
> (деферред/форвард).

Это уже другой разговор.

#21
14:38, 30 окт. 2014

innuendo
> Пока десктопы, потом и мобилки планируется
Ну десктоп и мобилки настолько по мощности отличаются, что рассчитывать на единый рендерный пайплайн не надо. Плюс екстеншены от вендоров. Проще скопипастить и "по месту" поправить, чем бояться сломать что-то ненароком.

> Весь смысл, чтобы платформонезависимого кода было как можно больше - и чтобы
> обертки всего дела что внутри не тормозили - вот как-то так
Иногда лучше простой платформозависимый код, который будет тупо портироваться в рамках отдельного проекта, чем сложный "платформонезависимый" с кучей ифдефов и перманентной нервотрепкой при сборке и тестах.

#22
15:21, 30 окт. 2014

Ataman
> Ну десктоп и мобилки настолько по мощности отличаются, что рассчитывать на
> единый рендерный пайплайн не надо

Ok. Забудем про Deferred :) Есть просто спрайты с простеньким шейдером аля sm2.0 - нужно чтобы запускалось на всех платформах с минимум кода и головной боли

#23
15:26, 30 окт. 2014
innuendo
> минимакс
Не удержался:
+ Показать

Минимакс
#24
15:31, 30 окт. 2014

innuendo
> Есть просто спрайты с простеньким шейдером

Софтверный рендер с GAPI интерфейсом в виде blt( SrcMemBitmap ), не ?

#25
16:20, 30 окт. 2014

innuendo
> Какой хитрый. Его интерфейс, пожалуйста

пожалуйста:

+ Показать

#26
16:27, 30 окт. 2014

Void12
> RenderQueue;

В него что-то входит, я даже догадываюсь что. Как это самое создаётся ?

#27
16:53, 30 окт. 2014

innuendo

typedef std::unordered_map<IBaseModelRenderer *, std::vector<IActor *>> RenderQueue;
вот же...

вызов рендера:

+ Показать

это специально для поддержки инстансов.
НО! происходит составление вектора, а это плохо в плане производительности...
переделать надо будет потом

#28
16:57, 30 окт. 2014

Void12
> вот же...
> вызов рендера:

Ты не понял. У RenderDevice есть ресурсы. Прежде чем поюзать, их нужно создать

#29
17:08, 30 окт. 2014

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

и у каждого актёра есть или прямой указатель на модель, или имя файла для ресурс менеджера.

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

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