별건 없고 그냥 최적화 테스트
블루프린트로 만들었을땐 수백개만 만들어도 프레임 박살나는데
역시 cpp이 빠르구나.
블프는 딱 기능구현, 프로토타입용이고, 진짜 성능은 코드로 작성해야 나온다는걸 처음으로 실감함.
만개 도달해야 60프레임까지 떨어지니, 탄막을 적당히 뿌리면 괜찮을듯 싶기도 하다.
하지만, 더 많이 뿌리고 싶으니 멀티 스레드랑 병렬 루프도 테스트 해봐야지.
ECS 구조로 만들고, 탄막은 인스턴스트 스태틱 매시로 만듬.
객체 지향으로 cpp까지 가본적이 없어서, 객체지향이랑 성능차이가 얼마나 나는지는 알수 없음.
그냥 지피티가 배열 여러개 만들고 인덱스 단위로 탄막 속성을 제어해야 빠르다고 하니까 그렇게 만듬.
그게 캐시 효율이 좋다나 뭐라나.
이론은 아는게 없으니 그냥 그렇다면 그런줄 아는 수밖에.
ㄷㄷ 언리얼은 ECS 안어렵나요?? - dc App
블프로 싹 구현한 후에 그대로 번역만 해서, 쉬웠어요. 디버깅이 쉬워지니 구현 자체의 난이도가 수직하락 합니다.
블프로 ecs라니 ㄷㄷㄷ ㄹㅇ신세계네요 ㅋㅋㅋ - dc App
그 지피티한테 배우길 어떤 객체의 모든 속성을 전부 배열로 만들고, 루프 돌리면서 인덱스 단위로 접근해서 처리하는게 ECS라고 배웠거든요. 그래서 객체지향으로 만들던걸 그대로 루프 방식으로만 바꾸면 되니까 쉬웠어요. 하나 막혔던 부분이 인공지능이었는데. 인공지능 상태 변환을 이넘으로 했는데, 이걸 배열에 못넣으니까 좀 당황스러웠는데. 그냥 인티저 스위치로 구현하고, 주석 달아서 해결했습니다. 블프는 그저 최곱니다 ㅋㅋ
@흑_두루미 어떤 객체의 모든 속성을 전부 배열로 만들고, 루프 돌리면서 인덱스 단위로 접근해서 처리하는 건 데이터 지향 설계의 Archetype 패러다임임. 유니티의 ECS는 Archetype 패러다임으로 만들어져서 자주 혼동함
@tpf 유니티랑 다르데요?? 그냥 지피티 말만 믿고 온거라 이론이나 용어쪽은 깡통이라 잘 모릅니다.
@흑_두루미 님이 어떻게 구현한 건지 몰라서 ECS인지 아닌지, Archetype인지 Sparse Set인지 모르겠음. 이런 이론적인 건 막힐 때 배우셔도 되고 지금 잘 돌아가면 그냥 놔둬도 됩니다
@tpf ECS 구조는 Entity, Component, System 이 세개로 이루어지는 구조를 말하는 건데, Entity는 Component의 집합이고, Component의 변경은 System을 통해 이루어짐. 유니티의 ECS가 이걸 아주 명확하게 구현했는데 그거랑 비슷한 구조면 ECS임.
@흑_두루미
만약 이론을 배우고 싶으면 이 책을 추천함:
https://www.manning.com/books/data-oriented-design-for-games
데이터
지향에 관한 책이고 ECS는 크게 다루진 않음. 다만 여기서는 ECS가 데이터 지향이 아니라는 점을 명확히 설명함.
@tpf 일단 전 이렇게 만들었어요. 먼저 루프 구조에서 제일 먼저 실행할 기준이 되는 배열. 불리얼 액티브. 여기서 루프를 시작하고, 비활성화인 탄막은 여기서 싹 걸러집니다. 여기서 루프중에 반환된 인덱스를 이용해서 탄막의 모든 속성. 위치, 방향, 트랜스폼, 등등 모든 속성을 인덱스로 접근해서 읽고, 수정합니다. 컴포넌트를 개별로 갖진 않구요. 전부 데이터로만 되어 있고, 랜더링은 인스턴스트 스태틱 매시 하나로 구현하고, 위의 트랜스폼 배열을 이용해 인스턴스 트랜스폼을 제어합니다.
@흑_두루미 설명만 봐선 Sparse Set인거 같은데, ECS인지는 설명만 봐선 모르겠음. 궁금한데 그냥 객체 지향으로 만들어봐서 성능 비교를 해보는 건 어떰?
@흑_두루미 ECS구조에서 위치, 방향, 트랜스폼 이런 님이 "속성"이라고 부른 게 컴포넌트고, 엔티티는 컴포넌트의 집합의 역할만 함. 컴포넌트의 변경은 시스템만을 통해 이루어지고, 시스템은 오직 "특정 조건에 맞는 컴포넌트들을 찾아서 특정 액션을 수행"하는 코드임. 이 3개가 있다면 ECS
@tpf 휴가가 곧 끝나서 시간이 없으므로, 멀티스레딩이랑 병렬루프 적용하고 다음 단계로 가려구요. 전업이었다면....흑흑
ue와 bevy 둘다 해본 입장에서 첨언하자면, ue에서 액터가 entity 비슷한 개념이고, 액터에 딸린 component가 component임. 다만 bevy에선 마치 테이블에서 쿼리하듯이 관련 조건을 만족하는 엔티티들을 쿼리해서 system이 게임 로직을 적용하는 반면, ue에선 그런 패턴을 권장하진 않지.
뭐 ue에도 GetActorsByClass 처럼 월드에서 특정 클래스나 특정 컴포넌트를 가진 액터를 쿼리할 순 있지만, 함수 주석에도 써져있듯이 비효율적인 함수이고, 틱당호출엔 적합하지 않음.
보통 ue로 만들어지는 프로젝트는 대규모 프로젝트가 많기 때문에, 쿼리 형태로 조건에 맞는 entity들을 찾아서 로직을 적용하는 것보다, 그냥 해당 로직을 적용할 액터들의 포인터를 물고있다가 적용부에서 해당 액터에 직접 접근하여 적용하는게 일반적이고, 비용 효율적임.
저거 빛 그림자 효과 갓레이 그거 기본으로 됨?
기본입니다. 딱히 뭘 건들진 않아서, 전부 기본값이에요
개좋당 ㄷㄷ
탄막이면 각자 따로 움직이는거 아니야? 인스턴스드 스태틱 메시로 만들었다고 해서
인스턴스들의 위치를 트랜스폼 배열로 관리하고 매틱 업데이트 해주면 되요
유니티맨의 의문 매 틱이란게 몇 ms임?? 저 많은 탄환들의 위치를 10ms 이내에 갱신하는게 가능한 거임..?
@211214 60프레임 기준 틱이 0.016초 인데요, 그 시간 안에 1만번의 거리계산을 하는데 그게 되네요 ㅋㅋㅋ. 기본 비용이 10ms에서 시작 했으니까 1만개 도달해도 여유롭데요. 2만 찍을때쯤 되니 좀 무거워 지더라구요. 제곱근 거리 계산이라 존나 빠릅니다. 랜더링 비용이 더 무거워요. 인스턴스드 스태틱 매시라 드로우콜이 1이라서 말도 안되게 가볍습니다. 저도 보고도 처음에 믿기질 않았음.
@211214 제곱근이 아니라 제곱....
전혀 모르겠꾼
와 충돌처리까지 하신건가요?
네. 충돌처리는 거리 제곱 비교연산으로 합니다. 이게 보기보다 엄청나게 가볍다고 합니다.