Timebased Animation Interface
어제 파워플 3차 모임에선 광호군이 트윈맥스에 대해 발표를 했습니다. 트윈맥스를 위시하여 트위너라 불리는 녀석들은 시간 기반의 애니메이션을 코딩할 수 있게 해줍니다. 따라서 이러한 라이브러리에서 가장 중요한 것은 시간의 통제입니다. 어떻게 시간을 기술할 것이냐에 따라 편리성이 달라지는 셈입니다.
1. Timeline스타일
거의 모든 모션관련 프로그램은 Timeline스타일을 좋아합니다. Timeline이란 절대적인 시간 축이 무조건 흐르고 있는 상태에서 특정한 모션이 시작되는 순간과 끝나는 순간을 절대시간 축을 이용하여 기술하는 방식입니다.
프로그래밍적인 인터페이스로 표현하면 아마도 다음과 같을 겁니다.
setAnimation( bitmap, startTime, endTime, {x:100} );
장점
절대적인 시간 축을 기준으로 애니메이션의 시간을 기술하기 때문에 언제 무슨 일이 생길 건지 알 기 쉽습니다. 즉 아래와 같은 경우 정확히 3초 시점에 몇 개가 애니메이션 되고 있을지 이해하기 편합니다.
setAnimation( bitmap1, 0, 5, {x:100} );
setAnimation( bitmap2, 1, 2, {x:100} );
setAnimation( bitmap3, 2, 5, {x:100} );
척 봐도 bitmap1과 bitmap3만 3초 시점에 애니메이션 중이겠죠.
단점
절대적인 시간 축을 사용하려면 시간이 절대적으로 흐르고 있는 경우만 가능합니다. 만약 클릭 등의 인터렉션으로 다른 시간 축에서 이벤트가 발생하게 된다면 이는 미리 정의할 수 없습니다.
setAnimation( bitmap1, 0, 5, {x:100} );
function click( $e:MouseEvent ):void{
setAnimation( bitmap2, 0, 5, {x:100} );
}
이 경우 click안에 기술된 0~5초는 메인에서 흐르고 있는 절대 시간 축과 다른 시간 축입니다. 이벤트 발생 시점을 0으로 보고 새롭게 흐르는 시간이죠. 따라서 3초 시점에 무슨 일이 일어나고 있는 알 수 없는 건 당연하고, bitmap1의 애니메이션이 끝나는 시점에 무엇을 하려고 할 때 bitmap2의 상황을 예측할 수 없습니다.
따라서 이런 경우는 bitmap1의 애니메이션이 끝나는 시점에 분기를 도입하여 bitmap2가 애니메이션 중이라면 중지 라는 로직을 추가해야 합니다.
2. duration 스타일
트윈맥스 등 트위너 들이 흔히 사용하는 스타일입니다. 시작하는 시점은 언제나 코드가 실행되는 시점이므로 상대적으로 0초부터 시작됩니다. 따라서 기술할 부분은 지속될 시간의 길이죠. 인터페이스로 표현하면 다음과 같습니다.
setAnimation( bitmap, duration, delay );
보통 delay가 도입되어 있는데 상대적인 0초로부터 얼마나 쉬었다가 시작할까를 나타내는 거죠. 따라서 1번 스타일을 2번 스타일로 옮기면 아래와 같이 기술됩니다.
//timeline 스타일 - 시작, 끝
setAnimation( bitmap1, 0, 5, {x:100} );
setAnimation( bitmap2, 1, 2, {x:100} );
setAnimation( bitmap3, 2, 5, {x:100} );
//duration 스타일 - 지속시간, 딜레이
setAnimation( bitmap1, 5, 0, {x:100} );
setAnimation( bitmap2, 1, 1, {x:100} );
setAnimation( bitmap3, 3, 2, {x:100} );
장점
애니메이션의 본질에 대해 더 이해하기 쉽게 만듭니다. 예를 들어 타임라인스타일의 다음 코드를 보죠.
setAnimation( bitmap3, 2.7, 12.3, {x:100} );
이 애니메이션을 보고 수정 요청이 좀 더 빠르게 해달라고 왔다고 하죠. 그럼 단순히 12.3을 11로 줄이는 것이 답이 되지 않습니다.
보통 애니메이션을 이해하기 위해 먼저 12.3 – 2.7 = 9.6 초를 뺄셈합니다. 그 뒤에 9.6초가 느리다니 그럼 7초 정도로 해주면 되나 하면서 2.7 + 7 = 7.7 로 endTime을 조정합니다.
즉 타임라인 기반의 애니메이션 기술은 전체 애니메이션을 이해하기 쉽게 만들지만 반대로 개별 애니메이션의 본질을 이해하기는 어렵게 만드는 인터페이스입니다.
이에 반해 duration스타일은 처음부터 지속시간이 기술되어 있습니다. 위의 샘플을 duration스타일로 표현해보죠.
setAnimation( bitmap3, 9.6, 2.7, {x:100} );
이렇게 된 상태에서는 처음부터 사고의 흐름이 9.6초가 느려? 그럼 7초로 해줄께 하고 수정도 9.6만 7로 바꾸면 됩니다. 개별 애니메이션에 대한 기민한 대응이 가능하죠.
또한 인터렉션 등으로 발생하는 이벤트처리에서 애니메이션 기술도 자연스럽습니다. 왜냐면 모든 애니메이션이 상대적으로 기술되고 있는 상황이라 프로그램 어디에도 절대 시간 축을 기반으로 하고 있는 부분이 없을 것이기 때문에 아예 위에서 언급했던 메인 타임라인이 5초가 되면 이란 식으로 전개되지 않습니다(아마 개별 애니메이션을 실행시키되 끝나거나 연결되는 경우는 전체 프로그램 수준에서 통제 로직을 짤 수 밖에 없겠죠 ^^)
단점
timeline스타일의 장점이 그대로 단점이 됩니다. 즉 3초 시점에 무슨 일이 일어나는 건지 이해하려면 열심히 덧셈을 해봐야 합니다.
3. frame스타일
frame스타일은 시간을 frame으로 추상화 시키는 방식입니다. 플래시IDE가 사용하는 방식이죠.
이 방식에서는 모든 애니메이션은 상대적입니다. 따라서 애니메이션을 비율로 기술하죠. 즉 아래와 같습니다.
setFramePerTime( 0.1 ); // 0.1초가 1프레임에 해당된다.
setAnimation( bitmap, 0, 50, {x:100} ); // 0~50프레임 즉 0~5초간 애니메이션이 작동한다.
장점
프레임레이트만 바꿔주면 전체 애니메이션의 실행시간이 비례적으로 바뀝니다. 한번 기술한 애니메이션으로 빨리 돌리기, 천천히 돌리기 등이 가능합니다.
단점
타임크리티컬한 애니메이션을 기술하면 이후 프레임레이트를 바꿀 때 문제가 생깁니다(당연하죠 =,=)
결론
frame스타일의 본질은 시간대신 frame을 쓴다는 점이지 타임라인이나 지속시간스타일과는 무관합니다. 플래시 IDE는 타임라인스타일에 프레임스타일을 합체한 모양으로 인터페이스가 제공되는 것이죠. 따라서 frame기반으로도 duration모델을 얼마든지 기술할 수 있습니다.
하지만 이게 결론은 아니고 결론은 타임라인 모델과 지속시간 모델은 상호 번역이 가능하다는 점입니다.
따라서 해당 애니메이션을 기술할 때 위에 언급한 세 가지를 섞어서 사용하는 편이 각각의 상황에 유지보수에 유리합니다.
트윈맥스의 경우도 기본 인터페이스는 duration스타일이지만 별도 객체를 이용하면 timeline스타일도 사용할 수 있습니다. 또한 속성을 주면 frameRate기반으로도 작동시킬 수 있습니다.
애니메이션의 인터페이스는 해당 애니메이션이 어떠한 목적과 속성을 갖고 있냐에 따라 다르게 기술하는 편이 유지와 수정에 용이하므로 이 점을 잘 활용해야 합니다.
관련된 글:
제가 생각하기에 일반 트위너에서 부족한 점은 항상 시간이 기준이 된다는 점입니다.
트위너를 적용하기 위해 어느거리를 얼마동안 가야한다는 경우처럼 단순화 되기 쉽지 않은 경우도 있었습니다.
가령, 100m 단거리 선수가 있습니다. 선수는 사람입니다. 그러므로 선수의 재량이 아무리 좋다고 해도 상식적으로 9초때로 달릴 수는 없죠.
하지만 트위너를 이용하면
TweenMax.to(선수,5초,{x:100m,ease:Sine.easeInOut}); 이게 됩니다. ㅡㅡ
저는 이렇게 하고 싶습니다.
TweenMax.to(선수,최대 10m/1초, {x:100m,ease:Sine.easeInOut});
그러니깐 이넘이 뛸 수 있는 시간당 최대 거리를 정해놓고서는 100m를 정해진 Ease함수로 뛰라는 겁니다.
이건 거리가 가변일때 더 힘을 발휘합니다.
어짜피 사람이 최대 5m/1초를 뛸 수 있다고 해놓고는 x:20km로 할 수도 있는거니깐요.
이게 의외로 필요하다는….
음 이징함수의 문제인거 같아요.
단순히 속도와 시간의 관계는 나누면 되는거니 그거야 얼마든지 처리할 수 있겠죠.
예를 들어 10초, {x:100m} 로 하면 원하는 대로 되니까
하지만 그렇게 해도 순간 각가속도제한이 없다는게 말씀하시려고 했던거라 추측중
linear의 경우 속도 자체가 각가속도로 환원되니까 초당 10m씩 증가하겠죠.
circle의 경우엔 (1 – 0.01)의 제곱근인 셈이니까 처음엔 초당 3m정도가다가 나중엔 10m에 근접되는 공식이니 결과적으로 초당 10m를 벗어나는 일은 없습니다.
문제는 elastic이나 back같은 구간처리가 별도인 이징이나 세제곱이상을 쓰는 녀석들인거 같은데, 스플라인 기반으로 함수를 미리 정하면 각가속도가 평균속도를 넘어가지 않는 선에서 정해질거 같은데 ^^
만약 이징을 사용하는 트위닝 문제를 넘어가면 물리엔진처럼 매번 각가속도를 구하는 세계로 진입하게 되니까 다른 문제가 되죠.
또한 between의 경우는 이징중에 물리이징이 있습니다. 이걸 이용하면 더욱 엄격하게 각가속도 제약이 가능하죠.
물리계가 이징이 가능한 이유는 다음 링크에서 유도식이 잘 나와있습니다.
http://www.be-interactive.org/index.php?itemid=504
ㅎㅎ 질문이 애매해서 제대로 의중을 파악한 답이 되었나 모르겠네 ^^;
네 맞습니다. 모든 이징함수에 거리관계에 있어서 문제가 생기죠. 스플라인이라는 것이 어짜피 보간법인데 각가속도가 큰 지점에서는 샘플 위치가 촘촘하지 않아 생기는 문제점이 가장 큰 원인일거라 생각합니다. 질문의도를 쉽게 하기 이해 예를 들었던 것이였고요. between에 각가속도 제약이 있는것은 몰랐네요. 답변 감사합니다. ^^
아 그리고…. 기존 트윈이 문제점인게 Vmax 도달시간을 마음대로 정할 수 없다는 것인 것 같아요. 그래서 squence로 묶어야 원하는 결과가 나오게 되겠지요.
TweenTo(object,최대값/1초,가속시간,감속시간,가속시이징함수,감속시이징함수,{x:100,y:300});
대략 이런것도 상상해 봤습니다.
시퀀스는 원래 그 모양인데다가 연결도 잘안되지만 스플라인은 원하는대로 디자인이 되잖아요.
vmax구간을 별도로 지정하면 되니까. 가속 감속 타이밍도 그렇고.
같이 대화를 해볼수록 용호씨의 원하는 방향을 생각해보니 현재 이징함수가 도함수의 식이 아니라 적분식으로 되어있는게 불만인것도 같아요.
즉 start + end * (이징계와 현재진행/전체시간 ) 스타일의 함수로 각가속도가 명확하게 드러나지 않으니 통제도 귀찮고 감으로 때려야하고 명확하게 제어도 안된다는 불만쪽이 강한듯.
각가속도 스타일로 보면 linear 의 경우 시간을 가로축으로 속도를 세로축으로보면 가로축에 평행선이잖아요.
1차 가속함수는 2차함수의 미분이니까 도함수로 보면 1차함수인 직선의 방정식이 될테고.
이를 시각화하거나 직접 도함수의 변화를 추적하는 스타일의 이징인터페이스가 제공된다면, 위에 언급하신 제한적인 조건인터페이스보다 명확하게 각가속도 제약을 걸 수 있을 것도 같아요.
이미 적분식 상태로야 대표적으로 스플라인 인터페이스가 대체하잖아요.
path = [ 0,0 100,100 200,0 ] 이런식으로 이징의 결과값을 기준으로 제어하는 인터페이스는 이미 존재하니까.
하지만 이 스타일에선 각가속도가 명확하게 안드러나는게 문제겠죠. 그럼 예상컨데
derivative = [
//10초까지의 구간의 각가속도 도함수 - 일정하게 10으로 각속도 유지
10, function( $time ):Number{return 10},
//20초까지의 구간에서 $time이 앞구간의 10을 빼고 0~10으로 제공된다면 10~20까지 각속도가 증가
20, function( $time ):Number{ return 10 + $time },
//30초까지의 구간에서 20~10까지 각속도가 감소
30, function( $time ):Number{ return 20 - $time },
];
이런쪽으로 표현하면 도함수중심으로 재편되니까 각가속도입장에선 명확한 인터페이스가 될지도
아~ 마지막 질문은 제가 좀 헛소리를 했습니다. 그게 아닌데…. 무시~~ ^^;
음 무시하지 않고 열라 진지하게 답글을 달아버리고 말았다는..
개인적으로 위에 말씀이 너무 어렵네요 -.-;;
다만 제가 일하는 입장에서는 애니메이션은 가장 중요한 주제이긴 합니다.
히카 형님께서 주신 인터페이스는
1.Timeline 스타일
2.Duration 스타일
3.Franm 스타일
이렇게 3개의 내용을 언급해 주셨는데요.
모두 장단점이 있을듯 합니다만
개인적으로 생각할때의 이점들과 사용해야할 대상에 대에서 언급해 보도록 하겠습니다.
1.Timeline 스타일의 경우 정적인 모션에 적합한 형태인것 같습니다.
즉 인터렉티브 요소가 들어가 있지 않는 요소들의 여러개의 오브젝트를 하나의 타임라인이라는 것에 묶어서 표현할때는 이방법을 사용할 경우
코드에서 표현과 인지가 좋은것 같습니다. 하지만 개인적으로 작업환경자체가 asset을 Flash IDE를 사용해서 만드는 경우가 많은지라 거의 사용하지 않는 스타일인것 같구요.
히카 형님과 같이 asset도 무조건 actionscript로 제작할경우는 꼭 필요한 인터페이스이지 않을까 합니다.
2. Duration 스타일의 경우 인터렉티브 모션이 일부 들어간 형태일때 적합한 경우 인것 같습니다.
오브젝트 하나하나가 개별의 타임라인을 같는것처럼 느껴지기 때문에 하나의 오브젝트에 대해서만 생각하기 쉽기 때문이지 않을까 합니다.
3. Frame 스타일의 경우 사실 조금 -_- 잘 모르겠습니다.
개인적으로 1번과 2번의 경우에서 표현되기 힘든 스타일이 있는데요.
이전의 히카 형님의 ‘애니메이션에 대한 생각’에 포스트에서 말씀하셨던 형태인데요.
코드로 표현하면 이런것이 아닐까 합니다.
저는 간단하게 ‘마우스를 따라다니는 오브젝트’ 라는걸 기술하고 싶은데요.
addEventListener(Event.ENTER_FRAME,enterFrame);
function enterFrame(event:Event):void{
TweenMax.to(target,??,{x:mouseX,y:mouseY,ease:Strong.easeOut});
}
여기서 표현하는 방법은 3D엔진에서 처럼 render함수 라는게 따로 있어야 할듯 한데
이런걸 지원하는 트위너는 못본것 같습니다.
1번의 경우 TimeLineMax의 형태로 표현될수 있고
2번의 경우 TweenMax의 형태로 표현 될수 있는데
위의 경우도 표현가능한 인터페이스가 있었으면 좋겠다는 생각이 들더라구요.
주기적으로 렌더링 해주고, 하드웨어 포퍼먼스에 따라 프레임 자르고 표현해주고
등록했다 해제 했다 할수 있는 인터페이스가 있으면 좋지 않을까 합니다.
아니면 개념자체를 이해를 잘못한게 아닐까 합니다 -.-
음 어렵다고 말한건 위에 각속도시리즈겠지?
인터렉션과 관련된 애니메이션은 그 전에 먼저 어떻게 표현할 건지를 생각해봐야할거 같아
예를 들어 마우스 움직임에 트래킹을 하는 움직임이 있다고 하자.
그럼 그 움직임이 시작되어 끝나는 조건이 있을거야. 그 조건만 해도 매우 다양하겠지.
코드로 표현하면 다음과 같지
function enterFrame( $e:* ):void{
if( 끝나는 조건 ){
}else{
//애니메이션처리
}
}
그럼 끝나는 조건을 end()함수라고 하면 if( end() ) 정도가 될거야. 이를 트위너에 반영하면 시간이 들어갈 자리에 다음과 같이 되겠지.
tween.to( target, end, {} );
그럼 end함수가 기본적으로 target은 알아야할테니 트위너가 내부적으로 target은 보내준다고 하면 end함수는 인자로 target을 받는다고 가정할 수 있어. 이걸로 종료 조건은 어느 정도 일반화되겠지만 더욱 문제는 인터렉션과 관련된 표현식이지.
위에 간단하게 {x:mouseX, y:mouseY}가 나와있는데 이거야 물론 간단하지, 구현도 가능하고. 하지만 우리가 엔터프레임을 사용해가면서 인터렉션 애니메이션을 구현할 때 저정도였던가.
현재 마우스자리에 파티클을 뿌리거나, 마우스 위치주변을 회오리돌면서 별이 움직이고 있다던가 하는건 어쩌지?
아마도 모든 수식을 매 프레임마다 동적으로 계산하는 익스프레션이 필요할거야.
예를들어 가장 흔한 마우스 이벤트 애니메이션은 현재의 위치에서 마우스의 위치까지의 거리의 반을 이동해서 매 프레임마다 부드럽게 따라붙는 애니메이션이지. 그걸 먼저 엔터프레임으로 구현하면 다음과 같다.
function enter( $e:* ):void{
target.x += ( _sprite.mouseX – target.x )*.5;
target.y += ( _sprite.mouseY – target.y )*.5;
}
무한부하를 피하기 위해 약간 더 꽁수를 부리면 다음과 같이 되겠지.
function enter( $e:* ):void{
var dx:Number, dy:Number;
dx = _sprite.mouseX – target.x;
dy = _sprite.mouseY – target.y;
if( dx > 1 || dy > 1 ){
target.x += dx*.5;
target.y += dy*.5;
}
}
이 수식을 자세히 생각해보면 dx, dy 정도는 너무 흔해서 트위너가 지원해줘야하는 수준인거 같다. 그럼 그걸 아래와 같은 표현식으로 바꿀 수 있을거야
{x:’+dx*.5′, y:’+dy*.5′}
if문은? limit라는 구문이 들어가야하지 않을까 ^^
{x:’+dx*.5′, y:’+dy*.5′, moveLimit:’dx>1 || dy>1′}
최종적으로 다음과 같은 인터페이스를 생각해볼 수 있다.
function end( $target:* ):Boolean{
//이 샘플은 무한루프이므로 종료조건이 무조건 참을 반환한다.
return true;
}
tween.to( target, end, {x:’+dx*.5′, y:’+dy*.5′, moveLimit:’dx>1 || dy>1′} );
근데 여기서 우리가 흔하게 사용하는 이징함수를 도입하려면 어찌할까?
먼저 매번 이징함수를 이해해야겠지. 이징함수는 상대적인 시간의 경과 비율과 초기값, 변화총량을 갖고 계산해. 즉 다음과 같다.
시간 : 10초
현재 경과시간 : 5초
처음위치 : 100
마지막위치 : 200 = 변화총량 : 100
이러한 조건이 주어졌을때 가장 평범한 linear의 경우 다음과 같이 구할 수 있다.
function linear( start, length, rate ):Number{
return start + length*rate;
}
result = linear( 100, 100, 5/10 ); //150
머 간단한거지. 인터렉티브 식에서 중요한 포인트는 start와 rate가 애매하다는거야. 따라서 마우스에 항상 일정하게 접근하는 트위닝을 구현하려면 일정하게 라는 단어를 시간으로 환산해야겠지. 언제나 초당 100px속도로 움직인다라면 시작위치는 언제나 target의 위치고 거리는 그 위치로부터 마우스까지의 거리며 시간은 역산으로 계산할 수 있다. 다음과 같이 조건이 주어진다고 하자.
target.x = 100;
mouseX = 200;
velocity = 100;
그럼 결국 초당 100px씩 움직이는 조건내에서 이 애니메이션은 1초짜리 애니메이션이 된다.
time = ( mouseX – target.x ) / velocity = 1;
time = Math.abs( time ); //음수인 경우도 시간은 양수
그럼 길이 초기값 시간을 구했으므로 linear애니메이션을 실행할 수 있다. 경과된 시간을 계산할 방법이 없다. 애니메이션이 시작된 시점으로부터 경과된 시간은 무의미하기 때문이지. 따라서 기존 easing접근이 아예 불가능하다(사실은 이걸 알려주려고 한참 썼다^^)
따라서 각속도로 접근해야한다.초당 100px를 미분하면 어찌될까?
컴터는 미분할 수 없지만 frameRate수준에서 각속도를 구할 수는 있지. 만약 fps가 30이라고 하면 초당 30번 수준으로 enter가 호출된다고 생각할 수 있다. 따라서 1초에 100px라는건 1frame에는 3.3px를 전진한다고 볼 수 있지. linear의 경우는 도함수가 미분때리면 상수로 주어진다( ax -> a ) 그러니 할일이 없지. 위에서 주어진 조건으로 linear의 도함수 버전을 만들면 다음과 같다.
function linear( velocity ):Number{
var speed:Number;
speed = velocity / fps;
if( mouseX – targetX > 1){
return targetX + speed;
}
}
맨날 시간으로 적분된 상태의 이징함수만 봐서 도함수 스타일이 무지하게 이상할 것이니라.
시간은 어디갔냐고? 없어 ^^ 각속도에 이미 포함되어있지(시간축으로 미분했으니 당연히 없지)
그럼 쌍곡선을 사용하는 기존의 이징함수도 대체해보자.
쌍곡선으로 이징을 하는 기본은 두개의 점을 통과하는 2차방정식을 도출하는데 있다.
ax^2 + bx + c 에서 x축을 rate로 보면 0일땐 start를 통과하고, end일 때는 start+length를 통과하는 곡선으로 생각할 수 있다.
따라서 0을 대입하며 c = start고 1을 대입하면 a + b + start = start + length 이므로 a + b = length 만 충족하면 그 안에서 다양한 기울기로 도출할 수 있다.
위에서 얘기했던 경우 start가 100, length가 100이므로 a에 50, b에 50을 대입하면 특정 rate의 결과는
50*rate*rate + 50*rate +100 = (50*rate)(rate+1)+100; 로 정리되어 다음과 같이 도출된다.
rate 0.0 = 0*1 + 100 = 100
rate 0.2 = 10*1.2 + 100 = 112
rate 0.4 = 20*1.4 + 100 = 124
rate 0.6 = 30*1.6 + 100 = 148
rate 0.8 = 40*1.8 + 100 = 172
rate 1.0 = 50*2.0 + 100 = 200
제법 가파른 곡선을 그리면서 수렴하는 circleOut같은 느낌이 연상되지?
이제 이걸 도함수로 바꿔서 처리해보자. 간단히 rate에 대해 미분하여 구해보면 다음과 같이 되지.
100*rate + 50
따라서 이 미분식을 이용하면 매 rate의 각속도를 구할 수 있다. 문제는 아까 말한대로 rate가 주어지지 않는다는거지. 따라서 linear처럼 rate가 제거되려면 미분을 한번 더 해야하는데 이러면 수식은 컴터가 극한을 처리하지 않으니까 프레임당 점화식으로 바뀐다.
음 출근타이밍이군 이따 오후에 마주 써야겠당.
답변하면서 대략 정리가 되어서 결국 수식을 완전히 도출할 수 있게 되었당 ㅎㅎ
곧 도함수 기반의 이쁜 이징을 발표할 수 있을 거 같다.
엇~ 스케일이 커지는데요 ^^
설마 이제와 발빼실 생각은!!