지금 우리는 일반 solver를 가지고 pop solver와 비슷한 시스템을 구현해보고 있는 것이다.
물론 완벽한 시스템도 아니고, 예외상황도 발생하고 물리법칙도 완벽하지 않지만, 이 과정을 거치고 dynamic solver를 가면 별거 아니네? 하게 될 것이다.
모든 랭글러를 위하여!
예제 1)
중력을 묘사해 보자.
지금까지 배운 것으로 중력을 묘사하면 문제가 발생한다.
- 어느 순간 제대로 튀어 오르지 못하고 바닥에서 갑자기 파파박 팝핑이 되는 순간이 온다.
- 우리가 만들어준 충돌에 대한 정의 때문에 포인트가 한 번은 벽 바깥으로 나갔다 오게 되는데 너무 많이 나갔다 들어오게 되는 부분이 아쉽다. (충돌 시점에 바운더리를 넘어가서 콕 박히는 느낌이 있다.)
그렇기에 우리가 이번 시간에 개선해야 할 점은 크게 3가지이다.
- 어느 순간 튀어 오르지 못하는 상황을 개선하자.
- 최대한 벽 안쪽에서 바운싱이 일어나도록 개선하자.
- 포인트의 바운스에 규칙을 만들어주자.
- 공이 바운스 될 때마다 바운스 되는 힘을 점점 잃게 되는 규칙을 만들어보자.
- 불규칙 바운스에 대한 규칙을 만들어보자.
중력에 대한 세팅을 잡아보자.
힘(중력)에 대한 정의가 필요하다.
힘이 존재함으로 인해 속도의 변화가 있고, 그로 인해 거리의 변화가 발생한다.
최종적인 움직임은 속도에 영향을 받는다.
속도가 얼마인지를 안다면 움직임을 알 수 있고, 움직임에 따라서도 속도를 유추할 수 있다.
속도는 힘에 의해 변형이 발생된다.
속도가 빨라지거나 느려지거나, 방향이 바뀌거나 하기 위해서는 어떠한 힘이 필요하다.
우리는 지금까지 속도에 대한 내용을 활용해서 움직임을 solver에서 묘사한 것이다.
이제 충돌에 따른 속도변화에 힘(중력)이라는 요소를 추가적으로 넣어줄 것이다.
최종적인 움직임은 어떠한 가속도가 표현되고 있는 움직임일 것이다.
시간에 따라 포인트가 가진 기존 속도에 힘(중력)으로써 지속적인 영향을 줄 것이다.
이제 우리는 주어진 포인트의 개성과 세팅을 활용해서 충돌에 따른 속도의 변화를 만들어주고 중력에 의한 속도 변화를 만들어주고 이렇게 만들어진 속도를 활용해서 움직임을 줄 것이다.
이 내용을 반복해 주는 것이 solver이다.
중력을 만들어주기 위해 Attribute wrangle을 만들어주자.
우리가 만들어줄 Gravity라는 정보는 속도에 영향을 줄 것이기 때문에 vector 정보여야 한다.
임의의 값을 중력으로 받을 수 있도록 channel vector로 만들어주자.
solver로 들어가 보자.
현재는 충돌에 따른 방향전환을 담당해 주는 Attribute wrangle과 @vel에 따른 움직임을 나타내는 Attribute wrangle이 있다.
우리가 가지고 있는 @vel이 있고, 충돌이 일어나지 않는다면 기존의 @vel을 그대로 활용하게 된다.
저 사이에 Gravity를 표현할 수 있는 Attribute wrangle을 추가해 주자.
위의 엑셀 그림처럼 원래 움직이려는 @vel을 지속적으로 중력으로 눌러주게 될 것이다.
처음 @vel에서 중력을 받은 횟수에 따라 방향이 아래로 내려가고 있다.
이것을 식으로 표현한다면 다음과 같다.(@vel에 대한 업데이트(갱신)이다.)
@vel = @vel + @gravity;
잘 작동되고 있다.
근데 아직 우리 3가지 문제 해결해야 한다.
복습을 할 때 주의해야 할 것!!
좋아. 여기에 이 식을 쓰면 되는구나. 이렇게 공부하지 말자.
전반적인 과정을 꼭!!! 이해하고 직접 식을 써 내려가자.
그래야 실력이 는다.
dynamic solver로 가면 이 모든 과정이 거의 다 노드로 이뤄져 있다.
gravity 노드 하나 꺼내서 연결해 주고 parameter에 값만 넣어주면 중력 적용 잘 된다. 쉽다.
하지만, solver의 뉘앙스를 알고 쓰느냐 모르고 쓰느냐의 차이로 dynamic solver 내에서 무언가를 할 수 있는가, 없는가 이런 차이가 발생한다.
volume 이야기는 하지 않았지만, smoke solver, pyro solver 모두 똑같다. 정말 똑같다. 우리가 지금 머리 굴리는 방식과 똑같다. 무슨 일이? 왜? 어떻게? 일어나느냐가 정말 중요하다. 우리가 배우게 될 rigid body에서 충돌 조건은 volume이다. particle 또한 dynamic solver 안에서 충돌조건은 volume이다. 그렇기 때문에 이와 같은 과정이 없다면 dynamic solver로 갔을 때, 다 뜯어놓고 설명하기가 어렵다.
대신 지금은, dynamic solver가 이렇게 작동하겠구나 하는 감각을 키울 수 있다. 전 frame이 가진 정보를 활용해서 규칙에 맞게 새로운 정보를 만들어낸다. 그리고, 원하는 규칙을 추가해 준다.
제일 먼저, 충돌할 때 바운더리를 튀어나가는 것들을 보정해 보자.
solver를 활용할 때 아직 한 번도 다루지 않았던 Sub Steps를 활용해야 한다.
Sub Steps
- 좀 더 높은 퀄리티의 결과를 얻기 위해 하는 것
- 근데 왜 높은 퀄리티를 결과를 얻을 수 있는가?
※ sub steps를 이해하려면 몇 가지를 동시에 이해할 필요가 있다.
- solver의 수행이 어떻게 되는지를 알아야 한다.
- block을 다뤘던
기억이 나면 좋다. 아니다.기억이 나야 한다. - dynamic solver와 일반 solver의 sub steps는 다르다.
이 세 가지 뉘앙스를 모두 이해해내야 한다. 특히 1번과 2번은 오늘 꼭 알아야 한다.
상황을 세팅해 주자.
add 노드를 활용해 {0,0,0}에 포인트를 만들고, solver를 달아주었다.
solver 내부는 간단하게 attribute wrangle을 활용해서 포지션이 {1,0,0}씩 이동하도록 해주었다.
1 frame에서 우리가 얻게 될 결과는? 없다. solver의 시작 프레임이 5 프레임이기 때문에 1~4 프레임은 얻을 수 있는 결과가 없다.
그렇다면 5 프레임에서의 결과는? 포인트가 {1,0,0}으로 이동한 결과를 얻을 수 있다.
- prev_frame에 {0,0,0} 포지션인 포인트가 들어가서 이동에 대한 solver 내부의 작업을 수행하고 OUTPUT의 결과를 보여주기 때문이다.
위의 이미지와 같은 결과를 얻을 수 있을 것이다.
만일 위와 같은 방식(solver)을 solver가 아닌 방식으로 표현한다면, 어떻게 될까?
Frame 이름이 붙은 Switch 노드는 parameter의 select input의 integer number에 따라 input의 정보를 결과로 보여줄 것이다.
- frame_0가 검은색인 이유는, 현재 후디니가 1 프레임부터 시작하는 것을 표현하기 위함이다.
5 프레임의 결과에 주목하자.
5 프레임의 결과는 add2가 아닌, wrangle이 실행된 OUTPUT이다.
solver에서 일어나는 일에 대해 표현해 준 것이다.
5 프레임의 결과가 6 프레임의 prev 노드로 들어가게 되고, 6 프레임의 결과가 7 프레임의 prev 노드로 들어가게 되는 것이다.
만일 우리가 120 frame의 결과를 보고 싶다면? 스타트 프레임을 고려해서 위와 같은 수행이 116번 이뤄져야 할 것이다.
위와 같은 반복을 어떻게 표현해 줄 수 있을까?
지금 구조를 보면, 우리가 얻은 결과에 대해서 반복이 발생하고 있다.
이와 같은 조건에서 우리가 사용할 수 있는 block이 있다.
- For-Loop with Feedback이다.
iteration의 값이 1이라면? block의 결과는 5 프레임의 결과일 것이다.
iteration의 값이 2라면? block의 결과는 6 프레임의 결과일 것이다.
iteration의 값이 올라가면 올라갈수록, 결과는 7,8,9,... frame의 결과를 얻을 수 있을 것이다.
sub steps는 solver가 한 프레임에 몇 번이나 반복을 해줄지를 정하는 것이다.
현재 각 iteration이 1인 블록을 연결해 준 모습이다.
solver의 sub steps가 1이라면, solver 내부의 작업을 1번 수행한 뒤의 결과가 우리가 얻게 될 결과라는 의미이다.
- sub steps가 1이라는 의미는, 지금까지 우리가 해왔던 작업과 동일하다는 것을 의미한다.
만일 sub steps가 2라면, solver 내부의 작업을 2번 반복한 뒤의 결과를 OUTPUT으로 쓰겠다는 것을 의미한다.
- 이 말의 의미는 위의 이미지의 블록의 iteration이 2일 때와 같다는 의미이다.
- solver의 sub steps가 3이라면, iteration도 3, sub steps가 8이라면, interation도 8이라는 의미이다.
sub steps가 2라면, solver 안의 내용이 2번 적용된 결과가 우리가 얻게 되는 결과이다.
마찬가지로 sub steps가 3이라면 solver 안의 내용이 3번 적용된 결과가 우리가 얻게 되는 결과이다.
그렇기 때문에 위의 그림처럼, sub steps가 2일 때는 solver 안의 내용(@P = @P + {1,0,0};)이 두 번 적용된 결과가 각 프레임마다 얻게 되어서 x축으로 2씩 증가하게 되고, 3인 경우 또한 그림과 같은 결과를 얻게 되는 것이다.
중력을 적용했던 바운싱 포인트의 sub steps 수치를 변경시켜 보자.
sub steps 수치에 따라 각각 빨간색이 1, 초록색이 2, 노란색이 3일 때의 결과이다.
- 배로 빠르게 움직이는 이유는 solver 안의 내용을 2번, 3번씩 반복한 결과를 output으로 전달해 줬기 때문이다.
- sub steps 수치가 증가함에 따라 포인트의 속도가 배로 빨라졌다.
- 우리가 원한 결과는 이런 것이 아니다.
- sub steps의 활용의 목적은 좀 더 높은 퀄리티의 결과를 얻기 위함이다.
- 지금은 sub steps의 수치에 따라 다른 결과가 나와버린다.
- 그리고, sub steps의 수치가 높은 결과가 더 엉성한 결과같이 보인다.
sub steps가 올라갔을 때, 훨씬 좋은 결과를 얻을 수 있도록 개선이 필요하다.
sub steps의 결과를 잘 얻고 싶다면, sub steps의 값이 변하더라도 맥락상 동일한 결과를 얻을 수 있어야 한다.
만일 Sub steps가 1일 때, @vel이 {1,0,0}이라면, 0에서 1까지 한 번에 이동하는 결과를 얻게 된다.
그런데, Sub steps가 2일 때, @vel에 변화를 줘서 @vel이 {1/2,0,0}이라면, sub steps가 2이기 때문에 두 번 반복하게 되므로, 위의 그림처럼 0에서 1까지 2번에 나눠서 이동을 하게 된다.
그렇기 때문에, Sub steps 1과 Sub steps 2는 맥락적으로 같은 내용이 된다.
어디가 바뀐 것인가?
- 속도 @vel이 sub steps 수치로 나눠졌다.
Sub steps 수치가 증가한다고 해서 얻게 되는 결과가 크게 차이가 나지 않는다.
그리고, Sub steps의 수치가 올라갔을 때, Sub steps 내부의 값을 우리는 볼 수 없다.
결과적으로 시작지점이 prev_frame이었고, sub steps 수치만큼 반복을 진행하고 나온 결과인 화살표 끝 부분의 데이터를 얻기 때문에 중간과정에 주황색 부분처럼 무언가 디테일한 결과들이 있었다 하더라도 의미가 없다.
작업을 수행하기 때문에 중간의 데이터를 얻은 기억은 있을 것이다. 하지만 우리가 확인할 수는 없다.
이것에 따라, 한 방향으로 가고 있는, 충돌에 대한 이야기가 없는 결과들은 큰 차이가 없다.
그런데, 충돌에 대한 조건을 달아준다면, sub steps가 증가함에 따라 @vel을 나눠주는 이 행위가 굉장한 디테일을 살려줄 수 있다.
위의 그림과 같이, 충돌이 생겼을 때, Sub steps 1은 바운더리를 상당히 뚫고 들어간 상태에서 방향전환이 이뤄지는 반면에 Sub steps의 수치가 올라감에 따라 바운더리에서 매우 가까운 위치에서 방향전환이 일어나게 된다.(오차가 줄어든다는 의미이다.)
우리가 가진 속도를 그대로 둔 상태로 Sub steps 수치를 올리는 것이 아니고, 이 속도에 대한 내용을 Sub steps 수치로 나눠준다면, 더 세분화되어서 충돌이 일어나는(조건이 바뀌는) 지점을 찾아내게 된다.
일단 중력은 제외하고, 3일 차에 만들었던 point bounce예제를 가지고 이야기해 보자.
현재는 아무런 작업을 해주지 않았기 때문에, sub steps의 수치가 올라감에 따라 속도는 배로 증가하게 된다.
Sub steps를 적용하기 위한 작업을 해보자.
System을 세팅하는 것이기 때문에 정보다발 쪽에 attribute wrangle을 만들어주자.
이제 sub steps의 값을 활용해서 solver 안에서의 속도의 변화를 줘야 한다.
solver 밖에서 정의해 준 sub steps의 값을 point 함수로 불러와서 @vel을 나눠주었다.
우리가 원래 이동해야 하는 @vel이 위에서 정해졌고,
이 속도를 SS로 나눠준다면, 포지션에 더해지는 @vel이 나눠진 값으로 더해지기 때문에 우리가 원했던 결과가 나올 것이다.
틀렸다.
결과를 보면 매우 적은 움직임을 보이고 그 자리에 굳어버리는 포인트를 볼 수 있다.
sub steps 수치가 1일 때는 잘 움직이지만, 수치를 증가시키면 똑같이 찔끔 움직이고 허공에 굳는 포인트를 볼 수 있다.
지금과 같은 세팅이라면, Sub steps가 2일 때, 주어진 속도가 16이라면, 충돌이 없기 때문에 충돌처리는 넘어가서 @vel은 계속 16을 유지한다. 그리고 vel_SS에 와서 @vel은 2로 나눠준 8로 갱신된다. 그리고 마지막 make it move 노드에서 우리가 원했던 16의 절반만큼 이동을 하게 된다. 이때 sub steps가 2이기 때문에, solver의 내용이 한번 더 작동을 하게 된다. 두 번째 반복에서의 @vel의 시작은 8이다. 충돌처리가 없으니 @vel은 8로 유지된 상태로 vel_SS로 넘어오는데, 그곳에서 다시 sub steps의 수치로 나눠주게 된다. 그리고 move 노드에서 @vel은 4로서 작동을 하게 된다. 이렇게 1 프레임이 끝나게 되고, 다음 프레임이 되면 다시 이 작업을 반복하게 되는데, 이때의 @vel의 시작값은 4이다.
@vel은 순식간에 감쇄되어 버려서 포지션의 변동이 매우 미미하게 움직이고 멈춰버리게 되는 것이다.
이 상황은 꼭 바꿔줘야 한다. 수정을 진행하거나, 쉬운 방법으로 변경을 해줘야 한다.
먼저 쉬운 방법으로 변경을 하는 것이다.
move 노드에서 sub steps의 수치를 포인트 함수로 받고, @vel의 값을 sub steps로 나눠준 값으로 포지션을 갱신하는 것이다.
위의 방법과는 분명 다르다. @vel을 sub steps 수치로 나눠주는 것은 같지만, 아까 안된 상황은 @vel을 갱신해 주는 것이고, 지금 되는 상황은 @vel이 새롭게 갱신되지 않고 초기 값을 유지한다.
@vel = @vel / SS;
이 경우라면, 앞에서 초기에 만들어줬던 @vel이 계속 새롭게 갱신되면서 작아지게 된다.
이렇게 되면 안 된다.
초기 @vel은 그대로 있고, 적용할 때만 작아지는 것이 맞다.
@P += @vel / SS;
@vel을 SS로 나눠주는 것은 같지만, @vel을 갱신하거나 하지 않기 때문에, 초기값을 잘 유지하게 된다.
두 번째로, 노드를 수정해 주는 것이다.
새로운 노드를 추가해 주었다.
아까 잘못된 방식과 비슷하지만, 초기의 @vel을 갱신하는 것이 아니고, 새로운 vector 어트리뷰트를 선언(여기에서는 SSvel)해서 거기에 @vel을 SS로 나눈 값을 할당해 주고, 그 값으로 포지션에 변화를 주는 것이다.
이 방법 또한 기존의 @vel은 sub steps가 진행되어도 변동이 없다.
이제 퀄리티를 비교해 보면서 sub steps 수치에 대해 고민해 보자.
Sub steps가 1인 것은 하얀색, 2인 것은 빨간색, 4인 것은 자주색, 8인 것은 청록색, 32인 것은 노란색이다.
잘 보면 처음에 상단 바운더리를 튕겨져 나오는 것부터 다르다.
두 번째 바운스 또한 다르다.
밖으로 나가지도 않고 꺾인듯한 뉘앙스이다.
이것은 sub steps 중간에 밖으로 나갔다가 돌아온 것이다.
sub steps 수치가 높은 데이터들은 이미 밖에 나갔던 데이터가 존재한다. 중간과정을 우리가 볼 수 없을 뿐이다.
후반부에 가서 이렇게 위치가 차이 나는 것은 밖으로 나갔을 때의 오차에 대한 움직임 보정으로 보면 될 듯하다.
sub steps를 높여준다는 것은 작업할 계산량이 증가한다는 것이다.
그렇기 때문에 얼추 괜찮은 선을 찾아줘야 한다.
지금은 괜찮을지 모르지만, volume 작업을 하는 smoke, pyro 등으로 가면 계산시간이 엄청 늘어난다. 그렇기 때문에 우리는 절충과 타협이 필요하다.
결론적으로 sub steps가 1일 때는 오차가 많이 발생하지만, 4 정도만 되어도 그럴싸한 결과에 근접할 수 있다. 엄청 정확한 정보가 필요하다면 sub steps의 수치를 더 높여줘야 할 필요도 있긴 하다.
두 번째 바운스의 노란색 라인을 보면 밖으로 나가지도 않고 꺾인 것처럼 보인다. 저것은 32번 @vel을 나눠서 밖으로 나갔다가 돌아온 것이다.
일반 solver를 이용하고 있다면, 이때 활용되는 sub steps를 잘 다뤄줘야 한다.
sub steps를 그냥 올려주면, 반복의 횟수가 증가하기 때문에 속도가 증가한 것처럼 보이게 된다. 우리가 원하는 결과는 그런 것이 아니다.
sub steps를 올려줌으로써 좀 더 디테일한 결과를 얻고 싶다면, solver 안에서 sub steps 값을 활용해서 변화를 주는 것이 필요하다.
sub steps의 값이 높을 때와 낮을 때가 동일한 의도를 가지고 작업이 될 수 있도록 세팅을 해줘야 한다.
ex) 그래서 우리는 @vel을 sub steps의 값으로 나눠주는 과정을 만들어줬고, @vel의 의도는 바꾸지 않았다.(초기 @vel은 sub steps를 높이던, 낮추던 변화가 없다.)
이제 다시 중력을 적용해 보자.
잘 생각해 보자. 우리가 이용할 중력에 대한 정보는 속도에 영향을 준다. 그렇기 때문에 매 프레임마다 속도가 변하게 된다. 그런데, 우리가 이용할 중력이라는 값은 변하는가? 아니다. 중력이라는 힘은 동일하다.
solver 내부에 중력에 대한 wrangle을 달아주었다.
file cache를 이용해서 sub steps의 수치에 따른 결과를 비교해 보자.
하얀색이 sub steps 1, 빨간색이 sub steps 2, 자주색이 sub steps 4의 결과이다.
sub steps 수치가 증가함에 따라 중력이 세지고, 훨씬 빠르게 땅에 박혀버리는 것을 볼 수 있다.
sub steps가 커짐에 따라 중력이 커지는 것은 우리가 원하는 결과가 아니다.
우리가 원하는 결과는, sub steps의 값과는 관계없이 의도가 동일해야 한다. sub steps의 값이 낮다면, 정교함은 아쉽겠지만, 빠르게 계산을 받을 수 있을 것이고, 반대로 sub steps의 값이 높다면, 시간이 걸리는 것을 감수하더라도 그만큼 정교한 결과를 얻고 싶다는 것을 의미한다.
그렇다면 중력에 대해서 어느 부분을 바꿔줘야 sub steps의 값과 관계없이 의도가 같게 만들어줄 수 있을까?
solver의 sub steps가 어떤 원리로 작동하는지 알면 간단하다.
- sub steps 값이 1일 때, solver 안에서 중력의 작용은 -1 한 번이다.
- sub steps 값이 2일 때, solver 안에서 중력의 작용은 -1, -1 두 번이다.
- sub steps 값이 4일 때, solver 안에서 중력의 작용은 -1, -1, -1, -1 네 번이다.
그렇다면, 애초에 들어오는 중력의 값 -1을 sub steps 값으로 나눠준다면 어떻게 될까?
- sub steps 값이 1일 때, solver 안에서 중력의 작용은 -1/1 한 번이다.
- sub steps 값이 2일 때, solver 안에서 중력의 작용은 -1/2, -1/2 두 번이다.
- sub steps 값이 4일 때, solver 안에서 중력의 작용은 -1/4, -1/4, -1/4, -1/4 네 번이다.
결과적으로 sub steps가 어떤 수치이더라도 중력의 작용은 -1이다.
sub steps가 1일 때는 벽 밖으로 나가서 생기는 오차가 많기 때문에 튀어 오르는 높이가 상쇄되지만, 10의 결과를 보면, 높이에 대한 상쇄가 많이 일어나지 않는 것을 볼 수 있다. 그럼에도 오차가 쌓이고 쌓이면 점점 낮아지는 것을 볼 수 있다.
우리는 지금까지 작업한 것을 적어보자면 다음과 같다.
- 조건에 있어서 충돌을 한다.
- 중력이 속도에 적용되고 있다.
- 결과의 퀄리티를 높이기 위해 sub steps의 값을 높여줄 수 있다.
- sub steps의 값과 관계없이 동일한 의도를 가진 모션이 나오는 것을 확인할 수 있다.
이제 충돌에 의한 에너지 손실을 묘사해 보자. 간단하다.
에너지 손실이라는 표현은 바운싱 되었을 때 튀어 오르는 높이가 줄어드는 것으로 표현할 수 있다.
- 초기에 1이라는 높이에서 바운싱 되었을 때 20%의 손실이 있다면, 0.8만큼 튀어 오를 것이고, 그다음 바운싱에서는 0.8 x 0.8 = 0.64만큼 튀어 오르게 될 것이다.
원리만 알고 있다면, 아주 작은 부분의 수정으로 적용이 가능하다.
solver의 충돌에 대해 제어해 주는 부분으로 가보자.
y에 대해서 이 조건에 부합한다면, 속도가 y축으로 180도 바뀌고 있다. 이때, 이곳에 에너지 손실 표현을 위해 0.8을 곱해준다면 속도가 바뀌어야 하는 순간에 방향만 바뀌는 것이 아니라 힘의 크기도 0.8만큼 줄어들 것이다.
고난주간 6일 차 숙제
움직이는 점에 대해 한 점으로 모이게 되는 중력을 표현해 보시오.
point gravity.
모든 공간에 대해 빨간 점을 향해서 중력이 발생한다.
일단 틀리다는 것을 전제로 하고 이야기를 진행해 보겠다.
일단 빨간 점의 움직임을 만들어줬다.
그리고 이 움직임은 solver의 input2에 연결해 주었다..
sphere를 만들고, scatter 노드로 점을 뿌려줬다.
각 점에 대해 @N = normalize(@P); 를 wrangle로 달아서 원의 중심으로부터 퍼져나가는 노멀방향을 만들어줬고, 이 노멀을 초기 @vel 값으로 설정하였다. 그리고 solver의 input 1로 연결하였다.
solver 내부에서는 일단 각 점 @P에 대해 input2로 들어온 빨간 점을 향하는 방향벡터 v@dir을 만들어줬다.
(v@dir = normalize(pos - @P);)
pos는 빨간 점 P의 포지션이고, 빨간 점 포지션 - 각 점의 포지션 인 이유는 벡터의 방향 때문이다.
그리고 @vel = @vel + @dir; 을 적어줘서 @vel이 @vel과 @dir의 합으로 갱신되도록 해줬다.
나머지는 @P에 @vel의 값이 계속 더해지도록 wrangle을 달아줬다.
solver 바깥에서는 trail 노드와 add 노드를 활용해서 라인형태로 궤적이 남도록 해주었다.
add 노드 적용 시, 지난번 지렁이 과제 때처럼 각 포인트에 대해 초기에 id를 부여해서 id attribute가 같은 것들끼리 라인으로 만들어지도록 해줬다.
오늘 강의가 이렇게 이론적으로 많은 것을 내포하고 있는지 정말 몰랐다.
과제를 진행하면서 딱 코드 몇 줄 바꿔주면서 중력의 표현은 쉽구나 하고 웃었던 나 자신을 반성한다.
속도에 대해 처음 속도를 유지해줘야 하는 것도 모르고, 나는 과제를 하면서 신나게 속도를 갱신해 줬던 거 같은데... 역시 완벽한 오답이었다.
더 깊게 생각하고 고민하면서 작업을 해야 하는구나 하고 오늘도 다짐해 본다. 그리고 오늘 배운 내용에 대해 복습을 철저하게 해야겠다.
과제는... 어디서부터 손을 대야 하지
과제는 어찌어찌 일단락 지은 것 같은데... 왜 공부를 하면 할수록 내가 모르는 것에 대해 화가 나는 걸까 ㅠ 이 화를 진정시키려면 더 열심히 공부해야겠다... 그래도 또 모르겠지...
You know nothing, Jon Snow
왕좌의 게임(얼음과 불의 노래)의 유명하다면 유명한 밈같은 대사가 떠오른다...
넌 아무것도 몰라 SevenEleven아...
'Houdini > Houdini1_Starter' 카테고리의 다른 글
| STARTER10 (0) | 2023.01.29 |
|---|---|
| STARTER09_고난주간 6일차_Point Gravity (2차 수정) (0) | 2023.01.28 |
| STARTER09_고난주간 4일차 (0) | 2023.01.25 |
| STARTER09_고난주간 3일차_Bounce with Solver (0) | 2023.01.21 |
| STARTER09_고난주간 2일차 (1) | 2023.01.19 |
