Razum писал(а):
Не, Шаман, это не решение.
Решение, если котелок маной наполнен, а не опилками, и руки не кривые. Моделек можно несколько, а можно ещё лучше - одну деформируемую. Бить треуги на три и тянуть вершины в нужном направлении можно и на первых пнях. Никакой сложной математики.
Razum писал(а):
А что, если юзер стрельнет так, что две дырки будут пересекаться
М-м-м...
Пространство морфируемой модели можно ограничивать параллелипипедом размером с выдернутый квадрат ландшафта.
Добавлено спустя 14 минут 54 секунды:
Или проверять пересечение дырковых моделей (что в любом случае делает физический движок для всех моделей), обрезать и сливать вместе дырки.
Вообще, разработка всей этой технологии будет жутко творческим процессом, что экономчески невыгодно, конечно. Это головоломка для энтузиастов. У меня пока мана на это родилась.
Добавлено спустя 13 минут 19 секунд:
Кстати, статичность количества треугов в моделе я считаю сильно застоявшимся упрощением. Конечно, это позволяет ускорить рендер, комбинируя треуги в полигоны и другие примитивы, уменьшая тем самым количество передаваемых в видеокарту вершин, но блин, можно уже и на наборы треугов переходить при современных скоростях памяти и шины?.. Ведь морфируемость объектов путём разбиения треугольников на несколько и изменения координат вершин требует от модели быть сохранённой как меш из треугольников. Можно, конечно, заранее разбить модель на кучу треугов, и морфировать только существующие вершины, но ИМХО, это не рационально. Я не вижу проблем делать разбиения в реальном времени. Это не столько грузит процессор, сколько кипятит котелок разраба. Проблема лишь в этом, мне кажется. У меня есть опыт работы с векторной геометрией и ассемблером, и посему скажу, что прикрываться недостаточной производительностью профессора в данном случае - лишь скрывать лень, ибо писанина на ассемблере - дикая головомойка и убийство времени, которое деньги.