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

Renderer или Object::show()

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

Страницы: 1 2 Следующая »
#0
12:21, 22 янв. 2005

Тут начал серьёзно задумыватся о том что всё-таки лучше использовать. С одной стороны Renderer может позволить сделать некоторую оптимизацию о порядке вызова обьектов (? правда не уверен что оно того стоит ?). С другой стороны, при таком подходе он достаточно слабо расширяем. Унаследовать свой Object и переписать ему show по необходимости скорее всего будет проще чем менять что-то в Renderer-е. Особенно если над проектом паралельно работает много человек.
Соответсвенно отталкиваясь от второго варианта вся остальная идеология строится как Material::apply() ... Camera::look() ... Envirnoment::set()
Вот.
Хотелось бы услышать все за и против, да и вообще все мысли по этому поводу.

PS: Рендерер будет только OpenGL (читай всегда один) т.к. необходима портация под Линукс.


#1
13:09, 22 янв. 2005

Kernel
Вариант когда рисует ТОЛЬКО рендер.. я считаю лучшим.

Обект должен только дать понять как! рисовать его.. самого любимого =)
для этого используеться Материалы..

#2
13:54, 22 янв. 2005

IROV..
А что делать если обьект например состоит из нескольких материалов? Разбивать колесо на железо и резину на обьектном уровне когда заранее известно что они не разбираются не очень хорошо имхо.
Или Если обьект собирается процедурно каждый кадр причём заранее неизвестно сколько у него вершин, но известно что не много? (Тогда его можно вообще сделать через glBegin()/glEnd(), не издеваясь над памятью и не пиша сложные структуры для хранения геометрии ...)
Вообщем вариант хороший то он хороший, но на счёт лучший это всё-таки спорно.
А если б ты ещё и привел причины почему ты считаешь его лучшим - было бы замечательно...

#3
14:01, 22 янв. 2005

Kernel
Насчет Колеса.. Если ты хочеш чтобы колесо нарисовалось.. с разными материалами.. то без композиции(в любом виде) ты не обделаешся.. А вот Рендер. спокойно сможет собрать все обекты под одиним материалом..  и вывести 4 шины за раз..

#4
14:13, 22 янв. 2005

Ну тогда для этого не обязательно иметь именно Renderer. Достаточно просто чтоб GroupNode сортировал по материалам, а текущий материал делал бы свой Material::restore() только при применении следующего другого. А сортировка вне GroupNode( под ним я понимаю что-то на подобие TransformationNode + прочее) всё равно бессмысленна т.к. по крайнеё мере иерархия преобразований должна соблюдатся - и тогда придётся постоянно гонять MODELVIEW матрицу, что боюсь скорости не прибавит. С другой стороны внутри одного нода сортировка по материалам боюсь даст не столь уж заметный выигрыш.

#5
14:48, 22 янв. 2005

MODELVIEW матрица твоя последняя проблемма, при такой архитектуре.. :))
Сначала разберись, что за железяка внизу, как она работает и что ей надо. Ей надо группу вертексов, индексов, 2 шейдернъх программъ и кучу параметров - и все.
То что тъ параметрично можеш создавать геометрию, и думать что glBegin/glEnd-ом ее запихать можно сколько угодно тут ничего не меняют, ибо ето просто одна абстракция - буффер вертексов и индексов и там тоже будет.
Колесо, машина... не надо путать обьект для рендера, обьект для физики, обьект для AI. Колесо спокойно может бъть 2 рендер обьекта, с разнъми материалами и общей трансфромационной матрицей. Для физики ето будет один обьект, а для AI его не будет - ето все - машина.
Материал, ето набор параметров, для конкретной модели - ето может бъть список текстур, цветов и ефекта к етому мешу.
В ефекте можно иметь множество шейдеров (ffp тоже), для разнъх условий рендеринга етого обьекта, типа с и без тенью, для многих лампочек, для фильтра ночьного видения, для glow/HDR и т.д.
Т.е. рендер обьект дает рендеру информацию типа буфера (VB/IB), шейдер, матрицу трансформации, блок параметров для шейдеров и т.д.
Рендер собирает такие обьектъ, сортирует их если надо (и если реализация такова) и потом рисует.

#6
12:42, 23 янв. 2005

Zemedelec

Т.е. рендер обьект дает рендеру информацию типа буфера (VB/IB), шейдер, матрицу трансформации, блок параметров для шейдеров и т.д.
Рендер собирает такие обьектъ, сортирует их если надо (и если реализация такова) и потом рисует.

С этим то как раз и возникают сложности.
1.Вот например какой должен быть рендерер чтобы уметь рисовать саму геометрию в несколько проходов.
2.Быть ещё и многопроходным.

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


Моё мнение что по хорошему и тот и тот подход должны использоваться комплексно ( т.е. вместе).
Чтот то типа набора различный рендереров или group node ( вообщем как назвать не суть важно) кторые умеют батчить гемоетрию на низком уровне, делать сортировку по материалам.
А сам объект уже определяет в какой проход какого рендерера ему так сказать добавиться на отрисовку( всего или толко своей части), если нужно то в кучу проходов пусть добавляется и в кучу рендереров.

#7
14:41, 23 янв. 2005

С этим то как раз и возникают сложности.
1.Вот например какой должен быть рендерер чтобы уметь рисовать саму геометрию в несколько проходов.
2.Быть ещё и многопроходным.

и в чем же именно возникают сложности? что мещает ему быть многопроходным?

#8
14:43, 23 янв. 2005

подписка

#9
14:57, 23 янв. 2005

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

#10
15:23, 23 янв. 2005

Outlaw
Концепция материала (ефекта) описъвает как обьект въглядит и как реагирует на сцену - лампочку, туман  и т.д.
Многопроходность - характеристика материала. Где тут проблемма?
Всякие отражения - ето тоже может бъть характеристика материала водъ, которая может запросить карту отражения у движка, как и карту тени (shadowmap) или что-то наподобии.
Конечно надо иметь ввиду какой рендер реализуем, хотя все возможности можно заталкивать в материал и реализовать им нормальнъй рендеринг, deffered рендеринг если надо и т.д.
Просто у всех материалов должнъ имется шейдера для всех случаев.

#11
17:49, 23 янв. 2005

подписался

#12
22:03, 23 янв. 2005

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

#13
22:17, 23 янв. 2005

Kernel

Если шарик не имеет текстур, то не факт, что нужно отключать уже установленные текстуры на всех текстурных юнитах. То есть надо исследовать вопрос целесообразности (может, есть penalty по интерполяторам), а потом уже отключать или не отключать. Шарик содержит примерно такую информацию

single pass in material:
указатель на D3D пиксельный шейдер - одна штука
указатель на D3D вершинный шейдер - одна штука
массив указателей на текстуры (if any)
параметры вершинного и пиксельного шейдеров.
разные стейты типа блендинга и альфа, Z, стенсиль тестов.

указатель на геометрию, но это особая статья...

Так вот, если текстуры можно не менять на тех текстурных юнитах, которые не используются, то шейдеры и render-стейты надо менять обязательно. И чтобы нарисовать простецкий одноцветный шарик, мы волей-неволей должны проделать много работы. Или не проделать, если менеджер достаточно умен и сгруппировал одноцветные шарики. Информация о шарике ограничена этим самым джентльменским набором, который приведен выше. Больше ничего знать не надо. Но и меньше нельзя знать.

Так вот, расширяться набор сведений не может. Ни о каком наследовании речи с моей точки зрения не идет. Так как свойства single pass in material однозначно отображаются на внутренние D3D стейты.  Расширяться они не будут.

#14
22:22, 23 янв. 2005

Единственный вопрос, который на мой взгляд стОит обсуждения - это необходимость сохранять частичный порядок при рисовании. Скажем, сохранить грубый порядок от ближнего к дальнему. Или упорядоченность проходов. Или порядок рисования прозрачной геометрии. Но это ни разу не OOP-related вопросы. И никаким боком к наследованию, инкапсуляции и полиморфизму отношения не имеют ИМХО.

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

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