Godot: 거의 매번 가장 느린 데이터 구조를 사용합니다.

성능이 필요한 사람은 누구입니까? :트롤페이스:

무엇을 측정하는지 궁금합니다.

이것이 Godot의 간단한 Light2D 노드가 컴퓨터를 태울 수 있는 이유를 설명할 수 있습니까?

@Ranoller 나는 그렇게 생각하지 않습니다. 나쁜 조명 성능은 현재 Godot가 2D 조명을 수행하는 방식과 가장 관련이 있습니다: 모든 스프라이트를 n번 렌더링합니다(n은 영향을 미치는 조명의 수).

편집: #23593 참조

명확히 하자면, 이것은 코드 전체의 CPU 측 비효율성에 관한 것입니다. 이것은 Godot 기능이나 Godot GPU 렌더링 자체와는 아무 관련이 없습니다.

@vblanco20-1 약간의 측면 접선에서, 당신과 나는 대신 ECS 엔티티로 모델링되는 노드에 대해 이야기했습니다. 나는 그 트릭이 점차적으로 나무와 나란히 작동하는 새로운 ent 모듈로 godot의 기능 분기를 수행하는 것인지 궁금합니다. get_tree() 및 get_registry()와 같습니다. ent 모듈은 아마도 트리/장면 기능의 80% 정도를 놓칠 것입니다. 그러나 테스트베드로 유용할 수 있습니다. 특히 많은 개체(컬링, 스트리밍, 배치 렌더링)로 큰 정적 레벨을 구성하는 것과 같은 작업에 유용할 수 있습니다. 기능과 유연성은 떨어지지만 성능은 향상되었습니다.

완전한 ECS를 시작하기 전에(내가 할 수 있음) 낮은 교수형 과일에 대한 실험을 하고 싶습니다. 나중에 전체 데이터 중심으로 이동하려고 할 수 있습니다.

따라서 첫 번째 업데이트:

update_dirty_instances : 0.2-0.25밀리초에서 0.1밀리초로
octree_cull(기본 보기): 0.35밀리초에서 0.1밀리초로

재미있는 부분? octree cull의 대체는 가속 구조를 사용하지 않고 모든 AABB를 사용하여 벙어리 배열을 반복합니다.

더 웃긴 부분은? 새로운 컬링은 10줄의 코드입니다. 병렬로 만들고 싶다면 라인을 한 번만 변경하면 됩니다.

속도 향상이 얼마나 축적되는지 확인하기 위해 조명으로 새로운 컬링을 계속 구현하겠습니다.

우리는 아마 마스터 브랜치에서도 구글 벤치마크 디렉토리를 얻어야 할 것입니다. 사람들이 그것에 대해 논쟁할 필요가 없도록 검증하는 데 도움이 될 수 있습니다.

godotengine/godot-tests 저장소가 있지만 아직 많은 사람들이 사용하지 않습니다.

새로운 업데이트:

2단계로 상당히 멍청한 공간 가속 구조를 구현했습니다. 매 프레임마다 생성하고 있습니다. 더 개선하면 다시 만드는 대신 동적으로 업데이트할 수 있습니다.

이미지에서 다른 행은 다른 범위이고 각 색상 블록은 작업/코드 덩어리입니다. 그 캡처에서 직접 비교를 위해 옥트리 컬과 내 컬을 나란히 하고 있습니다.

전체 가속 구조를 다시 만드는 것이 오래된 단일 octree 컬링보다 빠르다는 것을 보여줍니다.
또한 추가 컬링은 현재 옥트리의 약 절반에서 1/3인 경향이 있습니다.

초기 생성 비용 외에는 내 멍청한 구조가 현재 옥트리보다 느린 경우를 한 번도 찾지 못했습니다.

또 다른 보너스는 멀티스레드 친화적이며 병렬로 원하는 코어 수로 확장할 수 있다는 것입니다.

또한 메모리를 완전히 연속적으로 확인하므로 큰 번거로움 없이 SIMD를 수행할 수 있어야 합니다.

또 다른 중요한 세부 사항은 코드 줄이 훨씬 적고 현재 옥트리보다 훨씬 간단하다는 것입니다.

당신은 왕좌의 게임의 끝이 더 많은 과대 광고를 일으키고 있습니다....

알고리즘을 약간 수정하여 이제 프로그래머가 병렬 또는 병렬 정렬을 수행하도록 지시할 수 있는 C++17 병렬 알고리즘을 사용할 수 있습니다.
주 절두체 컬링에서 약 2배의 속도 향상이 있지만 조명의 경우 이전과 거의 같은 속도입니다.

내 culler는 이제 기본 보기에서 Godot octree보다 10배 빠릅니다.

변경 사항을 살펴보고 싶다면 가장 중요한 것은 다음과 같습니다.
https://github.com/vblanco20-1/godot/blob/4ab733200faa20e0dadc9306e7cc93230ebc120a/servers/visual/visual_server_scene.cpp#L387
이것은 새로운 컬링 기능입니다. 가속 구조는 바로 위에 있는 기능에 있습니다.

이것은 VS2015로 컴파일해야 합니까? 콘솔은 entt\ 내부의 파일에 대해 많은 오류를 발생시킵니다.

@Ranoller C++ 17이므로 최신 컴파일러를 사용하고 있는지 확인하십시오.

어, Godot가 아직 C++17로 옮기지 않은 것 같아요? 적어도 나는 그 주제에 대한 몇 가지 토론을 기억합니까?

Godot는 C++ 03입니다. 이 움직임은 논란이 될 것입니다. 나는 @vblanco20-1이 Juan이 연말연시를 마치면 이야기할 것을 권합니다... 이 최적화는 훌륭할 것이고 우리는 즉시 "이런 일이 일어나지 않을 것입니다 TM"을 원하지 않습니다

@vblanco20-1

octree_cull(기본 보기): 0.35밀리초에서 0.1밀리초로

얼마나 많은 개체?

@nem0

@vblanco20-1

octree_cull(기본 보기): 0.35밀리초에서 0.1밀리초로

얼마나 많은 개체?

약 2200. godot octree는 수표가 매우 작으면 일찍 종료되기 때문에 더 나은 성능을 보입니다. 쿼리가 클수록 느린 godot octree가 내 솔루션과 비교됩니다. Godot octree가 장면의 90%를 조기에 제거할 수 없다면, 모든 단일 객체에 대해 본질적으로 링크드 리스트를 반복하기 때문에 엄청나게 느립니다. 반면 제 시스템은 각 캐시 라인이 상당한 양의 AABB를 보유하는 배열 구조로 되어 있어 캐시 미스.

내 시스템은 모든 블록이 128개의 인스턴스를 보유할 수 있는 블록 배열인 2단계의 AABB를 사용하여 작동합니다.

최상위 레벨은 대부분 AABB 배열 + 블록 배열입니다. AABB 검사를 통과하면 블록을 반복합니다. 블록은 AABB 구조의 배열, 마스크 및 인스턴스에 대한 포인터입니다. 이렇게 하면 모든 것이 완료됩니다.

현재 최상위 데이터 구조의 생성은 매우 멍청한 방식으로 수행됩니다. 더 잘 생성되면 성능이 훨씬 더 커질 수 있습니다. 128 이외의 다른 블록 크기로 몇 가지 실험을 수행하고 있습니다.

다른 숫자를 확인했는데 블록당 128개가 여전히 최적의 위치인 것 같습니다.

작은 물체에서 "큰" 물체를 분리하도록 알고리즘을 변경함으로써 ive는 또 다른 30% 속도 업그레이드를 얻을 수 있었습니다. 대부분은 지도 중앙을 들여다보지 않는 경우입니다. 큰 개체가 작은 개체를 포함하는 블록 AABB를 팽창시키지 않기 때문에 작동합니다. 3가지 사이즈가 가장 잘 어울릴 것 같아요.

블록 생성은 여전히 ​​최적이 아닙니다. 큰 블록은 중앙을 볼 때 인스턴스의 약 10~20%만 컬링하고 지도 밖을 볼 때 최대 50%를 컬링하므로 필요한 것보다 많은 추가 AABB 검사를 수행합니다.

개선 사항은 아마도 현재 octree를 재사용하지만 "평평하게"하는 것이라고 생각합니다.

병렬 실행 없이도 내 알고리즘이 현재 옥트리보다 같거나 더 나쁜 경우는 이제 없습니다.

@vblanco20-1 나는 당신이 release 모드( -O3 )로 컴파일된 godot와 비교를 하고 있다고 가정하고 디버그의 일반 편집기 빌드(최적화가 없고 기본값임)가 맞습니다. ?
어리석은 질문이라면 죄송하지만 스레드에 그것에 대한 언급이 없습니다.
암튼 좋은 작품입니다 :)

@Faless 일부 최적화를 추가하는 release_debug입니다. 게임을 열 수 없기 때문에 전체 "릴리스"를 테스트할 수 없었습니다(게임도 빌드해야 하나요?)

Ive는 컬링을 훨씬 더 개선하고, 모든 프레임을 재생성할 필요를 없애고, 더 나은 공간 최적화를 만드는 방법에 대한 아이디어를 가지고 있었습니다. 내가 무엇을 시도할 수 있는지 볼 수 있습니다. 이론적으로 그런 것은 재생성을 제거하고, 메인 컬의 성능을 약간 향상시킬 수 있으며, 컬 성능을 엄청나게 증가시켜 거의 0에 가까운 비용을 갖는 포인트라이트에 대한 특정 모드를 가질 수 있습니다. "반경 안의 객체"를 얻기 위해 값싼 O(1)로 바뀝니다.

내 실험 중 하나가 작동한 방식에서 영감을 얻었습니다. 여기서 서로 튀는 400,000개의 물리 개체를 수행합니다.

이제 새로운 컬링이 구현됩니다. 이제 블록 생성이 훨씬 더 스마트해져서 더 빠른 컬링이 가능해졌습니다. 조명에 대한 특별한 경우는 아직 구현되지 않았습니다.
내 포크에 커밋

현재 마스터 브랜치의 빌드에서 해당 벤치마크 도구(스크린샷에 있는 도구)를 실행하여 현재 구현에 비해 구현이 얼마나 많은 성능을 제공하는지에 대한 참조 지점을 제공할 수 있는지 궁금합니다. 난 바보야, 이런.

@LikeLakers2 스크린샷에서 현재 구현과 구현을 모두 볼 수 있습니다.

그는 이것을 마스터 포크에서 실행했습니다.

2018년 12월 12일 수요일 MichiRecRoom [email protected]
썼다:

@neikeq https://github.com/neikeq 설명? 나는 스크린 샷을 생각했다
게시된 것은 그의 구현일 뿐입니다.
스크린샷과 함께 지금까지 표현되었습니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/godotengine/godot/issues/23998#issuecomment-446831151 ,
또는 스레드를 음소거
https://github.com/notifications/unsubscribe-auth/ADLZ9pRh9Lksse9KBfWV0z5GmHRXf5P2ks5u4crCgaJpZM4YziJp
.

이 주제에 대한 뉴스가 있습니까?

이 주제에 대한 뉴스가 있습니까?

나는 reduz와 이야기했다. 프로젝트에 맞지 않기 때문에 병합되지 않습니다. 대신 다른 실험을 하러 갔습니다. 나중에 4.0으로 컬링을 업그레이드할 수도 있습니다.

정말 유망해 보였다는 점을 생각하면 유감입니다. 이러한 문제가 제때 해결되기를 바랍니다.

아마도 이것은 4.0 이정표가 주어져야 합니까? Reduz는 Vulkan 4.0에 대한 작업을 계획하고 있기 때문에 이 주제는 성능에 관한 반면 렌더링에 중점을 두거나 적어도 OP는 그렇습니다.

@vblanco20-1 안맞는다고 하던가요? C ++ 17로의 이동 때문에 가정하고 있습니까?

그러나 이정표에 다른 관련 문제가 있습니다. #25013

관심이 있을 수 있습니다. 나는 꽤 오랫동안 멋진 포크에 대해 작업했습니다. 현재 결과는 다음과 같습니다.
4코어 인텔 CPU와 GTX 1070이 탑재된 대형 게임용 노트북에서 캡처
노멀 고도

내 포크 https://github.com/vblanco20-1/godot/tree/ECS_Refactor

두 프로필 모두에서 Red는 본질적으로 "GPU 대기"입니다. 현재 opengl에서 너무 많은 drawcall로 인해 병목 현상이 발생했습니다. vulkan 또는 전체 렌더러를 다시 작성하지 않고는 실제로 해결할 수 없습니다.

CPU 측에서는 13ms 프레임에서 5ms 프레임으로 이동합니다. "빠른" 프레임은 5.5ms에서 2.5ms로 이동합니다.
"총 프레임" 측에서는 13ms에서 8-9ms로 이동합니다.
~75FPS ~ ~115FPS

CPU 시간 감소 = 게임 플레이에 더 많은 시간을 할애할 수 있습니다. 현재 godot는 CPU에서 병목 현상이 발생하므로 게임 플레이에 더 많은 시간을 할애하면 FPS가 낮아지고 포크는 GPU에 바인딩되므로 CPU가 "무료"이기 때문에 FPS를 그대로 사용하여 더 많은 게임 플레이 로직을 추가할 수 있습니다. 매 프레임마다 꽤 오랜 시간이 걸립니다.

이러한 개선 사항 중 많은 부분이 Godot로 병합될 수 있습니다. IF Godot는 최신 C++를 지원하고 매우 저렴한 "작은" 작업을 허용하는 멀티스레딩 시스템을 갖추고 있습니다.
가장 큰 이득은 동적 개체 #25013에서 다중 스레드 그림자 및 다중 스레드 라이트맵 읽기를 수행하여 이루어집니다. 둘 다 같은 방식으로 작동합니다. 렌더러의 다른 많은 부분도 다중 스레드입니다.
다른 이점은 Godot보다 10배에서 20배 빠른 Octree와 컬 목록을 반복하는 대신 깊이 사전 통과 및 일반 통과 렌더링 목록을 한 번에 모두 기록하는 것과 같은 렌더링 흐름의 일부 개선입니다. 몇 번이고 라이트->메쉬 연결이 작동하는 방식이 크게 변경되었습니다(연결 목록이 없습니다!).

저는 현재 TPS 데모 이외의 더 많은 테스트 맵을 찾고 있으므로 다른 유형의 맵에서 더 많은 메트릭을 가질 수 있습니다. 또한 이 모든 것이 어떻게 작동하는지 자세히 설명하는 일련의 기사를 작성할 것입니다.

@vblanco20-1 완전 굉장합니다. 공유해 주셔서 감사합니다!

나는 또한 Vulkan이 멋지지만 괜찮은 GLES3 성능을 갖는 것이 Godot에게 절대적인 승리가 될 것이라는 데 동의합니다. 완전한 Vulkan 지원은 조만간 착륙하지 않을 가능성이 높지만 GLES3 패치는 여기 사람들이 지금 완전히 할 수 있는 것으로 입증된 것입니다.

이것에 점점 더 많은 관심을 가져 온 것에 대한 나의 거대한 +1. Reduz가 커뮤니티가 GLES3를 개선할 수 있도록 동의했다면 나는 지구상에서 가장 행복한 사람일 것입니다. 우리는 Godot에서 1.5년 동안 매우 진지한 3D 프로젝트를 하고 있으며 Godot를 매우 지지하고 있습니다(기부금 포함). 그러나 견고한 60FPS의 부족은 정말로 우리를 의욕을 꺾고 우리의 모든 노력을 큰 위험에 빠뜨립니다.

크레딧이 충분하지 않아 정말 아쉽습니다. 현재(3D 면에서 매우 간단한) 프로젝트로 앞으로 몇 달 안에 60FPS를 달성하지 못할 경우 플레이 가능한 게임을 제공하지 못하고 모든 노력이 낭비될 것입니다. :/

@vblanco20-1 솔직히 말해서 포크를 프로덕션 게임의 기반으로 사용하는 것도 고려하고 있습니다.

추신: 몇 가지 생각: 최후의 수단으로 2개의 GLES3 래스터라이저(GLES3 및 GLES3-커뮤니티)를 갖는 것이 완전히 가능할 것이라고 생각합니다.

추신: 몇 가지 생각: 최후의 수단으로 2개의 GLES3 래스터라이저(GLES3 및 GLES3-커뮤니티)를 갖는 것이 완전히 가능할 것이라고 생각합니다.

그것은 나에게 의미가 없습니다. GLES3 및 GLES2 렌더러로 직접 수정 및 성능 향상을 가져오는 것이 더 나은 아이디어일 것입니다(기존 프로젝트에서 렌더링이 주요 방식으로 중단되지 않는 한).

다른 이점은 Godot보다 10배에서 20배 빠른 Octree와 컬 목록을 반복하는 대신 깊이 사전 통과 및 일반 통과 렌더링 목록을 한 번에 모두 기록하는 것과 같은 렌더링 흐름의 일부 개선입니다. 몇 번이고 라이트->메쉬 연결이 작동하는 방식이 크게 변경되었습니다(연결 목록이 없습니다!).

@vblanco20-1 C++03을 유지하면서 깊이 사전 통과를 최적화할 수 있습니까?

@Calinou 깊이

@vblanco20-1 솔직히 말해서 포크를 프로덕션 게임의 기반으로 사용하는 것도 고려하고 있습니다.

@and3rson 제발

Godot를 프로파일링하기 위해 어떤 도구를 사용하시나요? 이 샘플을 생성하기 위해 Godot 소스에 Profiler.Begin 및 Profiler.End 플래그를 추가해야 했습니까?

Godot를 프로파일링하기 위해 어떤 도구를 사용하시나요? 이 샘플을 생성하기 위해 Godot 소스에 Profiler.Begin 및 Profiler.End 플래그를 추가해야 했습니까?

Tracy 프로파일러를 사용하며 여기에서 사용하는 다양한 유형의 스코프 프로파일 마크가 있습니다. 예를 들어 ZoneScopedNC("Fill List", 0x123abc)는 해당 이름과 원하는 16진수 색상으로 프로필 표시를 추가합니다.

@vblanco20-1 - 이러한 성능 향상 중 일부가 Godot 메인 브랜치로 옮겨지는 것을 볼 수 있을까요?

@vblanco20-1 - 이러한 성능 향상 중 일부가 Godot 메인 브랜치로 옮겨지는 것을 볼 수 있을까요?

아마도 C++11이 지원될 때일 것입니다. 그러나 reduz는 vulkan이 발생하기 전에 렌더러에서 더 많은 작업을 수행하는 것을 원하지 않으므로 절대 그럴 수 없습니다. 최적화 작업의 일부 결과는 4.0 렌더러에 유용할 수 있습니다.

@vblanco20-1 브랜치에 대한 컴파일러 및 환경 세부 정보를 공유하는 마음, 나는 대부분을 알아낼 수 있다고 생각하지만 필요하지 않은 경우 문제를 파악하는 데 시간을 낭비하지 마십시오.

또한 AABB 변경 사항을 Godot 메인에 추가 비용 없이 추가할 수 없나요?

@vblanco20-1 브랜치에 대한 컴파일러 및 환경 세부 정보를 공유하는 마음, 나는 대부분을 알아낼 수 있다고 생각하지만 필요하지 않은 경우 문제를 파악하는 데 시간을 낭비하지 마십시오.

또한 AABB 변경 사항을 Godot 메인에 추가 비용 없이 추가할 수 없나요?

@swarnimarun Visual Studio 17 또는 19(나중 업데이트 중 하나)는
scons 스크립트는 cpp17 플래그를 추가하도록 수정되었습니다. 또한 현재 편집기 실행이 중단되었습니다. 복원할 수 있는지 확인하는 중입니다.

슬프게도 AABB 변경은 가장 큰 것 중 하나입니다. Godot octree는 비주얼 서버의 많은 것들과 얽혀 있습니다. 컬링을 위해 개체를 추적할 뿐만 아니라 개체를 페어링하기 위한 자체 시스템으로 조명/반사 프로브에 연결합니다. 이러한 쌍은 또한 octree의 연결 목록 구조에 의존하므로 많은 시각적 서버를 변경하지 않고 현재 octree를 더 빠르게 조정하는 것은 거의 불가능합니다. 사실 나는 여전히 몇 가지 객체 유형에 대해 포크에서 일반적인 godot octree를 제거할 수 없었습니다.

@vblanco20-1 패트리온이 있나요? 성능에 중점을 둔 포크에 약간의 돈을 투자하고 고대 C++로 제한되지 않으며 아마도 저만이 아닐 것입니다. 3D 프로젝트를 위해 Godot를 가지고 놀고 싶지만 핵심 팀에 대한 성능 및 사용성에 대한 접근 방식을 증명하는 개념이 없으면 실행 가능해질 것이라는 희망을 잃어가고 있습니다.

@mixedCase 저는 Godot의 모든 종류의 포크를 지원하는 것을 매우 주저합니다. 포크와 단편화는 종종 오픈 소스 프로젝트의 죽음입니다.

더 나은 시나리오, 그리고 더 새로운 C++가 상당한 최적화를 허용한다는 것이 입증되었기 때문에 Godot는 공식적으로 최신 버전의 C++로 업그레이드할 것입니다. 나는 이것이 Godot 4.0에서 일어날 것으로 예상하고, 3.2에서 파손의 위험을 최소화하고, Vulkan이 Godot 4.0에 추가될 때 새로운 C++ 기능이 활용되기를 기대합니다. 또한 reduz가 삭제를 원하기 때문에 GLES 3 렌더러에 중요한 변경 사항이 있을 것으로 예상하지 않습니다.

(그러나 나는 Godot 개발자를 위해 말하는 것이 아닙니다. 이것은 단지 내 추측일 뿐입니다)

@aaronfrank 저도 동의합니다. 영구 포크는 이상적이지 않다고 생각합니다. 그러나 그가 말한 것에서 내가 수집한 것(제가 틀렸다면 저를 바로 잡아 주십시오 )은 된다고 믿고 있다는 것입니다. 그들 중 일부는 코드를 "읽을 수 없는" 것으로 만드는 것으로 인식합니다(적어도 C++이 거의 10년 전에 있었던 "증강 C"에 익숙한 개발자에게는).

저는 Juan이 매우 실용적인 사람이라고 믿습니다. 따라서 엔지니어링 트레이드 오프가 아마도 가치가 있다고 확신시키기 위해 현대 추상화와 보다 효율적인 데이터 구조를 사용하는 이점을 보여주는 개념 증명이 필요할 것입니다. @vblanco20-1은 지금까지 놀라운 일을 해냈기 때문에 개인적으로 그가 그런 일을 하고 싶다면 매달 그에게 약간의 돈을 적는 것을 주저하지 않을 것입니다.

나는 Godot 개발자들이 좋은 아이디어, 성과, 발전에 알레르기가 있는 것처럼 행동하는 방식에 끊임없이 놀랐습니다. 이게 안들어간게 아쉽네요.

이것은 최적화, 정확히 데이터 구조 사용에 대해 작업 중인 일련의 기사에서 발췌한 것입니다.

Godot는 STL 컨테이너와 C++03을 금지합니다. 이는 컨테이너에 이동 연산자가 없으며 컨테이너가 STL 컨테이너 자체보다 더 나쁜 경향이 있음을 의미합니다. 여기 Godot 데이터 구조에 대한 개요와 그 문제가 있습니다.

미리 할당된 C++ 배열. 전체 엔진에서 매우 일반적입니다. 크기는 일부 구성 옵션에 의해 설정되는 경향이 있습니다. 이것은 렌더러에서 매우 일반적이며 적절한 동적 배열 클래스가 여기서 잘 작동합니다.
오용의 예: https://github.com/godotengine/godot/blob/master/servers/visual/visual_server_scene.h#L442
이 배열은 정당한 이유 없이 메모리를 낭비하고 있습니다. 동적 배열을 사용하면 컴파일 상수에 의한 최대 크기 대신 필요한 크기만 만들 수 있으므로 여기에서 훨씬 더 나은 옵션이 될 것입니다. MAX_INSTANCE_CULL을 사용하는 각 Instance* 어레이는 0.5MB의 메모리를 사용하고 있습니다.

Vector( vector.h) std::vector 동적 배열과 동일하지만 심각한 결함이 있습니다.
벡터는 copy-on-write 구현으로 원자적으로 다시 계산됩니다. 당신이 할 때

벡터 a = build_vector();
벡터 b = a;

refcount는 2로 이동합니다. 이제 B와 A는 메모리의 동일한 위치를 가리키고 편집이 이루어지면 배열을 복사합니다. 이제 벡터 A 또는 B를 수정하면 벡터 복사가 트리거됩니다.

벡터에 쓸 때마다 원자 refcount를 확인해야 하므로 벡터의 모든 단일 쓰기 작업이 느려집니다. Godot Vector는 최소한 std::vector보다 5배 느린 것으로 추정됩니다. 또 다른 문제는 벡터에서 항목을 제거하면 벡터가 자동으로 재배치되어 제어할 수 없는 끔찍한 성능 문제가 발생한다는 것입니다.

풀 벡터(pool_vector.h). 벡터와 거의 같지만 대신 풀입니다. 벡터와 같은 함정이 있는데, 아무 이유 없이 쓰기 시 복사하고 자동으로 축소합니다.

목록( list.h)에 해당하는 std::list를 나열합니다. 목록에는 2개의 포인터(첫 번째 및 마지막) + 요소 수 변수가 있습니다. 목록의 모든 노드는 이중 연결되어 있으며 목록 컨테이너 자체에 대한 추가 포인터도 있습니다. 목록의 모든 노드에 대한 메모리 오버헤드는 24바이트입니다. Vector가 일반적으로 좋지 않기 때문에 Godot에서 끔찍하게 남용됩니다. 엔진 전체에 끔찍하게 오용되었습니다.

큰 오용의 예:
https://github.com/godotengine/godot/blob/master/servers/visual/visual_server_scene.h#L129
이것이 목록이어야 할 이유가 없으며 벡터여야 합니다.
https://github.com/godotengine/godot/blob/master/servers/visual/visual_server_scene.h#L242
이 경우는 모두 잘못된 것입니다. 다시 말하지만 벡터 또는 유사해야 합니다. 이것은 실제로 성능 문제를 일으킬 수 있습니다.
가장 큰 실수는 컬링에 사용되는 옥트리에서 List를 사용하는 것입니다. 나는 이미 이 스레드에서 고도 옥트리에 대해 자세히 설명했습니다.

Boost::intrusive_list와 유사한 SelfList(self_list.h) 침입 목록. 이것은 항상 노드당 32바이트의 오버헤드를 저장합니다. 이는 자체도 가리키기 때문입니다. 엔진 전체에 끔찍하게 오용되었습니다.
예:
https://github.com/godotengine/godot/blob/master/servers/visual/visual_server_scene.h#L159
이것은 특히 나쁩니다. 전체 엔진에서 최악 중 하나입니다. 이것은 아무 이유 없이 엔진의 모든 단일 렌더링 가능한 개체에 8개의 뚱뚱한 포인터를 추가하는 것입니다. 이것이 목록일 필요는 없습니다. 다시, 그것은 슬롯맵이나 벡터가 될 수 있고, 그것이 내가 그것을 대체한 것입니다.

Map(map.h) 적-검정 나무. 거의 모든 용도에서 해시맵으로 오용됩니다. 사용법에 따라 OAHashmap 또는 Hashmap을 위해 엔진에서 삭제해야 합니다.
내가 본 지도의 모든 사용은 잘못되었습니다. 나는 그것이 의미가있는 곳에서 사용되는 Map의 예를 찾을 수 없습니다.

Hashmap( hash_map.h) 은 std::unordered_map과 거의 동일하며, 연결 목록 버킷을 기반으로 하는 폐쇄형 주소 지정 해시맵입니다. 요소를 제거할 때 다시 해시할 수 있습니다.

OAHashMap( oa_hash_map.h) 새로 작성된 고속 개방 주소 지정 해시맵. 로빈후드 해싱을 사용합니다. 해시맵과 달리 요소를 제거할 때 크기가 조정되지 않습니다. std::unordered_map보다 훨씬 잘 구현된 구조입니다.

CommandQueueMT(command_queue_mt.h) 비주얼 서버와 같은 다른 서버와 통신하는 데 사용되는 명령 큐입니다. 하드코딩된 250kb 어레이를 할당자 풀로 사용하여 작동하고 모든 명령을 가상 call() 및 post() 함수를 사용하여 객체로 할당합니다. 푸시/팝 작업을 보호하기 위해 뮤텍스를 사용합니다. 뮤텍스를 잠그는 것은 비용이 많이 듭니다. 대신 무디카멜 대기열을 사용하는 것이 좋습니다. 이 대기열은 훨씬 더 빨라야 합니다. 이것은 많은 움직이는 개체와 같이 시각적 서버로 많은 작업을 수행하는 게임의 경우 병목 현상이 될 수 있습니다.

이것은 Godot의 데이터 구조의 거의 핵심 세트입니다. 적절한 std::vector 동등물이 없습니다. "동적 배열" 데이터 구조를 원하는 경우 벡터와 쓰기 시 복사 및 크기 축소에 대한 단점이 있습니다. 저는 DynamicArray 데이터 구조가 바로 지금 godot가 가장 필요로 하는 것이라고 생각합니다.

내 포크의 경우 외부 라이브러리의 STL 및 기타 컨테이너를 사용합니다. 나는 godot 컨테이너가 2개의 해시맵을 제외하고 STL보다 성능이 좋지 않기 때문에 피합니다.

4.0의 vulkan 구현에서 문제가 발견되었습니다. 진행 중인 작업을 알고 있으므로 수정할 시간이 아직 있습니다.

렌더 API에서 맵 사용. https://github.com/godotengine/godot/blob/vulkan/drivers/vulkan/rendering_device_vulkan.h#L350
내가 언급했듯이 Map은 잘 사용되지 않으며 존재할 이유도 없습니다. 이러한 경우에는 해시맵이어야 합니다.
배열 또는 이와 유사한 것 대신 연결 목록을 남용합니다.
https://github.com/godotengine/godot/blob/vulkan/drivers/vulkan/rendering_device_vulkan.h#L680
운 좋게도 이것은 빠른 루프가 아닐 가능성이 있지만 여전히 사용해서는 안되는 List를 사용하는 예입니다.

렌더링 API에서 PoolVector 및 Vector 사용. https://github.com/godotengine/godot/blob/vulkan/drivers/vulkan/rendering_device_vulkan.h#L747
렌더 API 추상화의 일부로 결함이 있는 2개의 구조를 사용할 이유가 없습니다. 이를 사용함으로써 사용자는 다른 데이터 구조를 사용할 수 없는 대신 단점이 있는 2개를 강제로 사용해야 합니다. 이러한 경우 포인터 + 크기를 사용하고 필요한 경우 벡터를 사용하는 함수 버전을 계속 사용하는 것이 좋습니다.

이 API가 사용자에게 해를 끼치는 실제 예는 정점 버퍼 생성 함수에 있습니다. GLTF 형식에서 정점 버퍼는 바이너리 파일로 압축됩니다. 이 API를 사용하면 사용자는 GLTF 바이너리 버퍼를 메모리에 로드하고 각 버퍼에 대한 데이터를 복사하는 이 구조를 만든 다음 API를 사용해야 합니다.
API가 포인터 + 크기 또는 Span<> 구조체를 사용하는 경우 사용자는 변환을 수행할 필요 없이 로드된 바이너리 버퍼에서 API로 정점 데이터를 직접 로드할 수 있습니다.

이것은 복셀 엔진과 같은 절차적 정점 데이터를 다루는 사람들에게 특히 중요합니다. 이 API를 사용하면 개발자는 개발자가 사용하는 내부 구조에서 직접 정점 데이터를 로드하는 대신 정점 데이터에 대해 Vector를 사용해야 하므로 상당한 성능 비용이 발생하거나 데이터를 Vector에 복사해야 합니다.

이 주제에 대해 더 알고 싶다면 CppCon의 이 강연이 제가 아는 최고의 강연입니다. https://www.youtube.com/watch?v=fHNmRkzxHWs
다른 좋은 이야기는 https://www.youtube.com/watch?v=-8UZhDjgeZU 입니다 . 여기서 Godot 요구에 매우 유용한 슬롯맵과 같은 몇 가지 데이터 구조를 설명합니다.

Godot는 성능에 큰 문제가 있습니다... 당신은 Godot 팀의 좋은 동료가 될 것입니다. 그것을 고려하십시오!

기여하거나 도움을 줄 올바른 방법이 아니라고 생각하기 때문에 이 스레드를 닫습니다.

@vblanco20-1 좋은 의도를 갖고 계시다는 점에 다시 한 번 감사드립니다. 하지만 엔진의 내부 작동 방식이나 그 뒤에 숨은 철학을 전혀 이해하지 못하고 계십니다. 귀하의 의견은 대부분 사용 방법, 성능에 얼마나 중요한지 또는 일반적으로 우선 순위가 무엇인지 이해하지 못하는 것에 대한 것입니다.

당신의 어조도 불필요하게 공격적입니다. 당신이 이해하지 못하는 것이 무엇인지, 또는 왜 어떤 것이 특정한 방식으로 행해지는지 묻는 대신에, 당신은 단지 오만하게 굴고 있습니다. 이것은 이 커뮤니티에 대한 올바른 태도가 아닙니다.

당신이 최적화에 관해 언급한 대부분의 것들은 내가 Godot 4.0에서 최적화를 위해 계획한 항목의 아주 작은 표면일 뿐입니다(내 목록에 더 많은 것들이 있습니다). 나는 이미 이것이 몇 달 전 이후로 여러 번 다시 작성될 것이라고 말했습니다. 저를 믿지 않으셔도 괜찮습니다만, 명백한 이유 없이 이것으로 시간을 낭비하고 많은 사람들을 혼란스럽게 하시는 것 같습니다.

작업을 마친 후에는 피드백을 매우 환영합니다. 하지만 지금 하고 있는 일은 죽은 말을 때리는 것뿐이므로 잠시 진정하십시오.

다시 말씀드리지만, Godot 4.0의 알파 버전이 출시되면(올해 말 전에) 모든 새로운 코드를 프로파일링하고 최적화 방법에 대한 피드백을 제공할 수 있습니다. 나는 우리 모두가 이익을 얻을 것이라고 확신합니다. 현재로서는 기존 코드가 4.0에서 사라지고 3.x 브랜치에서 병합되지 않을 것이기 때문에 여기에서 다른 것을 논의하는 데 큰 의미가 없습니다. 이 지점에서는 안정성이 최적화보다 더 중요합니다.

많은 사람들이 기술적 세부 사항에 대해 궁금해 할 수 있기 때문에:

• 모든 공간 인덱싱 코드(vblanco가 다시 작성한 것)는 다중 스레드를 사용한 컬링을 위한 선형 알고리즘으로 대체되며, 계층적 오클루전 컬링을 위한 octree 및 중복 검사를 위한 SAP와 결합됩니다. 모든 종류의 게임에서 성능. 이러한 구조에 대한 할당은 O(1) 인 새로운 RID_Allocator와 같은 맥락에서 이루어집니다. 나는 전에 @vblanco20-1과 이것을 논의했고 그의 접근 방식은 일반적으로 일반적인 Godot 사용자가 가질 것으로 기대되지 않는 조정에 어느 정도의 전문 지식이 있어야 하기 때문에 그의 접근 방식이 모든 유형의 게임에 적합하지 않다고 설명했습니다. 또한 오클루전 컬링을 추가하는 방법도 좋지 않았습니다.
• 목록을 사용할 수 있는 경우에는 배열을 사용하지 않을 것입니다. 목록은 분할 위험이 전혀 없는 작은 시간 할당을 수행하기 때문입니다. 어떤 경우에는 항상 증가하고 절대 축소되지 않는 섹션화된 배열(페이지에 정렬되어 조각화 없음)을 할당하는 것을 선호합니다(RID_Allocator 또는 2D 엔진 Vulkan 분기의 새 CanvasItem에서와 같이 이제 항목을 다시 그릴 수 있음). 많은 명령을 매우 효율적으로 사용) 하지만 여기에는 성능상의 이유가 있어야 합니다. Godot에서 목록이 사용되는 이유는 성능보다 작은 할당이 선호되기 때문입니다(실제로 다른 사람들이 읽을 수 있도록 코드 의도를 더 명확하게 만듭니다).
• PoolVector는 연속 메모리 페이지가 있는 매우 큰 할당을 위한 것입니다. Godot 2.1까지는 사전 할당된 메모리 풀을 사용했지만, 이것은 3.x에서 제거되었으며 현재 현재 동작이 잘못되었습니다. 4.0의 경우 가상 메모리로 대체되며 할 일 목록에 있습니다.
• Godot의 Vector<>를 std::vector와 비교하는 것은 사용 사례가 다르기 때문에 무의미합니다. 우리는 주로 데이터를 전달하는 데 사용하고 빠른 액세스를 위해 잠급니다(ptr() 또는 ptrw() 메서드를 통해). std::vector를 사용했다면 Godot는 불필요한 복사로 인해 훨씬 ​​느려질 것입니다. 우리는 또한 다양한 용도로 쓰기 메커니즘의 복사를 많이 활용합니다.
• Map<>은 많은 양의 요소에 대해 더 간단하고 친숙하며 단편화를 생성하는 급격한 성장/축소에 대해 걱정할 필요가 없습니다. 성능이 필요할 때 HashMap이 대신 사용됩니다(사실이지만 OAHashMap을 더 사용해야 하지만 너무 새롭기 때문에 그럴 시간이 없었습니다). 일반적인 철학으로 성능이 우선시되지 않을 때 운영 체제의 메모리 할당자가 작은 구멍을 찾는 것이 더 쉽기 때문에 작은 할당이 큰 할당보다 항상 선호됩니다(이는 거의 의도된 작업입니다). , 효과적으로 더 적은 힙을 소비합니다.

다시 말하지만, 당신이 원할 때 언제든지 계획과 디자인에 대해 물어볼 수 있습니다. 도적질하고 불평하는 대신, 이것은 프로젝트를 돕는 최선의 방법이 아닙니다.

또한 이 스레드를 읽는 많은 사람들이 공간 인덱서가 처음부터 느린 이유에 대해 궁금해할 것이라고 확신합니다. 그 이유는 아마도 여러분이 Godot를 처음 접했을 수도 있지만, 아주 최근까지 3D 엔진은 10년이 넘었고 매우 구식이었습니다. OpenGL ES 3.0에서 현대화 작업을 수행했지만 OpenGL에서 발견한 문제와 Vulkan에서 더 이상 사용되지 않는다는 사실 때문에 중단해야 했습니다(Apple에서 포기했습니다).

이에 더해 Godot는 얼마 전까지만 해도 PSP와 같은 장치에서 실행되었습니다. 지금은 하드웨어가 매우 다르기 때문에 더 최적화되고 더 많은 메모리를 사용하는 코드로 변경되고 있지만 필요하지 않을 때 이 작업을 수행하는 것은 무의미하고 성능이 저하되는 많은 위치에서 사용되는 목록을 보는 것이 좋습니다. 중요하지.

또한, 우리가 하고 싶었던 많은 최적화(더 나은 성능을 위해 많은 뮤텍스 코드를 원자로 이동)는 Godot를 C++11(인라인된 원자에 대한 훨씬 더 나은 지원을 갖고 있고 그렇지 않은)으로 이동할 수 있을 때까지 보류되어야 했습니다. 전체 네임스페이스를 오염시키는 Windows 헤더를 포함하도록 요구합니다. 이는 안정적인 분기에서 할 수 있는 작업이 아닙니다. C++11로의 이동은 Godot 3.2가 분기되고 기능이 정지된 후에 이루어질 것입니다. 그렇지 않으면 Vulkan Master 분기를 동기화 상태로 유지하는 것이 큰 고통이 될 것입니다. 현재 초점이 Vulkan 자체에 있기 때문에 서두르지 않습니다.

죄송합니다. 시간이 걸리겠지만 서두르는 것보다 제대로 처리하는 것이 좋습니다. 장기적으로 더 나은 성과를 냅니다. 현재 모든 성능 최적화 작업이 진행 중이며 곧 준비될 것입니다(Vulkan 분기를 테스트한 경우 2D 엔진이 이전보다 훨씬 빠름).

안녕하세요 reduz님
나는 대부분 당신의 요점이 유효하다는 것을 알지만, 나는 동의하지 않는 두 가지에 대해 논평하고 싶습니다:

• 목록은 조각화 위험이 전혀 없는 작은 시간 할당을 수행하기 때문에 목록을 사용할 수 있는 경우 배열을 사용하지 않습니다. 어떤 경우에는 항상 증가하고 절대 축소되지 않는 섹션화된 배열(페이지에 정렬되어 조각화 없음)을 할당하는 것을 선호합니다(RID_Allocator 또는 2D 엔진 Vulkan 분기의 새 CanvasItem에서와 같이 이제 항목을 다시 그릴 수 있음). 많은 명령을 매우 효율적으로 사용) 하지만 여기에는 성능상의 이유가 있어야 합니다. Godot에서 목록이 사용되는 이유는 성능보다 작은 할당이 선호되기 때문입니다(실제로 다른 사람들이 읽을 수 있도록 코드 의도를 더 명확하게 만듭니다).

연결 목록이 기하급수적으로 증가하는 동적 배열보다 속도나 메모리 효율성을 고려하여 전반적인 성능이 더 좋을지 의심스럽습니다. 후자는 실제로 사용하는 것보다 최대 2배 많은 공간을 차지하도록 보장되는 반면 List<some pointer> 는 정확히 3배 많은 저장 공간(실제 내용, 다음 및 이전 포인터)을 사용합니다. 단면 배열의 경우 상황이 훨씬 더 좋아 보입니다.

적절하게 래핑되었을 때(그리고 내가 이미 Godot 코드에서 본 것으로부터 말할 수 있는 한, 그들은 프로그래머에게 거의 동일하게 보입니다. 그래서 "그들 [목록 ] 코드 의도를 더 명확하게 만듭니다".

IMHO, 목록은 정확히 두 가지 조건에서 유효합니다.

• 컨테이너 중간에 요소를 자주 지우거나 삽입해야 합니다.
• 또는 요소의 일정한 시간(단순히 상각된 일정 시간이 아닌) 삽입/삭제가 필요합니다. 즉, 시간 소모적인 메모리 할당이 불가능한 실시간 컨텍스트에서는 괜찮습니다.

• Map<>은 많은 양의 요소에 대해 더 간단하고 친숙하며 단편화를 생성하는 급격한 성장/축소에 대해 걱정할 필요가 없습니다. 성능이 필요할 때 HashMap이 대신 사용됩니다(사실이지만 OAHashMap을 더 사용해야 하지만 너무 새롭기 때문에 그럴 시간이 없었습니다). 일반적인 철학으로 성능이 우선시되지 않을 때 운영 체제의 메모리 할당자가 작은 구멍을 찾는 것이 더 쉽기 때문에 작은 할당이 큰 할당보다 항상 선호됩니다(이는 거의 의도된 작업입니다). , 효과적으로 더 적은 힙을 소비합니다.

libc-allocator는 일반적으로 매우 똑똑하며 OAHashMap(또는 std::unordered_map)이 때때로 저장소를 재할당하기 때문에(상각 상각된 일정 시간) 할당자는 일반적으로 메모리 블록을 컴팩트하게 유지하도록 관리합니다. 나는 OAHashMap이 Map과 같은 일반 이진 트리 맵보다 효율적으로 더 많은 힙을 소비하지 않는다고 굳게 믿습니다. 대신 Map의 각 요소에 있는 거대한 포인터 오버헤드가 실제로 OAHashmap(또는 std::unordered_map)의 힙 조각화보다 더 많은 메모리를 소비한다고 확신합니다.

결국, 나는 이러한 종류의 논쟁을 분류하는 가장 좋은 방법은 그것을 벤치마킹하는 것이라고 생각합니다. 확실히 이것은 Godot 4.0에서 훨씬 더 많이 사용됩니다. 왜냐하면 -- 당신이 말했듯이 -- 거기에서 많은 성능 최적화가 일어날 것이고 어쨌든 4.0에서 완전히 재작성될 수 있는 개선된 코드 경로를 많이 사용하지 않기 때문입니다.

하지만 @reduz 님 , @vblanco20-1이 제안한 이러한 모든 변경 사항을 벤치마킹하는 것에 대해 어떻게 생각하십니까(지금도 3.1에서). @vblanco20-1(또는 다른 사람)이 그러한 벤치마킹 제품군을 작성하는 데 시간을 투자하고 vblanco의 변경 사항에 대해 Godot3.1의 성능(속도 및 "조각화를 고려한 힙 소비" 측면에서 모두)을 평가할 의향이 있다면? 실제 4.0 변경 사항에 대한 귀중한 힌트를 얻을 수 있습니다.

그런 방법론이 '서두르지 않고 제대로 하고 있다'는 당신에게 잘 맞는다고 생각한다.

@vblanco20-1: 사실, 당신의 노고에 감사드립니다. 변경 사항이 실제 성능 향상인지 여부를 실제로 측정할 수 있도록 그러한 벤치마크를 생성하도록 동기를 부여하시겠습니까? 나는 매우 관심이 있을 것입니다.

@Windfisch 몇 가지를 잘못 읽거나 잘못 이해했기 때문에 위의 내 게시물을 다시 읽는 것이 좋습니다. 나는 당신을 위해 그들을 명확히 할 것입니다.

• 목록은 귀하가 설명하는 사용 사례에 정확히 사용되며 더 나은 성능을 제공한다고 주장한 적이 없습니다. 작은 할당으로 구성되어 있기 때문에 힙을 재사용하는 데 배열보다 효율적입니다. 규모에서(의도한 사용 사례에 대해 많이 사용하는 경우) 이는 실제로 차이를 만듭니다. 성능이 필요할 때 더 빠르거나 더 많이 포장되거나 더 나은 캐시 일관성을 가진 다른 컨테이너가 이미 사용됩니다. 좋든 나쁘든 Victor는 주로 PSP용 게임을 퍼블리싱하는 데 사용되는 사내 엔진이었기 때문에 최적화되지 않은 오래된 엔진 영역(실제로 가장 오래된 것은 아닐지라도) 중 하나에 집중했습니다. 이것은 오랫동안 재작성을 보류했지만 다른 우선순위가 있었습니다. 그의 주요 최적화는 내가 최근에 추가한 CPU 기반 복셀 원뿔 추적이었습니다. 솔직히 말해서, 3.0 릴리스 근처에서 너무 서두르기 때문에 제대로 작업하지 못했습니다. 그러나 이에 대한 적절한 수정은 완전히 다른 알고리즘이며 그렇지 않습니다. 그가 한 것처럼 병렬 처리를 추가합니다.
• 나는 @vblanco20-1의 작업 성능에 대해 논쟁한 적이 없으며 솔직히 그것에 대해 신경 쓰지 않습니다. 그의 작업을 병합하지 않는 이유는 1) 그가 사용하는 알고리즘은 게임의 평균 개체 크기에 따라 수동 조정이 필요하기 때문입니다. 이는 대부분의 Godot 사용자가 수행해야 하는 작업입니다. 나는 약간 느리지만 조정할 필요 없이 더 잘 확장되는 알고리즘을 선호하는 경향이 있습니다. 2) 그가 사용하는 알고리즘은 오클루전 컬링에 좋지 않습니다(단순한 옥트리는 계층적 특성으로 인해 더 좋습니다). 3) 그가 사용하는 알고리즘은 페어링에 적합하지 않습니다(SAP가 더 나은 경우가 많습니다). 4) 그는 C++17과 내가 지원하는 데 관심이 없는 라이브러리를 사용하거나 필요하지 않다고 생각하는 람다를 사용합니다. 는 가능한 한 빨리 3.2를 릴리스할 예정이므로 수정하거나 작업하지 않을 것입니다. 기존 코드는 느릴 수 있지만 매우 안정적이고 테스트되었습니다. 이것이 병합되면 버그 보고서, 회귀 등이 있습니다. 우리는 이미 4.0 분기로 대부분 바쁘기 때문에 아무도 그것에 대해 작업하거나 Victor를 도울 시간이 없습니다. 이것은 모두 위에 설명되어 있으므로 게시물을 다시 읽으시기 바랍니다.

어쨌든 저는 Victor에게 인덱싱 코드를 플러그인할 수 있다고 약속했습니다. 따라서 결국에는 다양한 유형의 게임에 대해 다른 알고리즘도 구현될 수 있습니다.

Godot는 오픈 소스이며 그의 포크도 마찬가지입니다. 우리는 모두 열려 있고 여기에서 공유하고 있습니다. 필요한 경우 그의 작업을 사용하는 것을 막을 수 있는 것은 없습니다.

그 최적화는 gdscript, 렌더링 또는 "말더듬기" 문제에 영향을 미치지 않는 것 같고 사람들이 불평하는 것들이 있기 때문에(나를 포함합니다), 아마도 최적화를 통해 사람들이 행복할 것입니다(내 포함)... 필요하지 않습니다 루아짓 속도...
"copy on write" 작업은 내 플러그인에서 매우 큰 성능 최적화였습니다(스크립트 구문 분석에서 25초에서 7000줄 스크립트에서 단 1초로)... 저는 이러한 종류의 최적화가 우리가 gdscript에서 렌더링이 필요하고 말더듬 문제가 해결됩니다. 그게 전부입니다.

@reduz 의 설명에 감사드립니다. 그것은 실제로 이전 게시물보다 귀하의 요점을 더 명확하게했습니다.

공간 인덱싱 코드가 플러그 가능하다는 것은 좋은 일입니다. 실제로 그 코드는 이전에 엄청나게 다른 규모로 많은 개체를 처리할 때 넘어졌기 때문입니다. 4.0이 기대됩니다.

나도 그것에 대해 생각하고 있었고 공간 인덱싱 최적화에 대한 아이디어가 포함된 공유 문서를 두어 더 많은 기여자가 이에 대해 배우고 아이디어를 던지거나 구현을 수행할 수 있도록 하는 것이 좋습니다. 수행해야 할 작업에 대해 매우 잘 알고 있지만 여기에 추가 최적화를 수행하고 흥미로운 알고리즘을 제시할 여지가 많다고 확신합니다.

알고리즘이 충족해야 하는 매우 명확한 요구 사항을 지정할 수 있습니다(예: 세계 크기의 평균 요소에 대해 가능하면 사용자 조정을 요구하지 않고 가능하면 스레드를 사용하여 무차별 대입할 필요가 없습니다. 물리학이나 애니메이션과 같은 엔진도 이를 필요로 할 수 있으며 모바일에서 더 많은 배터리를 소모하고 재투영 기반 오클루전 컬링과의 호환성이 있으므로 어떤 형태의 계층 구조가 필요할 수 있지만 무차별 대입에 대해서도 테스트해야 합니다. 섀도우 버퍼 업데이트에 대해 - 아무 것도 변경되지 않으면 업데이트하지 않음 - 방향성 섀도우에 대한 재투영 기반 오클루전 컬링과 같은 최적화를 탐색하십시오. 우리는 또한 몇 가지 벤치마크 테스트의 생성에 대해 논의할 수 있습니다(저는 TPS 데모가 개체나 폐색이 많지 않기 때문에 좋은 벤치마크라고 생각하지 않습니다). @vblanco20-1 우리의 코딩/언어 스타일과 철학을 따를 의향이 있다면 물론 기꺼이 도움을 줄 수 있습니다.

나머지 렌더링 코드(RenderingDevice를 사용한 실제 렌더링)는 다소 간단하고 수행할 방법이 많지 않지만 인덱싱은 최적화를 위해 해결해야 할 더 흥미로운 문제인 것 같습니다.

공간 인덱싱에 대한 참조는 @reduz 입니다. 원래 타일 기반 컬링은 이 스레드의 중간쯤에 제거되고 Octree로 대체되었습니다. 내가 거기에서 얻은 octree는 WIP(일부 재맞춤 기능 누락)이지만 결과는 프로토타입에 대해 상당히 좋습니다. 그 코드는 프로토타입 특성에서 그리 좋지 않으므로 tps-demo와 같은 복잡한 장면에서 이러한 종류의 옥트리가 어떻게 수행되는지 확인하는 데만 유용합니다.
언리얼 엔진 옥트리가 작동하는 방식에서 영감을 받았지만 플랫 반복 가능성과 같은 몇 가지 수정 사항이 있습니다.

주요 아이디어는 옥트리의 잎사귀만 객체를 보유하고 해당 객체가 64 크기의 배열에 보유된다는 것입니다(컴파일 시간 크기는 다를 수 있음). octree 잎은 65개 요소로 "넘쳐"나간 후에만 분할됩니다. 개체를 제거할 때 부모 노드의 각 잎사귀가 64 크기 배열에 맞는 경우 잎사귀를 다시 부모 노드로 병합하여 잎사귀가 됩니다.

그렇게 하면 옥트리가 너무 깊어지지 않기 때문에 노드에서 테스트하는 시간을 최소화할 수 있습니다.

내가 한 또 다른 좋은 점은 리프 노드도 플랫 어레이에 저장되어 컬링에서 병렬을 허용한다는 것입니다. 이 방법은 포인트 섀도우를 위한 컬링 또는 기타 "작은" 작업을 수행할 때 계층적 컬링을 사용할 수 있으며, 컬링을 위한 플랫 병렬을 기본 뷰에 사용할 수 있습니다. 물론 모든 것에 계층 구조를 사용할 수 있지만 더 느리고 병렬화할 수 없습니다.

블록 구조는 약간의 메모리를 낭비하지만 최악의 시나리오에서도 노드가 양 이하로 떨어지면 병합되므로 많은 메모리를 낭비하지 않을 것이라고 생각합니다. 또한 노드와 리프가 모두 일정한 크기를 갖는다는 점에서 풀 할당자를 사용할 수 있습니다.

또한 포크에 여러 옥트리가 있는데, 이는 몇 가지를 최적화하는 데 사용됩니다. 예를 들어 섀도우캐스터 개체에 대해서만 옥트리가 있어서 섀도우맵을 컬링할 때 "섀도우를 투사할 수 있음"과 관련된 모든 논리를 건너뛸 수 있습니다.

렌더 API에 대한 Vector 및 다른 사람들에 대한 나의 우려에 대해 이 문제는 내가 걱정했던 것을 설명합니다. https://github.com/godotengine/godot/issues/24731

포크의 라이브러리와 C++17에서 .. 불필요합니다. 포크는 라이브러리의 일부가 필요했기 때문에 많은 라이브러리를 과도하게 사용합니다. 정말 필요하고 Godot가 필요하다고 생각하는 유일한 것은 업계에서 가장 강력한 병렬 대기열입니다. 저는 이를 위해 무디카멜 대기열을 사용했습니다.

람다에서 사용은 주로 컬링에 사용되며 검사를 통과한 개체만 출력 배열에 저장하면 되므로 상당한 양의 메모리를 절약하는 데 사용됩니다. 대안은 반복자 객체(언리얼 엔진이 옥트리로 수행하는 작업)를 수행하는 것이지만 결국 코드가 더 나빠지고 쓰기가 훨씬 더 어려워집니다.

내 의도는 "도둑질"하는 것이 아니라 "시연을 위해 포크를 만들 수 있습니다"라는 빈번한 의견에 답하는 것이었습니다. 이것이 바로 제가 한 일입니다. 스레드의 첫 번째 메시지는 약간 불안하고 정확하지 않습니다. 내 유일한 목표는 가장 인기 있는 오픈 소스 게임 엔진을 돕는 것이기 때문에 무례하게 보였다면 죄송합니다.

@vblanco20-1 훌륭하게 들리고 octree가 작동한다고 언급한 방식은 매우 의미가 있습니다. 솔직히 병렬 큐를 구현하는 데 신경 쓰지 않습니다(외부 종속성이 필요하지 않을 만큼 간단해 보이고 제대로 수행하려면 C++11이 필요하므로 Vulkan 분기에서만 발생할 것으로 생각합니다). 만약 당신이 이것을 커밋했다면, 나는 확실히 그것을 살펴보고 싶을 것입니다. 그래서 나는 그것을 Vulkan 브랜치에서 인덱서 재작성을 위한 기초로 사용할 수 있습니다. ). 물론 구현을 지원하려는 경우(새 API에 더 많은 것이 있을 때) 매우 환영합니다.

평평한 배열이 있는 병렬 버전을 사용하는 것은 흥미롭지 만 그것에 대한 제 관점은 오클루전 컬링에 그다지 유용하지 않을 것이며 일반 옥트리 컬링보다 얼마나 개선되었는지 측정하는 것도 흥미로울 것입니다. 사용된 코어의 추가 양을 고려합니다. 여러 스레드를 사용하여 더 효율적으로(무차별적으로) 사용할 수 있는 다른 영역이 많이 있음을 명심하십시오(물리와 같이). 따라서 이 접근 방식으로 상대적으로 미미한 개선을 얻더라도 항상 그렇지는 않습니다 다른 영역이 CPU를 사용하지 못하게 할 수 있으므로 최선의 이익입니다. 어쩌면 그것은 선택 사항 일 수 있습니다.

나는 또한 Bullet 3의 dbvt 구현이 상당히 흥미롭다는 것을 알았습니다. 이 구현은 점진적 자체 균형 조정 및 선형 할당을 수행합니다. 이는 제가 더 연구하고 싶었던 것 중 하나입니다(이 접근 방식이 독점 엔진에서 구현되는 것을 본 적이 있어 언급할 수 없습니다 :P ). 알고리즘적으로 균형 잡힌 이진 트리는 설계상 옥트리보다 훨씬 덜 중복되며 페어링 및 폐색 테스트 모두에서 더 잘 작동할 수 있으므로 적절한 유용성을 고려하면 플러그형 브로드페이즈/컬링 접근 방식이 실제로 좋은 아이디어일 수 있습니다. 벤치마크 장면.

어쨌든, 당신은 매우 똑똑하고 우리가 이 문제에 대해 함께 일할 수 있다면 좋겠지만, 항상 당신의 취향에 맞지 않을지라도 우리가 가지고 있는 기존의 많은 디자인 철학을 이해하고 존중해 주기를 부탁드립니다. . 프로젝트는 거대하고 관성력이 강하며 취향을 위해 물건을 바꾸는 것은 좋은 생각이 아닙니다. 사용자 친화성과 "그냥 작동"은 디자인과 관련하여 항상 목록에서 첫 번째이며 코드의 단순성과 가독성은 일반적으로 효율성보다 우선합니다(즉, 영역이 중요하지 않기 때문에 효율성이 목표가 아닌 경우). 지난번에 우리가 논의했을 때, 당신은 거의 모든 것을 바꾸고 싶어했고 어떤 추론에 귀를 기울이거나 실제 문제에 집중하기를 원하지 않았습니다. 그리고 그것은 우리가 일반적으로 커뮤니티 및 기여자들과 협력하는 방식이 아닙니다. 좋은 의도.

성능이 필요한 사람은 누구입니까? :트롤페이스:

성능과 소스 모델은 저를 Godot와 함께 유지하는 것입니다.

편집: 죄송합니다. 주제를 벗어난 것일 수도 있지만 오픈 소스의 이점을 명확히 하고 싶었습니다.

@mixedCase 저는 Godot의 모든 종류의 포크를 지원하는 것을 매우 주저합니다. 포크와 단편화는 종종 오픈 소스 프로젝트의 죽음입니다.

나는 그렇게 생각하지 않는다. 오픈 소스의 본질은 코드를 원하는 대로 자유롭게 사용하고 재사용할 수 있다는 것입니다. 그래서 그것은 일부 프로젝트의 끝이 아니라 사용자를 위한 더 많은 옵션이 될 것입니다.
당신이 말하는 것은 독점이며 그것이 오픈 소스를 옹호하는 것이 아닙니다. 무언가를 완전히 통제하는 것이 더 낫다는 것을 보여주는 척하는 회사에 속지 마십시오. 그것은 거짓말입니다. 적어도 오픈 소스 세계에서는 다른 사람이 코드를 가지고 있다면 당신도 코드를 가지고 있기 때문입니다. 그들이해야 할 일은 커뮤니티를 처리하는 방법이나 그것에 대해 어떻게 괜찮을지 돌보는 것입니다.

어쨌든 원래 개발자는 포크의 개선 사항을 병합할 수 있습니다. 그들은 항상 그것을 할 자유가 있습니다. 그것이 오픈 소스 세계의 또 다른 특성입니다.

그리고 최악의 경우 포크가 원본보다 나을 것이며 많은 기여자가 거기에 갈 것입니다. 아무도 잃지 않고 모두 승리합니다. 아, 죄송합니다. 회사가 원본에 뒤처져 있으면 손실을 입을 수 있습니다(또는 포크의 개선 사항도 병합할 수 있음).