IPB

Здравствуйте Гость ( Вход | Регистрация )

 
Reply to this topicStart new topicStart Poll

Каскадный · [ Стандартный ] · Линейный

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

v1s0r
post Понедельник, 01 Марта 2010, 23:20
Отправлено #1


Knight
Group Icon

Группа: Members
Сообщений: 125
Регистрация: 7-Дек-09
Из: Санкт-Петербург
Пользователь №: 5,699



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

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

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

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

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

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

Сообщение отредактировал v1s0r - Четверг, 04 Марта 2010, 09:55


--------------------
Windows - аналог плохо понятых механизмов Unix
Use Linux - open your mind
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
v1s0r
post Четверг, 04 Марта 2010, 20:45
Отправлено #2


Knight
Group Icon

Группа: Members
Сообщений: 125
Регистрация: 7-Дек-09
Из: Санкт-Петербург
Пользователь №: 5,699



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

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

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

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

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

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

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


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

Сообщение отредактировал v1s0r - Четверг, 04 Марта 2010, 21:02


--------------------
Windows - аналог плохо понятых механизмов Unix
Use Linux - open your mind
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
v1s0r
post Четверг, 04 Марта 2010, 21:47
Отправлено #3


Knight
Group Icon

Группа: Members
Сообщений: 125
Регистрация: 7-Дек-09
Из: Санкт-Петербург
Пользователь №: 5,699



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

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

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


--------------------
Windows - аналог плохо понятых механизмов Unix
Use Linux - open your mind
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
Sagrer
post Суббота, 06 Марта 2010, 09:56
Отправлено #4


Wizard
Group Icon

Группа: Members
Сообщений: 304
Регистрация: 24-Дек-01
Из: Курска
Пользователь №: 16



Имхо надо:

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

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

Сообщение отредактировал Sagrer - Суббота, 06 Марта 2010, 09:57


--------------------
Gipat Group
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
Durane
post Суббота, 06 Марта 2010, 13:30
Отправлено #5


Knight
Group Icon

Группа: Members
Сообщений: 143
Регистрация: 9-Ноя-04
Из: Ukraine, Kiev
Пользователь №: 2,839



QUOTE(v1s0r @ Четверг, 04 Марта 2010, 20:47)
2. Нужно уметь быстро отсортировать секторы, на которые разбит ландшафт, отфильтровать и отправить в очередь рендеринга.



QuadTree тебе в помощь smile.gif


--------------------
user posted image

user posted image
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
v1s0r
post Воскресенье, 07 Марта 2010, 09:48
Отправлено #6


Knight
Group Icon

Группа: Members
Сообщений: 125
Регистрация: 7-Дек-09
Из: Санкт-Петербург
Пользователь №: 5,699



QUOTE(Sagrer @ Saturday, 06 March 2010, 09:56)
1) класс, который просто парсит содержимое mpr-ки и пишет это в себя в удобном для использования виде. При необходимости на его основе можно написать и потомка с функцией записи. В самом классе при этом хранится вся инфа, какая может потребоваться движку.
*


Согласен. Сейчас так есть. Есть ресурсные классы для mpr, fig. Там только загрузка, никакого мусора для рендеринга или логики.
QUOTE(Sagrer @ Saturday, 06 March 2010, 09:56)
2) для конкретных задач (визуализация, просчёт проходимости и всё такое прочее) - либо отдельные классы (если для оптимизации надо выбрать какую-то конкретную инфу из класса mpr-ки и переработать её определённым образом - тогда конструктору этого класса можно по ссылке кидать класс mpr-ки), либо просто функции или методы других классов, в которые передаётся ссылка на класс с инфой из mpr-ки - если достаточно просто взять инфу из класса mpr-ки и это особо не повлияет на производительность.
*


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

Добавил: v1s0r
QUOTE(Durane @ Saturday, 06 March 2010, 13:30)
QuadTree тебе в помощь smile.gif
*


Не, он подождёт, оганичимся обычным 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 и получить корректную картинку.

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


--------------------
Windows - аналог плохо понятых механизмов Unix
Use Linux - open your mind
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
Sagrer
post Воскресенье, 07 Марта 2010, 15:28
Отправлено #7


Wizard
Group Icon

Группа: Members
Сообщений: 304
Регистрация: 24-Дек-01
Из: Курска
Пользователь №: 16



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


--------------------
Gipat Group
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
v1s0r
post Воскресенье, 07 Марта 2010, 16:24
Отправлено #8


Knight
Group Icon

Группа: Members
Сообщений: 125
Регистрация: 7-Дек-09
Из: Санкт-Петербург
Пользователь №: 5,699



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


--------------------
Windows - аналог плохо понятых механизмов Unix
Use Linux - open your mind
User is offlineProfile CardPM
Go to the top of the page
+Quote Post
v1s0r
post Понедельник, 15 Марта 2010, 20:59
Отправлено #9


Knight
Group Icon

Группа: Members
Сообщений: 125
Регистрация: 7-Дек-09
Из: Санкт-Петербург
Пользователь №: 5,699



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


--------------------
Windows - аналог плохо понятых механизмов Unix
Use Linux - open your mind
User is offlineProfile CardPM
Go to the top of the page
+Quote Post

Reply to this topicTopic OptionsStart new topic
2 чел. читают эту тему (2 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
 

Упрощённая версия Сейчас: 19 Июля 2019 - 00:14