.[ ČeskéHry.cz ].
ODE - determinismus
Jdi na stránku Předchozí  1, 2, 3, 4  Další
 
odeslat nové téma   Odpovědět na téma    Obsah fóra České-Hry.cz -> Fyzikální modely
Zobrazit předchozí téma :: Zobrazit následující téma  

Časový krok (který používám)
ODE - konstantní
5%
 5%  [ 1 ]
ODE - proměnný
0%
 0%  [ 0 ]
Vlastní fyz. engine - konstantní
40%
 40%  [ 8 ]
Vlastní fyz. engine - proměnný
10%
 10%  [ 2 ]
Jiný fyz. engine (Bullet, ...) - konstantní
20%
 20%  [ 4 ]
Jiný fyz. engine (Bullet, ...) - proměnný
10%
 10%  [ 2 ]
Fyziku neřeším ;) nebo nevím (třeba Blender GE, kdoví, jak to tam je)
15%
 15%  [ 3 ]
Celkem hlasů : 20

Autor Zpráva
frca



Založen: 28. 07. 2007
Příspěvky: 1554

PříspěvekZaslal: 28. květen 2008, 07:56:35    Předmět: Odpovědět s citátem

Po nějaké době jsem se k tomu vrátil.
Vpodstatě jde o to, když fyzika jede konstantně na třeba 20 fps, tak aby animace jely na hodnotě fps dané vykreslovací rychlostí, třeba ~500 fps (ta není nikdy úplně konstantní).
Jako jedinou cestu vidím pro každý grafický frame dosimulovat fyziku od fyzikálního framu do aktuálního času, ale třeba to jde vyřešit jinak.

Takže úplně v základu mi jde o plynulé animace (na co vykreslovat 500 fps, když by animce nejely líp než 20 fps?).
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu Zobrazit autorovi WWW stránky
]semo[



Založen: 29. 07. 2007
Příspěvky: 1525
Bydliště: Telč

PříspěvekZaslal: 28. květen 2008, 08:39:19    Předmět: Odpovědět s citátem

20 fps je málo, dej tak nejmíň 50 na fyziku a nemusíš nic víc řešit, bude to plynulý, i když pojede grafika rychleji
_________________
Kdo jede na tygru, nesmí sesednout.
---
http://www.inventurakrajiny.cz/sipka/
Aquadelic GT, Mafia II, simulátory
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
Fila



Založen: 31. 07. 2007
Příspěvky: 853

PříspěvekZaslal: 28. květen 2008, 09:13:52    Předmět: Odpovědět s citátem

Semo ma pravdu.
Pokud opravdu nemuzes delat fyziku rychleji nez 20fps, muzes budto dopocitavat ten frame, nebo (ale to by hre mohlo vadit) byt ve fyzice o jednu iteraci v budoucnu a v grafice interpolovat.
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
nou



Založen: 28. 07. 2007
Příspěvky: 1047

PříspěvekZaslal: 28. květen 2008, 14:15:46    Předmět: Odpovědět s citátem

ja si v hrach zapinam v-sync aby mi grafika tolko nehriala a nezrala. ja by som sa na nejke interpolovanie vyflakol ak pojdu animacie a fyzika na 50fps tak to nikto nema sancu ustriehnut a kto si honi nad vysokymi FPS tak nech sa mu rata ten isty obraz aj 5 krat, uvidi ho aj tak nanajvis raz.
_________________
Najjednoduchšie chyby sa najtažšie hľadajú.
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
Marek



Založen: 28. 07. 2007
Příspěvky: 1782
Bydliště: Velká Morava

PříspěvekZaslal: 28. květen 2008, 15:37:21    Předmět: Odpovědět s citátem

Fyzika většinou způsobí, že bottleneck bude na cpu, ne na gpu. Pokud by se tam ta interpolace přidala, mohlo by to způsobit další snížení fps a to se nevyplatí (zrovna mám v projektu problém, že u 2000 objektů už cpu přebírá roli pomalejšího a to i tehdy, když vypnu fyziku).
_________________
AMD Open Source Graphics Driver Developer
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
frca



Založen: 28. 07. 2007
Příspěvky: 1554

PříspěvekZaslal: 28. květen 2008, 21:31:17    Předmět: Odpovědět s citátem

Takže nejlepší je nechat uživatele, ať se kochá úžasnými 600 fps, protože to, že to jede max. 50 fps, vím jenom já? Wink
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu Zobrazit autorovi WWW stránky
Marek



Založen: 28. 07. 2007
Příspěvky: 1782
Bydliště: Velká Morava

PříspěvekZaslal: 29. květen 2008, 01:09:47    Předmět: Odpovědět s citátem

frca> Spíš uživatel uvidí 50fps a že to má 600fps budeš vědět jen ty, on to ze scény nemá jak poznat. Použij VSync a nebudeš muset řešit takový blbosti. Smile
_________________
AMD Open Source Graphics Driver Developer
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
]semo[



Založen: 29. 07. 2007
Příspěvky: 1525
Bydliště: Telč

PříspěvekZaslal: 29. květen 2008, 07:50:51    Předmět: Odpovědět s citátem

Nejde o to, omezit to jen shora, fyzika by měla šlapat konstatně. VSync ti to omezí třeba na 85 Hz (fps) (podle nastavení monitoru). Ale fyzika musí stále pracovat na (např. ) 50 fps, i když framerate klesne řekněme na 25.

Vezmeš si dobu, za kterou trval jeden frame hry a zjistíš kolik se jich tam vejde fyzikálních a klidně je za sebou provedeš. Takže pro fps menší než fyzikální fps budeš provádět více framů fyziky, pro fps větší než fyzikální fps provedeš fyzikální frame "jednou za čas".
_________________
Kdo jede na tygru, nesmí sesednout.
---
http://www.inventurakrajiny.cz/sipka/
Aquadelic GT, Mafia II, simulátory
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
Fila



Založen: 31. 07. 2007
Příspěvky: 853

PříspěvekZaslal: 29. květen 2008, 08:36:18    Předmět: Odpovědět s citátem

Eosie napsal:
Fyzika většinou způsobí, že bottleneck bude na cpu, ne na gpu. Pokud by se tam ta interpolace přidala, mohlo by to způsobit další snížení fps a to se nevyplatí (zrovna mám v projektu problém, že u 2000 objektů už cpu přebírá roli pomalejšího a to i tehdy, když vypnu fyziku).


Ale no tak, psal jsem, ze interpolace jedine za podminky, ze z nejakeho duvodu fyzika nemuze jet rychleji nez 20fps (treba je extremne narocna a nevadi to jeji stabilite, i kdyz si to skoro neumim predstavit Smile). Pokud by se srovnala z hlediska narocnosti na stejne scene fyzika na 20 fps + interpolace, je to nesrovnatelne mene narocne, nez fyzika na 50 fps bez interpolace (interpolace udela pro kazde teleso pomerne malou konstantni praci, fyzika je zpravidla kubicka k poctu jointu, nebo linearni s poradnou multiplikativni konstantou).

Jinak samozrejme 600fps je jen na to, aby se to nekde v rohu vypisovalo, monitory vykresluji na mnohem nizsi frekvenci.
A Semo ma pravdu, jestli nechces, aby fyzika delala haluze, nech ji jet na konstantnim fps.
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
xtopi



Založen: 11. 08. 2007
Příspěvky: 24
Bydliště: La republica Checa

PříspěvekZaslal: 30. květen 2008, 02:21:05    Předmět: Odpovědět s citátem

nema nikdy cenu vykreslovat scemu, ktera se od minule nepohnula, takze pokud je fps grafiky vetší než fyziky, tak je to špatně, a to nejen proto, že nikdo rozdíl v fps nepozná (např. fyz. 60 a grafika 300), ale HLAVNĚ proto, že výsledek nebude plynulej, a bude tím horší čím scéna bude náročnější a fps se budou blížit (např. 60 a 100), no a uplná hrůza je pak (60 a 70), to bys musel vědět o čem mluvim Smile. No zkrátka, já používám (něco jako) tuhle podmínku a ta je podle mě nad zlato Smile

kód:

if (physicsUpdatedSinceLastRender)
{
   render();
   physicsUpdatedSinceLastRender = false;
   // fyzika tohle zase zpatky nastavi na true, jakmile updatne scenu
   // receno zjednodusene, fyzika sama nic nenastavi :),
}
  else
{
  // muzu delat neco jinyho, nebo pockat na fyziku, to je totiz lepsi varianta
  // nez kdyz fyzika "ceka" na render
}
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
frca



Založen: 28. 07. 2007
Příspěvky: 1554

PříspěvekZaslal: 30. květen 2008, 08:58:17    Předmět: Odpovědět s citátem

Počkat na fyziku? Ona jede v jiném vlákně, nebo jak to čekání realizuješ?
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu Zobrazit autorovi WWW stránky
Fila



Založen: 31. 07. 2007
Příspěvky: 853

PříspěvekZaslal: 30. květen 2008, 09:27:58    Předmět: Odpovědět s citátem

Budto muzes mit fyziku extra v druhem vlakne (urcite rozumnejsi kvuli bezne vyskytujicim se vicejadrovym CPU), nebo pokud chces konstantni krok i framerate fyziky, tak ji muzes protocit nekolikrat na frame -- to samozrejme funguje jen za predpokladu, ze mas nejnarocnejsi grafiku a fyzika se prepocita hodne rychle (kdyz chces napr. 50fps a grafika ti zabere vic nez 1/50s, protocis vypocet fyziky vickrat bez renderingu, abys "dohnal cas").
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
xtopi



Založen: 11. 08. 2007
Příspěvky: 24
Bydliště: La republica Checa

PříspěvekZaslal: 30. květen 2008, 14:57:05    Předmět: Odpovědět s citátem

Jo jak říká Fila.... už když sem to psal, tak sem věděl, že výraz "počkám na fyziku je nepřesnej" Smile, i když totiž nemám víc vláken tak jakoby čekám na fyziku. Ale zapoměl jsem říct, že mluvim o konst. čas. kroku fyziky, u prměnnýho teď nevim, nepoužívám to tak nechci o tom mluvit blbosti...

Zkrátka, když mám fyziku která mi běží na 50ti fps, 50fps odpovídá 20ms, tzn. každých 20ms počítám fyziku, vždycky musím počkat než uplyne těch 20ms než začnu počítat znova, takže např. takhle čekám já...

kód:

{
   // 50 fps => 20ms
   int timestep = 20;

   // ziskam absloutni cas v milisekundach (jsou i jiny funkce pro cas)
   int time1 = timeGetTime() - timestep; 

   while(!konec)
   {
       time2 = timeGetTime();

       if (time2 - time1 > timestep)
       {
           fyzika.update( (float) timestep / 1000 );  // [ms] -> [s]

           time1 = time2;
           fizyka_updated = true
       }

        if (fyzika_updated)
        {
             // render and present....
             render();

             fyzika_updated = false;
        }
   }
}



no a koukam ze sem nakonec napsal celou svoji loopovaci smycku Smile, ale je to pro prehlednost zjednoduseny, ale je tam teda vidět to čekání - ten cykl jede vlastně donekonečna, a render čeká na fyziku a fyzika čeká na vhodnej čas, takže to čekání jsou ty IFy

V určitých chvílích se loopuje cyklem aniž by to "vlezlo" do jediný podmínky, schválně si můžeš zkusit počítat počet cyklů/s ale u triviální scény si radši připrav 32b int Smile. Tohle loopování taky žere CPU, ale to teď nikoho nezajímá Smile

edit: no takze koukam jak sem to zjednodusil, tak je to ted trochu nemsylny, protoze ten render() by ted mohl byt primo v tom prvnim ifu, ale ono to zacne mit smysl, kdyz misto toho prvniho ifu bude while a bude se pouzivat akumulatr (takze fyzika se bude moct pocitat vickrat za sekundu), to je uz ted jedno....Smile
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
kerekes



Založen: 29. 07. 2007
Příspěvky: 57

PříspěvekZaslal: 30. květen 2008, 17:52:15    Předmět: Odpovědět s citátem

Nieje jednoduchsie/lepsie pocitat fyziku s premenlivym casovym krokom (cas od predchadzajuceho framu) 1 krat za frame?
Iste vedie to k nepresnostiam, ale pri 3fps mi je jedno ci je ten vypocet realisticky nie?

Zrejme to zavisi aj od pouzitia, ale myslim ze pre bezne veci(*), vypocty kolizii(**) je to jedno.

Hraca s malm fps bude nejakych par centimetrov nepresnosti trapit najmenej (pod 15 fps je to tak ci tak malo hratelne a >50-fpskova fyzyka mu to este viac spomali), nad 15 fps to je uz celkom presne, a kto ma vysoke >60 fps tak nech si uziva peknu presnu simulaciu.

* Myslim ze pri tvorbe vecsiny hier (nie AAA, nie zavodnych) sa z fyziky riesia iba problemy typu pohyb hraca (plynuly rozbeh dobeh), kolizie jeho obalky (kruh, gula, elipsoid) s okolim, a nejaka ta strelba/hadzanie predmetov a pod. Takze vobec tu nezalezi natom ci sa ta fyzika zrata 5, alebo 50 krat za sekundu, a uz vobec nie ked sa ajtak na popis dejov pouzivaju fake rovnice (co si dovolim tvrdit ze drtiva vecsina to tak robi).

** Videl som par kodov, kde bol problem pri pocitani kolizie pohybujuceho sa objektu (gula, ...) s meshom(3d)/ciarou(2d) pri malom fps, ze kolizia sa nezaregistrovala, ale lepsie nez spoliehat sa na vysoke fps je dynamicky rozkuskovat pohybovy krok, ak je vecsi ako trebarz polomer obalky, a spocitat to vo viac iteraciach.

Ja by som teda radsej celkovo fyzikalne enginy nechal stranou*** (zbytocna komplikacia, zbytocne vecsie naroky na cpu, zbytocne zvysovanie zavislosti projektu na dalsich knizniciach), zakladne fyz. veci zriesil fakeovo (vecsinou to aj lepsie vyzera), pocital to s dt od predosleho framu, a sup ho radsej robit hratelnu hru Smile.

*** Ak teda nerobite nieco suprove v style assassin's creed/nfs x/gta4.
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
Ladis



Založen: 18. 09. 2007
Příspěvky: 1534
Bydliště: u Prahy

PříspěvekZaslal: 30. květen 2008, 20:23:22    Předmět: Odpovědět s citátem

Pokud vas zajima, jak to resi jini, tak je znamo, ze v Doom 3 bezi fyzika na 60 fps a grafika se kresli jako interpolace mezi 2 snimky fyziky. Je to tam z duvodu, aby fyzika nezavisela na fps (hlavne kvuli multiplayeru).

http://ucguides.savagehelp.com/Doom3/FPSVisuals.htm napsal:
John Carmack of id sofware: "The game tic simulation, including player movement, runs at 60hz, so if it rendered any faster, it would just be rendering identical frames. A fixed tic rate removes issues like Quake 3 had, where some jumps could only be made at certain framerates. In Doom, the same player inputs will produce the same motions, no matter what the framerate is."


EDIT: Jeste k fyzice pri nizkem fps, pokud nepouzivate konstantni framerate pro fyziku: Pokud je uplynuly prilis velky a muze se stat, ze objekt proleti objektem, do ktereho by pri dostatecne vysokem fps narazil, tak jednoduse pocitejte fyziku po zvolenych maximalnich povolenych casovych usecich, dokud se kroky fyziky nenascitaj do uplynule doby od posledniho snimku. Mam to tak treba ve sve hricce Zarkanoid, kde by pri vysokych rychlostech micek prolitl cihlou pri nizsich fps.
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
Zobrazit příspěvky z předchozích:   
odeslat nové téma   Odpovědět na téma    Obsah fóra České-Hry.cz -> Fyzikální modely Časy uváděny v GMT + 1 hodina
Jdi na stránku Předchozí  1, 2, 3, 4  Další
Strana 2 z 4

 
Přejdi na:  
Nemůžete odesílat nové téma do tohoto fóra
Nemůžete odpovídat na témata v tomto fóru
Nemůžete upravovat své příspěvky v tomto fóru
Nemůžete mazat své příspěvky v tomto fóru
Nemůžete hlasovat v tomto fóru


Powered by phpBB © 2001, 2005 phpBB Group


Vzhled udelal powermac
Styl "vykraden" z phpBB stylu MonkiDream - upraveno by rezna