Zobrazit předchozí téma :: Zobrazit následující téma |
Časový krok (který používám) |
ODE - konstantní |
|
5% |
[ 1 ] |
ODE - proměnný |
|
0% |
[ 0 ] |
Vlastní fyz. engine - konstantní |
|
40% |
[ 8 ] |
Vlastní fyz. engine - proměnný |
|
10% |
[ 2 ] |
Jiný fyz. engine (Bullet, ...) - konstantní |
|
20% |
[ 4 ] |
Jiný fyz. engine (Bullet, ...) - proměnný |
|
10% |
[ 2 ] |
Fyziku neřeším ;) nebo nevím (třeba Blender GE, kdoví, jak to tam je) |
|
15% |
[ 3 ] |
|
Celkem hlasů : 20 |
|
Autor |
Zpráva |
frca
Založen: 28. 07. 2007 Příspěvky: 1558
|
Zaslal: 28. květen 2008, 07:56:35 Předmět: |
|
|
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 |
|
|
]semo[
Založen: 29. 07. 2007 Příspěvky: 1526 Bydliště: Telč
|
Zaslal: 28. květen 2008, 08:39:19 Předmět: |
|
|
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 |
|
|
Fila
Založen: 31. 07. 2007 Příspěvky: 853
|
Zaslal: 28. květen 2008, 09:13:52 Předmět: |
|
|
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 |
|
|
nou
Založen: 28. 07. 2007 Příspěvky: 1047
|
Zaslal: 28. květen 2008, 14:15:46 Předmět: |
|
|
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 |
|
|
Marek
Založen: 28. 07. 2007 Příspěvky: 1782 Bydliště: Velká Morava
|
Zaslal: 28. květen 2008, 15:37:21 Předmět: |
|
|
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 |
|
|
frca
Založen: 28. 07. 2007 Příspěvky: 1558
|
Zaslal: 28. květen 2008, 21:31:17 Předmět: |
|
|
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á? |
|
Návrat nahoru |
|
|
Marek
Založen: 28. 07. 2007 Příspěvky: 1782 Bydliště: Velká Morava
|
Zaslal: 29. květen 2008, 01:09:47 Předmět: |
|
|
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. _________________ AMD Open Source Graphics Driver Developer |
|
Návrat nahoru |
|
|
]semo[
Založen: 29. 07. 2007 Příspěvky: 1526 Bydliště: Telč
|
Zaslal: 29. květen 2008, 07:50:51 Předmět: |
|
|
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 |
|
|
Fila
Založen: 31. 07. 2007 Příspěvky: 853
|
Zaslal: 29. květen 2008, 08:36:18 Předmět: |
|
|
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 ). 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 |
|
|
xtopi
Založen: 11. 08. 2007 Příspěvky: 24 Bydliště: La republica Checa
|
Zaslal: 30. květen 2008, 02:21:05 Předmět: |
|
|
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 . No zkrátka, já používám (něco jako) tuhle podmínku a ta je podle mě nad zlato
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 |
|
|
frca
Založen: 28. 07. 2007 Příspěvky: 1558
|
Zaslal: 30. květen 2008, 08:58:17 Předmět: |
|
|
Počkat na fyziku? Ona jede v jiném vlákně, nebo jak to čekání realizuješ? |
|
Návrat nahoru |
|
|
Fila
Založen: 31. 07. 2007 Příspěvky: 853
|
Zaslal: 30. květen 2008, 09:27:58 Předmět: |
|
|
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 |
|
|
xtopi
Založen: 11. 08. 2007 Příspěvky: 24 Bydliště: La republica Checa
|
Zaslal: 30. květen 2008, 14:57:05 Předmět: |
|
|
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" , 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 , 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 . Tohle loopování taky žere CPU, ale to teď nikoho nezajímá
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.... |
|
Návrat nahoru |
|
|
kerekes
Založen: 29. 07. 2007 Příspěvky: 57
|
Zaslal: 30. květen 2008, 17:52:15 Předmět: |
|
|
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 .
*** Ak teda nerobite nieco suprove v style assassin's creed/nfs x/gta4. |
|
Návrat nahoru |
|
|
Ladis
Založen: 18. 09. 2007 Příspěvky: 1536 Bydliště: u Prahy
|
Zaslal: 30. květen 2008, 20:23:22 Předmět: |
|
|
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 |
|
|
|