Real time fizika hogyan?
 Sziasztok.
Érdekelne hogy lehet a címben említett dolgot megoldani
c++ nyelven.(vagy 1 hónapja tanulom),de eddig html és php programozást tanultam és készítgetem oldalakat.
Én most szeretnék egy sims-hez hasonló játékot csinálni ahol tud az ember házat vagy kocsit törni ehez kellene a segítségetek. |
3 hónap az a 10 év.  |
Jaja :)
Egyszerűen olvashatatlan... Haver mutatta a szirmay-s feladatait, nahogy segítsek neki, erre az első reakcióm az volt, hogy kérek egy szótárt, mert a szavak miatt nem értem a feladatot :D |
A Szirmay-hoz is egy külön értelmező szótárt lehetne írni:
csipkézettség kivasalása = AA
bucka leképezés = bump mapping
"És, amikor áttuszkoljuk a csővezetéken a dolgokat, akkor a rasztertáron jön ki az eredmény."
 |
Én durván 13 éve "tanulom" az angolt, és még mindíg gondot okoznak az egyszerűbb mondatok is (hogy valóban megértsem és ne csak sejtsem). Szóval van aki "be van oltva" ellene.
Ha arról van szó, megnézek egy filmet angol nyelven, ha nem értek mindent tisztán az nem gond, de programozásnál apróbb jelentésbeli különbségek is számíthatnak.
Természetesen előbb-utóbb szükséges az angol nyelv megtanulása. És az is lehetséges, hogy a fordított szöveg már nem azt a jelentést fogja tartalmazni, így az eredeti az igazi. Plusz több is az angol dokumentáció.
De kezdőknek a magyar szöveg is megfelel, a finomságokra az elején úgysem tud figyelni.
Plusz amíg megtanul valaki angolul folyamatosan olvasni, azalatt párhuzamosan már haladó szinten megtanulhat programozni is. Szóval ha nincs kéznél az angol tudás azért nem kell azt mondani bárkinek, hogy most 2 évig még ne programozzon, tanulja az angolt ezerrel és majd később jöjjön vissza. Akkor meg a programozásból kihagyott idő hiánya okoz gondot. |
| Orulok hogy eppen ennyire egyetertesz |
Szirmay nemzetközileg elismert szakember (egyetlen hibája, hogy kissé túl matematikus szemszöggel nézi a grafot, szerintem), szal az ő szakmaiságával nincsen baj. Egyetlen problémát a kifejezések magyarítása jelenti, mivel ha bárki is ilyen helyen dolgozik, kbra nem értik meg ha a magyar verzióját használja a szakkifejezésekkel.
Erre ellenpélda a Nyisztor Károly féle könyvek, azok nem csak a nyelvezetükben félrevezetőek, hanem szakmailag is a jf alja. De Szirmay-t bátran. Kezdőknek megfelelő, csak könyörgöm ne úgy beszéljetek, hogy csővezeték, meg árnyaló egység... |
En meg startbol nem javasolnam senkinek hogy magyar nyelven olvasson barmit. Nem eri meg.
   |
En meg startbol nem javasolnam senkinek hogy magyar nyelven olvasson barmit. Nem eri meg. Aki programozni akar hosszabbtavon az ugyse kerulheti el az angol nyelvet. Ugynaugy mint ahogy a programozas megtanulasaert aldozatot/energiat kell fektetni, ugyanugy az angol is egy elengedhetlen szukseges tanulnivalo.
Kulonben is nemtudom mi olyan nehez az angolba: 1. a csapbol is mindenutt az angol folyik, 2: Csak kicsit alapszinten kell elsajatitani, a tobbi "specifiuks" szavakat megtanulod ut kozbe. |
Még egy könyv, ami szerintem egészen használható alap dinamikához: Szirmay-Kalos László: 3D Grafika, animáció és játékfejlesztés.
Igazából itt prog.hu-n minden önjelölt játékfejlesztővel ki kéne olvastatni, mielőtt játékot akarnak írni. Hasznos lenne.
off: mindig mosolygok, amikor a "Fizika" mindenkinek annyit jelent, hogy golyók meg téglák pattognak ide-oda. Ha valakinek véletlenül részecske transzport programcsomag kéne, ajánlom a Geant-ot:) |
| Vedd elő a fizika könyvet, vannak szép erőtörvények, közegellenállás stb... azokat kell használni. |
Peldaul a PhysX szerintem annyira agyonra van optimalizalva(+a pontossag is megadhato) hogy meg processzoron(CPU) is nagyon szuper. Nem mondom hogy lehetetlen gyorsabb es jobb algoritmust irni "kezileg" de nem lenne tul konnyu.
Jo persze most en is gondolok valami 3D-s jobb dologra... |
| A főnököm is ilyen volt... |
 hát ha valaki a weboldali programozás után odateszi magát egy önjelölt sims - klón játékfejlesztőnek zéró tapasztalattal, nos az biztos álmodozó személyiség lehet 8))! LOL  |
Szóval az "univerzális" dolgok lehetnek lassabbak, sokszor lassabbak is.
És itt megint bejön az a kérdés, hogy pontosan mire kell.
Egy átlag játékban mindegy, hogy 100, vagy 1000 órajelig tart az ütközési merőleges kiszámítása, mert egyszerűen nem lesz annyi ütközés, hogy számítson.
De ha egy részecskemodellezést kell csinálni, akkor már jól jöhet egy saját motor, ami nem törekszik olyan pontosságra, de esetleg 10-szer olyan gyors. |
De nem biztos, hogy a játék ebből a sok okos fizikából mindent használni akar, lehet hogy egy játékhoz 1-2 alap képlet is elég. Ez játék függő.
Az is, hogy milyen pontos számítások kellenek, így elképzelhető, hogy valaki gyorsabb fizikát ír, mint amit a népszerű motorok használnak, hisz nem végez olyan számításokat amikre nincs szüksége. Az is lehet, hogy nem kell teljesen 3D-ben gondolkodni.
Szóval az "univerzális" dolgok lehetnek lassabbak, sokszor lassabbak is.
Persze az is lehet, hogy valaki hiába töri magát, évek alatt sem tudja megírni azt, amit elképzelt, és jobban jár ha mások által írt eljárásokat használ.
Sok "gyári" játékban sem tudják megírni mondjuk a kamerakezelést. Ennek sok köze nincs a fizikához, de szemlélteti, hogy a profiknak sem sikerül minden. |
Ha elég lelkes, otthon is meg tudja tanulni. De két-három év valóban kell neki. Meg annyi pénz, hogy ez alatt az idő alatt mást ne nagyon kelljen csinálni. 
Egyébként egyszer elkezdtem írni egy fizikai motrot. (Van egy kissé gyenge, de használható 3D-s motrom, azt próbáltam bővíteni)
Addig eljutottam, hogy ütközésvizsgálat.
Beleraktam a világba két, egymást vonzó kockát, amik a tömegüknek megfelelően el is kezdtek egymás felé gyorsulni. Ütközéskor a megadott energiaveszteséggel vissza is pattantak egymásról.
A gond akkor kezdődött, amikor rájöttem, hogy az ütközésvizsgálatom szép és jó, megmondja, ha két objektum összeütközött, de az ütközési merőleges megtalálása már gondot okozott. Inkább hagytam is az egész fizikát. Ez néhány éve volt. Azóta megutáltam már az egész 3D-t.
Bár a nyáron lehet, hogy újra előveszem.  |
| Korrekt, bocs, a 2d gémekre gondoltam. És még pontosabban a telefonra készült gémekre. |
ui: itt javasolják a fórumon a fizikai apikat...nos én meg nem.
2d-ben van esélyed, de 3-ban szinte semmi, de azért egyszer próbáld meg megírni. (valósághű ruha, haj, gumitehén - hogy csak a legfontosabbakat mondjam  )
Nem kell messzire menni, csak az XNA világába, és jól lehet látni, ha sajátot írsz mennyivel gyorsabb lehet.
Érdekelne vmi videó ezzel kapcsolatban.
A játékfizika nem egy túl absztrakt dolog, éppen pont a fizika könyv szabályait kell lekódolni.
Nem igazán. Ütközési pontok, lebegőpontos-ábrázolás pontatlanságai, vagy a testek diszkrét távokkal történő mozgatása nem léteznek a valóságban, egy rakat trükk kell, mire nagyjából úgy néz ki, ahogy kéne. Az ütközésvizsgálatot még csak-csak meg lehet írni típusonként:
gömb,kapszula,(henger,gúla),téglatest,'konvex test',trimesh,heightfield (ezeken kívül vannak még a szimulációban részt nem vevő objektumok, pl triggereknek). Ráadásul ált. minden kombinációjára érdemes külön megcsinálni, speciális optimalizációkkal.
Az ütközésre adott válasz sokkal bonyolultabb ennél.
Ezt még megfejelni szilárdtest és softbody algókkal, legyenek izületek is.
Utána jönnek a különböző térfelosztások, axissweep-es cuccok, szimlációs szigetek, callback-rendszer (speckó eseményekhez), scene mentése-töltése, memóriamanager (xna-ban ez nem kell - ez mondjuk igaz).
A tetejére meg kéne pár util: fizika alapú animációk (nézzen vmerre, menjen fel a lépcsőn, de szépen ám), járművek, rombolhatóság, folyadékok. Mindezt különféle menő egzotikus platformon tudja kb. ugyanúgy.
Egy szó, mint száz, én azért megnézném azokat a fránya apikat.
Csak azért írtam ezeket le, hogy aki megírná, az tudjon róla, hogy nem 10 sor. 10 év. Ha többen is írják egyszerre. |
Szia!
Az itt jelenlévőknek el tudom képzelni, hogy nincs túl nagy gém fejlesztési tapasztalatuk..2d se (de ne legyen igazam).
Nekem sincs túl sok csak 3 hónap, de végzetes következtetéseket nem vonnék le hogy mit lehet és mit nem.
Inkább ajánlok egy könyvet.
http://www.libri.hu/konyv/shaderprogramozas.html
Az első 110 oldal kimondottan fizikával, és elméletekkel foglalkozik, magyar nyelven nincs jobb pillanatnyilag.
Ne zavarjon hogy DX...az első része tényleg megpróbálja a fogalmakat tisztába rakni (egész jól).
Roland
ui: itt javasolják a fórumon a fizikai apikat...nos én meg nem.
Nem kell messzire menni, csak az XNA világába, és jól lehet látni, ha sajátot írsz mennyivel gyorsabb lehet.
A játékfizika nem egy túl absztrakt dolog, éppen pont a fizika könyv szabályait kell lekódolni...gyorsulás szögsebesség, elektromágnesesség ilyesmi...gravitáció...mindegyik nem több 10 sornál. Egy egy függvénybe beteszed őket 1 osztályon belül és jóccaka..szerintem. |
| Ne viccelj... |
És aki távmunkában dolgozik?  |
| Úgyse fog sikerülni, minek szenvedsz vele? Legalább 2-3 év c++ háttér (nem otthon ülős, kódolgatós, hanem napi 8 órában dolgozós), és akkor lesz esélyed összerakni. |
Üdv.
Fizikai api-kat érdemes nézegetni, vagy vagy 2 tucat: Physix,Havok,Bullet,Newton. Licenszeket is érdemes megnézni, mindegyiknek más. Vannak példaprogramjaik is c++-ban, fordításhoz legkönnyebb a 'Visual Studio C++ EE' (2008,2010).
Mindegyik hasonló fizikai elveken működik,sebesség-összehasonlításokról nem tudok. A Nvidia Physix elég széles körben elterjedt, sok tutor van hozzá - mondhatni az ipari standard. A Havok alacsony szintű, nagyon professzionális api (és kedvesek a csókák a fórumokon, de csak egy fórumja van az intel honlapján ), szóval sokat kell vele dolgozni. A Bullet egy opensource cucc, nagyon jó ez is - s mivel nyílt le lehet fordítani más rendszerekre is, nem csak pc-re. (amúgy mindegyiknek van portja Xbox360,PS3-ra is.)
|
Jól mondod.
Ha működik egy játék 2D-ben, akkor már könnyebb megvalósítani 3D-ben. De ha 2D változatot sem tudja valaki megcsinálni, akkor gondban lesz.
A témához még annyit, hogy az, hogy milyen módon tárolja az ember a játékot, szereplőket, pályát, grafikát, és milyen módon rajzolja ki, ez nagyban befolyásolja, hogy hogyan lehet ezeket mozgatni, milyen "fizikát" lehet alkalmazni. Így logikus ezt a két dolgot összekapcsolni. Persze ettől a két kódrészletet el lehet különíteni, meg ha kész a grafika utána tetszőlegesen bővíteni a mozgatást, fizikát. De azért "kicsit" össze vannak nőve.
Ha megnézzük a régebbi 3D-s játékokat, azokban nem volt nagy fizika, sok grafikai elem 2D volt, a szereplők lebegtek a levegőben ha meghaltak, vagy belógtak félig a falba.
Mégis ámultunk és azt éreztük minden valóságos. És az elején jó ha az ember ilyen gyengébb változatot tud készíteni, aztán lehet fejlődni tovább.
Akik most írják a szuper játékokat azok is sok éve gyakorolnak és ezért "klónozzák" a játékokat, mert könnyebb a meglévőt javítgatni, mint a nulláról újraírni mindent. De ha belegondolunk jobb is ez. |
Troll  |
| Snake, Tetris, Pac-Man, Breakout már megvolt 2D-ben? Ha nem akkor kezd ezekkel, aztán ugyanezek 3D-ben, utána esetleg valami bonyolutabb. |
Elnézést kérek az előítéleteim miatt, csak nekem php után nagy váltásnak tűnt a c++-os (meg gondolom d3d, shaderek, és az egyéb velejárók és/vagy egy korszerű engine megtanulása) játékfejlesztés. És akkor a legkisebb probléma a realtime fizika, mert előre legyártani egy-két előre számolt esetet az már nem trendi. Arról nem beszélve hogy egy sims1 szerű játékot még jó képességekkel és munkakedvvel is hosszú idő összehozni - szerintem....
kisnagycsaj hozzászólása Mekkelek5 (12:08) részére előzmény | privát | 2010.06.19. 12:17 | válasz
Grafikusi motor?
A fizikát hogy lehet a Grafikusi motorba berakni?
Vagy csak én nem értem hogy pontosan mit kell ezekkel csinálni?
...izé erről beszéltem, ja.
|
Grafikusi motor?
A fizikát hogy lehet a Grafikusi motorba berakni?
Vagy csak én nem értem hogy pontosan mit kell ezekkel csinálni?    |
Szerintem is korai még fizikán gondolkodni.
Amúgy úgy lehet, hogy megírja az ember a programot. Matek az egész.
Relatime attól lesz, hogy a grafikát, koordinátákat nem előre készíted el, hanem menet közben számolod.
De sok esetben elég előre kiszámolni, letárolni azt. Vagy egyszerű számításokat készíteni. A játékos úgyis többet gondol bele, mint ami valójában.
Kérdés, hogy 2D vagy 3D a grafika, illetve a "tér" amiben gondolkodunk. Bár egy sims szerű játék elkészítéséhez nem árt, vagy fél év programozói tudás. Ettől függetlenül ha átrakják a társalgóba a témát akkor el lehet beszélgetni benne.
Szintén kérdés, hogy most mit is akarsz.
Legegyszerűbb lehetőség, hogy a szereplő mozog a pályán, van egy tárgy, amihez ha hozzáér (és éppen üt), akkor a tárgy "képét" egyszerűen kicseréled egy összetört képre. Esetleg néhány pixellel arrébbcsúsztatod, esetleg csinálsz egy effektet, hogy repkednek szét a darabok.
De ehhez nem kell nagy fizika és egy átlag játékba ez is megfelel.
Régebben a 3D grafika sem volt bonyolultabb. Ma már nagyobbak az igények, de szerintem neked még nem kell ilyen minőséget produkálni.
De ahogy írták, legegyszerűbb megoldás, ha egy már meglévő grafikus motort használsz.
ui: utolsó hozzászólásodból látom, hogy 3D-ben gondolkodunk.
Ebben az esetben csinálsz egy "összetörés" animációt, meg kicsit elmozgatod a tárgyat ha van hely. Csak a koordinátákkal meg forgatással kell szórakozni. Szerintem.
ui2: a listádból a "grafikus motor" hiányzik. |
Miért mi kell még?Légyszi ne nézz szőkének.
Elkészítem a modelleket meg a pályát az irányítást meg a fizikát. nem? |
|
