Здравствуйте. Проблема следующая: для реализации коллизии объекта с миром необходимо получить высоту ландшафта в заданной точке [x , y]. Допустим посчитать высоту этой точки зная какому треугольнику она пренадлежит я смогу. Если ландшафт загружается из карты высот, то узнать какой это треугольник не составит особой проблемы. Но если мир загружается не из карты высот, а из файла экспортируемого 3DMax'ом, и представляет собой линейный массив вершин и массив граней содержащий индексы пренадлежащих грани вершин, то поиск нужного треугольника может выглядеть как простой перебор этого массива, что сильно ударит по производительности.
 Как найти нужный треугольник более быстрым способом? Перейти на загрузку из карты высот не получится, так как ландшафт это не поле, а город, не думаю что уместно город создавать как карту высот. Единственный вариант, что я пока вижу - это создать карту высот отдельно и загружать вместе с ландшафтом специально для обработки физизики.
 Ваше мнение. Спасибо.

OctTree поможет

Его использование будет быстрее чем дополнительная карта высот с моделью? Ведь получить треугольник с карты высот очень просто, а сама реализация Octree(которая мне пока не знакома) может занять больше вычеслений.

использование OctTree логичнее.
Ваш алгоритм подразумевает две независимых геометрии, что нелогично и потребует от художников лишней работы.
Зачем?
В любом случае с OctTree разбираться придется. На самом деле за этим страшным словом прячется довольно простая технология.
Если планируете профессионально работать в геймдеве, то с деревьями всеравно придется знакомиться. Лучше раньше.

P.S.
К томуже карта высот работает только с простыми поверхностями.

Октарное дерево - это разбиение сцены на кубы. В моем случае я думаю проще было бы использовать разбиение на квадраты. Но опять же разбиение на кубы необходимо для рендеринга сцены, таким образом использовать октарное дерево придется в любом случае.

 Можно совет?
Лутше создавать класс для работы с OctTree и для каждого объекта использовать свой энкземпляр класса, чтобы было проще хранить такие данные как координаты текстур и само разбиение объекта на кубы будет происходить один раз?
Или все же писать один модуль в который будут вноситься все грани сцены (возможно с сылкой на объект) и обрабатываться/отрисовываться вместе? Думаю в этом случае динамические объекты придется разбивать на кубы постоянно.

 P.S.
   Мне кажется, что я уже ответил на свой вопрос(энкземпляр класса TOctTree для каждого объекта). Но все же хочется услышать Ваше мнение.

я делаю сцену из независимых объектов.
А уже конкретные объекты определяю в блоки OctTree(одно дерево).

То есть предположим объекты: земля, дом, пенек они все статичные и их можно занести в одно дерево, а автомобиль в это дерево не заносим, но как же тогда поступить с отсечением ненужных граней авто, да и обработку столкновений двух динамических объектов?
 Думаю если создавать для каждого динамического объекта свое дерево, могут возникнуть проблемы с преобразованием локальных координат в глобальные.
 Вот, уже запутался, ведь ничего не получится если деревьев несколько, они не связаны между собой и говорить о их взаимодействии бессмысленно.

Почему динамический объект нельзя занести в дерево?

Потому, что дерево строится один раз. Если заносить в его динамические объекты, то это дерево само по себе станет динамическим, будет требовать построение на каждый тик, не ударит ли это по производительности?

> [8] Galiaf   (17.06.09 16:26)

Строить дерево каждый тик не надо, надо лишь перемещать динамические объекты, котороые этого требуют. Это не ударит.

Значит придется указать дереву какие объекты статические, а какие динамические, и на каждый тик, выстраивать дерево смотря только на вершины динамических объектов, а вершины статических оставить на месте не трогая?
 Ведь при перемещении объектов по сцене, их вершины будут попадать в другие узлы, а двигать узлы как бы ни хотелось не получится в любом случае. Один только поворот объекта чего стоит.
 Еще вариант: динамический объект не будет разбиваться на вершины, а при перемещении проверять в каком узле находится и прописываться там, а не создавать новые узлы. В этом случае нет необходимости строить дерево каждый тик, но имеем огромный недостаток: динамический объект в моей сцене будет содержать огромное количество полигонов. Для отсекания невидимых полигонов динамических объектов придется использовать что-то альтернативное.

Какой смысл хранить треугольники в дереве?
ИМХО рациональнее хранить отдельные объекты.
По идее дерево не должно знать статический объект или динамический.
Объект должен иметь ссылку на дерево, при изменении своего положения должен сообщить дереву - я переместился! Пересчитай меня!

Ну а с мега полигональными объектами два варианта(не исключающих друг друга):
1) Разбиение объекта на части
2) LODы

Просто весь город вместе с домами, мостами, дорогами представляет собой один мешь, статьи из которых я узнал что такое OctTree описывали его использование в целях отсечения ненужных граней. Я подумал, что смогу решить сразу две задачи одним деревом. Быстрее найти треугольник которому пренадлежит точка, и отсечь невидимые треугольники.
Если я буду использлвать VBO, отсекание треугольников становится бесполезным и даже вредным так? Тоесть нужно использовать дерево ТОЛЬКО для физики?

Я тоже раньше использовать город как один меш. это не очень хорошая идея.
лучше делить на куски. Например улицы отдельно, дома отдельно, детали экстерьера отдельно.
Тогда можно вполне убирать часть геометрии не перестраивая VBO.

Тоесть даже если объект всегда будет присутствовать на сцене, делая его отдельным можно будет выбросить из VBO когда тот не виден? Я еще не пробовал использовать VBO, так что ничего о нем не знаю, кроме того, что все данные о вершинах, текстурах хранятся в видео памяти.
 Думаю в таком случае, будет проще псчитать столкновение с домом, сделаю у каждого объекта указатель на форму и размер, например куб 5х7х5х6, и буду обрабатывать столкновение с кубом, а не искать нужный треугольник. Можно даже в дерево заносить этот указатель на форму.
 Остается только решить как будет осуществляться поиск треугольника под колесом. Может быть использовать для поверхности QuadTree, или при создании OctTree поверхность разбивать на грани, а все остальное хранить просто как объект?

Тут я уже ничем помочь не могу, решайте сами.

По моему ты не с того конца начал))
У тебя получается физика прикручивается к графическому объекту.
А нужно наоборот, сначала создать физическую модель,
и уже к ней прикручивать графику.

> [17] main ©   (18.06.09 15:59)
> А нужно наоборот, сначала создать физическую модель,
> и уже к ней прикручивать графику.

Откуда такое правило?

> @!!ex ©   (18.06.09 16:01) [18]


Это правило от верблюда ))