게임 장면 그래프에는 무엇이 포함되어야합니까?

게임 장면 그래프에 정확히 무엇이 포함되어야 하는지 명확히 설명해 주시겠습니까 ? 다음 목록을 참조하십시오 :

• 게임 배우? (물론 예, 모든 객체 변경 상태는 장면 그래프의 주요한 프리트이어야합니다)
• 간단한 정적 게임은? (배경에서 애니메이션되지 않은 장소 나 충돌하지 않는 장소를 의미 함)
• 게임 트리거?
• 게임 조명?
• 게임 카메라?
• 무기 총알?
• 게임 폭발과 특수 효과?

위에서 고려한 객체 유형. 이제 장면 그래프 의 적용 범위입니다.

• 레벨 시작 이후 장면 그래프에 게임 레벨 맵 전체가 포함되어야합니까 , 아니면 맵 의 보이는 부분 만 포함해야 합니까? 두 번째가 참이면 플레이어가 움직일 때 게임 객체를 추가 / 제거하여 장면 그래프가 지속적으로 업데이트됨을 의미합니다. 그러나 가시적 인 맵만 포함하면 통과하고 업데이트하는 것이 훨씬 빠릅니다.

다른 장면 그래프 기술이 무엇을하고 있는지 잘 읽어 보면 많은 이점을 얻을 수 있다고 생각합니다.

배경
예를 들어, Ogre3D 설명을보십시오. 오픈 소스 인 장면 그래프 기반 그래픽 엔진입니다. 튜토리얼을보고 씬 노드가 어떻게 사용되는지 봅니다 (참고 : 오우거 사용 방법을 배우는 것이 아니라, 오우거의 씬 노드 및 씬 관리자에 어떤 기능이 있는지 알려 드리지 않았습니다)

SceneNode 설명서 :
http://www.ogre3d.org/docs/api/1.9/class_ogre_1_1_scene_node.html

SceneManager 설명서 : http://www.ogre3d.org/docs/api/1.9/class_ogre_1_1_scene_manager.html

다른 가치가있는 것은 다음 링크입니다 :
http://sgl.sourceforge.net/#features

OpenGL 기반 장면 그래프 솔루션이며 기능 페이지에는 포함 할 수있는 모든 노드가 표시됩니다.

제안 된 노드
씬 그래프는 게임 로직에서 최대한 추상화되어야하므로 의존성 문제가 없다고 생각합니다. 각 글 머리 기호에 대해 다음과 같이 말합니다.

게임 배우는
아마 아니오라고 말할 것입니다. 오우거와 마찬가지로 기본 Entity 클래스 (객체 별 논리 포함)와 Entity 멤버 포인터가있는 기본 SceneNode를 사용하여 객체를 렌더링하기위한 적절한 정보를 얻습니다 (위치, 방향 등)

편집 : 여기 장면 그래프에 게임 배우를 포함시키지 말라고 말하는 것이 아닙니다 (그렇지 않으면 아무것도 표시되지 않습니다 : P) 논리적 게임 배우 클래스를 참조하는 장면 노드가 있다고 말하고 있습니다. 게임 오브젝트의 렌더링과 업데이트가 느슨하게 결합되었습니다.

간단한 정적 게임 ojbects
예

게임 트리거?
아니요, 이것은 게임 고유의 논리처럼 들립니다.

게임 조명?
예

게임 카메라?
예

무기 총알?
이것에 대해 완전히 확신하지는 못하지만 아마도 예라고 말할 것입니다. 그러나 "BulletCollection"부모 장면 노드에 대한 모든 글 머리 기호를 원할 것입니다. 그래서 그 위치를 캐시 할 수 있으므로 장면 그래프를 많이 제거하고 렌더링 할 글 머리 기호를 추가합니다.

게임 폭발과 특수 효과?
확실하지 않습니다, 나는 다른 사람이 그 대답을하도록 할 것입니다.

장면 그래프 범위
상대적으로 작은 레벨 인 경우 전체 레벨을 장면 그래프에 저장 한 다음 Octree (일반적으로 실외 환경) 또는 BSP 트리 (일반적으로 실내 환경)를 사용하여 가시성을 최적화 할 수 있어야합니다.

레벨이 훨씬 높고 레벨로드를 원하지 않는 경우 스트리밍이 시작되는 곳이지만 이는 또 다른 문제입니다. 작은 수준부터 시작하여 성능에 부정적인 영향을 미치지 않으면 서 얼마나 크게 만들 수 있는지 점진적으로 확인합니다.

결론
장면 그래프는 게임 루프의 렌더링 부분입니다. 렌더링과 논리 업데이트를 너무 밀접하게 결합해서는 안됩니다. 그렇지 않으면 성가신 종속성 문제가 발생할 수 있습니다.

내 성향은 장면 그래프 에 적은 수의 물건을 넣는 것이 좋습니다 . Tom Forsyth가 쓴이 기사를 참조하십시오 : " 장면 그래프-그냥 말하지 마십시오 ."

Forsyth의 기사의 핵심은 하나의 큰 마스터 데이터 구조에 관련되지 않은 많은 것들을 넣지 말아야한다는 것입니다. 이것은 게임의 모든 것을 파생시킨 다음 하나의 큰 이기종 목록 (즉, 나쁘다)으로 모든 것을 밀어 넣는 것과 관련 하여이 답변에서 만진 아이디어와 매우 유사합니다 GameObject.

세계에서 나무 구조에 적합한 부모-자녀 관계를 보여주는 개체는 거의 없습니다. 테이블에있는 커피 잔의 표준 예가 여기에서 일반적으로 사용됩니다. 물론 적어도 테이블이 떨어져 나올 때까지 테이블의 '자식'이라고 생각할 수 있습니다. 그렇다면 여전히 테이블의 자식입니까? 이것은 당신의 '트리'가 어쨌든 목록에 대해 매우 얕고 변질 될 수 있음을 의미합니다.

따라서 여러 가지에 대해 여러 데이터 구조를 사용하는 것이 좋습니다. 예를 들어 정적 지오메트리와 조명은 장면 그래프에 넣는 것이 합리적인 것처럼 보입니다. 표현 된 객체에 자연스러운 부모-자식 관계가없는 경우에도 정적이라는 사실은 구조적 부모-자식 관계를 통해 절대 변하지 않는 것을 알 수 있습니다.

게임 배우 ... 잘 모르겠어요. 실제로 움직이는 경향이있는 것은 대개 그래프의 근본 근처에 두거나 지속적으로 부모를 돌봐야한다는 것을 의미합니다 (이것은 매우 효율적이지 않습니다).

총알, 방아쇠, 특수 효과 및 다른 곳에 저장할 다른 과도 물체. 렌더링하거나 시각적으로 표현하는 것은 없습니다 (트리거는 일반적으로 보이지 않는 경계 볼륨, 글 머리 기호는 보통 레이 캐스트 임)는 렌더링 그래프에 없어야합니다. 렌더 레이어와 로직 레이어를 분리하려고 노력해야합니다 .

가치있는 것을 위해, 나는 비 학문적 인 용도로 구축 한 렌더러에서 트리와 같은 장면 그래프를 사용한 적이 없습니다 (분명히 전에 트리와 같은 장면 그래프를 만들었습니다. 지금 동의하려고합니다).

게임 스타일에 적합한 공간 분할 방법 (쿼드 트리, 옥트리, BSP 등)을 사용하여 (a)이 프레임을 처리하고 (b) 렌더링해야하는 논리 엔티티를 게임에서 그룹화 / 컬링합니다. 이 프레임. 그런 다음 목록 (b)에서 객체 집합을 논리적 객체를 매핑하여 설명을 렌더링하는 시스템으로 공급하고 속성을 기반으로 해당 설명을 버킷으로 정렬합니다 (예 : 투명도를 사용하는 모든 항목은 "stuff" 그런 다음 모든 버킷을 순서대로 렌더링하고 각 버킷에 대해 모든 설명을 순서대로 렌더링합니다. "트리"라고 부를 수는 있지만 일반적인 상태는 표시하지 않습니다. 전통적인 트리 지향 장면 그래프가하는 전파 전파 방법 YYMV,