Комментарии 22
Это очено здорово. А просто несколько анимированных png нельзя было использовать?
Очень здорово! Может кто-то сталкивался с аналогичной задачей по бросанию кубиков под html5 мобильные приложения? Как решали?
Посмотрите пример отсюда: ux.stackexchange.com/questions/11229/is-this-rotating-cube-interface-user-friendly — там есть ссылка на работающую демку — peterolson.github.io/jqCube/demo/demo.html
Прикольно. Я заметил, что у Вас во втором видео для пущей объемности еще и некое подобие теней. А вот как это достигалось?
Хех, мы подобным способом в универе крутили всякие фигуры, прям живо вспомнился катающийся дорожный знак. =)
Интересное, хотя в общем-то логичное решение.
P.S.: Если уж игра делалась для мобильных устройств, можно было сделать так, чтобы кубики катались от положения устройства и ускорения. Потряс планшет — кубики перемешались. Повернул — скатились в угол и т.д.
P.S.: Если уж игра делалась для мобильных устройств, можно было сделать так, чтобы кубики катались от положения устройства и ускорения. Потряс планшет — кубики перемешались. Повернул — скатились в угол и т.д.
А почему Вы не сделали все на CALayer, ведь все то, что можно представить плоскостями отлично анимируется с помощью слоев «без» openGL. К примеру
www.cocoanetics.com/2012/08/cubed-coreanimation-conundrum/
weblog.invasivecode.com/post/29307073330/core-animation-transform-layer
Более того, я даже помню wwdc шное видео, где Apple рассказывала о одной своей «кубической» анимации в месенджере и проблемах, с которыми они столкнулись
www.cocoanetics.com/2012/08/cubed-coreanimation-conundrum/
weblog.invasivecode.com/post/29307073330/core-animation-transform-layer
Более того, я даже помню wwdc шное видео, где Apple рассказывала о одной своей «кубической» анимации в месенджере и проблемах, с которыми они столкнулись
Спасибо, что упомянули про слои. Но, фактически, CALayer — это прослойка opengl-ная, много подготовительного кода требовалось, в отличие от ImageView.
Но UIImageView не далеко отошел от CALayer. Без исходного кода сложно судить, но вроде как Вы модифицировали матрицу преобразований, вот только вместо банальных CGAffineTransformRotate сами высчитывали коэффициенты матрицы преобразований. Как академическая задача — шикарно, но как практическая… Не хотел бы я этот код поддерживать :)
Код действительно сложно поддерживать — он состоит из двух строчек инициализации
и одной строчки в цикле для картинки
IBOutlet UIImageView *p; // картинка уже в XIB файле
float xs = 1.0/100.0; // размер картинки по ширине
и одной строчки в цикле для картинки
p.transform = CGAffineTransformMake(xs*(x3-x2), xs*(y3-y2), xs*(x2-x1), xs*(y2-y1), 0.5*(x1+x3), 0.5*(y1+y3));
повторюсь, обожаю иронию
Но тем не менее, сложность поддержки определяется не количеством строк. ++i + ++i менее понятен, чем его развернутый вариант
Но тем не менее, сложность поддержки определяется не количеством строк. ++i + ++i менее понятен, чем его развернутый вариант
Какого кода, если к любому UIView можно прицепить неограниченое число CALayer и задать каждому свой CA3DTransform? Прослойка-то понятно, весь CoreAnimation на GL сделан. В целом ваш фокус родом из 90х, тогда без аппартной акселерации приходилось имитацию 3д делать деформацией отображаемой картинки. Наверняка вы тоже баловались трюком с пропуском каждого n-го столбца и/или строки для имитации повернутой на сколько-то градусов плоскости.
Так вот для чего нужна математика в программировании! :)
Если проекция изометрическая (не перспективная), то квадратные грани перейдут в параллелограмы. В этом случае не нужно резать грань на два треугольника, достаточно применить одно аффинное преобразование ко всему квадрату, так как аффинное преобразование переводит параллелограмм в параллелограмм.
Если проекция перспективная, то при наличии текстуры приближение с помощью двух аффинно преобразованных треугольников будет неточным, особенно при сильной перспективе. Дело в том, что в этом случае нужно честно интерполировать текстурные координаты с учетом перспективной проекции, чего не добиться аффинным преобразованием.
Еще в формулах где-то ошибка. Если подставить точку (0, 0), на выходе получится (0.5*(x1+x3), 0.5*(y1+y3)).
Если проекция перспективная, то при наличии текстуры приближение с помощью двух аффинно преобразованных треугольников будет неточным, особенно при сильной перспективе. Дело в том, что в этом случае нужно честно интерполировать текстурные координаты с учетом перспективной проекции, чего не добиться аффинным преобразованием.
Еще в формулах где-то ошибка. Если подставить точку (0, 0), на выходе получится (0.5*(x1+x3), 0.5*(y1+y3)).
Формулы первого курса, умышленно перевёрнуты — молодец, что заметил. Данный алгоритм я использовал для более общего случая отрисовки трапеций (для трассы бобслея) — поэтому выбрал треугольники.
Мой предыдущий ответ на Ваш комментарий прошу считать недействительным. Центр исходной картинки имеет координаты (0,0). Поэтому вершины смещены на -50 пикселов. Соответствующее изображение в статье исправил.
Один в один мои первые потуги с 3d анимацией на бейсике :)
Эх, помнится, делал я как-то 3D-тетрис на плоскости, простыми примитивными drawLine, drawRect,… :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как бросить кости без OpenGL