Оптимизация интерактивности
25.09.2007 Антон ВолковХочу поделиться подходом к оптимизации интерактивности 3D-объектов. Когда-то, ещё во второй версии 3D-движка, мы использовали стандартные MouseEvent для получения мышиных событий на 3D-объектах. Однако, проэкспериментировав с 1-2 тысячами граней, когда каждая является слушателем событий, мы убедились в несовершенности и перегруженности стандартного механизма рассылки мышиных событий. FPS при перемещении мышью над объектами падал с 100 до 50.
Смириться с этим мы не могли, поэтому решили делать собственную систему 3D-событий. Суть её сводится к тому, что все полигоны являются обычными Shape (что, кстати, опять же даёт некоторый прирост производительности), а на камере есть хит-область. При получении мышиного события на этой области мы математически анализируем, какие полигоны входят в этот сектор (см. пример карты границ). Далее, анализируя геометрию, находим ближайший полигон и далее по формуле плоскости ищем пересечение луча из точки мыши до выбранного полигона. В итоге получаем честные 3D-координаты мыши. При этом производительность не пострадала ни на FPS.
04.10.2007 в 14:13
Gaia Online (www.gaiaonline.com) уже всю облазили? ))) Практически все идеи этого проекта там реализованы. Только там упор на развлечения, а не на карьеру/торговлю (мне например и в реале карьеры хватает)
05.10.2007 в 10:25
Кстати нет, спасибо за ссылку! Чего-то не могу там никуда перейти, кроме первой локации, всё прогружает и потом виснет на этапе Joining Server…
По поводу идей позволю себе пару цитат (ну вот такое настроение с утра):
«Что было, то и будет; и что делалось, то и будет делаться, и нет ничего нового под солнцем. Бывает нечто, о чем говорят: «смотри, вот это новое», но это было уже в веках, бывших прежде нас … » - Екклезиаст
«Широко известно, что идеи стоят 0.8333 цента каждая (исходя из рыночной цены 10 центов за дюжину). Великих идей полно, на них нет спроса. Воплощение идеи в законченную игру требует долгой работы, таланта, терпения и креативности, не говоря уж о затратах денег, времени и ресурсов. Предложить
идею просто, воплотить – вот в чём проблема» - Steve Pavlina
От себя могу добавить, что он-лайн большой, на всех хватит :) Нам важно сделать хорошую игру, а не обставить конкурентов по каким-либо параметрам.
05.10.2007 в 12:09
Я занимаюсь “созданием блокнотов”, поэтому ничего не понимаю в создании игр и 3Д, но слово оптимизация - это по моей части. Для очень динамичных сцен ваш новый подход очень хорош (каждый полигон слушатель - был кашмар). Для статичных сцен я бы использовал другой. Каждый полигон имеет свой порядковый номер (наверное). Если рисовать ту же картину, что видит пользователь на экране, ещё и на скрытом экране, но используя в качестве цвета порядковый номер полигона, то определение номера полигона по которому кликнул пользователь на реальном экране сводится к определению цвета соотвествующей точки на скрытом экране.
Очевидно, что если рисовать на экранах отдельно (Draw(Screen1,Show); Draw(Screen2,Hide)), то потеря производительности составит 50%. А вот если провести оптимизацию, то потеря составит не более 5%. Основные потери происходят при определении того, какой из полигонов должен отображаться в данной конкретной точке. Чем больше полигонов покрывают одну точку, тем больше потери. После того, как определилось, точка какого полигона должна быть отображена на экране, можно вывести её на реальный экран под реальным цветом, а также на скрытый экран под цветом равным номеру полигона (желателен 32битный цвет).
При таком подходе скорость будет зависеть только от размера экрана, и не будет зависеть от количества полигонов.
Зато процент потерь на анализ мыши будет зависить обратно пропорционально количеству полигонов.
К сожалению этот метод плохо вяжется с shape.
В вашем новом методе, производительность всё-таки будет зависеть от количества полигонов попавших в хит-область.
С уважением, Гимаев Наиль.
05.10.2007 в 12:56
Наиль, спасибо за обстоятельный ответ. Ваш вариант напоминает мне Z-буфер. Я был бы очень рад если бы технология позволила нам это реализовать, но к сожалению флэш катастрофически медленно работает с растром, поэтому это технически мало реально.
Также я не уточнил, что некоторые области должны пропускать клик сквозь себя (например полупрозрачные спрайты и т.п.), а некоторые наоборот могут быть не видимы, но должны реагировать на события мыши.
Действительно, производительность будет зависеть от скорости математики и количества проверок. Практика показывает, что на вполне нагруженной сцене в секторе оказывается 10-20 полигонов. При этом они уже имеют некоторую сортировку по слоям, поэтому мы начинаем с самых ближних. Как только мы нашли пересечение, прекращаем обработку. Поэтому на практике расчётов производится очень мало, да и математику мы оптимизировали достаточно хорошо, т.к. она же используется и при честной Z-сортировке.
Буду рад вашим комментариям, в том числе и по другим заметкам.