Войти
ПрограммированиеФорумОбщее

Вопросы (рассуждения) о конструкции движка

Страницы: 1 2 3 Следующая »
#0
23:11, 26 июля 2009

Привет всем.

Сразу к делу.  (буду задавать по одному вопросы)

Есть у меня графический движок а есть игровой...  в графическом  у сцены есть сценеграф, там, всякие узлы его (модели, свет и.т.д. это узлы сценеграфа ). Ввот хочу я чтобы, К ПРИМЕРУ, ручка двери двигалась вместе с дверью!  тобишь мне тут нужна иерархия, где дверь будет родительским узлом для ручки...  для ручки просчитываем матрицу умножая её мировую на родительскую.. тут всё ясно..  а вопрос вот:  где это лучше сделать (эту иерархию)  в графическом движке? или в игровом?

#1
23:14, 26 июля 2009

В игровом.

#2
23:30, 26 июля 2009

Нужно при модделинге сделать дверь с ручкой и все.

#3
23:30, 26 июля 2009

где в игровом?  ещё 1 граф строить?

#4
23:32, 26 июля 2009

Pokimon
> Нужно при модделинге сделать дверь с ручкой и все.
арррр  ну я ж жирным выделил ДЛЯ ПРИМЕРА  ну хорошо...  ОРУЖИЕ прикрепить к автомобилю : )

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

#5
23:35, 26 июля 2009

Pokimon
> где в игровом? ещё 1 граф строить?
Кто тебе мешает, например, передать указатель на граф в графическую систему?
Графическая система обойдет граф, найдет те объекты, которые сможет отобразить и нарисует их.

Можно сформировать в игровой системе массив объектов и матриц к ним, и передать в графическую систему.

#6
23:39, 26 июля 2009

Demiurg-HG
> Кто тебе мешает, например, передать указатель на граф в графическую систему?
игровой и графический движки у мну отдельны

#7
1:05, 27 июля 2009

heihachi
Ну насколько отдельны?
Игровой ведь точно знает про графический, верно?
Ну вот и пусть предоставляет графическому некие интерфейсы...или нет?

#8
8:30, 27 июля 2009

heihachi
Как ты хранишь модели в движке?  Вообщем тебе подойдёт так: есть обьект, содержащий инфу для рендера, физики и т.д. (авто, корабль, дверь) + матрица трансформации + вектор, содержащий объекты таково же, подчинённые родителю (оружие для автомобиля, контейнеры на корабле, ручка двери). При рендере последовательно умножаешь матрицы трансформации.

#9
11:32, 27 июля 2009

KaronatoR
> Ну насколько отдельны?
на 100%  : )  2 отдельных проекта какбе изначально..

в GameEngine  юзаю DLL  LifeEngine (графический) 

Alexcru
> Как ты хранишь модели в движке?
в графическом у меня так:
есть объекты -  статичный, динамичный, система частиц и т.д.  все они узлы сцены (SceneNode), все находятся в SceneGraph
"внутри" объектов содержится ссылка на геометрию (Geomertic класс), ссылки на текстуры, материалы сабсетов и т.д.

Какбе ресурсы хранятся в буфферах в DataManager а объекты (в графическом понимании) держат на них ссылки и находятся в SceneGraph

в игровом - пока оченть тупо.. просто массив объектов Entity  в которых есть ссылка на графический объект в графическом двиге и ссылка на физический объект в ODE

#10
11:33, 27 июля 2009

Alexcru
> При рендере последовательно умножаешь матрицы трансформации.
я в курсе, как прицепить один объект к другому, вопрос в том, где ПРАВИЛЬНЕЙ это будет сделать?  в графическом или в игровом движке?

#11
14:08, 27 июля 2009

Наверное все же в игровом, т.к. оружие может упасть, ручка отвалиться. Если гарантированно нет, то зачем ручке нужна отдельная матрица? Переводим сразу в пространство двери и вперед...

#12
14:50, 27 июля 2009

Dronas
> Наверное все же в игровом
ну я какбы тоже так думаю, тогда опять вопрос, где именно?  опять строить граф объектов?

#13
15:44, 27 июля 2009

Так,и вдогонку сразу второй вопрос (не забывая, конечно, о первом).

С объектами любыми у меня всё пучком. Но вот с растительностью я особо не заморачивался. Я обычно ставлю её по 1 объекту как StaticObject и всё.  Думаю уже давно пора это переделать. Как обычно у Вас хэндлится растительноть,хранится и рисуется?

Вот как я хочу сделать (покритикуйте):

1. Сделать перечисление типов растительности:
Grass, Tree, Bush, Unknown  (к примеру).
Это(наверно) нужно, чтоб знать, что это за растительность. Зная тип растительности  - по разному с ней работаем, например: деревья дальние заменять на импостеры, а  траве импостеры не нужны, просто куллим по дереву, фруструму, дальности.

2. для каждого загруженного типа растительности держим динамический массив их позиций
Да, только позиций, поворачивать растительность я НЕ буду и это точно. И скейлить тоже НЕ буду.
Добавляя дерево на ландшафт, я просто дописываю положение нового дерева в контейнер с позициями деревьев.

3. юзаю инстансинг (у меня сейчас только хардварный но могу и константный сделать)  - беру геометрическое представление дерева,беру позиции из контейнера с позициями и рисую инстансингом деревья (тоже и с другой растительностью)

Edit: скоорее всего нужно держать не только позицию но и тип дерева (деревья же разные)

прошу жестокой критики

#14
15:58, 27 июля 2009

У нас вся растительность - гейм обьект, для редактора. В игре, где редактора нет деревья видно только вблизи, вдали - спрайтъ. Травка - запеченнъе буфера с позициями, ротациями и типом травки - для инстансинга. Инстансинг есть и для деревьев.
Нормал меп отрубается после некой дистанции, примерно метров 20-30. На 50-100 вообще деревьев уже нет, одни спрайтъ.
Также растительность вдали юзает шедоумеп более ниского разрешения, но ето не на PC, там такое я не делал.

Граф для куллинга обьектов хорошо сделать так, чтобъ вдали в нем бъло действительно только то, что видно, т.е. деревья, которъе исчезают и превращяются в спрайтъ - чтобъ бъли отдельно.
Чтобъ можно бъло куллить слоями - весь фрустум для больших обьектов / патчей с импостерами, фрустум только вблизи - для растительности, ближних чарактеров и всякой мелочи.

Страницы: 1 2 3 Следующая »
ПрограммированиеФорумОбщее

Тема в архиве.