현재 파편이 튀어나가는 모습이 조금 인위적이다.(무게감도 떨어지는거같고)
파편이 튀어나가는 것에 한계를 지정해보자.
시뮬레이션에서 변형을 주고자 하는 것은 부숴지는 벽(frac)이다. frac에 대한 sop 세팅을 만들어주도록 한다.
충돌에 의해 날아가는 조각들의 속도와 회전량에 한계값을 줄 수 있도록 새로운 노드를 추가한다.
Pop speed limit Node
- particle의 속도 / 회전량의 최대/최소 한계를 지정해줄 수 있다.
- Maximum Speed 와 Maximum Spin 을 설정할 경우, 각각의 조각은 설정한 속도와 회전량을 넘지 못한다.
- rigid body에서 올바르게 사용이 가능한 이유는 각각의 조각(물체)들이 packing된 상태로 마치 particle스러운 면모를 가지고 있기 때문이다.
원하는 결과가 나올만큼(이게 가능하려나... 인간은 만족을 모른다) tweak을 진행했다면, 결과를 file cache로 저장해주도록 한다.
(선생님은 19버전, 나는 18버전)
19버전 기준으로는...
Base Folder 에 작업자가 cache를 저장하고자 하는 폴더의 경로를 기입해준다.
18버전 기준으로는...
Geometry File의 "$HIP/geo/" 부분을 작업자가 cache를 저장하고자 하는 폴더의 경로로 바꿔준다.
$HIPNAME : 현재 houdini 작업 파일 이름
$OS : cache를 저장하고자 하는 노드의 이름 (현재는 filecache1일 것이다.)
19버전은 Base Name에 따로 $F를 붙일 필요가 없다.
- Time Dependent Cache를 활성화해주면 뒤에 $F4가 자동적으로 붙는다.
또한 Version별로 관리하고 싶을 경우, Version을 활성화해주면, Base Name 뒤에 Version에 대한 정보가 붙게 된다.
18버전은 다 Geometry File parameter에 다 적어주도록 한다.
이후의 작업은 Rigidbody 작업이 끝났다는 가정 하에 진행되는 작업이다.
car, frac에 대한 cache 데이터를 불러온다.
충돌이 발생하는 시점에 모래나 먼지가 튀어나가면 좋을듯 싶다.
이것을 위해서 사용할 수 있는 노드가 있다.
Debris Source Node
- 시뮬레이션 결과를 토대로 필요하다고 판단되는 곳에 particle을 생성할 수 있는 source를 만들어주는 노드
- 편리한 노드이다.
하지만 지금 강의에서는 쓰지 않는다.
debris source 노드를 사용하지 않는 이유
- debris source가 작동될 조건을 따로 맞춰서 시뮬레이션을 진행해야하는 구간이 있다. 이 부분이 불편하다.
- 이 노드 없이 작업을 진행해봐야 얻을 수 있는 아이디어가 따로 존재한다.
- debris source 노드 없이도 모래를 구현하는 것이 전혀 어려운 것이 아니다.
작업자가 일단 고민해봐야하는 것은, 어디에서 모래가 발생하면 좋을까? 이다.
어디에서, 어떤 시점에 모래가 발생해야할까?
기본적으로... 조각이 나는 곳에서 모래가 발생되어야하지 않을까?
여기에 추가적으로, 모래가 발생되는 타이밍은 '충돌이 발생했을 때' 모래가 나오게 될 것이다.
이것들을 노드로 구현하거나, 식으로 구현할 수 있으면 source에 대한 준비는 끝이다.
준비된 source는 particle solver로 작동시켜주면 모래 묘사는 완성될 것이다.
벽에 대해 unpack을 해주면 이전에 작업한 내용 중, 큰 조각에 대한 voronoi fracture의 결과로 in / out을 나눈 group과, 치핑된 조각에 대해 voronoi fracture의 결과로 in / out을 나눈 group을 확인할 수 있다.
여기에서 큰 조각에 대한 Aout을 떼어내준다.
이제 판단할 것은 어떤 조각들이 충돌에 영향을 받고 있는가? 이다.
현재 houdini에서 충돌을 판단할 데이터가 없다.
그렇기 때문에 시뮬레이션 된 내용 혹은 unpack된 내용을 토대로 충돌의 발생여부를 기록할 방법이 필요하다.
- 속도 정보를 이용하면 쉽게 구할 수 있다.
위 영상과 같은 자유낙하하는 sphere가 있을 때, 현재 프레임의 sphere의 속도에서 이전 프레임의 sphere의 속도를 빼보면 충돌 직전까지는 일정한 것을 확인할 수 있다.(중력에 의한 자유낙하운동이기 때문이다.)
충돌이 일어나는 순간 두 프레임의 속도의 차는 부호도 바뀌고 값도 확 튀는 것을 확인할 수 있다.
그리고, 일반적인 두 프레임 간의 속도의 차이에 대한 vector의 크기를 1로 가정한다고 했을 때, 이 값보다 큰 경우 '충돌이 발생했다'고 볼 수 있을 것이다.
식으로 표현한다면,
if( length( @prev_vel - @vel ) > limit ){
...충돌이 발생했음을 확인할 수 있는 무언가 ...
}
@prev_vel = 이전 프레임의 속도
@vel = 현재 프레임의 속도
limit = 임의로 주어지는 한계값
이전 프레임의 속도와 현재 프레임의 속도의 차이에 대한 vector의 길이가 어떠한 한계값(limit) 보다 크다면, 충돌이 발생했다고 인지할 수 있을 것이고, 예를 든다면, @Cd = {1, 0, 0}을 주는 것으로 해서 충돌이 발생한 부분에 대해 빨간색으로 묘사할 수도 있을 것이다.
나중을 위해서 vel 정보는 point가 아닌, primitive로 넘겨서 작업을 진행한다.
unpacking 상태에는 속도정보(v)가 포함되어있지 않기 때문에 속도정보를 계산해주기 위해서 trail 노드를 활용한다.
그리고 이전 프레임의 데이터를 받기 위해서 time shift 노드를 사용해서 이전 프레임의 정보를 받을 수 있도록 해준다.
빨간색이 계속 깜박이는것이 눈이 아프다.
색이 서서히 빠지도록 만들어주자.
이전에 했던, solver를 이용한 작업을 진행한다.
이전 frame 데이터의 컬러값을 일정값으로 감쇄해주고(여기에서는 0.5로 감쇄했다) 첫번째 인풋으로 들어오는 데이터의 빨간색을 가져와서 이전 프레임의 @Cd에 더해줬다. 이전 frame을 바탕으로 계속 진행이 된다면, 위치가 바뀌지 않는 것처럼 묘사될 수 있기 때문에, @Cd의 변화에 대한 값을 Attribute copy로 첫번째 인풋에게 넘겨주는 것으로 한다.
이렇게 만들어진 빨간색 정보를 point를 생성하는 기준으로 사용할 수 있다.
@Cd.x 값을 @density로 치환해준다.
그리고 scatter를 사용해서 density 정보를 이용해서 점을 뿌려준다.
scatter parameter에서 Relax Iterations 를 비활성화 해주면 좀 더 자연스럽게 포인트가 뿌려지게 된다. 그리고 Force Total Count 항목 또한 비활성화해주면, Density(밀도)에 맞게 포인트들이 생성되게 된다.
- Density Scale을 조절해주면, 밀도당 생성되는 포인트의 수량을 조절해줄 수 있다.
위의 하얀색 포인트들에서 파티클이 생성되면, 모래처럼 묘사될 수 있을 것이다.
시간에 따라 뿌려주는 포인트에 변화를 주기 위해서 scatter 노드의 Global Seed Parameter를 $FF 로 설정한다.
그리고 scatter 노드에 속도 정보가 없기 때문에, scatter 전에 primitive 정보로 가지고 있던 vel 정보를 attribute promote 노드로 point 정보로 넘겨준다.
attribute를 한번 정리해주도록 하자.
그리고 dop network를 만들어준다.
기본적인 particle simulation을 위한 pop 세팅을 진행한다.
파티클은 잘 생성이 되는데, 모래같은 느낌은 들지 않는다.
가장 기본적으로 모래는 저렇게 바닥을 미끌어지지 않는다.
- 모래 파티클과 바닥 사이에 큰 마찰력이 필요할 듯 싶다.
- 바운스 값도 많이 줄여줘도 될 듯 싶다
현재 생성되는 particle은 충돌조건으로 ground만 사용되고 있다. 조각들에 대해서는 충돌이 일어나지 않고 있다.
이 부분의 수정이 필요하다.
충돌조건을 세팅할 때 bullet의 convex hull 세팅을 진행할 경우, 작업자가 원하는 결과를 얻을수가 없다.
이번에는 concave로 세팅해서 사용한다.
비효율이라고 하지만, concave를 사용하는 이유는,
particle의 충돌조건으로 volume 정보를 사용할 수도 있지만, 복잡한 물체를 그때 그때 volume 데이터로 컨버팅하는 과정, 그 시간이 아깝다. 그래서, converting을 하지 않기 위해 bullet으로 사용하는 이유도 있고, 이번에 concave를 사용해도 되겠다고 하는 이유로, 각각의 조각을 계산하려는 것이 아니기 때문이다. 각 조각의 충돌 시뮬레이션이 이 dop network에서 발생하는 것이 아니고, 일종의 벽으로 작용하기 때문에 concave를 사용해도 큰 부하를 주지 않을 것이라 판단이 되기 때문이다.
위 영상의 파티클 중 끝까지 살아서 툭툭 모래를 뿜어내는 부분이 어색하다.
일단 위에서 만들어줬던 이전프레임과 현재 프레임의 속도 차에 대한 length 값의 한계값을 더 올려서 적은 구간에서 파티클이 생성되도록 해준다.
멀리 떨어진 조각들에게서 떨어져나오는 모래 파티클의 수량을 조절하는 방법 중, limit를 조절하는 방법도 있지만, 거리로서 조절해주는 방법도 있다.
충돌 발생지역을 기준으로 멀면 멀수록 scatter에 영향을 주는 @density가 작아지면 될 것이다.
point를 활용해서 벽의 위치에 point를 위치시키고 그 위치정보를 불러온다. 그리고 각 조각들의 위치정보와 벽의 위치정보의 차이를 길이로 변환해서 @collen 어트리뷰트에 저장해주고, 이 값을 활용해서 @density를 나눠준다. 그러면, 각각의 조각이 벽의 위치에서 멀어지면 멀어질수록 length는 커지게 되고, @density는 더 큰 값으로 나뉘게 되므로 작아지게 되면서 이 값을 scatter에 활용할 경우 멀어질수록 밀도에 의해 점이 뿌려지는 수량이 적어지게 된다.
거리에 의한 감쇄를 더 극적으로 표현하기 위해서 거리의 제곱으로 @density를 나누게 되면 어떻게 될까?
생성되는 파티클을 나중에 필요한만큼 줄여줄 수 있기 때문에(늘리는건 귀찮고 어렵고 기타 등등이다. 줄이는게 훨씬 쉽다.) scatter로 생성되는 점의 수를 늘려준다.(컴퓨터가 죽어날뿐이다.)
애초에 제공하는 포인트들이 날아가는 속도에 노이즈를 줄 수도 있다.
- attribute randomize 노드를 사용해서 v 랜덤값을 기존값에 더해주는 것으로 약간의 노이즈를 추가해줄 수 있다.
이후로는 tweak 의 영역이다.
다음으로 필요한 것은 연기표현이다.
연기가 발생하는 곳 또한 조각이 나는 곳이기 때문에, 위에서 작업해준 부분을 활용할 수 있다.
미리 해줘야할 것은, smoke 작업을 위한 dop network가 또 만들어지게 되고, 조각에 대해 위에서 작업한 일반 solver 또한 하나가 더 생기는 상황이라서 매 순간마다 돌아야하는 solver 시스템이 많은 편이다.
그렇기 때문에 일반 solver의 내용과 위에서 만들어준 particle에 대한 시뮬레이션 결과를 file cache로 구워주는 것이 좋다.
연기가 발생하는 구역이 조각과 조각의 사이 아주 안쪽은 아니어도 될 듯 싶다.
충격이 발생했을 경우 겉면에서도 연기는 발생할 수 있기 때문이다.
초반에 blast에서 겉면을 떼어줬던 부분을 삭제해주고 캐시를 구워주자.
이 포인트를 활용해서 volume을 만들어줄 것이다.
- VDB from Particles 노드를 사용한다.
VDB from particles 에서 이전에 공부했던 것 중 공식처럼 공부했던 부분이 있다.
voxel size / point radius scale / minimum radius in voxels 의 관계이다.
- point radius scale = (voxel size * minimum radius in voxels) + 0.0001
- 선생님 강의에서는 식의 변형이 있었다.
- minimum radius in voxels = (voxel size * point radius scale)
이것을 활용해준다.
기본적인 smoke solver 세팅을 만들어준다.
아직은 temperature도 vel 정보도 들어있지 않고, density가 시간이 지남에 따라 빠지는 것 또한 작업되지 않았기 때문에 그냥 smoke가 움직임 없이 쌓이기만 한다.
아주 기본이 되는 세팅이 준비되었다.
이제, volume이 움직이고 충돌할 조건들을 만들어주면 된다.
일단 source에 넣을 velocity 정보가 필요하다.
- 그래야지 자연스럽게 smoke에 움직임이 발생한다.
실제 조각들을 가져와서 충돌과 함께 움직이는 것처럼 묘사할 수도 있지만, 조각들의 움직임은 이미 정해져있기 때문에, 그 조각들의 속도를 활용해서 vector field를 만들어줄 수 있을 것이다.
조각들에 대해 unpack을 해주면, 현재 속도정보는 존재하지 않는 것을 확인할 수 있다.
- unpack 노드의 transfer attribute parameter에 v를 기입해줌으로써 속도정보를 가져올 수 있다.
- unpack에서 v 정보를 받게 될 경우, 포인트가 대변하는 속도를 모두 받아오기 때문에 각 조각을 이루는 모든 포인트들이 가지는 속도를 모두 받아오게 된다.
- 그래서 실제로는 약간의 오차가 있을 수 있다. (그 대신 trail 보다는 약간 빠르다.)
- 또 한가지 방법으로는 trail 노드를 활용해서 속도를 계산해주는 것이다.
- 대신에 이 방법은 이전 정보와 현재 정보를 비교해서 속도 정보를 만들어주기 때문에 약간 시간이 오래 걸린다.
- 시간이 오래 걸리는 대신에 약간 더 정밀한 느낌이 있다.
이렇게 구해준 속도정보는 vdb from particle 노드를 사용해서 vel 정보로 만들어준다.
이번에는 distance vdb / fog vdb 를 만들려는 것이 아니고, 맨 아래의 Point Attributes 를 활용하려는 것이다.
이제 smoke_source에 vel 정보를 merge로 묶어서 넣어주고, volume source에 vel volume을 vel field 에 올려준다.
속도에 영향을 미치는 것이 조각만 있는 것은 아니다. 모래파티클 또한 속도에 영향을 미칠 수 있다.
그렇기 때문에 vel field에 조각이 만들어내는 속도 정보와 모래 파티클이 만들어내는 속도 정보를 동시에 올려주도록 한다.
속도 정보에 애니메이션을 줌으로써 시간에 따라 속도가 변하도록 해줄 수도 있다.
이때 속도에 대해 키 애니메이션을 주게 되면, 속도가 0이 된다는 것이 더이상 추가적인 속도를 source로 주지 않겠다는 의미이지 volume의 속도를 0으로 하겠다는 것은 아니다.
그래서 이번에는 속도를 0으로 하는 것이 아닌, 일정 시간 이후 속도가 반대가 되도록(-1) 세팅을 해준다.
이렇게 되면 뻗어나오던 방향에서 주춤하면서 어느정도 멈추는 느낌을 만들어줄 수 있다.
이번에는 초기 발생시기에 아주 약간 위로 올라가는 느낌을 줄 수 있도록, 약간의 temperature를 추가해주도록 하자.
이미 있는 정보를 활용할 수 있는데, temperature field에 density volume을 올려줌으로써 활용이 가능하다.
배웠던 것을 활용해서 advection에 도움을 줄 수 있도록 engine을 바꿔주도록 한다.
그리고 gas turbulence도 추가해주자.
gas shred 또한 추가해주고, 초반에 density가 많이 약해서 density 값을 초반에 살짝 높았다가 낮아지도록 키 애니메이션을 추가해줬다.
volume의 모양을 잡아주기 위해서 gas disturb 노드를 사용해서 몽글몽글한 느낌보다 좀 더 자글자글하게 흩어주도록 해본다.
이후의 작업은 tweak이다.
오늘 작업의 핵심
- 모래에 사용할 파티클을 만드는 것
- 충돌에 의한 연기를 만드는 것
- 내가 어떠한 volume을 사용할 것인지
- 그 volume을 어떻게 develop 해나갈 것인지
- '기준'부터 잡는 것이 중요하다.
- '낮은' 화질에서 큰 덩어리를 구한 다음에
- '조금씩' 화질을 높여가는 것이 좋다.
- 안그러면, 불필요한 tweak이 너무 많아진다.
- turbulence, shred 같은 노드들도 초반부터 사용하는 것이 아니고, 큰 덩어리가 모두 준비된 다음에 적용해보는 것이다.
- 선생님의 tweak의 값을 따라가는 것은 의미가 없다.
- 선생님 강의의 결과와 작업자가 작업을 진행하면서 만지고 있는 결과가 다르다.
- 어떠한 방식으로 tweak을 해나가는지, 그 뉘앙스를 파악하고 이해하는 것이 '핵심'이다.
- file cache를 적극 활용해라.
- 작업은 꼭 직접 해봐야 본인의 것이 된다.
- 가볍게 작업을 진행하다가 막판에 화질을 쭉 올리는 것은 연습해두면 좋다.
숙제.(ing)
car 관련 모래 / 먼지 직접 다시 해보기.
brute 기둥 부수는 것에도 적용해서 만들어보기
하... 컴퓨터가 죽어간다 아주...
선생님 말처럼 가볍게 작업을 하고 막판에 화질 올리는 것을 또... 어정쩡한 화질로 제대로 tweak도 못하고 어물쩍 거리다가 시간을 많이 까먹었다.
덩어리 감을 얻을 수 있을 가벼운 화질을 작업해보고, 퀄리티를 점진적으로 높이는 작업을 계속 진행해봐야겠다.
앞으로도 계속 이렇게 시뮬레이션이 진행되고 할텐데 컴퓨터 사양때문에 징징거리고만 있을수는 없으니 말이다.
'Houdini > Houdini1_Rigidbody' 카테고리의 다른 글
| RIGID BODY_18 재질표현 + 어려움🔥🔥🔥 - Ep18_Part 09.철과 강화유리 (1) | 2023.05.07 |
|---|---|
| RIGID BODY_18 재질표현 + 어려움🔥🔥🔥 - Ep18_Part 08. RENDER & 치핑보다 작은 모래 조각은? (0) | 2023.05.05 |
| RIGID BODY_18 재질표현 + 어려움🔥🔥🔥 - Ep18_Part 06. 차로 박살내보자 (1) | 2023.04.28 |
| RIGID BODY_18 재질표현 + 어려움🔥🔥🔥 - Ep18_Part 05. 캐릭터로 박살내보자 (1) | 2023.04.27 |
| RIGID BODY_18 재질표현 + 어려움🔥🔥🔥 - Ep18_Part 04. 기둥+벽 박살내보자 (0) | 2023.04.26 |
