ฉันควรแชร์ข้อมูลระหว่างกราฟิกและเอนจิ้นฟิสิกส์ในเกมหรือไม่


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 ไม่สามารถสร้างวัตถุใหม่เพียงแค่ "assing" วัตถุที่มีอยู่จาก engine3D (อย่างใดก็ดูต่อต้านฉันขึ้นสำหรับฉัน)
  2. กำลังส่งข้อมูลในฟังก์ชัน assingModel3D
  3. ฟิสิกส์เครื่องยนต์และกราฟิกเครื่องยนต์ต้องระวัง - พวกเขาไม่สามารถลบข้อมูลเมื่อพวกเขาไม่ต้องการพวกเขา (เพราะคนที่สองอาจต้องการมัน) แต่มันเป็นสถานการณ์ที่หายาก ยิ่งไปกว่านั้นพวกเขาสามารถลบตัวชี้ไม่ใช่วัตถุ หรือเราสามารถสันนิษฐานได้ว่ากราฟฟิกเอ็นจินจะลบวัตถุออกฟิสิกส์เอนจินเพียงแค่ชี้ไปที่มัน

ทางไหนดีกว่ากัน?

สิ่งใดจะทำให้เกิดปัญหามากขึ้นในอนาคต

ฉันชอบโซลูชันที่สองมากกว่า แต่ฉันสงสัยว่าทำไมเครื่องมือกราฟิกและฟิสิกส์ส่วนใหญ่จึงต้องการโซลูชั่นแรก (อาจเป็นเพราะพวกเขามักจะสร้างเฉพาะกราฟิกหรือเครื่องยนต์ฟิสิกส์เท่านั้น

พวกเขามีข้อดีและข้อด้อยที่ซ่อนอยู่อีกหรือไม่


คำถามของฉันเช่นกัน
danijar

คำตอบ:


9

ทุกวันนี้เอ็นจิ้นเกมเพิ่มเติมมีการออกแบบส่วนประกอบ (เช่น Unity, Unreal) ในการออกแบบชนิดนี้ a GameObjectประกอบด้วยรายการส่วนประกอบ ในสถานการณ์ของคุณอาจมีMeshComponentและ a PhysicalComponentติดกับวัตถุเกมเดียว

เพื่อความง่ายคุณสามารถเปลี่ยนโลกให้เป็นตัวแปรGameObjectได้ ในระหว่างการอัปเดตวลีPhysicalComponentผลลัพธ์ของโลกจะเปลี่ยนเป็นตัวแปร ในระหว่างการเรนเดอร์การMeshComponentอ่านตัวแปรนั้น

เหตุผลที่อยู่เบื้องหลังการออกแบบนี้คือการแยกระหว่างองค์ประกอบ ทั้งMeshComponentมิได้PhysicalComponentรู้ซึ่งกันและกัน พวกมันขึ้นอยู่กับอินเตอร์เฟสทั่วไป และสามารถขยายระบบโดยการจัดองค์ประกอบได้ง่ายกว่าการใช้ลำดับชั้นเดียวของการสืบทอด

อย่างไรก็ตามในสถานการณ์ที่เป็นจริงคุณอาจต้องการการจัดการที่ซับซ้อนมากขึ้นระหว่างการซิงโครไนซ์กับฟิสิกส์ / กราฟิก ตัวอย่างเช่นการจำลองทางฟิสิกส์อาจต้องดำเนินการในขั้นตอนเวลาที่แน่นอน (เช่น 30Hz) ในขณะที่การแสดงผลจะต้องเป็นตัวแปร และคุณอาจจำเป็นต้องสอดแทรกผลลัพธ์จากผลลัพธ์ของเอนจินฟิสิกส์ เอนจิ้นฟิสิกส์บางตัว (เช่น Bullet) ได้รับการสนับสนุนโดยตรงจากปัญหานี้

ความสามัคคีให้การอ้างอิงที่ดีของส่วนประกอบของตนซึ่งน่าดู


สิ่งนี้ไม่ได้ตอบคำถามเลยการมี 2 องค์ประกอบไม่ได้บอกอะไรเลยว่าพวกเขาแบ่งปันข้อมูลตาข่ายหรือไม่
Maik Semder

2
ที่จริงแล้วมันมีการออกแบบที่ดีกว่าซึ่งถูกต้องตามกฎหมายอย่างสมบูรณ์
jcora

7

เอ็นจิ้นมักจะเลือกตัวเลือกแรก (ฟิสิกส์ของตัวเองและตาข่ายของตัวเอง) เพราะพวกเขาต้องการข้อมูลที่แตกต่างกันมากทั้งด้านคุณภาพและปริมาณ

คุณภาพเนื่องจากเอ็นจิ้นฟิสิกส์ไม่สนใจเกี่ยวกับพิกัดพื้นผิวกลุ่มปกติและสิ่งต่าง ๆ ที่มีจินตนาการเช่นนี้ แต่ละคนคาดว่าข้อมูลในรูปแบบที่เฉพาะเจาะจงมากลงมาถึงปัญหาการจัดตำแหน่งการบรรจุการแทรกข้อมูล ฯลฯ

ปริมาณเนื่องจากตาข่ายฟิสิกส์มักจะมีรูปสามเหลี่ยมน้อยลงวิธีการเรนเดอร์รุ่นที่มีความละเอียดสูงก็ง่ายขึ้น

โดยการแยกทั้งสองเราทำให้แน่ใจว่าเราสามารถทวีคูณหนึ่งรวมถึงการเปลี่ยนเค้าโครงข้อมูลเพื่อประสิทธิภาพที่ดีขึ้นโดยไม่ทำให้คนอื่นเสียหาย มันเป็นวิธีที่ปรับขนาดได้มากขึ้น


0

นอกจาก @Millo Yip คำตอบที่ดีฉันอยากจะเตือนคุณว่าคุณจะต้องแบ่งปันข้อมูลเดียวกันกับโมดูลการควบคุมและโมดูล AI และถ้าฉันไม่ผิดห้องสมุดเสียงส่วนใหญ่มีความคิดของตำแหน่งของตัวเปล่งเสียง ดังนั้นคุณจะต้องแชร์ข้อมูลกับโมดูลนั้นด้วย


0

อย่างที่คนอื่น ๆ พูดกันมันเป็นเรื่องธรรมดาที่ฟิสิกส์มีสถานะข้อมูลภายในถูกจัดการแยกจากสถานะข้อมูลภายในของเอ็นจิ้นการเรนเดอร์ เป็นเรื่องปกติที่จะเห็นแม้แต่ข้อมูลแปลง (ตำแหน่ง / ทิศทาง / สเกล) ที่จัดเก็บแยกต่างหากจากทั้งฟิสิกส์และเรนเดอร์เบิลเพราะเป็นไปได้ว่ามีวัตถุเกมซึ่งไม่ได้ถูกกำหนดโดยฟิสิกส์หรือแสดงผล แต่ต้องการตำแหน่งโลก

ข้อมูลที่ได้จากฟิสิกส์จนถึงเรนเดอร์นั้นขึ้นอยู่กับคุณทั้งหมด

คุณสามารถทำได้ผ่านกระบวนการส่งสัญญาณระหว่างระบบย่อยโดยใช้กิจกรรม / ข้อความ คุณสามารถทำได้โดยการเปิดเผยอินเตอร์เฟสสาธารณะของระบบย่อยการเรนเดอร์ไปยังระบบย่อยทางฟิสิกส์เพื่อให้ฟิสิกส์สามารถตั้งค่าตำแหน่งของเรนเดอร์ที่สามารถแสดงออกได้โดยเฉพาะ อีกตัวเลือกหนึ่งคือระบบย่อยที่สามารถเรนเดอร์ทำการสอบถามเอนทิตีสำหรับการแปลงระหว่างการอัพเดตและทำการอัพเดตตำแหน่งขององค์ประกอบที่สามารถเรนเดอร์แล้วตามด้วยการวาด

โดยธรรมชาติแล้วขึ้นอยู่กับเกมของคุณสองสามวิธีนี้จะเป็นมิตรกับแคชมากขึ้นและมีประสิทธิภาพที่ดีกว่าคนอื่น ๆ ฉันจะไม่ติดอะไรมากในตอนนี้และเลือกรูปแบบการสื่อสารแล้วลองทำ คุณสามารถทำใหม่ในส่วนนี้ได้ในภายหลังเพื่อทดสอบวิธีการต่าง ๆ เพื่อการปรับให้เหมาะสม

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.