Движок на Квесте.

[Sqwer]

Кто-нибудь создавал движок на Квесте?
интересны фитчи, устройство иерархии, устройство интерфейсов между внутридвижковых сущностей и т.д.

[DimiS]

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

есть 3 основных категории кода: Core, Library, Application

Ядро это набор менеджеров без которых ничё по сути не работает - конфиг менеджер, камера менеджер, лоадинг менеджер(лоадинг моделек), текстуре менеджер, шейдер менеджер и т.д Также там живут functions - это набор класиков облегчающих жизнь при программировании, например стек, сортированый список, хмл ридер/вритер
Библиотека это набор менеджеров использование которых не обязательно, но удобно иметь какие то заготовки. Это например WeatherManager, шедоумап, набор разных камер и разных дефолтных классов обжектов
Апликейшен это набор разных компонентов специфических для приложения в котором используется фреймворк, если какой то компонент начинает использоваться повторно в других проектах то он обычно тоже попадает в лайбрари.

Модельки у меня импортятся в виде списка нодов, списка сюрфейсов и списка материалов. Нод это имя + матрица + список дочерних сюрфейсов. Сюрфейс это 3дОбжектДата + текстура + ссылка на материал. Эта инфа хранится в базовых интерфейсах нода и сюрфейса, но класс сюрфейса обычно включает в себя несколько ещё допонительных интерфейсов, например NewtonBody(по обжект дате сюрфейса генерит колижен обжект), MouseOverListener(проверяет пересечение луча мыщки с обжект датой и потом инпут менеджер выбирает ближайший листенер)

ещё много чё можно написать, но мб меня не в ту степь несёт, задавай вопросы

[Sqwer]

он весь сделан с использованием квестового ОО, хз будет ли тебе интересна такая архитектура

Средство программирования  меня как раз интересует меньше всего. Важнее понять как у кого реализована иерархия сущностей.
ЗЫ делал  врапер  на квесте, далее слабый двиг на ДХ10, затем  пришлось  портировать его на Квест под ДХ9,  а теперь   двиг  после всех "набитых шишек"  на стадии редизайна с удобным фреймворком. на перспективах стоит внедрение  LUA на каждый менеджер.



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


А менеджеры выполняют роль контейнеров  сущностей? (хранят указатели на объекты,  возвращают указатели на целевые объекты по имени).


Как решается проблема бэквард визинга при удалении объектов.
Например ситуация с иерархией:  объект сцены -> материал -> effect ?
Иными словами    объект сцены состоит из материала , а материал использует данные  эффекта.

Так вот, при удалении  объекта Эффекта  происходит ли  удаление  всех материалов которые зависят  от данного эффекта, а далее  удаление всех объектов , которые используют эти материалы?


Как дела с многопоточной загрузкой данных?

Есть ли свой визуальный редактор, шейдерлаб?

Различные постэффекты, уникальные  объекты сцены(например скин объекты)  относятся  к "Library" или  индивидуально для проекта "Application".

[anval]

На счет материалов...Я решаю это так же как и Dimis(если я правиьно понял)т.е. jbject texture, object hlsl.Если надо скину примерчик...

[DimiS]

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

Менеджеры так, + у них ещё какие то дополнительные сервисные функции

Не знаю что такое бэквард визинг)) у меня в фреймворке не удаляются объекты, и не подгружаются на лету -- не было необходимости. Соответственно и многопоточной загрузки тоже нет. Но если б и было удаление то структуру с описанием параметров я бы удалял, а вот текстурки нет. Ну и мне кажется я не совсем понимаю что такое эффеект в твоём описании

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

Разница между аппликейшен и лайбрари по сути в том будет ли этот компонент использоваться в других проектах или нет. Какие то захардкоденые данные по моему в лайбрари попасть не должны никак)

[Sqwer]

to DimiS

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

и не стоит забывать, что полупрозрачные объекты  необходимо сортировать по дальности и отрисовывать. Для них  смена рендерстейтов не минуема.

Для этого лучше  иметьв арсенале 2 варианта рендера:
-Отрисовать все не полупрозрачные объекты эффекта.
-Отрисовать полупрозрачный объект.

Не знаю что такое бэквард визинг))

этот термен я сам придумал =)  но суть его описал. Это прослежка зависимости  по иерархии   от  перента к чилдрену  и обратно с сохранение ссылочной целостности при удаление одного из них.

такое эффеект в твоём описании

у меня класс эффект - это совокупность таких параметров как:
Рендер стейты:
-РастрСтейты
-ДептхСтейты
-БлендСтейты
Варианты рендера:
- Нормальный рендер
- Z pass рендер
- CubeMap рендер
- Depth рендер
- PSSM рендер
- CubeMap Depth рендер
Маска параметров шейдера:
- текстуры  (название текстуры в программе - тип текстуры - путь к папке - название текстурного семпла в шейдере)
- переменные (почти тоже самое)
Контейнер зарегестрированных графических сущностей для отрисовки с минимальным колвом смены рендер стейтов. (только для не полупрозрачных объектов)
Пару технических указателей DX. (шейдер, техники, пассы).
Константный буфер  на эффект.
и т.д.

В итоговом рендере всё сводится к простому:
если не полупрозрачные объекты
NME_Effect* pEffect = GetEffectMgr().GetEffect(index); // указатель на эффект
pEffect->SetZPassRender(); // установка типа рендера на Z препасс
pEffect->DrawEffect(); // отрисовка всех графических сущностей, зарегестрированных в эффекте
pEffect->SetNormalRender(); // установка типа рендера на Нормальный рендер
pEffect->DrawEffect(); // отрисовка всех графических сущностей, зарегестрированных в эффекте

если полупрозрачные
GetObjectMgr().GetObject(index)->DrawSelf();

[DimiS]

да, полупрозрачные потом рендерятся отдельно как ты и описал

двунаправленность связей между структурами это не какой то универсальный критерий правильности/неправильности или чего-то такого, просто иногда это надо, а иногда нет. Дерево нодов у меня двунаправленное, связь между нодами и сюрфейсами тоже, а вот связь между сюрфесами и материалами -- нет. И проблемы как ты описал при удалении эффекта у меня нет, не могу представить зачем вообще может понадобится его удалить.

и насколько я понимаю теорию отрисовки с отдельным рендером глубины, то нужно сначала сделать рендер глубины _всем_ эффектам, а потом нормал рендер _всем_ эффектам, не?

[Sqwer]

зачем вообще может понадобится его удалить.

1)-полный ингейм редактор;
2)-шейдерлаб;
3)-статистическая информация (кто кого имеет).

и насколько я понимаю теорию отрисовки с отдельным рендером глубины, то нужно сначала сделать рендер глубины _всем_ эффектам, а потом нормал рендер _всем_ эффектам, не?

ага всем не полупрозрачным эффектам

PS
глубина нужна например для простой тени. и мы все объеты рендим с позиции  от источника света.

затем переключаемся на камеру   и рендим  объекты  нормальным способом.

PSS
в ДХ10 можно читать дептх буффер как обычную текстуру и даже строить для неё мипы.