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

[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 и получить корректную картинку.

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