Pull to refresh

Comments 63

Думаю, что специального софта нет. Но и сделать подобные карты не сложно, если у вас есть 3D моделька человечка в максе/майе. Сначала текстурируете человечка нормальной текстурой, делаете анимацию, заменяете текстуру на специальную с координатами вместо цвета, ставите человечка в нужную позу и рендерите раскадровку.
Да, я уже сам догадался и дописал «P.S.» :)
Альфа канал в B-компоненте вы автоматом получите, если текстура развертки в синем канале будет залита 255, а рендерить вы будете на черном фоне.
неожиданно! интересно это кто-то сам родил или этим уже давно пользуются?
В 3D-играх такое на каждом шагу, во флэше вижу впервые
В 3D играх такое не используется.
ну как не используется? Обычные текстурные координаты (UV). Только на 3д-моделях они обычно повертексно распределены, а здесь закодированы пиксельно.
Но особой разницы же нет, обычный float2 вектор, просто отображенный значениями RG в битмапе.
ОМФГ, да любые бинарные данные это флоат2 вектор, и что с того?
Этак технология не имеет смысла в контексте трехмерной графики.
не нервничайте.

еще как имеет, если использовать per pixel mapping (в каких либо специфичных ситуациях)
в анриловском движке, например, дисторшен текстурных координат именно так и делается — подаются uv-анимированные битмапы (RG) как координаты смещения пикселов текстуры.
еще в matte-paint'овых задниках можно использовать, которые с хайреза в лоурез пекутся.

Вообще можно везде использовать, где нужна низкая детальность геометрии и высокая точность позиционирования текселя на поверхности (чтобы диагонали не ломали равномерное распределение текстуры)
Говорить как вы — это все равно, что говорить, что перемножение матриц и поиск подстроки — одно и то-же: берем бинарные данные, производим над ними операцию, кладем результат.
На каком-то уровне абстракции, конечно все так, но в реальности мы имеем очевидную ситуацию: есть разные технологии, которые достигают разных целей.
я вам про Фому вы мне про Ерёму…
Вы вообще в разработке графики для игр участвовали когда-нибудь?
Спасибо, интересный метод.
Возможно, пригодится) Я задумывался о реализации похожего эффекта.
А в чем выигрыш, в занимаемом месте? Можно в цифрах, сколько весили исходные картинки и сколько весит результат?
Я так понимаю, что выигрыш в кастомизации — можно наплодить много разных человечков :)
Не столько в месте, сколько в удобстве скиннинга. Для добавления нового вида человечков достаточно просто нарисовать скин.

В противном случае пришлось бы все перерендеривать.
А например то, что нет антиалиасинга — это недостаток технологии, или конкретной реализации? Мне почему-то кажется, что сделать сглаживание при таком подходе сложно. Не даром у человечка во время движения появляется до пяти глаз.
Сделать сглаживание — вполне реально. Правда, возможно придется в скин паддинги вставить. Если заранее нагенерить — то и тормозить не будет.

Но у подхода есть минус — геометрия статична, если захочется добавить, скажем, шляпу — фигач новую анимацию. Но можно попробовать пофиксить это через микс нескольких анимаций для разных геометрий и наборов скинов для каждой. При таких размерах изображения должно хватить штук эдак 5 для практически любого логичного внешнего вида персонажа.
Даже если разобрать логически сам способ получения карты анимации:
Мы рендирим объект с антиалиазингом. Получаем пиксель, который на 50% составляет ногу, на 50% ботинок. Т.к. цвет — это координаты смещения в текстуре, то при смешивании двух таких цветов мы получаем не координату на текстуре, где лежит средний между этими объектами цвет, а просто координаты пикселя, который лежит где-то по середине.
Видимо, нужно как-то рендерить без антиальясинга.

Сам я в 3Д не знаток. Пусть кто-нить подскажет. Думаю, это возможно.
Рендирить то без антиалиасинга возможно, но это и результат будет без антиалиасинга, вот в чем проблема.
Так в примере и есть — без антиальясинга.

Антиальясинг можно сделать уже потом. Допустим, когда берем точку из текстуры с координатами (100,100) — учитывать еще соседние точки в текстуре.
Рендерить просто нужно в большем разрешении (тут правда есть ограничение в 256 точек). А выводить на экран уменьшенное изображение — вот и будет обычный антиалиасинг.
Да нет тут ограничения в 256 точек ;)

Ограничение в 256 точек — оно для текстуры, а не для рендеримого изображения!
Спрайтмэп надо сделать во вдвое большем разрешении, а после ее рендеринга вдвое уменьшить вместе с альфа-каналом.
Выигрыш в том, что если у вас 100 текстур человечков, то вам не нужно делать 100 анимаций-раскадровок, а только одну.
А я всегда думал, как такие текстуры натягиваются на анимацию. Все оказалось достаточно просто :)
Спасибо — очень полезная технология — особенно для онлайн-проектов. Хотелось бы посмотреть на качество маппинга на краях в более масштабном случае.
А разве наличие альфа-канала как раз не то что нужно?
Да вроде то, но пример больно мелкий.
Классное решение. Правда, для спрайтов больше 255 пикселей в любом направлении не подойдет, но такие пока, к счастью, встречаются редко :)
Use png with 48 bit, Luke :)
Зависит от конкретной задачи. Зачастую можно выкрутиться и со спрайтами больше 255 пикселей.
— Можно использовать текстуру RGBA, где будет по 2 канала на каждую координату х/у. Ну а если под альфу используется 1 бит, то её можно кодировать в любом канале. К примеру, 255 в красном канале будет обозначать полную прозрачность, любые другие значения — полную непрозрачность.
— Можно использовать текстуру 16 бит/канал. Правда такую не просмотрите в графических редакторах, что усложняет генерацию и отладку. Я в свое время намучился ))
Не спрайтов, больше 255 пикселей, а текстур с размерами более 256x256.
Точно! Спасибо за фикс.
Можно понихить градации альфы до 64, получим возможность использовать текстуры до 512*512. Но вообще, с учетом общих проблем метода, такие большие текстуры ему все равно не нужны, 256*256 за глаза хватит.
Хех, знакомая картинка ) Ситивиль?
Спасибо за анализ, когда сам копался в исходниках обратил внимание на необычный способ, но копать не стал.
во флэше есть встроенный механизм DisplacementMapFilter, но он не подошел
Но AS реализация наверняка будет напрягать процессор, там должен использоваться встроенный механизм с оптимизированным кодом. Если вы еще и это раскопаете, полезность топика удвоится.
А зачем сильно быстро? Все текстурки можно наложить один раз при старте, и получить привычные спрайты.
Например для быстрого старта :) Для игр это важно. Но я не в теме флеш-игр, возможно вы правы.

Кстати, по пути нагуглил пример использования DisplacementMapFilter по прямому назначению. Выглядит неплохо, но и процессор напрягает сильно (может потому, что на Убунте).
На то он и фильтр.
Для быстрого старта можно делать render-on-demand.
Да, такие штуки всегда требуют ухищрений и от архитекторы.
Зато экономия и в объёме передачи данных и в занимаемой памяти.
Я такое делал еще в 2000-м году на C++. «Времена меняются — Хёршис остается».
Не могли бы сделать картинки в чуть побольше варианте? Спасибо
Не заработают – сам принцип по-другому строен.
Не могу. Это ж не мои картинки и отрендерены они были именно в таком размере :)
Спасибо, идея интересная, хотя и применима только в очень узком кругу задач. Да, кстати, называть это displacement map-ом не совсем верно, т.к. этот термин применяется для совсем другой технологии. Ну и на данной текстуре, собственно, нет никаких смещений — только абсолютные координаты.
Да, согласен. Подкорректировал статью. Это, скорее, — некий «placement map» :)
Я себе так скин в Quake 2 рисовал. Именно такую развертку и приходилось делать.
В флеше вижу впервые.
Это здесь вообще не при чем. В Quake 2 — там чистое 3D и на 3д модельку натягивается текстура.

Тут же речь идет вообще о другой технологии, без какого-либо 3д.
И здесь на модельку натягивается текстура =)
Только моделька не 3D, а 2D.
Хотя с таким же успехом можно назвать это палитрой… но выглядит оно действительно похоже на развёртку текстуры Q1/Q2.
врядли «без какого либо 3Д», ибо рендеринг спрайтов с анимацией делается именно в 3д с последующей упаковкой UV+Alpha в RGB атласа спрайта
С момента появления кинематографа фильмы были трехмерными.
Ну ведь оригинал фильма — поезда всякие — трехмерные, значит и сам фильм трехмерный, так?

(Хинт, если конечные данные+алгоритм не содержат прямых данных о трехмерных свойствах, и не используют трехмерных преобразований над этими данными — такая технология будет «без какого-либо 3д», а то, как мы генерируем исходные данные — вопрос третий.)
с вами крайне сложно вести беседу, простите.
UFO just landed and posted this here
Есть подозрение, что потом сверху лепится пререндеренный слой с освещением.
UFO just landed and posted this here
Единственное, что могу предположить:
При правильном методе текстурирования расстояние между точками, на которые сссылаются соседние точки анимации, связано с нормалью(правда, криво-косо).
Ан нет, все гораздо проще, похоже.
На текстуре есть градиент. На анимации в плоскости G — тоже очевидный градиент по ссылкам. Штука в том, что текстура — не классическая текстура, она так-же содержит версии для разной освещенности. А анимация напрямую ссылается на них. Но, учитывая то, что например лицо на текстуре явно только в одной версии, освещение таким методом сделано не для всего конечного спрайта, а только для некоторых областей.
Only those users with full accounts are able to leave comments. Log in, please.