fyzikální engine jednoduchý na naučení s dobrou dokumentací

[asiJa]

ahoj,
prošel jsem hodně diskuzi typu "best physics engine" a "bullet vs ODE vs PhysiX" ... a udelal jsem si jakousi predstavu co od ceho ocekávat ohledne výkonu a mozností.

Pokud se ale realisticky podívám na své skusenosti a plány myslím ze pro me (a asi i pro mnoho jiných zacátecníků) je mnohem důlezitejsí nez výkonost to aby se dal engine co nejrychleji stáhnout, nastavit v kompilatoru, slepit s grafickym engine, prohlédnout examply a dostat první lamovske výsledky pokudmozno hned V dalsím kroku je pak důlezité aby clovek nasel na kazdou otázku co nejrychleji odpovede v dokumentaci a/nebo nejlépe zase nejaký príklad zdrojáku který se dá hned skompilovat.

Cetl jsem napr. ze Bullet je skvelý ale má hroznou dokumentaci. Zajímalo by me teda jak to je s ostatními. Preferoval bych opensource ale není to podmínka. Jména co jsem slysel

ODE, PhysiX, Bullet, Newton, Tokamak, Simple Physics Engine

[Ladis]

Po precteni prvniho odstavce sem ziskal dojem, ze me bude cekat tvuj souhrn o jednotlivych fyzikalnich enginech, o kterych si cetl, a jejich srovnani (podle zkusenosti ostatnich).
_________________
Award-winning game developer

[Marek]

Můžu doporučit PhysX, používá to asi stovka komerčních her, je to multiplatformní a jede i na konzolích (linux x64 se plánuje, x86 už je). Použití na Windows a Linux je zdarma, MacOSX nevím, na konzole je potřeba už něco zacvakat. Dokumentaci má dobrou a v SDK je hromada příkladů. Na používání je to dost jednoduché, pošleš tam objekty a jejich parametry a další snímek si vyzvedneš výsledky. Umí to pevné tělesa a jejich rozbíjení, měkká deformovatelná tělesa a jejich trhání, látky a jejich trhání, kapaliny... Fyzika jede ve vlastním vlákně automaticky, kde akorát fetchResults() synchronizuje, takže využiješ dualcore a nemusíš dělat nic s vláknama. Dá se akcelerovat pomocí nVidia GeForce a Ageia PhysX karet, ale většinou ti bohatě stačí softwarová implementace na cpu. Slepení s grafickým enginem je taky snadné, ale je potřeba znát nějaký grafický engine, ten bude asi složitější na používání...
_________________
AMD Open Source Graphics Driver Developer

[asiJa]

Ladis > bohuzel, na to se teda fakt necitim

Eosie> aha ja sem si nebyl uplne jisty jestli to nejede prave jenom s hardware akceleraci (tzn. nepotrebuje nvidia grafiku). No trochu me na tom odrazuje ze to neni opensource, ale nejsem nijak ortodoxni, jinak se mi (asi hlavne kvuli marketingu) PhysiX fakt libi hodne, takze se na to nejspise podivam.

[pcmaster]

Ja prave teraz tiez skusam PhysX a riesim podobny problem ako ty. Myslim si, ze proti ODE to ma o dost lepsiu dokumentaciu aj API. Bullet by mozno tiez slo pouzit, ja som ortodoxny open-sourcista, no PhysX mi az tak nevadi (aj tak pouzijem este Bass alebo FMOD...). Zda sa, ze je to prijemne (SM 4.0 kartu nemam, ani PhysX kartu )
_________________
Off-topic flame-war addict since the very beginning. Registered since Oct. 2003!
Interproductum fimi omne est.

[Vilem Otte]

PhysX od Ageia je jedno z nejpřehlednějších api na použití (já ho používám), ale samply k němu dodané jsou napsány IMNSHO snad nejchaotičtějším možným způsobem)
Každopádně můžeš zkusit i podle mě snad nejlepší fyzikální knihovnu pro hry na trhu - HAVOK - http://tryhavok.intel.com/ pokud stavíš middleware (engine, nebo cokoliv jiného), anebo freeware, tak ZDARMA (Big THX to INTEL )

#PCMaster - hraju si s PhysX na SM 4.0 kartě už nějaký ten pátek a žádné problémy s implementací nebyly ... ale zatím jsem nepoznal rozdíl jestli to běží HW nebo SW (ono s pár stovkami objektů to ani poznat nejde)
_________________
Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration.

[Marek]

Akcelerace PhysX se hodí pouze pokud potřebuješ simulovat opravdu strašně velké množství různých objektů (hlavně kapaliny), ve hrách toto ale není potřeba (nepočítám hry dělané z cílem propagovat PhysX za každou cenu, to je jiné kafe). Těch pár fyzikálních objektů, které mezi sebou v dnešních hrách interagují, nepotřebují ani to vlastní vlákno (např. HL2).

Vilem> Jaké jsou výhody a nevýhody Havoku oproti PhysX? Myslím samozřejmě z vlastní zkušenosti, pokud s tím nějakou máš...
_________________
AMD Open Source Graphics Driver Developer

[asiJa]

Vilem Otte > no pekne ale ja nic nestavim, je vylozene se chci se stim jen tak seznamit a pohrat si s tim, prave ze fakt nepotrebuju asi nic moc sofistikovaneho.

Defacto na to co chi naprogramovat (jen takovy proof-of-concept game mechanizmu mortal-kombat like hry zalozene na fyzice a boji jako stavovem automatu, s minimalistickou grafikou a nulovym gui, + malovatko se simulaci dynamiky stetce) by mi stacil GLUT a fyziku bych si napsal vlastni (to byla puvodni idea)....
ale rikam si ze kdyz ty fyzikalni enginy jsou, tak by byla skoda to nevyskouset. Zvlaste kdyz fyzikalni simulace jsou vlastne muj obor, a s GPGPU bych se chtel seznamit, takze to PhysX mi prijde dost atraktivni, jen se mi nelibi ze to je +/- proprietalni vec, a ze je to uz docela velky moloch na me skrome poterby
Kdyby byl fyzikalni engine ktery si stahnu jako devpack do devc++ ktery by umel resit jenom srazky kulicek a raycasting na trinagle byl bych spokojeny.

[pcmaster]

Ak chces len sphere vs sphere a line vs triangle, tak si to napis Tak jednoduchy fyzikalny solver mas za 2 dni
Nevidim dovod, preco si nevyskusat PhysX... Tych par10 MB dnes nikoho nezabije...
_________________
Off-topic flame-war addict since the very beginning. Registered since Oct. 2003!
Interproductum fimi omne est.

[asiJa]

pcmaster > no to asi jo, ale spise sem myslel na nejakou organizaci sceny - ty enginy maji jako dost vychytavek pro predbezny odhad jestli se 2 veci vubec muzou srazit, ne jen octree ale i jine.
A pak dalsi vec, co sem nerekl ze sem si z tech kouli chtel udelat ragdoll (docela pochopielne pro bojovku).

No hlavni problem vidim v tom jak skloubit fyziku (kolize, gravitace, vazby) s animaci (jako ze prechody mezi jednotlivymi pozami "chvatu")
vymyslel sem si to tak ze bych si udelal referenci pozy (tj. x,y,z poloha kazdeho kloubu) ktere by byly jakoby atraktor (pusobici silou/zrychlenim) na skutecny kloub (tzn. kloub by se dynamicky podle newtonovych zakonu pohyboval za svym atraktorem).
A pri ovladani (tj. reakci na klavesu) by se zmenila referenci poza => panacek by konvergoval do sve nove referenci pozy ze stare referenci pozy a pritom by se nove hybnosti pricitaly ke starym.
Jediny problem je ze aby to vypadalo trochu realisticky musi byt polohy koloubu definovane ne absolutne (napr vuci rrotu panacka) ale relativne k nejblizsimu nadrazenemu koloubu (napr. zapesti vuci loku, loket vuci ramenu). A tim nemyslim relativne jako ze odectu x,y,z ale predevsim relativne vuci orientaci (natoceni) toho nadrazeneho.
A to uz je trochu problem (aspon pro me). Sice uz sem nasel nejaky predpis pro to jak ziskat rotacni matici z 2 vektoru (jako matice ktera je definovana tak ze zobrazi 2 jednotkove vektory jeden na druhy) ale komplikuje se to, takze sem si rikal ze ten fizikalni engine vyresi vice veci naraz, a vubec je proste lepsi nejaky odlazeny engine pouzivat, otvira to nove moznosti.

ad physX, no uz skousim.... jen me odradilo ze sem kvuli tomu musel nainstalovat Visua C++, pod mingw sem vubec nevedel jak to sprovoznit (snad linuxovou verzi ale ta je v .rpm), ale je to fakt hezke

[pcmaster]

A vies, ze taka hra uz existuje? Toribash. dokonca tu na to bol niekdy link sa mi zda...
_________________
Off-topic flame-war addict since the very beginning. Registered since Oct. 2003!
Interproductum fimi omne est.

[asiJa]

uff, si me me vydesil.... sem si to stahnul a je to jakesi tahove, to neni zadna sranda

spise kdy uz tak neco takoveho
http://www.youtube.com/watch?v=13yM0PfHon4
http://www.ragdollsoft.com/ragdollmasters/
ale ne tak crazy neovladatelne, a 3D kdyz se zadari
prijde mi ze tahle hra vznikla tak ze nekdo chtel utelat Mortal-Kombat-S-Fyzikou, ale narazil prave na ten problem skloubeni animace/ovladani a samovolnych fyzikalnich pohybu, pak ale zjistil ze to je crazy funny tak to ovladani obetoval