Comments 63
Мне статья напомнила об этих методах: «Perfect spatial hashing» (2D/3D) и «Geometry images» (3D)
Думаю, что специального софта нет. Но и сделать подобные карты не сложно, если у вас есть 3D моделька человечка в максе/майе. Сначала текстурируете человечка нормальной текстурой, делаете анимацию, заменяете текстуру на специальную с координатами вместо цвета, ставите человечка в нужную позу и рендерите раскадровку.
неожиданно! интересно это кто-то сам родил или этим уже давно пользуются?
В 3D-играх такое на каждом шагу, во флэше вижу впервые
в 3D то я в курсе.
В 3D играх такое не используется.
ну как не используется? Обычные текстурные координаты (UV). Только на 3д-моделях они обычно повертексно распределены, а здесь закодированы пиксельно.
Но особой разницы же нет, обычный float2 вектор, просто отображенный значениями RG в битмапе.
Но особой разницы же нет, обычный float2 вектор, просто отображенный значениями RG в битмапе.
ОМФГ, да любые бинарные данные это флоат2 вектор, и что с того?
Этак технология не имеет смысла в контексте трехмерной графики.
Этак технология не имеет смысла в контексте трехмерной графики.
не нервничайте.
еще как имеет, если использовать per pixel mapping (в каких либо специфичных ситуациях)
в анриловском движке, например, дисторшен текстурных координат именно так и делается — подаются uv-анимированные битмапы (RG) как координаты смещения пикселов текстуры.
еще в matte-paint'овых задниках можно использовать, которые с хайреза в лоурез пекутся.
Вообще можно везде использовать, где нужна низкая детальность геометрии и высокая точность позиционирования текселя на поверхности (чтобы диагонали не ломали равномерное распределение текстуры)
еще как имеет, если использовать per pixel mapping (в каких либо специфичных ситуациях)
в анриловском движке, например, дисторшен текстурных координат именно так и делается — подаются uv-анимированные битмапы (RG) как координаты смещения пикселов текстуры.
еще в matte-paint'овых задниках можно использовать, которые с хайреза в лоурез пекутся.
Вообще можно везде использовать, где нужна низкая детальность геометрии и высокая точность позиционирования текселя на поверхности (чтобы диагонали не ломали равномерное распределение текстуры)
Говорить как вы — это все равно, что говорить, что перемножение матриц и поиск подстроки — одно и то-же: берем бинарные данные, производим над ними операцию, кладем результат.
На каком-то уровне абстракции, конечно все так, но в реальности мы имеем очевидную ситуацию: есть разные технологии, которые достигают разных целей.
На каком-то уровне абстракции, конечно все так, но в реальности мы имеем очевидную ситуацию: есть разные технологии, которые достигают разных целей.
Спасибо, интересный метод.
Возможно, пригодится) Я задумывался о реализации похожего эффекта.
Возможно, пригодится) Я задумывался о реализации похожего эффекта.
А в чем выигрыш, в занимаемом месте? Можно в цифрах, сколько весили исходные картинки и сколько весит результат?
Я так понимаю, что выигрыш в кастомизации — можно наплодить много разных человечков :)
Не столько в месте, сколько в удобстве скиннинга. Для добавления нового вида человечков достаточно просто нарисовать скин.
В противном случае пришлось бы все перерендеривать.
В противном случае пришлось бы все перерендеривать.
А например то, что нет антиалиасинга — это недостаток технологии, или конкретной реализации? Мне почему-то кажется, что сделать сглаживание при таком подходе сложно. Не даром у человечка во время движения появляется до пяти глаз.
Сделать сглаживание — вполне реально. Правда, возможно придется в скин паддинги вставить. Если заранее нагенерить — то и тормозить не будет.
Но у подхода есть минус — геометрия статична, если захочется добавить, скажем, шляпу — фигач новую анимацию. Но можно попробовать пофиксить это через микс нескольких анимаций для разных геометрий и наборов скинов для каждой. При таких размерах изображения должно хватить штук эдак 5 для практически любого логичного внешнего вида персонажа.
Но у подхода есть минус — геометрия статична, если захочется добавить, скажем, шляпу — фигач новую анимацию. Но можно попробовать пофиксить это через микс нескольких анимаций для разных геометрий и наборов скинов для каждой. При таких размерах изображения должно хватить штук эдак 5 для практически любого логичного внешнего вида персонажа.
Даже если разобрать логически сам способ получения карты анимации:
Мы рендирим объект с антиалиазингом. Получаем пиксель, который на 50% составляет ногу, на 50% ботинок. Т.к. цвет — это координаты смещения в текстуре, то при смешивании двух таких цветов мы получаем не координату на текстуре, где лежит средний между этими объектами цвет, а просто координаты пикселя, который лежит где-то по середине.
Мы рендирим объект с антиалиазингом. Получаем пиксель, который на 50% составляет ногу, на 50% ботинок. Т.к. цвет — это координаты смещения в текстуре, то при смешивании двух таких цветов мы получаем не координату на текстуре, где лежит средний между этими объектами цвет, а просто координаты пикселя, который лежит где-то по середине.
Выигрыш в том, что если у вас 100 текстур человечков, то вам не нужно делать 100 анимаций-раскадровок, а только одну.
А я всегда думал, как такие текстуры натягиваются на анимацию. Все оказалось достаточно просто :)
Спасибо — очень полезная технология — особенно для онлайн-проектов. Хотелось бы посмотреть на качество маппинга на краях в более масштабном случае.
Отличная инфа, спасибо )
Классное решение. Правда, для спрайтов больше 255 пикселей в любом направлении не подойдет, но такие пока, к счастью, встречаются редко :)
Use png with 48 bit, Luke :)
Зависит от конкретной задачи. Зачастую можно выкрутиться и со спрайтами больше 255 пикселей.
— Можно использовать текстуру RGBA, где будет по 2 канала на каждую координату х/у. Ну а если под альфу используется 1 бит, то её можно кодировать в любом канале. К примеру, 255 в красном канале будет обозначать полную прозрачность, любые другие значения — полную непрозрачность.
— Можно использовать текстуру 16 бит/канал. Правда такую не просмотрите в графических редакторах, что усложняет генерацию и отладку. Я в свое время намучился ))
— Можно использовать текстуру RGBA, где будет по 2 канала на каждую координату х/у. Ну а если под альфу используется 1 бит, то её можно кодировать в любом канале. К примеру, 255 в красном канале будет обозначать полную прозрачность, любые другие значения — полную непрозрачность.
— Можно использовать текстуру 16 бит/канал. Правда такую не просмотрите в графических редакторах, что усложняет генерацию и отладку. Я в свое время намучился ))
Не спрайтов, больше 255 пикселей, а текстур с размерами более 256x256.
Можно понихить градации альфы до 64, получим возможность использовать текстуры до 512*512. Но вообще, с учетом общих проблем метода, такие большие текстуры ему все равно не нужны, 256*256 за глаза хватит.
Хех, знакомая картинка ) Ситивиль?
Спасибо за анализ, когда сам копался в исходниках обратил внимание на необычный способ, но копать не стал.
Спасибо за анализ, когда сам копался в исходниках обратил внимание на необычный способ, но копать не стал.
во флэше есть встроенный механизм DisplacementMapFilter, но он не подошелНо AS реализация наверняка будет напрягать процессор, там должен использоваться встроенный механизм с оптимизированным кодом. Если вы еще и это раскопаете, полезность топика удвоится.
А зачем сильно быстро? Все текстурки можно наложить один раз при старте, и получить привычные спрайты.
Например для быстрого старта :) Для игр это важно. Но я не в теме флеш-игр, возможно вы правы.
Кстати, по пути нагуглил пример использования DisplacementMapFilter по прямому назначению. Выглядит неплохо, но и процессор напрягает сильно (может потому, что на Убунте).
Кстати, по пути нагуглил пример использования DisplacementMapFilter по прямому назначению. Выглядит неплохо, но и процессор напрягает сильно (может потому, что на Убунте).
Я такое делал еще в 2000-м году на C++. «Времена меняются — Хёршис остается».
Не могли бы сделать картинки в чуть побольше варианте? Спасибо
Спасибо, идея интересная, хотя и применима только в очень узком кругу задач. Да, кстати, называть это displacement map-ом не совсем верно, т.к. этот термин применяется для совсем другой технологии. Ну и на данной текстуре, собственно, нет никаких смещений — только абсолютные координаты.
Я себе так скин в Quake 2 рисовал. Именно такую развертку и приходилось делать.
В флеше вижу впервые.
В флеше вижу впервые.
Это здесь вообще не при чем. В Quake 2 — там чистое 3D и на 3д модельку натягивается текстура.
Тут же речь идет вообще о другой технологии, без какого-либо 3д.
Тут же речь идет вообще о другой технологии, без какого-либо 3д.
И здесь на модельку натягивается текстура =)
Только моделька не 3D, а 2D.
Хотя с таким же успехом можно назвать это палитрой… но выглядит оно действительно похоже на развёртку текстуры Q1/Q2.
Только моделька не 3D, а 2D.
Хотя с таким же успехом можно назвать это палитрой… но выглядит оно действительно похоже на развёртку текстуры Q1/Q2.
врядли «без какого либо 3Д», ибо рендеринг спрайтов с анимацией делается именно в 3д с последующей упаковкой UV+Alpha в RGB атласа спрайта
С момента появления кинематографа фильмы были трехмерными.
это вы к чему?
Ну ведь оригинал фильма — поезда всякие — трехмерные, значит и сам фильм трехмерный, так?
(Хинт, если конечные данные+алгоритм не содержат прямых данных о трехмерных свойствах, и не используют трехмерных преобразований над этими данными — такая технология будет «без какого-либо 3д», а то, как мы генерируем исходные данные — вопрос третий.)
(Хинт, если конечные данные+алгоритм не содержат прямых данных о трехмерных свойствах, и не используют трехмерных преобразований над этими данными — такая технология будет «без какого-либо 3д», а то, как мы генерируем исходные данные — вопрос третий.)
UFO just landed and posted this here
Есть подозрение, что потом сверху лепится пререндеренный слой с освещением.
UFO just landed and posted this here
Единственное, что могу предположить:
При правильном методе текстурирования расстояние между точками, на которые сссылаются соседние точки анимации, связано с нормалью(правда, криво-косо).
При правильном методе текстурирования расстояние между точками, на которые сссылаются соседние точки анимации, связано с нормалью(правда, криво-косо).
Ан нет, все гораздо проще, похоже.
На текстуре есть градиент. На анимации в плоскости G — тоже очевидный градиент по ссылкам. Штука в том, что текстура — не классическая текстура, она так-же содержит версии для разной освещенности. А анимация напрямую ссылается на них. Но, учитывая то, что например лицо на текстуре явно только в одной версии, освещение таким методом сделано не для всего конечного спрайта, а только для некоторых областей.
На текстуре есть градиент. На анимации в плоскости G — тоже очевидный градиент по ссылкам. Штука в том, что текстура — не классическая текстура, она так-же содержит версии для разной освещенности. А анимация напрямую ссылается на них. Но, учитывая то, что например лицо на текстуре явно только в одной версии, освещение таким методом сделано не для всего конечного спрайта, а только для некоторых областей.
Sign up to leave a comment.
Текстурирование спрайтов с помощью (dis)placement map