Архитектура движка Cursed Earth

[v1s0r]

О как завернул)))

На самом деле понятия не имею с чего начать.

Наверно, для начала пара общих слов. Зачем всё это? Никаких готовых движков использоваться не будет. Будем делать велосипед. Готовые движки же будем использовать на работе (условно). Моя цель - научиться. Все, у кого похожие цели - добро пожаловать.

По поводу реализации - предлагаю здесь об этом забыть. Неважно, что на C. Если будет нереализуемо на C, перейдём на C++.

За основу можно взять здравые идеи из готовых движков Irrlicht, OGRE (я уже вовсю их читаю). В общем, приглашаются все желающие, кому есть что сказать!

П.С. Можно попробовать начать с системы ресурсов. Как что-то оформлю в голове, напишу.

[v1s0r]

Так, пора что-то написать.
Только без рисунков пока!

Хочу начать с мешей и иже с ними.
У нас 2 вида ресурсов-мешей: ландшафт и модельки.

1. Сериализация, загрузка данных с ресурсов. Будет набор классов, в которых содержатся сырые данные, структурированные. Например, в mpr есть свои материалы. Но суть одна: это некий поток данных, которые нужно причесать. Например, в mpr нет вершин. А в fig есть, но их нужно извлекать с учётом некоторых параметров.

2. Создание мешей из сериализованных данных. Меш - хранилище вершин, нормалей, ..., анимаций в удобном виде (редактирование?).

3. Конкретные экземпляры, использующие один меш (по мере возможности...).

4. Визуализация. Хотелось бы хранить вершины где-то поблизости с памятью видеокарты. В OGL это могут быть буферы вершин или списки. Для этого будет создан класс, скрывающий конкретную реализацию хранения вершин. Он то и будет отсылаться на рендеринг.

Это общая структура, без деталей. Хз, хоть какое-то начало))


Добавил: v1s0r [mergetime]1267724716[/mergetime]
А вообще, если хорошо подумать, запихнуть уровень и модели под один интерфейс не получится (и надо ли?). В меше модели должны храниться "запакованные" вершины, чтобы делать из них экземпляры с разными характеристиками (рост, вес, ...).
Надо чтобы кто-нибудь настучал по башке, пока не натворил дел...

[v1s0r]

Если подумать о ландшафте...
Нужную информацию можно разбить на 2 составляющие: для логики и для визуализации.

Для логики.
1. Границы зоны.
2. Высота в заданной точке.
3. Подскажите, что ещё...

Для визуализации.
1. Вершины, текстурные координаты, ...
2. Нужно уметь быстро отсортировать секторы, на которые разбит ландшафт, отфильтровать и отправить в очередь рендеринга.
3. Вроде больше ничего...

[Sagrer]

Имхо надо:

1) класс, который просто парсит содержимое mpr-ки и пишет это в себя в удобном для использования виде. При необходимости на его основе можно написать и потомка с функцией записи. В самом классе при этом хранится вся инфа, какая может потребоваться движку.
2) для конкретных задач (визуализация, просчёт проходимости и всё такое прочее) - либо отдельные классы (если для оптимизации надо выбрать какую-то конкретную инфу из класса mpr-ки и переработать её определённым образом - тогда конструктору этого класса можно по ссылке кидать класс mpr-ки), либо просто функции или методы других классов, в которые передаётся ссылка на класс с инфой из mpr-ки - если достаточно просто взять инфу из класса mpr-ки и это особо не повлияет на производительность.

Вот такая имха ). Но я движки никогда не писал, если что %).

[Durane]

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

QuadTree тебе в помощь

[v1s0r]

1) класс, который просто парсит содержимое mpr-ки и пишет это в себя в удобном для использования виде. При необходимости на его основе можно написать и потомка с функцией записи. В самом классе при этом хранится вся инфа, какая может потребоваться движку.
[right][snapback]40132[/snapback][/right]

Согласен. Сейчас так есть. Есть ресурсные классы для mpr, fig. Там только загрузка, никакого мусора для рендеринга или логики.

2) для конкретных задач (визуализация, просчёт проходимости и всё такое прочее) - либо отдельные классы (если для оптимизации надо выбрать какую-то конкретную инфу из класса mpr-ки и переработать её определённым образом - тогда конструктору этого класса можно по ссылке кидать класс mpr-ки), либо просто функции или методы других классов, в которые передаётся ссылка на класс с инфой из mpr-ки - если достаточно просто взять инфу из класса mpr-ки и это особо не повлияет на производительность.
[right][snapback]40132[/snapback][/right]

Здесь у нас полное взаимопонимание)
За ландшафт у меня отвечает классец terrain. В нём 2 вида инфы: набор классов для рендеринга и минимальная порция переработанных данных из mpr для логики.

Добавил: v1s0r [mergetime]1267944497[/mergetime]

QuadTree тебе в помощь
[right][snapback]40133[/snapback][/right]

Не, он подождёт, оганичимся обычным frustum (который уже давно используется).
Я имел в виду нечто иное.
Последнее время ломал голову насчёт того, как построить конвеер рендеринга.
Читал код движков и вот к чему пришёл. Я сомневаюсь, что получится эффетивно реализовать единый класс для рендеринга зоны и объектов. Кто знает mpr в курсе, что там информация уложена весьма специфически. Например, в OpenGL нет смысла делать огромные буферы для вершин для mpr (с учётом дублирования текстурных координат...). А можно прямо сразу отдать в видеопамять. А в fig устроен более традиционно.

Вот набросок иерархии, которую я смог оформить на данный момент.
1. Render Item - абстрактный класс.
Он умеет визуализировать себя. Также есть данные об ограничивающих телах и данные для сортировки.
Его реализуют ландшафт, фиг без морфинга и фиг с морфингом. Тем самым мы избегаем тупого перекопирования большого объёма данных, а укладываем их максимально эффективно для каждого типа.

2. Render Layer - просто контейнер для удобства. Плюс свои ограничивающие тела, чтобы можно было отбросить сразу все Render Item.

3. Render Queue - очередь из Render Item. Принимает много Render Layer, фильтрует из них Render Item с учётом отсечений, раскладывает на прозрачные/непрозрачные и сортирует.

После чего можно сказать Render Queue -> render и получить корректную картинку.

Как то так... хотелось бы критики)

[Sagrer]

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

[v1s0r]

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

[v1s0r]

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