Архитектура рендера. (data holder <-> render agent architecture) (комментарии)

Архитектура рендера. (data holder <-> render agent architecture) (комментарии)

Это сообщение сгенерировано автоматически.

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

З.С. топег коментариев не видел, тупо тыкнул кнопку коментировать

kas
По поводу врапера, основная  мысль - нафиг не нужен ибо в конце-концов будет представлять клон АПИ отсюда и лишний код - посмотри XEngine яркий пример такого подхода.
По поводу того, почему меш не должен себя рендерить, как ты представляешь сортировку по материалам?  сортировка Z front-to-back? правильная отрисовка альфа канала(опять же сортировка)? то есть для любой обработки на уровни множества мешей - нужна централизующая единица - рендер агент, для каждого типа объектов он свой.

xmvlad
>По поводу врапера, основная мысль - нафиг не нужен ибо в конце-концов будет
>представлять клон АПИ отсюда и лишний код - посмотри XEngine яркий пример
>такого подхода.
а как тогда хранить данные о вершинах, индексы? или хранить их в массиве а при рендере делать буффер?

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

kas
>мех тупо знает свои буфера, какой шейдер поставить и материал.

захотелось было мне отражений, преломлений, шадоумапных теней и так далее :)

KleMiX
Смотри статью Путь №4: каждый объект data holder хранит некоторые "данные" - материал, вертексный и индексный буффер и т.д, которые и отдает своему агенту при вызове -> render.

kas
> значицо так, отвечаю попорядку. врапер он нужен для мультиапи
Описанная архитектура идеально подходлит для мультиапишности/мультиплатформенности. Пользователь работает с интерфейсом Static_Mesh, от Static_Mesh наследуются Static_Mesh_OGL, Static_Mesh_D3D, Static_Mesh_PS2(нда, размечтался) :)
, каждый из них хранит кастумные данные (OGL - ИДЫ VBO, текстур, шейдеры, D3D - указатели на КОМ объекты IDirect3DVertexBuffer9 и т.д), потом вызывается object_3d->render() они сливают все эти данные конкретному рендер агенту - Static_Mesh_Render_OGL, Static_Mesh_Render_D3D, Static_Mesh_Render_PS2 :), которые уже в рамках конкретной платформы/апи производят необходимую обработку. Опять же, можно сделать рендеринг скелетки на GPU/CPU.

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

MiF
не вижу проблемы, отражения/преломления какое отношения к меху имеют то? он просто себя рисует, материалы шейдеры и всякое другое ставят уровнем выше, траблов никаких. чичас прочитал выше песал что мех знает шейдера и т.д. я не имел ввиду что они хардкодед :) просто на момент рисования он их знает (:
xmvlad
вот как раз твоя схема плодит ужоснах скоко кода, причом большая часть етой тупой копипаст вызовов апи.
про граф сцены я ещё не осознал для себя до конца. думаю как у шодана в презентации - топлевел ноды - шейдеры, потом тикстуры, патом всё остальное, илиже чуть в другом порядке.

xmvlad
>Смотри статью Путь №4: каждый объект data holder хранит некоторые "данные" -
>материал, вертексный и индексный буффер и т.д, которые и отдает своему агенту
>при вызове -> render.
тогда появляется вопрос насчёт мульти апи, зачем ему хранить VertexBuffer к примеру если апи на данный момент огл?
Но потом обьяснение:
>Описанная архитектура идеально подходлит для мультиапишности/мультиплатформенности. Пользователь работает с интерфейсом >Static_Mesh, от Static_Mesh наследуются Static_Mesh_OGL, Static_Mesh_D3D, Static_Mesh_PS2(нда, размечтался) :)
>, каждый из них хранит кастумные данные (OGL - ИДЫ VBO, текстур, шейдеры, D3D - указатели на КОМ объекты IDirect3DVertexBuffer9 и т.д), >потом вызывается object_3d->render() они сливают все эти данные конкретному рендер агенту - Static_Mesh_Render_OGL, >Static_Mesh_Render_D3D, Static_Mesh_Render_PS2 :), которые уже в рамках конкретной платформы/апи производят необходимую обработку.
Но мне кажется что это не очень удобно...

kas
сразу хочется поинтересоваться - ты хоть одну реализацию рендера сложнее RenderObject->Render() делал? Если да, то опиши пожалуйста вкратце ее архитектуру

KleMiX
>тогда появляется вопрос насчёт мульти апи, зачем ему хранить VertexBuffer к
>примеру если апи на данный момент огл?

не понял, а почему не хранить?

MiF
я слышу сарказм?

kas
>я слышу сарказм?
нет, вполне конкретный вопрос

MiF
конечно писал, я делаю RenderObject->Update( dt ); а только потом RenderObject->Render()

kas
>конечно писал, я делаю RenderObject->Update( dt ); а только потом
>RenderObject->Render()

типа шутка чтоли? или я чего не понял?