게임에서 그래픽과 물리 엔진간에 데이터를 공유해야합니까?


9

몇 개의 모듈로 구성된 게임 엔진을 작성 중입니다. 그 중 두 가지는 그래픽 엔진물리 엔진 입니다.

데이터를 공유하는 것이 좋은 솔루션인지 궁금합니다.

두 가지 방법 (공유 여부)은 다음과 같습니다.

데이터를 공유하지 않고

GraphicsModel{
    //some common for graphics and physics data like position

    //some only graphic data 
    //like textures and detailed model's verticles that physics doesn't need
};

PhysicsModel{
    //some common for graphics and physics data like position

    //some only physics data 
    //usually my physics data contains A LOT more informations than graphics data
}

engine3D->createModel3D(...);
physicsEngine->createModel3D(...);

//connect graphics and physics data 
//e.g. update graphics model's position when physics model's position will change

두 가지 주요 문제가 있습니다.

  1. 많은 중복 데이터 (물리 및 그래픽 데이터의 두 위치와 같은)
  2. 데이터 업데이트 문제 (물리 데이터가 변경 될 때 그래픽 데이터를 수동으로 업데이트해야 함)

데이터 공유

Model{
     //some common for graphics and physics data like position
};

GraphicModel : public Model{
    //some only graphics data 
    //like textures and detailed model's verticles that physics doesn't need
};

PhysicsModel : public Model{
     //some only physics data 
    //usually my physics data contains A LOT more informations than graphics data
}

model = engine3D->createModel3D(...);
physicsEngine->assingModel3D(&model); //will cast to 
//PhysicsModel for it's purposes??

//when physics changes anything (like position) in model 
//(which it treats like PhysicsModel), the position for graphics data 
//will change as well (because it's the same model)

여기에 문제가 있습니다 :

  1. physicsEngine은 engine3D에서 기존 객체를 "어셈블"하는 것만으로 새로운 객체를 생성 할 수 없습니다 (어떻게 든 더 독립적 인 것처럼 보입니다)
  2. assingModel3D 함수에서 데이터 캐스트
  3. physicsEngine 및 graphicsEngine은주의해야합니다. 데이터가 필요 없을 때는 데이터를 삭제할 수 없습니다 (두 번째 데이터가 필요할 수 있기 때문에). 그러나 드문 상황입니다. 또한 객체가 아닌 포인터를 삭제할 수 있습니다. 또는 graphicsEngine이 객체를 삭제한다고 가정 할 수 있으며 physicsEngine은 객체에 대한 포인터 일뿐입니다.

어느 쪽이 더 낫습니까?

앞으로 어떤 문제가 더 많이 발생합니까?

나는 두 번째 솔루션을 더 좋아하지만 대부분의 그래픽 및 물리 엔진이 왜 첫 번째 엔진을 선호하는지 궁금합니다.

더 이상 숨겨진 장점과 대조가 있습니까?


정확히 내 질문도.
danijar

답변:


9

요즘에는 더 많은 게임 엔진이 컴포넌트 디자인 (예 : Unity, Unreal)을 채택하고 있습니다. 이러한 종류의 디자인에서 a GameObject는 구성 요소 목록으로 구성됩니다. 상황 에 따라 단일 게임 오브젝트에 a MeshComponent및 a PhysicalComponent가 모두 첨부 될 수 있습니다 .

간단히하기 위해 월드 변환 변수를에 넣을 수 있습니다 GameObject. 업데이트 문구 중 PhysicalComponent월드 변환을 해당 변수로 출력합니다. 렌더링하는 동안 MeshComponent해당 변수를 읽습니다.

이 설계의 근거는 구성 요소를 분리하는 것입니다. 어느 쪽 MeshComponentPhysicalComponent서로를 알지 못한다. 그들은 단지 공통 인터페이스에 의존합니다. 또한 단일 상속 계층 구조를 사용하는 것보다 구성별로 시스템을 확장하는 것이 더 쉬울 수 있습니다.

그러나 실제 시나리오에서는 물리 / 그래픽 동기화간에보다 정교한 처리가 필요할 수 있습니다. 예를 들어, 물리 시뮬레이션은 고정 시간 단계 (예 : 30Hz)로 실행해야하지만 렌더링은 가변적이어야합니다. 물리 엔진의 출력 결과를 보간해야 할 수도 있습니다. 일부 물리 엔진 (예 : Bullet)은이 문제를 직접 지원합니다.

Unity는 구성 요소에 대한 좋은 참조를 제공했으며 살펴볼 가치가 있습니다.


이것은 전혀 질문에 대한 답이 아니며, 2 개의 컴포넌트가 메시 데이터를 공유하는지 여부에 대해 아무 것도 말하지 않습니다.
Maik Semder

2
실제로, 그것은 더 나은 디자인을 제공하며, 이는 완전히 합법적입니다.
jcora

7

엔진은 품질과 수량면에서 매우 다른 데이터가 필요하기 때문에 일반적으로 첫 번째 옵션 (자체 물리 메시와 자체 렌더 메시)을 선택합니다.

물리 엔진은 텍스처 좌표, 일반 그룹 및이 모든 멋진 렌더링 작업에 신경 쓰지 않기 때문에 품질. 그들 각각은 정렬 문제, 패킹, 데이터의 인터리빙 등과 같은 매우 구체적인 레이아웃의 데이터를 기대합니다 .

물리 메쉬는 일반적으로 삼각형이 적으므로 고해상도 렌더 메쉬의 단순화 된 버전입니다.

둘 다를 분리함으로써 우리는 다른 것을 손상시키지 않고 더 나은 성능을 위해 데이터 레이아웃을 변경하는 것을 포함하여 하나를 tweek 할 수 있습니다. 확장 성이 훨씬 뛰어납니다.


0

@Millo Yip의 훌륭한 답변 외에도 Controls 모듈 및 AI 모듈과 동일한 데이터를 공유해야하며 실수하지 않는 경우 대부분의 오디오 라이브러리는 사운드 방출기의 위치에 대한 개념을 가지고 있음을 상기시키고 싶습니다. 따라서 해당 모듈과 데이터를 공유해야합니다.


0

다른 사람들이 말했듯이 물리학에서 내부 데이터 상태는 렌더링 엔진의 내부 데이터 상태와 별도로 관리되는 것이 일반적입니다. 물리 및 렌더러 블과 별도로 저장된 변환 데이터 (위치 / 방향 / 스케일)조차도 흔히 볼 수 있습니다. 물리에 의해 부과되거나 렌더링되지는 않지만 다른 역학에 대한 월드 위치가 필요한 게임 오브젝트가있을 수 있기 때문입니다.

물리에서 렌더링 가능으로 데이터를 가져 오는 방법은 전적으로 귀하에게 달려 있습니다.

이벤트 / 메시지를 사용하여 서브 시스템 간 디스패치 프로세스를 통해이를 수행 할 수 있습니다. 물리가 특정 렌더링 가능 위치를 간단하게 설정할 수 있도록 렌더링 하위 시스템의 공용 인터페이스를 물리 하위 시스템에 노출하여이를 수행 할 수 있습니다. 또 다른 옵션은 렌더링 가능한 하위 시스템이 업데이트 중에 변환에 대해 엔터티를 쿼리하고 렌더링 가능한 구성 요소의 위치를 ​​업데이트 한 다음 그리기를 수행하는 것입니다.

당연히 게임에 따라 이러한 수단 중 일부는 다른 캐시보다 캐시 친화적이며 성능이 향상됩니다. 이 시점에서 특정 방식으로 너무 많이 잡지 않고 의사 소통 패턴을 선택하여 시도해보십시오. 나중에이 부분을 쉽게 재 작업하여 다양한 최적화 수단을 테스트 할 수 있습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.