Геодата

AlleyCat> Кстати, запрет в конфиге на волкера работает?

Если уолкер детектится - то да. Если нет - понятно, что он может точно клиентом прикинуться. Думаю, всё от его версий зависит.

AlleyCat> Тогда еще предложение. Брать только проверенніх админов, чтоб могли волкера нормально отключить. А то фигня війдет с картой.

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

ivse> кстати, глупый вопрос - а карты на клиента не в формате unreal tourn хранятся?
ivse> а то может достаточно расшифровать и в редактор UT загнать?

Проснулся.

AlleyCat> Тогда еще надо посмотреть как отрабатывается вода.

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

AlleyCat> А как с ТОИ, Крумой, Гиантс Кейв, некрополисами?

А что с ними? Чем их многоэтажность не впишется в описанный мною метод?

AlleyCat>> Кстати, запрет в конфиге на волкера работает?
Balancer> Если уолкер детектится - то да. Если нет - понятно, что он может точно клиентом прикинуться. Думаю, всё от его версий зависит.

Ну тогда банить. Однозначно.
Можно поробовать волкера по скорости ввода логина и пароля отслеживать.
Хотя не уверен.

AlleyCat>> Тогда еще предложение. Брать только проверенніх админов, чтоб могли волкера нормально отключить. А то фигня війдет с картой.
Balancer> "Проверенных админов" будет мало, чтобы обегать весь мир

Я имел в виду, что бегать будут мои игроки. То есть данные брать для построения скажем с 10-20 серверов где админов относительно прямые руки.

AlleyCat>> Тогда еще надо посмотреть как отрабатывается вода.
Balancer> А воду нужно будет просто ещё до тех пор реализовать на сервере
Balancer> Если я правильно понял, то с ней непоняток, вроде как, нет. Только, пока мы клиентские файлы раздраконить на составляющие подфайлы не можем нужен неленивый человек, который ручками для каждого региона уровень воды пропишет

Ну это можно. Хотя не понял как ты будешь дно вычислять?

AlleyCat>> А как с ТОИ, Крумой, Гиантс Кейв, некрополисами?
Balancer> А что с ними? Чем их многоэтажность не впишется в описанный мною метод?

Все. Туплю.

AlleyCat> Ну это можно. Хотя не понял как ты будешь дно вычислять?

А дно - по минимальному из значений Z-координат, приходящихся на заданную точку

AlleyCat>> Ну это можно. Хотя не понял как ты будешь дно вычислять?
Balancer> А дно - по минимальному из значений Z-координат, приходящихся на заданную точку

А границы водоема?
Сервер же сейчас вообще ничего не различает. И даже если будем знать. что вот для этого региона уровень воды скажем 1000, то тут же рядом будет ложбина без воды, у которой высота равна 500, и тогда будет полоска дыхания и прочие глюки воды.

AlleyCat> А границы водоема?

На сколько я понял геодату, для каждого региона прописан уровень воды. Всё, что ниже этого уровня - вода. Так и границы определяются. Z-игрока <= Z-воды в регионе = в воде

AlleyCat> Сервер же сейчас вообще ничего не различает. И даже если будем знать. что вот для этого региона уровень воды скажем 1000, то тут же рядом будет ложбина без воды, у которой высота равна 500

Нет, как я понимаю, в мире Lineage таких мест нет Найди ложбину ниже уровня воды, но без воды в пределах одного региона - тогда я не прав.

Водоёмов не так много, и, в принципе, можно будет оббегать их админом как-нибудь, с некоторым флагом включённым.

Много Колодцы всякие и т.п...

Ткните пальцем в колодец? Я знаю только колодцы возле некрополей.

Murkt> Ткните пальцем в колодец? Я знаю только колодцы возле некрополей.

Координат не помю, но встречал некольк раз

Плюс - реки, озёра. Они весьма протяжённые, задолбаешься описывать. Одна береговая линия Элмора чего стоит

По моим наблюдениям геометрию можно разделить на два вида:
1. Ландшафт - представляет собой координатную сетку с шагом 128 единиц по X и по Y. Его можно представить массивом где-то 2824x5120. Хотя для эффективного алгоритма обнаружения столкновений нужно будет все это преобразовать в треугольники и рассчитать нормали к поверхностям.
2. Детали ландшафта (дома, деревья, подземелья, скалы и т.д.) представлено произвольными треугольниками.

Всю эту информацию можно получить из Direct3D. Причем можно отдельно получить информацию о ландшафте и о деталях, основываясь на размере вертекса: 36 - ландшафт, 24 - детали.
Ландшафт довольно просто получить и сохранить в нужном формате. С деталями сложнее. Во первых очень большой объем информации, во вторых много избыточной информации (которая не нужна серверу). Я так и не нашел эффективного способа бороться с этими проблемами. Можно конечно сохранить в каком-то формате, открыть в 3D редакторе и вручную удалять лишнее, только это займет уйму времени. Также нужно преобразовывать сложные детализированные объекты в Bounding Box.

Создавал тему на счет карты высот на сайте проекта L2J. Мне luisantonioa ответил что у них есть карта высот от C4. Нужно только написать эффективный алгоритм обнаружения столкновений.

Кому интересно, могу выслать мои наработки на e-mail. Пишите в личку. К сожалению карту высот найти не могу, но её не проблема сделать еще раз. Всё что нужно - это просканировать всю местность, например, летая на драконе.

Стокновений в самом простом случае (когда чар и любой моб это параллелепипед) - легко.
По предварительным данным должно работать быстро даже при 10000+ юзерах в мире.
А если разбить по локациям то вообще будет супер

Может оно и легко, токо вот никто еще не сделал

Проблем несколько. Навскидку:

При простых разбивках не сделать многослойности. Я её для себя (в планах) решаю так. Если квадрат карты многослойный, то в него приписывается вместо 16-битной высоты особое число, указывающее на использование отдельного списка высот. Дальше ищем наиболее близкий к предыдущей высоте - его и используем.

Точность. 128 - это ОЧЕНЬ грубо. Мы либо на сможем близко подходить к стене (напомню, что средний радиус чаров - 10. Т.е. мы не сможем приближаться к препятствиям ближе, чем на 13 своих размеров!), даже сквозь двери не сможем проходить. Либо, если проходимость для таких квадратов устанавливать, то мобы смогут ходить сквозь тонкие стены.

Если получать геодату через DirectX - то всё ок. Если же записью прохождения игроков через заданные точки, то возникают неразрешимые, для меня пока, проблемы с расчётом прохождения "толстых" мобов. Того же Антареса. Он либо вообще ходить не сможет, либо, опять же, спокойно сможет уходить, например, до половины своего размера в стены

...

ИМХО, геодату нужно делать в виде набора объёмных плоских полигонов. В вырожденном случае - треугольников. Для аппроксимации таких полигонов, и, особенно - БЫСТРОЙ проверки пересечения границ и т.п., требуется высокий уровень знания стереометрии. Я пока таким не обладаю, я привык на плоскости жить пока

Использование многослойности ИМХО это бред. Все объекты нужно представить в виде треугольников, разбить мир на зоны, например, 2048x2048 как в клиенте. Проиндексировать треугольники на принадлежность к конкретной зоне. При такой разбивке в одной зоне будет 256 треугольников ландшафта + детали ландшафта. В худшем случае, если персонаж находится на пересечении четырех зон, нужно будет обработать 1024 треугольника ландшафта + детали. Далее проверяем пересечение поверхностей зоны с цилиндром, представляющим персонажа.
Реализацию алгоритма пересечения цилиндра с поверхностью можно найти на сайте:

Balancer> Точность. 128 - это ОЧЕНЬ грубо.
С точностью 128 в клиенте хранится ландшафт. Дома, двери, скалы, деревья, камни, навесы над входом в пещеру, пещеры и т.д. - это объекты представленные треугольниками с произвольными координатами.

Balancer> Если получать геодату через DirectX - то всё ок.
Я вижу в этом самый доступный и точный метод получения геодаты.

Balancer> БЫСТРОЙ проверки пересечения границ и т.п., требуется высокий уровень знания стереометрии.
Этим занимается раздел геометрии - аналитическая геометрия.

Алгоритм обнаружения столкновений я вижу такой:
Исходные данные:
1. Вектор скорости персонажа
2. Высота персонажа
3. Радиус персонажа
4. Номер зоны в каторой находится персонаж
5. Треугольники, принадлежащие зоне (треугольник описан координатами вершин и вектором нормали к поверхности)

Алгоритм:
1. Вычисляем проверяемое положение персонажа из текущего положения и вектора скорости
2. Проверяем вычисленное положения на столкновения с поверхностями, а именно:
2.1. На плоскости XY находим треугольники зоны, которые пересекают окружность персонажа
2.2. В пространстве находим пересечения цилинда персонажа с поверхностью треугольников, которые на этапе 2.1 пересекали окружность.
2.3. Если на этапе 2.2 поверхность пересекает цилиндр, то вычисляем разницу координаты Z двух положений (текущего и проверяемого)
2.4. Если разница координаты Z больше определенного значения, то движение в этом направлении невозможно, иначе проверяемое положение становится текущим и переходим к этапу 1.

Приблизительно так.
Реализация на C++ есть на сайте Geometric Tools
Нет только пересечения окружности с треугольником, но есть пересечение окружности с линией, его можно взять за основу.

Valar77, проверь ПМ плз

zabbix> Valar77, проверь ПМ плз

Я в личку отписал, если не дошло напиши тут

vse ok
thx

я так понял, он в бмп только террайн инфу кидает? а меши сыпятся в .цсв?

zabbix> я так понял, он в бмп только террайн инфу кидает? а меши сыпятся в .цсв?

Да. Так и есть. Я специально разделил на Mesh-и и ландшафт. От Mesh-ей очень много инфы получается. Есть еще прога которая конвертит cvs в wrl. Исходники 404 Not Found

ЗЫ: Сильно не смейтесь с исходного кода, писал я это для себя, и программист я не С++, а 1С

Control Version System (cvs) и csv (не помню, как расшифровывается) - "это две большие разницы" ©

Не путайте.

И с мешами еще пробламка, я заметил, что клиент по нескольку раз одни и те же объекты рисует. У меня Гиран в формате VRML занимал ~250Мб