+- Город Джунов (https://www.gipat.ru/forum)
+-- Форум Аддон для Проклятых Земель (https://www.gipat.ru/forum/forum-20.html)
+--- Форум Программирование (https://www.gipat.ru/forum/forum-6.html)
+--- Темы: Архитектура движка Cursed Earth (/thread-3374.html)
Архитектура движка Cursed Earth - v1s0r - 02.03.2010
О как завернул)))
На самом деле понятия не имею с чего начать.
Наверно, для начала пара общих слов. Зачем всё это? Никаких готовых движков использоваться не будет. Будем делать велосипед. Готовые движки же будем использовать на работе (условно). Моя цель - научиться. Все, у кого похожие цели - добро пожаловать.
По поводу реализации - предлагаю здесь об этом забыть. Неважно, что на C. Если будет нереализуемо на C, перейдём на C++.
За основу можно взять здравые идеи из готовых движков Irrlicht, OGRE (я уже вовсю их читаю). В общем, приглашаются все желающие, кому есть что сказать!
П.С. Можно попробовать начать с системы ресурсов. Как что-то оформлю в голове, напишу.
Архитектура движка Cursed Earth - v1s0r - 04.03.2010
Так, пора что-то написать.
Только без рисунков пока!
Хочу начать с мешей и иже с ними.
У нас 2 вида ресурсов-мешей: ландшафт и модельки.
1. Сериализация, загрузка данных с ресурсов. Будет набор классов, в которых содержатся сырые данные, структурированные. Например, в mpr есть свои материалы. Но суть одна: это некий поток данных, которые нужно причесать. Например, в mpr нет вершин. А в fig есть, но их нужно извлекать с учётом некоторых параметров.
2. Создание мешей из сериализованных данных. Меш - хранилище вершин, нормалей, ..., анимаций в удобном виде (редактирование?).
3. Конкретные экземпляры, использующие один меш (по мере возможности...).
4. Визуализация. Хотелось бы хранить вершины где-то поблизости с памятью видеокарты. В OGL это могут быть буферы вершин или списки. Для этого будет создан класс, скрывающий конкретную реализацию хранения вершин. Он то и будет отсылаться на рендеринг.
Это общая структура, без деталей. Хз, хоть какое-то начало))
Добавил: v1s0r [mergetime]1267724716[/mergetime]
А вообще, если хорошо подумать, запихнуть уровень и модели под один интерфейс не получится (и надо ли?). В меше модели должны храниться "запакованные" вершины, чтобы делать из них экземпляры с разными характеристиками (рост, вес, ...).
Надо чтобы кто-нибудь настучал по башке, пока не натворил дел...
Архитектура движка Cursed Earth - v1s0r - 04.03.2010
Если подумать о ландшафте...
Нужную информацию можно разбить на 2 составляющие: для логики и для визуализации.
Для логики.
1. Границы зоны.
2. Высота в заданной точке.
3. Подскажите, что ещё...
Для визуализации.
1. Вершины, текстурные координаты, ...
2. Нужно уметь быстро отсортировать секторы, на которые разбит ландшафт, отфильтровать и отправить в очередь рендеринга.
3. Вроде больше ничего...
Архитектура движка Cursed Earth - Sagrer - 06.03.2010
Имхо надо:
1) класс, который просто парсит содержимое mpr-ки и пишет это в себя в удобном для использования виде. При необходимости на его основе можно написать и потомка с функцией записи. В самом классе при этом хранится вся инфа, какая может потребоваться движку.
2) для конкретных задач (визуализация, просчёт проходимости и всё такое прочее) - либо отдельные классы (если для оптимизации надо выбрать какую-то конкретную инфу из класса mpr-ки и переработать её определённым образом - тогда конструктору этого класса можно по ссылке кидать класс mpr-ки), либо просто функции или методы других классов, в которые передаётся ссылка на класс с инфой из mpr-ки - если достаточно просто взять инфу из класса mpr-ки и это особо не повлияет на производительность.
Вот такая имха ). Но я движки никогда не писал, если что %).
Архитектура движка Cursed Earth - Durane - 06.03.2010
v1s0r,Четверг, 04 Марта 2010, 20:47 Написал:2. Нужно уметь быстро отсортировать секторы, на которые разбит ландшафт, отфильтровать и отправить в очередь рендеринга.
QuadTree тебе в помощь
Архитектура движка Cursed Earth - v1s0r - 07.03.2010
Sagrer,Saturday, 06 March 2010, 09:56 Написал:1) класс, который просто парсит содержимое mpr-ки и пишет это в себя в удобном для использования виде. При необходимости на его основе можно написать и потомка с функцией записи. В самом классе при этом хранится вся инфа, какая может потребоваться движку.Согласен. Сейчас так есть. Есть ресурсные классы для mpr, fig. Там только загрузка, никакого мусора для рендеринга или логики.
[right][snapback]40132[/snapback][/right]
Sagrer,Saturday, 06 March 2010, 09:56 Написал:2) для конкретных задач (визуализация, просчёт проходимости и всё такое прочее) - либо отдельные классы (если для оптимизации надо выбрать какую-то конкретную инфу из класса mpr-ки и переработать её определённым образом - тогда конструктору этого класса можно по ссылке кидать класс mpr-ки), либо просто функции или методы других классов, в которые передаётся ссылка на класс с инфой из mpr-ки - если достаточно просто взять инфу из класса mpr-ки и это особо не повлияет на производительность.Здесь у нас полное взаимопонимание)
[right][snapback]40132[/snapback][/right]
За ландшафт у меня отвечает классец terrain. В нём 2 вида инфы: набор классов для рендеринга и минимальная порция переработанных данных из mpr для логики.
Добавил: v1s0r [mergetime]1267944497[/mergetime]
Durane,Saturday, 06 March 2010, 13:30 Написал:QuadTree тебе в помощьНе, он подождёт, оганичимся обычным frustum (который уже давно используется).
[right][snapback]40133[/snapback][/right]
Я имел в виду нечто иное.
Последнее время ломал голову насчёт того, как построить конвеер рендеринга.
Читал код движков и вот к чему пришёл. Я сомневаюсь, что получится эффетивно реализовать единый класс для рендеринга зоны и объектов. Кто знает mpr в курсе, что там информация уложена весьма специфически. Например, в OpenGL нет смысла делать огромные буферы для вершин для mpr (с учётом дублирования текстурных координат...). А можно прямо сразу отдать в видеопамять. А в fig устроен более традиционно.
Вот набросок иерархии, которую я смог оформить на данный момент.
1. Render Item - абстрактный класс.
Он умеет визуализировать себя. Также есть данные об ограничивающих телах и данные для сортировки.
Его реализуют ландшафт, фиг без морфинга и фиг с морфингом. Тем самым мы избегаем тупого перекопирования большого объёма данных, а укладываем их максимально эффективно для каждого типа.
2. Render Layer - просто контейнер для удобства. Плюс свои ограничивающие тела, чтобы можно было отбросить сразу все Render Item.
3. Render Queue - очередь из Render Item. Принимает много Render Layer, фильтрует из них Render Item с учётом отсечений, раскладывает на прозрачные/непрозрачные и сортирует.
После чего можно сказать Render Queue -> render и получить корректную картинку.
Как то так... хотелось бы критики)
Архитектура движка Cursed Earth - Sagrer - 07.03.2010
кста, насчёт текстур рельефа - ты будешь накладывать отдельными тайлами, или генерить текстуру целиком для сектора и наклеивать уже то что получилось? Имхо если генерить - сожрёт больше видеопамяти, но может быть будет быстрее %).
Архитектура движка Cursed Earth - v1s0r - 07.03.2010
Вообще я уже полностью реализовал рельеф - текстурирую отдельными тайлами.
Делал предварительный профайлинг (чуток) - текстуры отжирают прилично. Насчёт генерить - можно будет попробовать, я это учту.
Архитектура движка Cursed Earth - v1s0r - 15.03.2010
Я не забыл про эту тему, скоро обязательно всё распишу в красках, просто сейчас дел тьма, не до писанины.
Пока же, кто заинтересуется какой-либо частью движка, пишите здесь - отвечу.