Alternativa3D 5
19.11.2007 Антон ВолковПосле запуска демо-версии стали очевидны минусы в разработанном движке. Недостаточно эффективно распределяется нагрузка на процессор — например, при отсутствии изменений на сцене процессор нагружен на 30-40%, что неприемлемо; сложные и зачастую “костыльные” методы оптимизации.
В первую очередь, в том числе благодаря отзывам, мы решили внедрить перспективную коррекцию. Дальше взялись за перепись честной Z-сортировки с учётом всевозможных оптимизаций. Переписали, но кардинально увеличить производительность не удалось. Можно считать, что за эти две недели была сделана 4-я версия движка.
По ходу многое было переосмыслено и на прошлой неделе приняли волевое решение создавать сразу 5-ю версию, в которой будет принципиально изменена архитектура движка (архитектуру не трогали со 2-й версии). В ней предполагается поддержка нескольких камер в одной сцене, перспектива и вообще восприятие камер как трёхмерных объектов. Z-сортировка будет построена на основе BSP-дерева — этот метод и сейчас, при гигантских мощностях видеокарт, активно используется в большинстве не-браузерных 3D-игр. Уже разработана новая система отслеживания изменений, которая позволяет максимально эффективно использовать процессор (другой вопрос, что пока не понятно, сколько ресурсов потребует сама система ;).
Параллельно с этим идёт пробная интеграция 3D-движка третьей версии с сервером.
19.11.2007 в 13:52
Да, BSP очень логичный для flash-3d алгоритм. Мы писали 3d движок - стереометрия, избрав бинарное дерево, как наиболее удачное решение. Ктсати от интерактивности визуальных объектов (слушанья мышиных событий полигонами на сцене) отказались на начальной стадии проекта и просчитывали объект под мышкой пробегом по дереву.
19.11.2007 в 14:10
FSB, есть ли возможность глянуть вашу разработку и ещё интересует, при создании BSP вы разбивали полигоны или в среднем определяли в какую полуплоскость полигон попадает?
19.11.2007 в 14:48
К сожалению, проект коммерческий, исходники предоставить не могу. По второму вопросу - движок обсчитывал все перечения плоскостей друг с другом и триангулизировал полигоны, в том числе пересения плоскостью разбиения, т.е. при пересении полигона плоскотью разбиения, полигон разбивался на полигоны по разные стороны от плоскости. Для нас производительность была не самым важным критерием - на сцене одновременно было не более 500 полигонов, точность построения была важнее, так что делали наверняка и не претендуем на самый оптимизированный алгоритм :-)
19.11.2007 в 15:45
Наконец то! Да БСП для флеша это самое то, лутше нету. По поводу бсп можно сделать алгоритм который бы разбивал как можно меньше полигонов! Причем для своего движка я обдумывал такую идею - например дом (или другой статический объект) для него делать отдельное бсп дерево… и прорисовывать объекты по отдельности, а потом все вместе. А вот на счет перспективы не думаю что хорошая идея… Т.к. тут появляется встречная проблема - коррекция текстур при перспективе + лишние расчеты на саму перспективу + всякие сложности с отсечением из вью-порта + как будут выглядеть спрайты при перспективе…
Ладно не буду пугать дальше :) Думаю что пятая версия двига сможет тягаться с папервижоном.
Удачи ребята!
19.11.2007 в 20:35
FSB:
Ни в коем случае не претендую на исходники. Хочется только посмотреть результат.
По поводу рассечений, сколько в среднем получалось кусочков, скажем при 500 оригинальных полигонах?
Super Man:
Есть сомнения в скорости BSP-разбивки. Хоть у нас сцена и более-менее статичная, но производятся загрузки/выгрузки объектов. Как бы не получилось медленнее, чем в прошлой версии. Насчёт коррекции текстур не беспокоимся, уже проработали концепцию. Отдельных расчётов перспективы уже тоже не будет, ну разве что плюс одно умножение на каждую точку. Базовое отсечение сделали, а по границе скорее всего и делать не будем, т.к. паннинг.
Спрайты будут либо плоскими (т.е. восприниматься как точки), либо уже квадами с натянутыми текстурами ;)
Большое спасибо за поддержку, и очень расчитываем на ваши советы/комментарии.
19.11.2007 в 21:26
Вах дарагой, снимаю шляпу. Маньяки :)
19.11.2007 в 22:04
Антон Волков
Пример сляпал: четыре средне пересекающихся икосаэдра (80 граней - треугольников) - после подсчета пересечений 952 треугольника: http://picasaweb.google.com/fsb.main/Public/photo#5134581978562953586
Результат тоже к сожалению выложить не имею права.
20.11.2007 в 01:22
Спасибо! Это полезные для нас данные.
Может быть есть идеи по минимизации рассечений (а то и вообще без них)?
20.11.2007 в 13:56
Давайте рассудим логично.
Перспективная коррекция возможно во флеше лишь несколькими способами:
1. Самый старый и простой - разбиение полигона на определенное количество треугольников. Количество треугольников может быть либо постоянным либо меняться в зависимости от угла камеры.
2. После введения фильтров во флеш таких как Displacement Map появился новый способ перспективной коррекции - “растягивать” нарисованный треугольник с помощью фильтра.
3. Это попиксельная прорисовка… Т.е. пикселизация.
Скорее всего “извращенные умы”(в хорошем смысле этих слов :) ) могут придумать еще более элегантный способ прорисовки. Но увы… Любые из этих методов проигрывают плоской текстуре, которая была у вас в изометрическом движке. Т.е. например есть сложный полигон - дно цилиндра(допустим оно состоит из 100 ребер) В изометрии можно отрисовать такой полигон за один раз. А в перспективе как минимум за 100 проходов (т.к. 100 треугольников)! А что такое прорисовать один треугольник? - это как минимум умножение двух матриц! Думаю товарищи вам надо сначала проверить ваши уязвимые места, а не просто мыслить концепциями.
Кстати камер в сцене может быть сколько угодно! Есть Вьюпорт - можно сказать это матрица текущей камеры + параметры перспективы, а есть куча камер… Когда меняется камера - во вьюпорт передается матрица камеры и параметры перспективы. Поэтому камер может быть сколько угодно и это не слишком отразится на производительности.
По поводу БСП разбивки. Что такое БСП дерево? - Это древообразная структура, и видеть мы можем только одну ветвь, либо даже часть ее. Поэтому расчеты производятся заранее при добавлении объектов на сервер производится пересчет только кусочка ветви. При загрузке объектов в флешь клиент загружается частично по ветвям и разветвлениям! При перемещении объектов не надо пересчитывать дерево! Надо просто выяснить в каком узле находится объект, кстати там можно делать супербыструю проверку на пересечение(читал где то). Поищите литературу там дофига про это написано!
20.11.2007 в 14:03
По поводу минимизации рассечений - БСП дает возможность предварительно считать дерево, поэтому можно придумать алгоритм любой сложности и трудоемкости, поэтому можно найти следующий нод такой что бы он делил другие треугольники меньшее количество раз. Причем еще советуют что бы дерево было как можно равномернее, что бы фпс был постоянным. Есть еще оптимизация БСП у каждой ветви считается Bounding Box (охватывающий параллелипипед) Тем самым отсекая из вью порта сразу целые куски ветвей!
20.11.2007 в 16:37
Для перспективы скорее всего пойдём по 1-му варианту с изменяемым количеством дроблений, т.к. displacement map убьёт всю производительность.
Перспективные искажения будут совершенно отдельно, не усложняя изометрический вид. Для игры нам необходима изометрия, но для дальнейшего развития движка было бы глупо не заложить перспективу, в особенности к выходу FP10 с перспективными искажениями мувиков.
Насчёт BSP спасибо за советы, видимо надо ещё поднакачаться литературой.
20.11.2007 в 19:09
почту на antonvolkov читаешь?
21.11.2007 в 04:26
Весь день читаю статьи по BSP, PVS и другим аббревиатурам. Голова квадратная!
Почту получил. Даже слов нет! Спасибо вам огромное!
21.11.2007 в 13:33
Хех когда я читал тож квадратная голова была, но когда въехал в суть то просто удивился на сколько же гениальная идея БСП!!! А вообще задача сортировки сложная штука… :) Будем надеяться что 10-ый флешь плеер будет поддерживать зет буфер, или что нить вроде того…
21.11.2007 в 17:23
лучше игру делайте ;)
23.11.2007 в 01:54
эх, молодцы! очень икосаэдры порадовали))
23.11.2007 в 16:20
Сделал сравнение старой и новой системы отслеживания изменений в сцене.
При отсутствии изменений - 0% загрузки, при сложных изменениях всей сцены (1000 объектов крутятся) скорость увеличилась на 15-20%. Ура!
О системе, если интересно, отдельно расскажу.
23.11.2007 в 16:46
Да очень интересно! Расскажи в общих чертах, может что нить посоветуем дельное! ;)
24.11.2007 в 04:17
как я уже неоднократно (пару-тройку раз) говорил одному из разработчиков, а может все-таки клиент? инфа об объектах локально, получаем только инфу об изменениях на карте. знаю-понимаю, что до этого далеко и, может быть, не попадает в концепт игры, но все-таки…
PS. С уважением, Bolek :-)
24.11.2007 в 04:21
Bolek, обмен данными между клиентом и сервером совершенно к 3D-движку не относится, это разные библиотеки. Может я не понял сути предложения?