Цитата(Sirocco @ 28.8.2017, 8:31)
![*](style_images/uokit/post_snapback.gif)
Я уже видел реализацию подобного алгоритма, назывался он Courageous True Line of Sight и касался только Мобов... или ты вообще с нуля все делал?
Да все делалось с нуля. Не отрицаю, существует упомянутая вами реализация и касается она далеко не только "мобов". Однако у нее есть два существенных недостатка - тот алгоритм работает только в одной плоскости, так к примеру цель за стенкой будет не видна, а цель что находиться прямо над вами или под вами на другом этаже окажется видимой. Конечно они все равно не будут видны на экране, но к примеру не их речь. По этой же причине этот алгоритм начинает рассыпаться на сложной неровной местности. Иными словами тот алгоритм не плох, но он подходит лишь для двухмерного пространства, где нет 3го измерения. (Кстати реализации алгоритмов LoS\FoV не в плоскости вообще фактически не существует и по особенностям и проблемам его реализации информация тоже отсутсвует). Ко второму недостатку можно отнести ограничение максимальной дальности в 16 тайлов (это при дальности прорисовки 18 тайлов, который уже давно многим кажется недостаточным). Конечно его можно переписать, расширив ограничение до 32 тайлов, но тем не менее.
К преимуществам моей реализации можно отнести:
1) Расчет во всех трех измерениях а не только в одной плоскости
2) Отсутствие жесткого ограничения на максимальную дальность области видимости.
3) Более "мягкие" тени, что лучше подходит для UO с большим количеством препятствий
4) Зона видимости не квадрат, а круг (это видно на прототипе, в видео не видно так как там снималось при очень большом по сравнению с областью отрисовки радиусе)
5) Возможность смены на лету радиуса зоны видимости без необходимости повторной инициализации (в упомянутом выше алгоритме к примеру для этого требуется кодогенерация и перерасчет всех масок затемнения)
6) Возможность использования угла обзора, отличного от 360 градусов
7) Влияния размера цели на расчет видимость - мелкую крысу за забором Вы можете не увидеть, а крупного дракона - и за стеной увидите
8) Реализация алгоритма позволяет найти свое применение и в решении других задач, к примеру извлечения высоты помещения для определения, где может ездить конный всадник а где нет и где для него слишком низкий потолок или для расчета траекторий полета стрел с проверкой попадания в цели находящиеся на траектории стрельбы.
9) Простота включения в расчет видимости динамических объектов, вроде дверей или других существ
10) Высокая скорость работы для своего класса
К недостаткам можно отнести:
1) Алгоритм не является симметричным.
2) Высокое потребление памяти, если на стороне клиента алгоритм использует около 4мб памяти под свои нужды, то со стороны сервера потребуется 1-2 Гб. Конечно при желании, можно обойтись и десятком мегабайт, отменив кэширование, но это прилично ударит по скорости работы. Как по мне пара гигабайт сегодня приемлемая цена за скорость. К тому же целиком весь кэш нужен лишь при очень сильной загрузке сервера, а это значит, что большую его часть можно скидывать на хард и подгружать по мере надобности.
Сообщение отредактировал StaticZ - 28.8.2017, 14:32