자기 최면이 필요한 강의이다.
쉽다... 쉽다... 나는 이 내용이 쉽고, 다 이해해내고 있고, 어서 빨리 다뤄보고 싶다.
선생님의 강의목록을 보면서 우리는 현재 어디까지 알고, 어디를 모르는지 대충 생각해볼 수 있다.
우리는 현재 1개의 단일 소스를 이용하고 있다.
아직 소스의 그룹을 제대로 활용한 바가 없다.
- 그룹을 나눠서 무언가 작업을 따로 한 적이 없다.
모든 파티클은 동일한 물리법칙이 적용되고 있다.
- pop object에서 physical을 적용시켰고, source에서는 source만 나왔기 때문에 동일한 물리법칙이었다.
우리는 아직 충돌에 대한 조건을 이용한 적이 없다.
- 바닥에 파티클이 닿았을 때 바운스가 일어나는데, 이 때 충돌에 대한 어떤 세팅을 다루거나, 어트리뷰트를 써본적이 없다.
update reap가 뭔데
- pop solver의 update tap에 보면, reap에 대한 항목이 두개 있다. 이 부분에 대해 다뤄본 적이 없다.
pop wrangle로 reap에 대해 직접 묘사하기
stream에 대해 모른다
- stream이 뭔지 기본적인 설명을 하면서 group과 함께 stream을 어떻게 사용하는지 배우게 된다.
pop properties & pop collisiondetect
- pop properties는 physical과 관련이 있다. pop object의 속성과 함께 이용이 될 부분이다.
- pop collisiondetect는 충돌에 대한 조건 이용에 대해 맥락적으로 고려해볼 부분이 있을 것이다.
stream예제1 - pop replicate - 비
stream예제2 - pop - 폭죽
파티클이 비처럼 떨어지도록 만들어줄 것이다.
여러 물체를 동시에 활용하도록 초기에 세팅을 구성한다.
이제 여기에 충돌할 물체를 만들어준다.
a 그룹에서 떨어지는 비에 맞게 될 물체를 만든다.
충돌에 대한 정보를 vdb로 만들어줄 수도 있다.
이렇게 두개의 물체를 더 만들어준다.(각각의 위치는 0, 1로 해서 B그룹, C그룹에서 떨어지는 비를 맞을 수 있도록 위치시킨다.)
기본적인 파티클 시스템을 세팅해준다.
staticobject1이 가지고 있는 collision 정보를 보자.
collision의 영역을 정의하는 것을 우리가 만들어준 volume 정보를 활용할 수 있도록 Mode를 Volume Sample로 바꿔준 뒤, Proxy Volume에 Volume 데이터의 경로를 기입해준다.
- 각각의 staticobject를 다 설정해준다.
- volume의 해상도가 낮을 경우, dop network 밖에서 우리가 만들어준 vdb의 voxel size를 줄여줌으로써 volume 해상도를 높일 수 있다.
- 움직이는 물체에 대해서는 꼭 Use Deforming Geometry를 체크해준다.
파티클이 떨어지도록 만들자.
- dop network 밖에서 @v를 활용해서 초기 속도를 만들어줄 수도 있고, gravity force를 활용할수도 있다.
너무 균일하게 떨어지는 파티클이 아쉽기에, pop source의 attribute tap에서 initial velocity를 add to inherited velocity로 바꿔준다. 그리고 파티클의 양도 많기 때문에, birth rate를 줄여준다.
일단 collision A만 활용해보자.
pop source의 source tap에서 source group을 활용해볼 예정이다.
우리가 SOP에 적어준 source를 dop network 밖에서 보면 세개의 그룹으로 나뉜것을 볼 수 있다.
이 중에서 a 그룹만 활용해보자.
source로 앞서 만들어준 a 그룹만을 활용하고 있다.
source group을 사용한다면, pop source를 여러개 만들어서 사용해줄 수 있을 것 같다.
dop network 밖에서 현재 우리가 만든 결과가 어떠한 정보를 가지고 있는지 확인해보자.
이렇게 모든 것이 다 출력되는 것을 바란것이 아니다.
dop import를 만들어주고, 이 노드를 기준으로 결과를 확인해보자.
DOP Network에 현재 dop network의 경로를 기입한다.
Object Mask는 현재 우리가 보고싶은 object의 이름을 기입한다.(p01은 pop object의 이름이다.)
dop import의 node info를 확인해보자.
우리가 주목해서 보고싶은 부분은 point group이다.
stream이 적힌 group은 왜 있는지 유추하기 어려울지 몰라도, a, b, c group은 왜 생겼는지 유추할 수 있다.
우리가 pop source에서 source group을 a, b, c를 사용했기 때문에 생긴 point group이다.
차이를 만들어주기 위해서 각 pop source의 birth rate를 다르게 해준다.
point group을 잘 보면, stream_popsource1이 a와 같은 600개, stream_popsource2가 b와 같은 42개, stream_popsource3가 c와 같은 200개의 포인트를 가지고 있는 것을 알 수 있다. 일단은 이렇게 같은게 있구나 정도만 참고하자.
이 그룹을 활용하면, 어떤 소스에서 만든 파티클인지 따로따로 확인을 할 수 있을 것이다.
그러면, stream이 붙은 group은 뭘까?
우리가 만들어준 a, b, c와 동일한 파티클이 나오는 것을 확인할 수 있다.
다시한번, 어려운 부분 들어가기 전에 자기최면을 걸자.
쉽다... 쉽다... 나는 이 내용이 쉽고, 다 이해해내고 있다.
현재, 서로 다른 source를 활용해서 파티클을 만들어주고 있다.
이번에는 각 소스마다 서로 다른 중력을 적용해보도록 하자.
각 그룹들의 파티클을 비교해보자면,
중력이 더 작은 a가 b그룹보다 파티클이 떨어지는 속도가 b 그룹에 비해 조금 느리다. 그리고 c 그룹의 파티클은 중력 방향에 따라 위로 솟구치고 있다.
이번에는 서로 다른 소스에서 나오는 파티클들에게 색 정보를 주도록 하자.
- pop color node를 사용한다.
다른 파티클도 색을 적용해보자.
만약, pop color에 다른 그룹에 대한 정보를 주게 된다면 어떻게 결과가 반영될까?
a 그룹에 적용된 pop color의 group을 활성화하고, 이곳에 다른 그룹의 정보를 기입해줬다.(a_color라는 그룹은 현재 없다.)
색은 적용되지 않았다.
node info를 확인해봐도 a_color라는 그룹은 활용되지 않았다.
이 말은 (당연한 이야기로 들릴수도 있겠지만) 우리가 현재 가지고 있는 group 중에서 불러서 사용하는 것이다.
그렇기 때문에, pop color의 활성화된 group에는 a를 써주는 것이 맞다.
그렇다면, 이곳에 b를 적어주면 어떻게 될까?
마찬가지로 b에 대해서 적용을 하지 못하고 있다.
그 이유는, pop color1 노드의 라인에서는 현재 b 그룹이 없는 상태이다.
그렇다면, b 그룹 노드라인의 pop color2를 bypass 해준 결과는?
a 그룹과 b 그룹의 파티클 모두 색이 적용이 안되고 있다. 원하는 곳에 제대로 지정이 안되었다는 의미이다.
우리는 활용할 임의의 그룹'에' 적용하겠다는 의미로 그 그룹의 이름을 적어주는 것이다.
- ex) pop source의 source group이 'a'일 경우, 아래쪽의 pop color 등에서 사용되는 group에는 a가 들어가는 것이 맞다.
dop network 안에서 하는 것들이지만, 논리는 geometry일 때와 동일하다.
dynamic solver 안에서 능동적으로 group을 만들어보자.
- 맨 오른쪽의 c 그룹 source에서 나오는 파티클의 높이가 2를 넘어갈 경우, over라는 그룹을 생성하도록 만들어보자.
setpointgroup을 사용한다.
geohandle = 0
name = 그룹 이름("over")
point_num = 포인트 넘버(@ptnum)
value = 0인 경우, 그룹에 해당되고, 1인 경우, 그룹에 해당되지 않는다. 여기에서는 1
mode = 포인트 그룹을 지정하겠다는 의미로 "set"
방금 만들어준 over group에 다른 색 정보를 대입해보자.
이번에는 새로운 조건을 넣어주려고 한다.
@P.y가 임의의 높이를 넘어선다면, 그 파티클은 지워주도록 하자.
조건문에서 한계점에 해당되는 값이 작아진다면, 더 낮은 위치에서 지워지게 될 것이다.
조건을 조금 다르게 적용해보자.
지워지는 것을 보여준 이유가 있다.
@dead 를 활용해보려고 한다.
pop solver는 당연하다는듯이 공유하는 어트리뷰트들이 있다.
- @v는 우리가 약속이라도 한 것처럼 속도라고 인지하고 있다.
- @force는 힘이다.
- @age는 파티클의 나이다.
- @life는 파티클의 수명이다.
이런 내용들이 기본 규칙처럼 쓰이고 있다.
그중에, @dead라는 정보가 있다.
- @dead 어트리뷰트는 solver가 @dead에 따라 파티클을 지우느냐, 마느냐를 결정한다.
이 내용이 pop solver의 update tap에 있다.
- Reap Particles
- Reap At Frame End
- Reap Particles
- @dead가 1로 설정된 모든 파티클은 지워진다.
over 그룹으로 들어가면서 주황색으로 물들던 파티클들이 2를 넘어서면서 @dead가 1로 설정되었기에 지워지고 있다.
removepoint를 사용하지 않고도, @dead를 1로 설정함으로써 solver가 알아서 지워주게 된다.
만약 Reap particles를 체크해제해주면?
파티클이 지워지는 대신, 아까 설정해준 over 그룹에 대한 색 정의(주황색)가 잘 적용되고 있다.
- 파티클의 life expactancy 또한 적용이 안되고 계속 살아있는 것으로 보인다. 이것으로 보아 life expactancy를 넘어서면 @dead가 1로 설정되는것을 알 수 있다.
만약 Reap At Frame End가 체크해제되어있다면?
2가 넘는 파티클들은 over 그룹에 들어가게 되고, 위에서 설정해준 색 정보에 의해 주황색으로 변하게 된다.
@dead = 1로 세팅되게 되므로, Reap particles가 체크되어있다면, solver가 파티클을 삭제하게 되는데, Reap At Frame End가 체크되어있으면, 죽는 순간에 이미 포착되지 않고 지워지게 되고, 체크해제되어있으면 죽는 마지막 순간이 포착되는 것이다.
죽을 때 애초에 사라질 것인가, 죽는 순간의 모습을 1frame 보이고 사라질 것인가 의 차이이다.
지금까지의 정리!
그룹에 대해서 이야기했다.
그룹에 따라서 색을 줄 수 있다는 것도 이야기했다.
pop wrangle로 attribute와 group을 만드는 것을 진행해봤다.(geometry나 dynamic solver나 다를 바 없었다.)
새로운 어트리뷰트를 사용해봤다.(@dead - 이 어트리뷰트를 조건으로 파티클을 지워줄 수 있었다.)
충돌에 대해 이야기해보자.
현재 얻은 결과는 충돌에 대한 어떠한 기록도 존재하지 않는다.
하지만, 우리가 만들어준 파티클들은 물체와 부딪히고 있다.
- 충돌을 감지하고 있다는 것이다.
이 때, 충돌에 대해 기록을 남겨달라고 solver에 요청을 할 수가 있다.
- pop solver 안의 collision behavior tap에서 해줄 수 있다.
Add Hit Attributes를 체크해주면, 충돌에 대한 기록을 남길 수 있다.
아까와는 다르게 존재하지 않던 hit로 시작하는 point attribute들이 생성된 것을 볼 수 있다.
@hitpos = 충돌에 대한 지점
@hittime = 충돌 시점
@hittotal = 몇번이나 충돌을 했는지 충돌횟수
a그룹의 source를 사용중인 pop source1의 기대수명을 10으로 늘리고 @hittotal을 확인해보자.
이 어트리뷰트를 활용하는 pop wrangle을 만들어보자.
- hittotal이 0보다 크다면(충돌이 발생했다면) 빨간색으로 변하게 해달라.
pop wrangle을 사용하지 않아도, 동일하게 표현이 가능하다.
- pop solver의 collision behavior tap에서 Color Hits를 체크해준다.
- Color Hits : 충돌이 발생했을 때, 어떤 색으로 바꿔주겠는가? 에 대한 항목
원래 pop solver는 충돌을 감지하고 있었다. (눈에 보이지 않았을뿐)
충돌에 대한 기록을 남기기 위해 collision behavior tap의 Add Hit Attributes 항목을 체크해준다.
그리고, 충돌했을 경우 색이 변하는지에 대해서도 정의를 내려줄 수 있다.(color hits)
@hittotal을 가지고 좀 더 무언가를 해보자.
조건을 만들어보자.
@hittotal > 0이면, @dead = 1이 된다.
충돌하면 포인트가 삭제된다. 빨간색이 보이는 이유는 color hits가 활성화되어있어서이고, reap at frame end가 비활성화 되어있기 때문이다.
이제 잠깐 이야기의 맥락이 바뀐다(?)
현재, 이 파티클들은 전부 동일한 물리법칙(physical)을 가진다.
- ex) bounce, 마찰력 등등
pop object에서 확인이 가능하다.
bounce를 0.1로 줄이게 되면 어떻게 될까?
생성된 파티클들이 아까보다 충돌 후 튀어오르는 것이 매우 줄어들었다.
그렇다면, 각각의 source에 대해 다른 physical을 적용(각각 다른 bounce를 가지도록)하려면 어떻게 해야할까?
- pop property 노드를 활용하면 된다.
pop property 노드를 달아주고, physical tap의 bounce를 활성화한다.
- physical tap의 항목들의 내용이 현재 전부 1로 되어있다. 이 의미는 pop object의 physical 수치에 pop property의 physical 수치를 곱해주는 것을 뜻한다.
pop property를 a 그룹의 파티클에 적용해서 bounce를 0.1로 낮춰주게 된다면...
b 그룹의 파티클과는 다르게 튕겨지고 있다.
pop object에 physical이라는 정보가 있다.
이 정보를 기준으로 pop property 노드를 활용해서 변화를 줄 수 있다.
pop property 노드를 활용해서 얻은 이득은?
- pop object가 가지고 있는 physical 정보에 어떠한 값을 곱해줌으로써 서로 다른 physical 정보를 만들어준 것이다.
우리가 이용했던 정보는 bounce였다.
만약, 각각의 stream에 서로 다른 friction 정보를 주었다면 어떻게 되었을까?
- 각각의 stream이 제공하고 있는 파티클의 마찰력에 대한 움직임이 서로 달라진다.
stream이란?
- 각 노드의 흐름이라고 이해하면 될까...?
- 각 stream은 다른 stream에 직접적인 영향을 줄 수 없다.
우리는 physical에 대해서 pop property 노드를 활용해서 각각의 stream에 서로 다른 물리력을 준 것 처럼, 충돌에 대해서도 각각의 stream에 따로따로 계산을 해줄 수 있다.
현재는 pop solver에서 충돌에 대한 세팅을 만들어놨다.
- 충돌이 발생했을 경우, @hit... 에 대한 어트리뷰트들이 생성되었다.
pop solver에서 이용하고 있는 것은 굉장히 global한 collision detect이다.
- pop solver 위의 모든 포인트에 대해서 충돌을 감지하고 반응하고 있는 것이다.
우리가 원하는 것은, 각각의 그룹을 활용한 pop source stream의 전용 collision detect가 필요하다.
이렇게 된다면, color hits을 각 stream마다 다르게 적용시켜서 한쪽은 빨간색으로, 다른쪽은 녹색으로 충돌 발생시 색이 변견되도록 해줄수도 있을 것이다.
- pop collision detect 노드를 사용한다.
- pop collision detect 노드에서는 어떤 물체와 충돌을 하게 되는지 Collision tap의 SOP Path에 구체적으로 기입해줘야한다.
현재는 a 그룹의 stream에만 pop collision detect를 적용하고 확인해보자.
hittotal이 2를 넘지 않는 이유는, 기대수명이 짧은 탓도 있겠지만, sphere와의 충돌만을 hittotal에 카운트했기 때문이다.
behavior tap의 Accumulate Hits를 체크해주면, 바닥과의 충돌에 대해서도 hittotal에 카운트해준다.
바닥과 충돌한다고 해서 color hits가 적용되지는 않는다. 이것은 SOP Path에 기입해준 object 한정이다.
b 그룹 stream에도 적용해보자.
이상태에서 녹색의 파티클만 추출해줄 수 있을까?
굳이 if의 조건문에 @Cd.r을 사용한 이유는?
@Cd가 정의되는 순간부터 파티클은 {1,1,1}의 정보를 @Cd로 가지게 된다.
만일 @Cd.g의 값을 가지고 녹색의 포인트를 판별하려 한다면, 판별을 할 수 있는 방법이 없다. 하지만, @Cd.r의 정보라면, 하얀색 포이트의 경우, @Cd.r = 1의 값을 가지고 있고, 녹색 포인트의 경우 @Cd.r = 0의 값을 가지기 때문에, 녹색 포인트에 대해 구분하기가 쉽다.
현재의 요점은...
dop network 안에서 누구와 충돌해줬는지 색으로 표현을 해줌으로써 그 점에 대해 isolate가 가능하다는 것이다.
Collision Detect의 다른 옵션도 보자.
Response : 반응에 대한 항목이다.
Die : 충돌 후 파티클을 죽인다.
Stop : 파티클이 충돌하게 되면 그 자리에 멈춘다. 움직이는 물체와 충돌할 경우, 물체의 움직임과 상관없이 그 자리에 그대로 멈춰버린다.(프리징)
Stick : 충돌이 발생하면 충돌한 물체 표면에 붙게 된다. 충돌한 물체가 움직일 경우, 파티클이 같이 표면에 붙어서 움직인다.
Slide : 충돌이 발생하면 미끌어져서 충돌체의 표면을 따라 흐른다.
파티클이 어떤 물체와 어떻게 상호작용을 하고 싶은지에 대해서는 구체적으로 지정해주는 것이 더 좋을 것이다.(pop solver에서 global하게 적용하는 것 보다는, collision detect를 각 스트림마다 연결해서 좀 더 private하게 적용해주는 것이 좋을 것 같다는 뜻으로 이해함)
흐름상 여기에서 한번 멈춰주신다 함...
particle stream / pop replicate / 복제 이야기는 다음 시간에...
오늘의 강의가 우리가 어떠한 어트리뷰트를 더 사용할 수 있을지, 파티클의 충돌에 대한 정보는 어떻게 사용할지, 이런 부분에 대한 힌트가 되었기를 바란다.
각각의 노드 흐름(이라고 이야기했었는데 선생님이 스트림... 이라는 단어를 쓰신다. 나도 이제 스트림이다.)에 대해 다른 physical과 collision detect를 적용하는 것이 매우 흥미로웠던 강의였다.
오늘 배웠던 @dead와 @hit 관련 어트리뷰트들도 강의를 듣는 중간중간 어떻게 활용할 수 있을 것 같은데... 라는 생각이 문득 문득 들었던 강의였다.
선생님의 강의 초반 자기최면 때문이었을까...? 오늘의 강의는 막 엄청 어렵게 느껴지지는 않았던것 같다. (일단은)
오히려, 지난 시간의 과제 풀이가 아니어서 다행이라는 생각이 더 강하다...
이 말인즉은, 이 공부일기를 적는 현재 시간까지 나는 아직 과제를 맘에 들게 만들지 못했다는 이야기...ㅠㅠㅠ
'Houdini > Houdini1_Particles' 카테고리의 다른 글
| PARTICLE07_Star(숙제 - Portal 만들기) (0) | 2023.02.12 |
|---|---|
| PARTICLE09_폭죽 만들기, POP에서 STREAM이란? (0) | 2023.02.10 |
| PARTICLE07_Star(숙제 업데이트) (0) | 2023.02.08 |
| PARTICLE06_다양하게 Source 준비하기 (0) | 2023.02.07 |
| PARTICLE05_스파크 묘사 & IMG에서 합성하기 - Simulation data 활용 (0) | 2023.02.04 |
