Crystallize писал: Сохраненная с редактора анимации
Оттуда сохраняются только покадровые значения трансформов для интерполяции (никаких настроек IK там нет). А движковая IK вроде думтришной модифицирует уже существующую запечённую анимацию.
Цитата:
Crystallize писал: скинить вершины в халфе и кваке
В халфе вершины трансформируются костями, а в кваке интерполируется положение вершин (чохом для всех) от кадра к кадру.
Crystallize писал: А в 1995 году в таких редакторах уже была IK?
В PowerAnimator-е и Softimage|3D была. Юрасег парк сделали же. Насчёт 3D Studio не знаю, скорее всего хрен.
Вообще IK всего лишь гнёт цепочку костей в направлении эффектора (есть ещё настройки жёсткости и поворота вокруг оси направления). Нет никаких причин считать её чем-то выдающимся или универсальным.
Цитата:
Crystallize писал: всё равно всё сводится к процессору
Вершинной анимации нужно больше памяти и меньше ЦПУ.
Crystallize писал: Сохраненная с редактора анимации, или в рилтайме? С ними можно всего ожидать.
Ну вот как можно нести такой фееричный бред, а?
Инверсная кинематика по определению не может быть запечена в анимацию, потому что тогда это будет не инверсная кинематика, а анимация.
Дядя Миша писал: Ну вот как можно нести такой фееричный бред, а?
Инверсная кинематика по определению не может быть запечена в анимацию, потому что тогда это будет не инверсная кинематика, а анимация.
Я имею в виду, что она присутствовала в редакторе как инструмент, а результаты её работы уже сохранялись как обычная анимация.
Кости как раз таки считать несложно, в силу того что костей мало.
Смерть быстродействию - это трансформация вершин и нормалей.
По одной трансформации на каждую вершину. Легко догадаться, что фпс падает прямо пропорционально кол-ву вертексов.
Вертексная анимация - это "запечённая" скелетная. там ничего рассчитывать не надо, но надо много памяти, т.к. каждый кадр является точной копией модели. Кармак с этим пытался бороться общеизвестными методами, например переводил координаты вертекса в локальное пространство, в результате чего, его координаты умещались в три байта, вместо трёх флоатов, нормали свёл в таблицу avertexnormals.h, просто подбирал максимально похожую при компиляции и в модели оставлял байтовый индекс на эту табличку, нормаль бралась оттуда. Таким образом на один вертекс у нас приходилось всего 4 байта. Так же широко использовались стрип-секвенции, чтобы избежать дупликации вертексов (хотя какая-то небольшая часть в разных анимациях всё равно повторяла друг-друга). Именно в силу этого модельки в первой кваке весят совсем немного 70-300 килобайт (включая текстуру). Но уже во второй кваке модель солдатика прибавила в весе до одного мегабайта. На современных высокополигональных моделях их вес бы зашкаливал за сотни мегабайт.
nemyax писал: У дяди Мишы в тестах видюха =)
А так — ЦПУ.
Почему же ЦПУ легко трансформировать вертексы на костях, но трудно на мешах? При том, что с костями их ещё и на суставах нужно считать с учётом двух костей?
Crystallize
Дядь Миша же тебе всё написал.
Вертексы на костях трансформировать не легко, а трудно. Потому что этих вертексов много и рассчитывать трансформации по-любому придётся. А при вершинной анимации не придётся, да ещё и оптимизировать можно. Ты чё?
| IP: 
17-02-2014 14:45
