Как бросить кости без OpenGL

[Aspos]

Это очено здорово. А просто несколько анимированных png нельзя было использовать?

[PapaBubaDiop]

Теоретически можно. Как это сделано в Talking Tom — с первого взгляда трехмерная игрушка. На самом деле набор подготовленных картинок. Однако при этом объем приложения возрастает катастрофически. Для кубика надо 36 * 18 = 700 картинок сформировать, с шагом 10 градусов по каждому углу.

[mannaro]

сделать 20, но анимацию кубика по всему полю ^_^
Слишком подло.

[apollonin]

Очень здорово! Может кто-то сталкивался с аналогичной задачей по бросанию кубиков под html5 мобильные приложения? Как решали?

[astec]

Посмотрите пример отсюда: ux.stackexchange.com/questions/11229/is-this-rotating-cube-interface-user-friendly — там есть ссылка на работающую демку — peterolson.github.io/jqCube/demo/demo.html

[agee]

Прикольно. Я заметил, что у Вас во втором видео для пущей объемности еще и некое подобие теней. А вот как это достигалось?

[PapaBubaDiop]

Точно так же- рисуем в режиме полупрозрачности 6 треугольников черного цвета. Со стороны наблюдателя (источника света) всегда видно три грани кубика.

[silvansky]

Хех, мы подобным способом в универе крутили всякие фигуры, прям живо вспомнился катающийся дорожный знак. =)

[Halt]

Интересное, хотя в общем-то логичное решение.

P.S.: Если уж игра делалась для мобильных устройств, можно было сделать так, чтобы кубики катались от положения устройства и ускорения. Потряс планшет — кубики перемешались. Повернул — скатились в угол и т.д.

[Flanker_4]

А почему Вы не сделали все на CALayer, ведь все то, что можно представить плоскостями отлично анимируется с помощью слоев «без» openGL. К примеру

www.cocoanetics.com/2012/08/cubed-coreanimation-conundrum/
weblog.invasivecode.com/post/29307073330/core-animation-transform-layer


Более того, я даже помню wwdc шное видео, где Apple рассказывала о одной своей «кубической» анимации в месенджере и проблемах, с которыми они столкнулись

[PapaBubaDiop]

Спасибо, что упомянули про слои. Но, фактически, CALayer — это прослойка opengl-ная, много подготовительного кода требовалось, в отличие от ImageView.

[Flanker_4]

Но UIImageView не далеко отошел от CALayer. Без исходного кода сложно судить, но вроде как Вы модифицировали матрицу преобразований, вот только вместо банальных CGAffineTransformRotate сами высчитывали коэффициенты матрицы преобразований. Как академическая задача — шикарно, но как практическая… Не хотел бы я этот код поддерживать :)

[PapaBubaDiop]

Код действительно сложно поддерживать — он состоит из двух строчек инициализации

    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));

[Flanker_4]

повторюсь, обожаю иронию
Но тем не менее, сложность поддержки определяется не количеством строк. ++i + ++i менее понятен, чем его развернутый вариант

[Nomad1]

Какого кода, если к любому UIView можно прицепить неограниченое число CALayer и задать каждому свой CA3DTransform? Прослойка-то понятно, весь CoreAnimation на GL сделан. В целом ваш фокус родом из 90х, тогда без аппартной акселерации приходилось имитацию 3д делать деформацией отображаемой картинки. Наверняка вы тоже баловались трюком с пропуском каждого n-го столбца и/или строки для имитации повернутой на сколько-то градусов плоскости.

[tonkado]

Так вот для чего нужна математика в программировании! :)

[FloppyFormator]

Далеко не только это.

[naething]

Если проекция изометрическая (не перспективная), то квадратные грани перейдут в параллелограмы. В этом случае не нужно резать грань на два треугольника, достаточно применить одно аффинное преобразование ко всему квадрату, так как аффинное преобразование переводит параллелограмм в параллелограмм.

Если проекция перспективная, то при наличии текстуры приближение с помощью двух аффинно преобразованных треугольников будет неточным, особенно при сильной перспективе. Дело в том, что в этом случае нужно честно интерполировать текстурные координаты с учетом перспективной проекции, чего не добиться аффинным преобразованием.

Еще в формулах где-то ошибка. Если подставить точку (0, 0), на выходе получится (0.5*(x1+x3), 0.5*(y1+y3)).

[PapaBubaDiop]

Формулы первого курса, умышленно перевёрнуты — молодец, что заметил. Данный алгоритм я использовал для более общего случая отрисовки трапеций (для трассы бобслея) — поэтому выбрал треугольники.

[PapaBubaDiop]

Мой предыдущий ответ на Ваш комментарий прошу считать недействительным. Центр исходной картинки имеет координаты (0,0). Поэтому вершины смещены на -50 пикселов. Соответствующее изображение в статье исправил.

[gleb_kudr]

Один в один мои первые потуги с 3d анимацией на бейсике :)

[Mezomish]

Эх, помнится, делал я как-то 3D-тетрис на плоскости, простыми примитивными drawLine, drawRect,… :)