Yavaş çekimde bir çarpışma göstermek hesaplamalı olarak rahatlatıcı mı?


11

Bir çarpışma gerçekleşmek üzereyken birçok yarış oyununda ( örneğin Burnout Paradise ), oyun otomatik olarak yavaş harekete geçer ve çarpışma tamamlanana kadar yavaş bir şekilde devam eder.

Bunun etkiler için olduğunu hep düşündüm. Çarpışmanın herhangi bir bölümünü kaçırmak istemezsiniz! Ancak arkadaşlarımdan biri kısa süre önce bunun bir çarpışma olduğunda ezici bir işlem oranı olmadığından emin olmak için yapıldığını önerdi.

Şimdi bunun tam tersi olduğunu düşünüyorum. Bir çarpışma olduğunda, ağır çekimde çok fazla ayrıntı gösterilir, eminim bilgi işlem ve işleme boru hattında bir ek yük vardır.

Ne doğru?

Ağır çekim sahnesi CPU / GPU kullanımını artırır mı yoksa azaltır mı?

Yanıtlar:


4

Fizik simülasyonunuzu sabit bir zaman aralığıyla çalıştırıyorsanız (gerektiği gibi), yavaş hareket fizik simülasyonuna daha az yük koyacaktır, çünkü çerçeve başına daha az hesaplama yapılması gerekecektir.

Diyelim ki fizikinizi saniyede 200 güncelleme ile çalıştırıyorsunuz. Örneğin. 0.005simülasyon süresinin her saniyesinde bir güncelleme . Oyunu saniyede 50 güncellemeyle çalıştırdığınızda, render güncellemesi başına 4 fizik güncellemesine neden olur. Şimdi oyunu ağır çekimde çalıştıracaksınız, yani simülasyon süresini yavaşlatıyorsunuz. Oyun hala 0.02saniyede 50 güncellemede ( simülasyon süresi saniye) çalışıyorsa, ancak dünyayı yavaş çekimde (diyelim yarı hızda) gösteriyorsanız, bir kare 0.01simülasyon süresinin saniyesine eşdeğer olacaktır . Yani işlenen kare başına sadece 2 fizik güncellemesi. Yani, oluşturulan çerçeve başına daha az fizik hesaplamaları.

Dolayısıyla, oluşturulan çerçeve başına CPU kullanımı perspektifinden bakıyorsanız, yavaş hareket daha az CPU ağırdır (yavaş hareket sırasında fizik simülasyon oranınızı artırmayı seçmediğiniz sürece). Çerçeve başına GPU yükü elbette hemen hemen sabittir.

Bir çarpışma süresi boyunca kümülatif CPU / GPU yükünü soruyorsanız , fizik simülasyonu aynıdır, yavaş hareket veya normal hız. Daha fazla kare oluşturduğunuz için GPU yükü daha yüksek olacaktır.


İlk paragrafınız GPU yükünün daha yüksek olduğundan bahsediyor. GPU üzerindeki yükün doğrudan kare hızı ile ilişkili nispeten sabit veya daha iyi ifade edilmesini beklerdim (sahnenin içeriğinin değişmediği varsayılarak).
notlesh

Çarpışma başına daha yüksek olduğunu söyledi , ancak bunun nedeni çarpışmanın daha uzun sürmesi. İlk paragrafın son cümlesi söylediği gibi.
MichaelHouse

Ortalama durumda yüklerin hepsi aynı kalması gerektiğini düşünüyorum - kod her iki şekilde de aynı pasajlar üzerinden çalışacak ve böylece yaklaşık aynı yük olacak. Özel durumlarda, tüm çarpışma süresi boyunca gözlemlendiğinde CPU üzerindeki yükün yavaş hareket durumunda daha yüksek olacağını düşünürüm, çünkü çarpışma çözünürlükleri muhtemelen bir çeşit zaman adımı faktörü ile çalışacaktır. yavaş çekimde çok daha küçük (sonuçta ortaya çıkan çevirileri küçülterek), kare başına çarpışmaların algılanma olasılığını artırarak çözünürlükle sonuçlanır
TravisG

Bunu bir cevap olarak eklemiyorum, çünkü şu anda aklıma gelen şey bu ve bunu destekleyecek yavaş hareket sistemleri ile ilgili hiçbir veri veya gerçek deneyimim yok: P
TravisG

2
@ Byte56 Soru "Bir yavaş çekim sahnesi CPU / GPU kullanımını artırıyor mu?" Bu [neredeyse] kesinlikle çarpışma başına değil, zaman başına kullanım anlamına gelir. Bence GPU'nun cevabı değişmeden kalıyor. Bunu sadece gündeme getiriyorum çünkü ilk paragrafın ne aktarmaya çalıştığı belli değil.
notlesh

3

Öyle mümkün bundan kaynaklanabileceğini söyledi. GPU'daki çarpışma için fizik yapmadığınız sürece bunun için çömelme anlamına gelir. Ama fiziğin kendisi açısından ... mümkün.

Birkaç vücudun hareketini simüle ediyorsanız, bunlar çok öngörülebilir bir şekilde hareket etme eğilimindedir. Kuvvetler ve kuvvet alanları (yani, yerçekimi) kolayca tahmin edilebilir. Hareket eden yer hızla hesaplanır.

Bir şey diğerine çarpana kadar. Bakın, fizikte, zaman dilimi denen şeye sahipsiniz; bu, fizik sisteminin yürütülmesinin kapsadığı süredir. Zaman diliminiz saniyenin 1 / 30'unu kapsıyorsa (fizik güncellemesi için 30 fps), her fizik güncellemesi nesneleri 33,3 milisaniyeyi geleceğe taşır.

Nesneler çarpışmazsa, onları 33.3ms'in başından sonuna kadar taşıyabilirsiniz. Bunu yapmak için fizik basittir ve yüzyıllardır iyi bilinmektedir. Sadece net kuvvetlerden ivmeyi belirlersiniz, bu hızlandırmayı nesneye uygular ve yeni hızına taşırsınız (not: daha fazla doğruluk istiyorsanız bu daha karmaşık olabilir).

Sorun nesnelerin çarpışmasıdır. Aniden, şimdi süreç fizik kuvvetlere sahip olan yerine sadece bir kez başında daha bir timeslice. Bir nesne bir fizik çerçevesi içinde iki veya üç kez çarpışırsa , bu daha fazla fizik hesaplaması yapmalısınız.

Bir zaman diliminde çok fazla çarpışma yaşarsanız, kare hızınızı gerçekten öldürebilirsiniz. Bununla birlikte, zaman diliminin boyutu azaldıkça, bir zaman dilimi içinde birden çok çarpışma olasılığı azalır. Forza ve Gran Turismo gibi üst düzey yarış sims, fizik sistemlerini inanılmaz çerçevelerde çalıştırıyor. Bence bunlardan biri fizik güncellemelerinde 300 + fps'ye kadar çıkıyor.

Yavaş hareket bunun etkili eşdeğeridir. Fizik zaman dilimini telafi etmek için oluşturma çerçevesini de arttırmadan azaltarak, dünya daha yavaş görünür. Bu nedenle, bir zaman diliminde birden çok çarpışma yaşamanızı daha az olası hale getirirsiniz.

Bununla birlikte, bu gibi oyunların yavaş hareket etmesinin nedeni budur. Genel olarak, görsel yetenek ve dramatik sunum için daha çok. Bu fizik sistemleri genel olarak performansı akıllıca halledebilir.


1

Her şeyden önce, bu performans nedeniyle değil, görsel efekt için yapılır.

Ağır fizik oyunlarındaki performansla baş etmenin standart yolu, nesnelerin sayısını ölçeklendirmek, nesne karmaşıklığını ölçeklendirmek ve simülasyon hassasiyeti ile performans arasında ölçeklemek için motor ayarlarıyla uğraşmaktır. Sorun varsa, en az önemli özellikler olarak algıladığınız şeyi düşürürsünüz.

Bununla birlikte, endüstrinin son ~ 15 yıl boyunca oldukça gerçekçi araba oyunları yaptığını, modern bilgisayarlarla işleri çalıştırmak için 3 tekerleğe geri dönmek zorunda gibi görünmüyor.

Sorun:
Bir çarpışmanın fazladan çalışmaya neden olabileceği, oyunun özelliklerine ne kadar bağlı olduğu, daha ayrıntılı bir fizik motorunun farklı parçalar arasında gerekli hesaplamada önemli bir artış oluşturabilecek çok sayıda küçük çarpışma olacağı doğrudur. . Ancak fizik ölçeklendiğinde bu dikkate alınmalıdır, yine de bazı çarpışmaları kaldırabilecek iyi fizik elde etmek bir sorun değildir.

Ağır çekim elde etmek için fizik simülasyonunu daha yavaş çalıştırırsanız, yük orantılı olarak düşecektir. Bununla birlikte, yavaş hareket ve gerçek zamanlı fizik gereksinimlerinin farklı olduğunu unutmamak gerekir, yarış hızında şeyler olduğunda daha düşük hassasiyete sahip olabilirsiniz. Oyuncu fizik motorunun yanlış olduğunu fark etmediği sürece büyük bir sorun değildir, yavaş hareket fişlerin yakalanmasını çok kolaylaştırır, bu nedenle yavaş hareket daha yüksek hassasiyet gereksinimine sahiptir.

Her iki gereksinimi karşılayacak şekilde ölçeklendirilmiş aynı fiziği kullanmayı tercih edebilirsiniz. Bu çözüm biraz ekstra işlem gücü gerektirecektir, ancak uygulanması ve modern bilgisayarların mükemmel şekilde uygulanabilir olması kolaydır.

Fizik ayarlarının değiştirilmesi daha karmaşıktır, ancak potansiyel olarak bazı muhteşem çarpışmalara neden olabilir, sadece hassasiyeti arttırmakla kalmaz, aynı zamanda otomobillerin fizik modellerini daha gerçekçi bir şekilde kırılan daha ayrıntılı olanlar için değiştirmek de mümkündür. Bu mod, fizik için normal modla yaklaşık aynı miktarda CPU zamanı kullanmalıdır, çünkü her ikisi de aynı minspec yapılandırmasında çalışacak şekilde ölçeklendirilmiştir.

Orta yol, değişken adım fizik motoru kullanmaktır, bunlar simülasyonu yavaşlattığınızda genel olarak hassasiyeti artıracak ve böylece sorunun en azından bir kısmını çözecektir. Değişken basamak fiziği kullanmamanın başka nedenleri de vardır, ancak değişken adım endüstride hala oldukça yaygındır.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.