การแก้ไขเฟรมอย่างที่ใช้โดย SmoothVideo Project เป็นตัวเลือกในการเพิ่มจำนวนเกมโดยไม่กระทบกับประสิทธิภาพหรือไม่?


11

โครงการ SmoothVideo ใช้การสอดแทรกเฟรมภาพต่อวินาทีเพื่อเพิ่มวิดีโอจาก 24 ถึง 60 ผลเป็นที่น่าประทับใจสวย ฉันสงสัยว่าสามารถใช้กับสิ่งนี้ได้หรือไม่และจะดูดีในวิดีโอเกมหรือไม่

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

บางทีความล่าช้านี้อาจทำให้มันไม่เหมาะกับเกมบุคคลที่ผ่านมาเร็ว แต่ฉันสงสัยว่ามันจะเป็นอุปสรรคในเกมที่เล่นช้ากว่า

ความล่าช้าจะลดลงที่อัตราเริ่มต้นที่สูงขึ้นดังนั้นฉันคิดว่ามันจะคุ้มค่าอย่างแน่นอนเมื่อไปจาก 60fps ถึง 100 + fps ซึ่งปรับปรุงประสบการณ์แม้ว่าจะเพิ่มขึ้นเล็กน้อยในขณะที่การเก็บภาษีบนระบบมาก


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

คำตอบ:


6

ระบบตามบรรทัดเหล่านี้ถูกนำมาใช้ในแรงสะใจ ฉันไม่ทราบชื่ออื่นที่เคยใช้


1
ขอบคุณสำหรับข้อมูล. พบสิ่งพิมพ์ในนั้น: dl.acm.org/citation.cfm?id=1837047ดูเหมือนว่าจะประสบความสำเร็จดังนั้นทำไมจึงไม่เห็นการใช้งานที่กว้างขึ้น?
cybrbeast

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

1
อ้างอิงจากบทความนี้โดยใช้การประมาณการทำนายที่วิธีการนั้นสามารถลดความล่าช้าได้จริง! eurogamer.net/articles/ ......ดังนั้นจึงน่าจะดีกว่าในทุกเมตริก แต่จะต้องมีบางสิ่งที่ขาดหายไปเพราะคุณคิดว่ามันจะถูกใช้ทุกที่ถ้านี่เป็นเรื่องจริง
cybrbeast

@David: บทความหมายความว่ามันลดความหน่วงแฝงที่เห็นได้ชัดเมื่อเปรียบเทียบกับการทำงานที่ 30 fps สำหรับอินพุตบางประเภท การวิ่งด้วยความเร็ว 60 เฟรมต่อวินาทีนั้นยังคงดีกว่าเมื่อเป็นไปได้ (เวลาแฝงที่ดีขึ้นและไม่มีการแก้ไขส่วน), devs จำนวนมากพิจารณาว่าเป้าหมายตัวเลือกแรกของพวกเขา เมื่อเกมไม่สามารถเข้าถึง 60 fps ได้มันไม่ได้มีเวลาเพียงพอหรือมีงบประมาณเหลือพอที่จะเขียนระบบการแก้ไขเพื่อทำให้ช่องว่างราบรื่น - ระบบนี้ค่อนข้างซับซ้อนและในกรณีของ TFU นั้นได้รับความช่วยเหลือจากบางส่วนของการเรนเดอร์ แชร์โดยทุกเกม
DMGregory

ฉันพยายามพูดได้ดีกว่าในทุกเมตริกเมื่อเทียบกับ 30 เฟรมต่อวินาทีที่ไม่ได้เสริมประสิทธิภาพไม่แสดง 60fps
cybrbeast

9

ใช่เป็นไปได้ แต่ไม่ได้โดยไม่มีภาวะแทรกซ้อน

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

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


ปฏิกิริยาใด ๆ ต่อวิธีการแก้ไขที่ชาญฉลาดนี้กล่าวถึงด้านล่างซึ่งอ้างว่าป้องกันการแฝงที่เพิ่มขึ้น? eurogamer.net/articles/…
cybrbeast

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

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

2

ใช่นี้เป็นไปไม่ได้เท่านั้น แต่ใช้ได้ในขณะนี้: ขอขึ้นเกม PC / คอนโซลกับทีวีที่ใช้การสอดแทรกการเคลื่อนไหว ความคิดเห็นแตกต่างกันไปและสิ่งนี้ไม่เหมาะสำหรับเกม Twitch เช่น FPS เนื่องจากการแก้ไขล่าช้า แต่สำหรับการลดอัตราเฟรมจาก 60 เป็น 120Hz จะทำงานได้ดี

สำหรับสิ่งที่สามารถทำได้ในเกมนั้นมีแรงกระตุ้นไม่เพียงพอในการที่จอภาพส่วนใหญ่ไม่สามารถส่งออกอัตราเฟรมที่สูงเหล่านั้น จอภาพ 120 + Hz สำหรับคอมพิวเตอร์นั้นมีอยู่ทั่วไปน้อยกว่าแม้ว่าจะตัดสินจากการที่ทีวีกำลังดำเนินไป แต่สิ่งนี้อาจเกิดขึ้นในไม่ช้า การมีตัวตรวจสอบอัตราการรีเฟรชที่สูงมีข้อได้เปรียบแม้ว่าเกมจะไม่สามารถเข้าถึงอัตราเฟรมเหล่านั้นได้: นอกเหนือจากการแก้ไขการเคลื่อนไหวบนทีวีดังที่กล่าวมาแล้วมันสามารถให้เฟรมที่นุ่มนวลขึ้นได้ up ala v-sync เมื่อจอมอนิเตอร์ 120 + Hz เป็นเรื่องธรรมดาฉันคาดหวังว่านักพัฒนาเกมจะสามารถใช้เทคนิคมากขึ้นรวมถึงการแก้ไขการเคลื่อนไหวเพื่อให้ได้อัตราเฟรมที่สูง


3
ประสบการณ์ของฉันคือระบบเหล่านี้มีความล่าช้าในการป้อนข้อมูลสูงเช่น 200 + ms (12+ เฟรมที่ 60fps) นี่คือเหตุผลที่ทีวีเหล่านั้นมี "โหมดเกม" ที่ปิดใช้งานคุณสมบัตินั้น
BlueRaja - Danny Pflughoeft

0

ความล่าช้าระหว่างเมื่อผู้ใช้ทำบางสิ่งและเมื่อผลลัพธ์ปรากฏบนหน้าจอไม่ควรเกิน 100ms มิเช่นนั้นผู้ใช้อาจสังเกตเห็นความล่าช้า

จอภาพของผู้ใช้อาจใช้เวลาประมาณ 30 ms เพื่อแสดงรูปภาพที่ได้รับ มีจอภาพที่เร็วกว่ามาก แต่ผู้ใช้โดยเฉลี่ยจำนวนมากไม่มีสิ่งเหล่านี้ หากการ์ดวิดีโอคำนวณ 30 เฟรมต่อวินาทีมันจะใช้เวลา 33 ms ในการคำนวณเฟรม ฉันถือว่า 30 เฟรมต่อวินาทีเพราะเราไม่ต้องการการแก้ไขเฟรมหากเกมรันที่ 60 เฟรมต่อวินาที ถ้าเราใช้การบัฟเฟอร์สามเท่าสิ่งนี้จะเพิ่มเป็น 66 ms นั่นคือ 90 มิลลิวินาที

ฉันคิดว่าเราต้องการบัฟเฟอร์สามเท่าสำหรับการแก้ไขเฟรมเพื่อให้เหมาะสม ดังนั้นหากเราใช้การแก้ไขเฟรมด้านบนเพื่อรับ 60 fps เราจะเพิ่มการหน่วงเวลาโดยเฟรม 60Hz หนึ่งเฟรมซึ่งเป็นอีก 17 มิลลิวินาที + เวลาการแก้ไข X นำเราไปที่ 107 ms + X ปัญหาไม่ใช่การแก้ไขเช่น เช่นนี้ แต่ความจริงที่ว่าเราอยู่ใกล้กับจุดที่เห็นความหน่วงแฝงอยู่ก่อนที่เราจะแนะนำการแก้ไข

อาจเป็นเรื่องดีสำหรับเกมที่ส่วนใหญ่เป็นภาพยนตร์เสมือนจริง แต่ใน FPS ผู้ใช้จะสังเกตเห็นว่ามีบางอย่างผิดปกติกับการเล็ง

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