2. Niagara?
• 언리얼엔진 4.20버전부터 추가된 새로운 이펙트 시스템
• 노드방식의 비주얼스크립팅이나 간단한 스크립트를 통
해 파티클을 컨트롤 하는것이 가능해짐
• GPU, CPU골라서 사용가능(몇몇경우제외)
• 매우 낮은 오버헤드 인터프리터에서 실행되는 바이트코
드로 컴파일되어 cpu시뮬에서도 성능이 좋음(퍼옴…)
• 후에 완전히 캐스케이드를 대체 할 것으로 보임
4. Cascade VS Niagara
캐스케이드
• 모듈형식의 파티클 제어
• 쉽고 구조가 보기 편하다
• 엔진에서 정해준 기능만 수행
할 수 있다.
• 리소스 재활용이 힘들다.
• 연산이 비교적 느리다.
나이아가라
• 스크립트방식의 파티클 제어
• 구조가 까다롭다.
• 자신이 원하는 기능을 스스로
만들어서 수행할 수 있다.
• 리소스를 재활용 할 수 있다.
• 연산이 비교적 빠르다.
6. Data Sharing
• 사실상 나이아가라의 제작 철학
• Data라는 것은 나이아가라에서 파티클 컨트롤을 위해 생성하는 모
든 변수, 함수, 사용자가 직접 만든 모듈, 전체적인 파티클까지 범위
가 상당히 큼.
• 나이아가라의 특징인 GPU파티클과 CPU파티클의 호환역시 이 Data
Sharing안에 포함된다고 할 수 있음.
• 모든 파티클 컨트롤은 HLSL로 컴파일되서 작업이 수행됨.
7. Node Graph Based Control
• 기존의 캐스케이드가 모듈을 Stack하는 방식이라 여러 가지가 혼합
되었을 경우 모듈을 하나하나 보면서 결과를 예상해야 했음.
• Node Graph Based Control의 경우 익숙해지면 전체적으로 한눈에
보면서 결과를 예상하고 원하는 부분을 쉽게 수정할 수 있음.
• 후디니의 VOP구조와 매우 유사하게 느껴짐.
• 다른 회사의 차세대 엔진들 (프로스트바이트, Decima 등)은 모두
이미Node Graph로 파티클을 제어하고 있음. Unity도 개발중
15. Niagara의 구조
• 이렇게 보면 캐스케이드가 더 파일이 적게 필요한것 같이 느껴짐
• 왜 이렇게 구성되어 있을까?
• Data Sharing을 위해
16. Niagara의 구조
• 이렇게 보면 캐스케이드가 더 파일이 적게 필요한것 같이 느껴짐
• 왜 이렇게 구성되어 있을까?
• Data Sharing을 위해
• Niagara Emitter 파일들은 재활용이 가능
17. Niagara의 구조
• 비슷하지만 조금 다른 PNS_Fire_02를 만든다고 해도 아까 만든
niagara emitter파일들을 그대로 새로운 niagara system에 넣어서
수치만 바꾸면 다른 이펙트가 됨.
• 머터리얼 인스턴스처럼 system속에서 emitter의 수치를 바꿔도 원
본 emitter파일에는 변화가 없음.
• 데이터가 많아질수록 효율적으로 관리가 가능
25. Niagara Dynamic Input
• 원하는 값을 나이아가라의 Dynamic Input으로 설정할 수 있다.
• 밑에 그림은 파티클의 position값을 normalize해서
NormalizedPosition이라는 값으로 저장한걸 보여줌
26. Niagara Dynamic Input
• 원하는 값을 나이아가라의 Dynamic Input으로 설정할 수 있다.
• 밑에 그림은 파티클의 position값을 normalize해서
NormalizedPosition이라는 값으로 저장한걸 보여줌
27. Niagara Dynamic Input
• 원하는 값을 나이아가라의 Dynamic Input으로 설정할 수 있다.
• 밑에 그림은 파티클의 position값을 normalize해서
NormalizedPosition이라는 값으로 저장한걸 보여줌
28. 후디니와의 연동
• 나이아가라의 Node Based Graph Editor는 후디니의 vop과 유사함.
• 그렇기 때문에 후디니와 연동이 잘 작동함
• 후디니에서 특정 값들을 attribute로 지정하면 niagara에서 읽을 수
있음.
• Csv파일 포맷을 이용함