endnu en artikel om, hvornår du skal bruge metoderne opdatering og rettet opdateret.
td;LR: efter at have ret let genskabt problemet med at blande og matche timesteps, har jeg overbevist mig selv om, at jeg skulle sætte al spiltilstand i faste opdateringsmetoder.
før du kommer ind i indholdet af denne artikel, ønskede at præcisere, hvorfor jeg er interesseret i enhed i første omgang:
- jeg har ikke meget interesse i hverken at spille eller skabe videospil
- jeg har en interesse i at opbygge nyttige værktøjer (været en internetudvikler i mange år)
- jeg er ikke en tidlig adopter
- Unity er en veletableret løsning til at skabe multi-platform 3D-oplevelser
med alt dette i tankerne er opbygning af praktiske Netdrevne Augmented Reality (AR)-løsninger med Unity noget, jeg har brug for at lære.
hvad angår læring af enhed, fandt jeg ikke særlig de officielle Unity-tutorials nyttige. Jeg fandt Udemy course Learn Unity 3D for absolutte begyndere at være fremragende.
Jeg kørte gennem materialerne og fandt mig selv hængt på lektionsforskellen mellem opdatering og rettet opdatering. Forsker lidt mere, kernen i problemet var, at jeg ikke forstod følgende begrundelse.
opdatering (); … bruges til regelmæssige opdateringer såsom: flytning af ikke-fysiske objekter
Fastopdatering ();… bruges til regelmæssige opdateringer såsom: Justering af fysik (Rigidbody) objekter
Unity — Update and Fastedupdate — Unity officielle Tutorials
lidt mere forskning dukkede op:
afslutningsvis skal du sætte al din spillogik i enten opdatering eller Fastopdatering. Bland ikke Og match timesteps, medmindre du er villig til at bide kuglen og acceptere noget stamme. Derudover, det er stærkt værd at overveje at sætte all game state I Fastopdatering, ved hjælp af opdatering udelukkende til brugerinput, visuelle effekter, og interpolation mellem spiltilstande. Selvom dette kræver en ændring, hvordan du strukturerer dine spil, det er en gennemprøvet designstruktur med mange fordele.
— KinematicSoup — Timesteps og opnå jævn bevægelse i enhed
et videoklip i artiklen illustrerer problemet med at blande og matche timesteps.
før jeg fulgte dette råd, ønskede jeg at genskabe problemet med at blande og matche timesteps alene.
den endelige version af projektet, som jeg brugte til at skrive denne artikel, kan hentes.
opdatering Versus Fastopdatering
Vi skal starte med en grundlæggende forståelse af forskellen mellem opdaterings-og Fastopdateringsmetoderne. For at illustrere opretter vi et tomt GameObject kaldet Setup og tilføjer følgende script-komponent:
aktiver/Setup.cs (ufuldstændig)
vores konsoludgang efter 3 sekunder lignede:
observationer:
- opdatering kaldes før hver gengivelse; frekvensen (billedhastighed) varierer afhængigt af kompleksiteten af gengivelsen og værtsenheden. Kraftige computere kan opnå billedhastigheder på over 150fps; min udviklingscomputer kørte omkring 50fps. Under 30 fps, anses for at være en dårlig oplevelse.
- Fastopdatering kaldes før hver intern fysikopdatering (flytning af ting på grund af fysik, f.eks. Unitys faste timestep er som standard 0,02; fører til, at Fastopdatering kaldes 50 gange i sekundet.
Simuler langsom billedhastighed
for at simulere en langsom billedhastighed (10 FPS) opdaterer vi opsætningen.cs script som følger:
aktiver / opsætning.cs (ufuldstændig)
vores konsoludgang efter 3 sekunder lignede:
observationer:
- indstilling af vsynccount til 0 deaktiverer enhed fra synkronisering af gengivelser og skærmopdateringshastigheder.
- den faktiske billedhastighed kan være lavere end
TARGET_FRAME_RATEpå grund af værtsenhedens begrænsninger og gengivelsens kompleksitet.
Manuel Animation
for at observere effekten af forskellige animationer begynder vi med at placere en fast terning til reference.
We add our first animated GameObject (Sphere) in front of it with the following script component.
Assets/Sphere.cs (incomplete)
Running it with the normal frame rate:
Running it with 10fps frame rate:
Observations:
- det er klart, at vi har et problem. Vi ønsker ikke, at animationshastigheden skal være afhængig af billedhastigheden.
- problemet er, fordi vi indstiller hastigheden til at være 0,1 enheder / ramme; vi ønsker, at hastigheden måles i enheder / sekund.
løsningen er at give hastigheden i enhederne af enheder / sekund; 0,1 enheder / ramme * 50 billeder / sekund = 5 enheder / sekund. Så bruger vi tiden.deltaTime at kende tiden siden sidste opkald til opdatering. Derefter er den tilbagelagte afstand hastighed * deltaTime.
aktiver / sfære.cs (ufuldstændig)
med denne rettelse på plads får vi den samme animation uanset billedhastigheden (men med 10 FPS er den rykkende som forventet).
efter at have brugt den reducerede billedhastighed til at illustrere behovet for at give hastighed i enheder / sekund, kan vi kommentere linjerne i opsætningen.cs, der simulerede en langsom billedhastighed.
Animation i fysik
i stedet for manuelt at animere et GameObject, kan vi animere det ved at anvende fysik til det. Vi kan animere en cylinder (bevæger sig lige med 5 enheder / sekund) ved:
- oprettelse af et plan (kaldet plan)
- oprettelse af en Cylinder (kaldet Cylinder)
- Tilføj en stiv Kropskomponent til Cylinder (og frysning af rotationen i alle retninger)
- Opret et fysikmateriale, glat, uden friktion og påfør det på både Cylinder og plan
- Startcylinder med en indledende hastighed ved hjælp af en scriptkomponent
aktiver/cylinder.cs
med dette på plads kan vi se, at kuglen og cylinderen bevæger sig til højre med samme hastighed.
observationer:
- kuglens position opdateres umiddelbart før gengivelsen (manuelt i opdateringsmetoden)
- cylinderens position opdateres i den interne fysikopdatering.
Animation med Animation
en tredje måde at animere et GameObject på er med en animation (naturligvis). Vi kan animere en kapsel (forsøger at bevæge sig lige med 5 enheder / sekund) ved:
- oprettelse af en kapsel (kaldet kapsel)
- oprettelse af en animationscontroller (også kapsel) og tilføjelse som en komponent til Kapselspilobjektet.
- oprettelse af en animation (også kapsel).
- i animationscontrolleren oprettes en tilstand (Start) med dens bevægelse for at være Kapselanimationen.
- endelig animerer vi positionen, så kapselens vandrette position er 5 enheder på 1 sekund.
med dette på plads kan vi se, at kuglen, cylinderen, kapslen (næsten) bevæger sig til højre med samme hastighed.
observationer:
- ikke sikker på hvorfor, men kapslen bevægede sig lidt hurtigere end forventet; problemer skudt et stykke tid og fandt ikke ud af hvorfor.
- kapselens position kan konfigureres til at opdatere inden gengivelse (standard) eller under fysikopdateringen.
implikationer af en hurtig billedhastighed
på kraftfulde computere kan man opnå billedhastigheder op til 150 FPS. På disse computere med standardfysikopdateringer 50 gange i sekundet (0,02 sekunder mellem opdateringer) opdateres de elementer, der opdateres før hver gengivelse, oftere end dem, der opdateres i fysikopdateringerne. Denne uoverensstemmelse er kilden til problemer med at blande og matche timesteps.
selvom jeg ikke kan øge billedhastigheden for min udviklingsmaskine (begrænset til omkring 50fps), kan jeg kunstigt sænke fysikopdateringerne til 10 opdateringer pr.1 sekunder mellem opdateringer) ved hjælp af projektets indstillinger.
som du kan se, har vi ved at blande og matche timesteps genskabt problemet (inkonsekvent bevægelse mellem gameelements).
for at rette op kan vi ændre kapselens animation for at opdatere om fysikopdateringer og ligeledes Opdatere Sphere ‘ s script-komponent som følger:
aktiver/Sphere.cs
Med dette opdateres alle animationer konsekvent før hver fysikopdatering.
endelig returnerer vi vores fysikopdatering til 50 fps (eller hvert 0,02 sekund); opnå både konsistente og rettidige opdateringer.
konklusioner
efter at have ret let genskabt problemet med at blande og matche timesteps, har jeg overbevist mig selv om, at jeg skal sætte al spiltilstand i faste opdateringsmetoder.