В то время как анимация волос включала динамическое моделирование одномерных прядей, ткань состояла из 2D-поверхности, деформирующейся в 3D. Кроме того, ткань имела внутреннюю структуру, которая влияла на то, как она двигалась и драпировалась. Более того, мы очень привыкли к поведению и движениям одежды, поэтому любые отклонения от физической реальности были очевидны для зрителей.
Я столкнулся с рядом проблем с симуляцией одежды. К ним относятся численное интегрирование и нестабильность, масштаб складок и другие артефакты, а также обнаружение столкновений и реагирование на них.
Мои первые пробы ткани больше напоминали листы резины, чем ткань. Ткань очень легко сгибается, но почти не растягивается в повседневных сценариях. Это означало, что краевые пружины должны были быть жесткими, что, в свою очередь, требовало небольших временных шагов моделирования для предотвращения численной нестабильности, что увеличивало время моделирования.
Разрешение сетки ткани определяло размер складок, которые можно было смоделировать. Шелк и хлопок требовали гораздо более высокого разрешения, чем кожа. Со временем я обнаружил, как использовать поперечные пружины для предотвращения сдвига и как контролировать изгиб ткани с помощью пружин второго соседа между вершинами.
Но самой большой проблемой при разработке программного обеспечения для моделирования одежды должны были стать столкновения. Как обнаружить и отреагировать на столкновения между одеждой и движущимся телом персонажа, обработав коллизии вершин полигонов и ребер меша.
Было приятно видеть, как обновления происходят в графическом окне просмотра, на нескольких процессорах коробки SGI размером с холодильник (и да, она все еще была лишь на долю мощнее современного смартфона). Блоки вершин в сетке обновляются и обновляются в средстве просмотра через общую память, поскольку мой код моделирования выполнялся в своих собственных процессах.
Оглядываясь назад, я не очень хорошо разбирался в проблемах архитектуры машины, хранении данных в кеше и так далее. У меня было, вероятно, из-за моего опыта работы с Лиспом, множество взаимосвязанных структур, а не большие массивы чисел с плавающей запятой, которые были бы более эффективны (из-за более когерентного доступа к памяти) для аппаратного обеспечения.
Потом здание сгорело.
Дизайн и код
«Всякое великое произведение — художественное, поэтическое, интеллектуальное или духовное — создается в те моменты, когда его творцы совершенно теряются в своих действиях, когда они совершенно забывают себя и свободны от самосознания». - Кристмас Хамфрис (1901–1983)
Прошла неделя с моего последнего поста. Я даже не включал свой компьютер для разработки пару дней после отключения электричества. Все время задавался вопросом, сколько работы я потерял в несохраненных буферах Emacs. Как обычно, страх был хуже реальности: не сильно, если вообще был.
Размышляя (как говорят в Новой Зеландии) о направлении своего развития, я немного почитал. На самом деле совсем немного. Перескакивая между пятью книгами: «Картинки революции» Марка Харриса, «Шелковые пути» Питера Франкопана, «По крупицам» Эндрю Эрвина, «Машина мечты» М. Митчелла Уолдропа и «Пусть превзойдет лямбду» Дуг Хойт.
Читая «По крупицам», я наткнулся на приведенную выше цитату известного британского адвоката и буддиста и подумал, что она прекрасно отражает то состояние, которое я испытываю, когда занимаюсь хорошим программированием. Common Lisp (наряду с Emacs и Slime) помогает мне прийти в такое состояние ума, даже если моя текущая разработка далека от того, чтобы быть «отличной работой». Сегодня, я думаю, мы склонны называть это состояние ума «потоком».
Я все еще сомневаюсь в том, в каком направлении должно развиваться мое развитие. Должен ли я стиснуть зубы и начать использовать некоторые из пакетов CL, а не заниматься домашним пивоварением. Какой пакет пользовательского интерфейса следует использовать? Почему нет явного кандидата? Есть ли какие-то идеи, которые я могу получить о взаимосвязи между кодом и геометрией? Может быть, что-то связанное с представлением фигур в виде S-выражений? Я слишком сильно волнуюсь?
В конце концов я решил потратить несколько дней на написание простого класса polyhedron и программы для чтения файлов obj, чтобы иметь возможность импортировать и отображать внешнюю геометрию. Примером может служить знаменитый чайник из Юты, показанный выше. Не думайте, что я написал программу для чтения файлов формата obj со времен Neo-Visuals. Я также был довольно ржавый о вводе-выводе файлов CL, и мне пришлось искать некоторые ссылки. Это то, для чего хорош Интернет.
