játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5440
FZoli:    4892
Kuz:    4455
gaborlabor:    4449
kicsy:    4304
TPG:    3402
monostoria:    3284
DMG:    3172
HomeGnome:    2919
Matzi:    2519

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2185
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1625
syam:    1491
~Cre@tine~> - Tag | 702 hsz       Online status #58685   2007.06.07 11:03 GMT+1 óra  
Ez a fékes dolog még nem teljesen realisztikus akárhogy póbálkozok. Még egy replyt feldobtam a topicban az AGEIA fórumon hátha lesz rá valami válasz. Még majd egyéb helyeken is fogok próbálkozni a 2. kérdéssel is. Végső soron ettől még a project nem állt le csak bosszantóak ezek a kis bugok itt-ott. Ha lesz a két kérdésre érdemben válasz akkor majd kiírom ide a megoldást hátha más is küzd majd ilyenekkel.

   
TPG - Tag | 3402 hsz       Online status #58276   2007.06.04 13:00 GMT+1 óra  
Idézet
~Cre@tine~> :
Szerintem maradok ennél, ha már így kidolgozták. Van benne hiba nem is egy, de valahogy megoldható. Most újra nem akarom szó szerint feltalálni a kereket.


Én a mai napig nem tudtam eldönteni hogy melyiket válasszam, igazán az a bajom hogy nem tudom hogyan tudnám lemásolni a tireFunction-jét a WheelShape-nek (talán anisotropic friction-el meg egy kis hackel megoldható de még nem álltam neki hogy részletesen kidolgozzam az ötletet). Ha ezt sikerülne megoldanom akkor összerántanék egy saját kerékmodellt: Actor-re ugyanúgy lehet forgatónyomatékot adni; a felfüggesztés megoldható rugósított joint-okkal és ezeken felül még softbody-val vagy pressured cloth-al szimulálható a gumifelület konkrét viselkedése is (ha tearable-re állítom még defektet is kaphat).
Reality is almost always wrong. - House

   
~Cre@tine~> - Tag | 702 hsz       Online status #58273   2007.06.04 12:54 GMT+1 óra  
Még ilyenre nem volt szükség, de majd megpróbálom. Már másokkal is diskuráltam erről külföldi fórumokon akik szintén autós játékot írnak és nem nagyon tudtak rá mit mondani.
Az első problémáról éreztem hogy triviális, de a második az már tényleg kicsi bosszantó, de ramélem az is megoldódik. Még 1X köszi a megoldást.

   
TPG - Tag | 3402 hsz       Online status #58272   2007.06.04 12:52 GMT+1 óra  
Idézet
~Cre@tine~> :
Ja igen így már jó. Szóval a 2. problémára nincs ötleted abszolút, hogy mi okozza?


Nekem bug gyanús, lehet hogy újra fel kellene vetni a témát az AGEIA fórumon hátha most észreveszik. Azért a kérdések nagy százalékára szoktak AGEIA alkalmazottak válaszolni. Ha meg megint nem mondanak semmit még mindig lehet őket e-mail-ben zaklatni.
Reality is almost always wrong. - House

   
~Cre@tine~> - Tag | 702 hsz       Online status #58271   2007.06.04 12:52 GMT+1 óra  
Szerintem maradok ennél, ha már így kidolgozták. Van benne hiba nem is egy, de valahogy megoldható. Most újra nem akarom szó szerint feltalálni a kereket.

   
TPG - Tag | 3402 hsz       Online status #58270   2007.06.04 12:49 GMT+1 óra  
Idézet
~Cre@tine~> :
Köszi a segítséget. A nagy torque az megvan de akkor a kocsi majdnem fejreáll farolni nem farol.
Ez a "fék" inkább olyan mesterséges súrlódás beállító valaminek tűnik amolyan fizikai vészfék féleség, semiképpen sem igazi kerékfék.
....


Egyszerű ellentétes irányba ható forgatónyomaték, olyan mintha motorTorque-nak negatív értéket adnál azzal a különbséggel hogy a breakTorque-nál megállás után nem kezd tolatni. Egyébként lehet hogy nem érdemes szívni a WheelShape-el, lehet hogy gyors, van kimunkált tireFuncion-je és alapból készen van de mivel raycast alapú ezért soha nem lesz olyan minőségű a szimulációja mint egy rendes fizikai objektumokból felépült kerékmodellnek.
Reality is almost always wrong. - House

   
~Cre@tine~> - Tag | 702 hsz       Online status #58269   2007.06.04 12:48 GMT+1 óra  
Ja igen így már jó. Szóval a 2. problémára nincs ötleted abszolút, hogy mi okozza? Már másnak is gondot okozott ez nem csak nálam fordut ez elő.

   
TPG - Tag | 3402 hsz       Online status #58268   2007.06.04 12:44 GMT+1 óra  
Idézet
~Cre@tine~> :
Köszi a segítséget. A nagy torque az megvan de akkor a kocsi majdnem fejreáll farolni nem farol.
Ez a "fék" inkább olyan mesterséges súrlódás beállító valaminek tűnik amolyan fizikai vészfék féleség, semiképpen sem igazi kerékfék.
A 2. fgv-t meg majd megnézem, de azt nem teljesen értem ennek mi köze van ahhoz hogy a kerék a talajhoz ér és csúszik.. Nekem ez inkább egy kerék forgási sebesség beállító dolognak tűnik ami meg a fékhez lenne jó szerintem leállítani a kereket. Vagy az lenne a baj, hogy a talajhoz érés előtt kipördül a kerék és ezért pattan vissza a kocsi? Mert ha igen akkor két legyet lehetne ütni egy csapásra. Bár a kipördülést azt másképp is lehet szabályozni éppenséggel, van a motornál olyan beállítás hogy gear up RPM.


A kettes megoldás is még az egyes problémához tartozik.
Reality is almost always wrong. - House

   
~Cre@tine~> - Tag | 702 hsz       Online status #58267   2007.06.04 12:27 GMT+1 óra  
Köszi a segítséget. A nagy torque az megvan de akkor a kocsi majdnem fejreáll farolni nem farol.
Ez a "fék" inkább olyan mesterséges súrlódás beállító valaminek tűnik amolyan fizikai vészfék féleség, semiképpen sem igazi kerékfék.
A 2. fgv-t meg majd megnézem, de azt nem teljesen értem ennek mi köze van ahhoz hogy a kerék a talajhoz ér és csúszik.. Nekem ez inkább egy kerék forgási sebesség beállító dolognak tűnik ami meg a fékhez lenne jó szerintem leállítani a kereket. Vagy az lenne a baj, hogy a talajhoz érés előtt kipördül a kerék és ezért pattan vissza a kocsi? Mert ha igen akkor két legyet lehetne ütni egy csapásra. Bár a kipördülést azt másképp is lehet szabályozni éppenséggel, van a motornál olyan beállítás hogy gear up RPM.

   
TPG - Tag | 3402 hsz       Online status #58200   2007.06.04 05:56 GMT+1 óra  
Idézet
~Cre@tine~> :
Valaki foglalkozott már komolyabb szinten jármű fizikával?
Lenne két kérdésem is amire még az AGEIA fórumon se válaszoltak.
(vagy azért, mert annyira triviális, vagy mert ők se tudják a választ. )

1.: Nem találtam normális fékezést. Ha példákban használatos féket használom (brakeTorque) akkor lelassul a kerék forgása, meg csökken a surlódás, de ez távolról se igazi fék.
Direktben hogy lehet leállítani a kerekek forgását úgy, hogy rendesen kifaroljon a kocsi ahogy azt elvileg kéne neki?
vid1
....


Csak elméleti síkon foglalkoztam a WheelShape-el, meg az All-Wheel Drive nevű training progit alakítgattam át, szóval lényegében komolyabb szinten nem foglalkoztam még a dologgal de azért lenne egy tippem.
1, Elmebeteg méretű brakeTorque.
2, setAxleSpeed, viszont ehhez kell a NX_WF_AXLE_SPEED_OVERRIDE flag ami meg azzal jár hogy neked kell a kerék forgássebességét folyamatosan kiszámolni és frissíteni, asetBrakeTorque és a setMotorTorque abszolút használhatatlannál válik.
Reality is almost always wrong. - House

   
~Cre@tine~> - Tag | 702 hsz       Online status #58186   2007.06.04 03:57 GMT+1 óra  
Valaki foglalkozott már komolyabb szinten jármű fizikával?
Lenne két kérdésem is amire még az AGEIA fórumon se válaszoltak.
(vagy azért, mert annyira triviális, vagy mert ők se tudják a választ. )

1.: Nem találtam normális fékezést. Ha példákban használatos féket használom (brakeTorque) akkor lelassul a kerék forgása, meg csökken a surlódás, de ez távolról se igazi fék.
Direktben hogy lehet leállítani a kerekek forgását úgy, hogy rendesen kifaroljon a kocsi ahogy azt elvileg kéne neki?
vid1

2.: Mikor a kocsi kerekei felemelkednek, majd újra érintkeznek a talajjal, a kerekek "elfelejtik" a beprogramozott súrlódási értéket. Magyarul ugratás után, vagy nagy sebességű farolás közben egyszerűen visszadobja a talaj a kereket a leérkezés pillanatában ahelyett, hogy ugyanúgy csúszna, mint mikor egyfolytában érintkezik a talajjal. Ezt hogy lehet kiküszöbölni?
vid2

Hátha kapok válasz ezekre a "kardinális" kérdésekre. Addig is itt van 1-2 teszt.
Teszt1(rigid body)
Teszt2(jármű fizika)
Teszt3(robbantás)

   
TPG - Tag | 3402 hsz       Online status #49208   2007.03.27 14:29 GMT+1 óra  
Idézet
~Cre@tine~> :
50 felett már emberi szemmel nem érzékelhető a szaggatás, maximum a galambok veszik észre.


Persze mert 50 felett már nem lát el az ember szemüveg nélkül a monitorig.
Reality is almost always wrong. - House

   
~Cre@tine~> - Tag | 702 hsz       Online status #49198   2007.03.27 11:49 GMT+1 óra  
50 felett már emberi szemmel nem érzékelhető a szaggatás, maximum a galambok veszik észre.

   
TPG - Tag | 3402 hsz       Online status #44666   2007.01.13 12:09 GMT+1 óra  
Idézet
szombatha :
hogy egy kicsit konkrétabb legyek: az előbb idézett helpet olvasva korábban ezt irtam le a kódomban

....
gScene->setTiming(TimeStep, 1, NX_TIMESTEP_FIXED);
gScene->simulate( 1.0 / 30.0f );
gScene->flushStream();
...

Ha csak a helpet olvasod akkor ennek szerintem jónak kellene lenni, de nem jó, mert rángatóznak az objektumok.
Viszont ha "gScene->simulate( 1.0 / 60.0f );"-at használok akkor minden ok. Nem rángatózik, minden oké. Sajna nekem ez nem kerek, hogy miért..


A TimeStep is 1/30? Egyébként 1/30 nem túl sok, ilyenkor ugyebár a szimuláció 30 "FPS"-el megy ami a 3D-s progiknál sem túl sok.
Reality is almost always wrong. - House

   
szombatha - Tag | 97 hsz       Online status #44663   2007.01.13 11:43 GMT+1 óra  
hogy egy kicsit konkrétabb legyek: az előbb idézett helpet olvasva korábban ezt irtam le a kódomban

....
gScene->setTiming(TimeStep, 1, NX_TIMESTEP_FIXED);
gScene->simulate( 1.0 / 30.0f );
gScene->flushStream();
...

Ha csak a helpet olvasod akkor ennek szerintem jónak kellene lenni, de nem jó, mert rángatóznak az objektumok.
Viszont ha "gScene->simulate( 1.0 / 60.0f );"-at használok akkor minden ok. Nem rángatózik, minden oké. Sajna nekem ez nem kerek, hogy miért..

   
szombatha - Tag | 97 hsz       Online status #44655   2007.01.13 10:33 GMT+1 óra  
ezt olvastam én is, de ez önmagában nem elég, mert a simulate()-nek átadott elapsedtime-nak nem szabad egy fix értéket választani, mint ahogy a példaprogramok nagyrészében szerepel. A problémák akkor váltak nálam láthatóvá, amikor az autó tetejére "felültettem" a kamerát és növeltem a sebességet. Csúnya rángatózás lett az eredmény. Megvizsgáltam az egyik Ageia-Physx példaprogramot is és ugyanezt tapasztaltam

   
TPG - Tag | 3402 hsz       Online status #44632   2007.01.13 06:29 GMT+1 óra  
Idézet
szombatha :
jelenleg a physx dokumentáltsága nem túl erős vagy nincs nagyon reklámozva, igy elég nehéz a paramétereket kitalálni. Én a "simulate()" korrekt felparaméterezésével szivtam sokat. A példaprogramok által használt fix értékek nálam rángatózást eredményeztek. Pedig itt az a cél, hogy úgy paraméterezzünk, hogy gyors és lassú CPU-n is egyaránt ugyanúgy viselkedjen. De mindenképp érdemes vele foglalkozni és nekem is nagyon szimpi az ageia hozzáállása.



Ez a SDK-val települő doksiból fényképeztem, perfektül leír mindent. Ennél több már nem nagyon kellhet.
Reality is almost always wrong. - House

   
szombatha - Tag | 97 hsz       Online status #44600   2007.01.12 23:36 GMT+1 óra  
jelenleg a physx dokumentáltsága nem túl erős vagy nincs nagyon reklámozva, igy elég nehéz a paramétereket kitalálni. Én a "simulate()" korrekt felparaméterezésével szivtam sokat. A példaprogramok által használt fix értékek nálam rángatózást eredményeztek. Pedig itt az a cél, hogy úgy paraméterezzünk, hogy gyors és lassú CPU-n is egyaránt ugyanúgy viselkedjen. De mindenképp érdemes vele foglalkozni és nekem is nagyon szimpi az ageia hozzáállása.

   
~Cre@tine~> - Tag | 702 hsz       Online status #44536   2007.01.12 07:21 GMT+1 óra  
Idézet
szombatha :
egyébként én addig amig nem találkoztam a physx-szel, addig ODE-ztam. Aztán az addigi kódjaimat átirtam physx-esre és végülis eddig nem bántam meg. A physx baromi gyors és ráadásul stabil is. Az ODE-t sajnos nagyon könnyű megfektetni, nagyon oda kell figyelni, hogy mit csinál az ember. Az eddigi tapasztalataim alapján az OpenSource-sága mellett van még egy jó tulajdonsága az ODE-nak amiben veri a physx-et, ez pedig az, hogy élethübb a szimuláció minősége. Irtam egy kis programot ami egy kormányozható négykerekű járművet mozgat a talajon és kürülötte pedig mindenféle lökködhető objektumok vannak. Kapcsolható volt a fizikai motor ODE és Physx között. Hát bizony nagy különbségeket tapasztaltam az ODE javára. Az igazsághoz azért hozzátartozik, hogy elég sok paramétere van a physx-nek (igaz az ODE-nek is) és lehet hogy még lehetett volna csiszolgatni a physx-es kódot és akkor az is élethűbb lett volna


Jármű fizikával fogllakoztam én is. PhysX ben ez egy kicsit (nagyon) körülményesebb az igaz (főleg a farolás része), de ugyanúgy megoldhatod benne mint akrámelyik másik engine-ben csak tudni kell, hogyan.
Az ODE borzalmasan lassú, szóval onnantól kezdve mivel mind két engine ingyenes, egyértelmű a választás.
ODE-nel nem igazán van obejct culling, vagy nem tudom minek hivják, szóval ha valami nem mozog akkor arra is számol fölöslegesen.

Ezt a hozzászólást ~Cre@tine~> módosította (2007.01.12 07:28 GMT+1 óra, ---)

   
szombatha - Tag | 97 hsz       Online status #44531   2007.01.12 06:18 GMT+1 óra  
egyébként én addig amig nem találkoztam a physx-szel, addig ODE-ztam. Aztán az addigi kódjaimat átirtam physx-esre és végülis eddig nem bántam meg. A physx baromi gyors és ráadásul stabil is. Az ODE-t sajnos nagyon könnyű megfektetni, nagyon oda kell figyelni, hogy mit csinál az ember. Az eddigi tapasztalataim alapján az OpenSource-sága mellett van még egy jó tulajdonsága az ODE-nak amiben veri a physx-et, ez pedig az, hogy élethübb a szimuláció minősége. Irtam egy kis programot ami egy kormányozható négykerekű járművet mozgat a talajon és kürülötte pedig mindenféle lökködhető objektumok vannak. Kapcsolható volt a fizikai motor ODE és Physx között. Hát bizony nagy különbségeket tapasztaltam az ODE javára. Az igazsághoz azért hozzátartozik, hogy elég sok paramétere van a physx-nek (igaz az ODE-nek is) és lehet hogy még lehetett volna csiszolgatni a physx-es kódot és akkor az is élethűbb lett volna

   
szombatha - Tag | 97 hsz       Online status #44526   2007.01.12 05:55 GMT+1 óra  
a samplék azért nem futnak le mert alapból HW-ra van állitva. Rá kell kereseni a main cpp-jében arra hogy _HW ha megtaláltad azt át kell irni _SW-re és igy már menni fog. Arra kell vigyázni, hogy van egy if ahol csak ellenőrzi, hogy HW támogatás van-e beállitva. Azt természetesen nem kell átirni!

   
Gabor - Tag | 32 hsz       Online status #44323   2007.01.10 07:13 GMT+1 óra  
Na, megvan asszem a megoldás, elég hülyén tettem fel a kérdést, sorry.

   
Gabor - Tag | 32 hsz       Online status #44230   2007.01.09 06:59 GMT+1 óra  
Sziasztok!

Most kezdtem el az Ageia PhysX tanulását... Nem könnyű, sok a változó, több, mint a directX-be, egy picit nehézkes felfogni a gondolkodását... Van néhány dolog, amit nem értek: elöszöris, a springeknél... Mi a damper tényező? Ha én egy gumikötelet elkezdek húzni, akkor minél jobban nyújtom ki (a relax távolságtól), annál nagyobb lesz az erőhatás a másik oldalról, ezt két változó adja meg:
NxSpringAndDamperEffectorDesc::springMaxCompressForce
NxSpringAndDamperEffectorDesc::springDistCompressSaturate
véleményem szerint az első egy távot ad meg, a második pedig, hogy ha eddig a távig elnyúlik a "kötél", akkor mekkora erő éri ellentétes irányból (és persze ha kevesebbet húzok a kötélen, akkor arányosan annyival kisebb lesz a visszahúzó erő).
Vagy a damper (szótárban lengéscsillapító) azt jelentheti, hogy akkor mennyire húzza maga után a kötél másik oldalán lévő objektumot, vagy nemértem...

   
Lexx - Tag | 117 hsz       Online status #39753   2006.12.06 01:47 GMT+1 óra  
köszi, este megnézem...
   
syam - Törzstag | 1491 hsz       Online status #39674   2006.12.05 05:38 GMT+1 óra  
egy #include<windows.h> a fiziksz include elé nekem elég volt. ( és lehet, hogy dob majd minmax hibát a fordításkor: ekkor #define NOMINMAX. ez a windows.h miatt kell, ha már volt egy windows.h include, amit a fiziksz nem lát)
alias aalberik
   
Lexx - Tag | 117 hsz       Online status #39672   2006.12.05 05:02 GMT+1 óra  
Joh, ha jól láttam akkor kellenek a dll interface könyvtárak és akkor ez az asm meg valahol _int64 definició hiányára panaszkodik...
   
syam - Törzstag | 1491 hsz       Online status #39663   2006.12.05 03:50 GMT+1 óra  
hi Lexx,

nagy mingw-s vagyok ergo gcc-vel használom a fizikszet. pár dolgot kell csak átírni és megy (pl. van benne egy asm kódrész, amikor egy lépésben lekéri egy szög szinuszát és koszinuszát. kb. ennyi az össz "komplikáció" )
ha gondolod bármiben segítek
alias aalberik
   
beast - Törzstag | 1241 hsz       Online status #39662   2006.12.05 03:39 GMT+1 óra  
A VC2005EE-vel készitett cuccot legálisan pénzre cserélheted...

   
Lexx - Tag | 117 hsz       Online status #39656   2006.12.05 00:39 GMT+1 óra  
Egy kérdésem lenne:
Tudtok olyat, hogy lehet felhasználni GCC környezetben? Mert úgy láttam csak MS környezetet szeret. Én nekem meg nincs erre pénzem, a free verzióval meg tudtommal nem készíthetek kereskedelmi rendszereket...
   
TPG - Tag | 3402 hsz       Online status #39587   2006.12.04 06:43 GMT+1 óra  
Idézet
syam :
ez oké, csak nekem másra is kell a collision detection
van 1 rövid cucc róla ageián (event triggered by contact vagy vmi ilyesmi): pl. belemész egy gömbbe és nem akarok semmi fizikát, csak, h megmondja, h benne vagyok a gömbben

fiziksznek nincs manualja (ha már manuteteje nincs)?


Az SDK dokist érdemes böngészni ezerrel. Egyébként a Training Program 304 Trigger Report-ja pont a témával foglalkozik. Ahogy az SDK doksiban nézem semmi extra nincs a cuccban (még sohasem használtam), annyi hogy a shape csinálásakor megadod a NX_TRIGGER_ENABLE flag-et és így csinálsz vele actor-t meg csinálsz egy osztályt egy függvénnyel amit a Physx terrorizálhat ha valami történik a triggerrel (belemegy valami, esetleg benne is marad vagy talán ki is jön ). Egyébként ilyen user report-okból van jó néhány érdemes átnézegetni őket mert hasznosak lehetnek.
Reality is almost always wrong. - House

   
syam - Törzstag | 1491 hsz       Online status #39584   2006.12.04 06:14 GMT+1 óra  
ez oké, csak nekem másra is kell a collision detection
van 1 rövid cucc róla ageián (event triggered by contact vagy vmi ilyesmi): pl. belemész egy gömbbe és nem akarok semmi fizikát, csak, h megmondja, h benne vagyok a gömbben

fiziksznek nincs manualja (ha már manuteteje nincs)?
alias aalberik
   
TPG - Tag | 3402 hsz       Online status #39576   2006.12.04 05:34 GMT+1 óra  
Idézet
syam :
hmm, valamelyik sample foglalkozik sima collision detectionnel (pl. 2 megadott actor/shape ütközése) ?


A training programs 1xx-es végig ilyen témával foglalkozik csak kicsit bonyolultabb dolgokkal. (A collision detect-et a Physx intézi helyettünk csak kell egy Shape amiből Actor csinálsz amit betolsz az aktuális Scene-be és kész a többi már megy magától; csak a simulate->flushStream>fetchResults triót kell lehetőleg frame-enként hivogatni és frissíteni a grafikai objektumok world mátrixát a Physx által számolttal)
Reality is almost always wrong. - House

   
syam - Törzstag | 1491 hsz       Online status #39544   2006.12.03 17:09 GMT+1 óra  
hmm, valamelyik sample foglalkozik sima collision detectionnel (pl. 2 megadott actor/shape ütközése) ?
alias aalberik
   
syam - Törzstag | 1491 hsz       Online status #39542   2006.12.03 16:07 GMT+1 óra  
thx


ez nagyon sz...omorú
alias aalberik
   
TPG - Tag | 3402 hsz       Online status #39538   2006.12.03 15:40 GMT+1 óra  
A System Software telepítése tudtommal elkerülhetetlen, nélküle sehogy nem fognak a PhysX SDK-t használó cuccok elindulni, az egész olyan mintha DX-es progit akarnál telepített DX nélkül futtatni (kb ugyanígy működik a System Software is).
Idézem a Knowledge Base cikket a devsupport.ageia.com-ról:
Idézet
What is the "PhysX System Software" and why is its installation required--especially if one does not have PhysX HW?

First, some definitions are in order, and then the components of the System Software will be defined in detail. In all cases, we will propose analogies from the graphics world that developers may be familiar with:

PhysX HW: Add-in PC hardware from AGEIA that allows PC systems with the hardware to run physics simulation computations at a much higher speed than a CPU can accomplish, alone. Because of the computational load, some of the types of features enabled by these computations may only be implemented on the hardware through the various PhysX SW components (SDK, runtime, driver, firmware).

PhysX SDK: A Software Development Kit from AGEIA that allows developers to add physics simulation functionality to a game without having to worry about the underlying hardware platform (PhysX HW, PC, PS3, or Xbox 360). This is analogous to the DirectX SDK, which isolates developers from specific driver or hardware concerns while adding graphics functionality to a game.

PhysX System Software: This is the installer package that includes all components required to enable PhysX SDK features of a game on a developer's or gamer's PC. It includes the PhysX Runtime, PhysX FW (including all past versions), and PhysX Driver. It is often simply (and erroneously) called the "driver" by developers and consumers--who may question why it needs to be installed by a consumer who does not have PhysX HW. The actual driver and FW components are just a small part of this installer, and are there as a convenience (and can be made silent at the discretion of the developer), so the System Software should be considered a necessary installation package, such as the DirectX runtime for games that use the DirectX SDK. Details on each of its components are below:

* PhysX Runtime: The graphics analogy for this is the DirectX Runtime, which consumers must install on their computers in order to support games that were developed by a game developer to provide graphics features present in a particular version of the DirectX SDK. Thus, most games automatically include the proper DirectX installer for their game to ensure that the consumer can play the game with minimal hassle (ie, having to go to Microsoft to download the latest version of the DirectX runtime). The runtime interfaces with the application, and is responsible for providing software fallbacks for any supported features when hardware is not present. There may be debug versions of the runtime that allow the developer to force software emulation and to enable him to step through the code to determine where a problem may exist, or at very least enable additional debug output.

* PhysX FW: Since the PhysX HW is a programmable, multi-processor element, features are mostly enabled through AGEIA-developed software that runs on the HW, itself--called "firmware". The graphics analogy is shader programs, but better analogies would be BIOS updates or the arcade emulation ROMs made popular by MAME--as the functionality is much more broad and is enabled by the manufacturer, not the game developer (at this time), as it is very hardware-specific.

* PhysX Driver: This is the system-level software responsible for communicating directly between the PhysX HW, PhysX Runtime, and the operating system (currently, only Windows is supported). Its main duty is simply to load the PhysX Firmware onto the hardware. Thus, the driver is almost never updated--new PhysX functionality, performance and bug fixes are applied to the SDK, firmware, and runtime components. The graphics analogy is 3D hardware drivers, but these drivers tend to do a lot of the SW-side implementation or preparation of graphics features, and thus are quite large and require frequent update and WHQL certification--so the analogy is not precise. During System Software installation, the installation of the driver will cause a search for PhysX HW. If none is present, there is no need to be concerned about the warning that HW is not present--simply do not try to use the non-existant in your applications! If you try to create a HW scene when no HW is present, the SDK will return a NULL scene pointer, which your application can use to control its code path.
Reality is almost always wrong. - House

   
syam - Törzstag | 1491 hsz       Online status #39536   2006.12.03 15:21 GMT+1 óra  
udvz,

nem tudjátok, hogy mi indítja el a physX virtuális gépét?

Idézet
Megtudnátok mondani hogy miért állnak le a samples .exe-ek azzal hogy a *.exe hibát észlelt ezért leállt küldhet üzenetet a microsoftnak blablabla. A másik hogy fordításnál (pl lesson101 box on a plane project) miért áll le kivétellel a program

(azt hiszem az a gondja, h nem indul el a virtuális gép)

sajnos nem tudom felrakni a coret (nem saját gép) és hátha meg lehetne kerülni valahogy az installt
alias aalberik
   
ANg - Tag | 9 hsz       Online status #37580   2006.11.20 13:53 GMT+1 óra  
Hi!

Megtudnátok mondani hogy miért állnak le a samples .exe-ek azzal hogy a *.exe hibát észlelt ezért leállt küldhet üzenetet a microsoftnak blablabla. A másik hogy fordításnál (pl lesson101 box on a plane project) miért áll le kivétellel a program

Unhandled exception at 0x00409c43 in Lesson101DEBUG.exe:0xX0000005: Access violation reading location 0x000000000.

Azt hol írja le hogy milyen libeket meg headereket kell hozzáadni?(gondlom opengl32,glut, ??).Bocs a bénaságomért.

   
TPG - Tag | 3402 hsz       Online status #37385   2006.11.18 12:54 GMT+1 óra  
Idézet
takraj :
DX10 ben úgy hallottam van valami Geometric Shader... elvileg ezt minden DX10-es kari tudni fogja. Namost, ez nem olyan lenne, mint a Physx csak GPU-val? Nem tud róla valaki bővebb információt, netán összehasonlítást a Physx-el?


A Geometry Shader a DX10 által felállított szabvány része (a Shader Modell 4 legfőbb újítása). Hasonló a Vertex Shader-hez (helyileg a Vertex Shader után de a Pixel Shader előtt van) viszont nem csak egy vertex adatait kapja meg egyszerre hanem egy egész primitív komplett adatait (három vertex háromszögeknél, kettő vonalaknál és egy pontoknál). Ezen kívül még lekérheti a szomszédos primitívek adatait is (háromszögeknél +3 primitív, vonalaknál +2). Ezen kívül képes arra hogy új vertexeket hozzon létre amikkel új primitíveket képez, render target array használatánál meg lehet vele határozni hogy az adott primitívet melyik RT-re kell raszterezni (egy komplett cube map-et meg lehet tölteni így egy menetben, nem kell hozzá hat mint idáig) stb. Elvileg akár fizikai számításokra is lehet használni, de sok egyéb másra is,
Reality is almost always wrong. - House

   
takraj - Tag | 77 hsz       Online status #37383   2006.11.18 12:37 GMT+1 óra  
DX10 ben úgy hallottam van valami Geometric Shader... elvileg ezt minden DX10-es kari tudni fogja. Namost, ez nem olyan lenne, mint a Physx csak GPU-val? Nem tud róla valaki bővebb információt, netán összehasonlítást a Physx-el?
..:: TakRaj ::..

   
TPG - Tag | 3402 hsz       Online status #37350   2006.11.18 09:37 GMT+1 óra  
Idézet
~Cre@tine~> :
Hmm, hát én se tudok magyar leírást, de talán már hozzá is szoktam, hogy általában mindent angolul kell nézni.
Szerintem elég szép számú tutor van hozzá az SDK-ban. Nem sok fizikai engine-t láttam ahol ilyen sok tutor lenne. Én mondjuk Ogre-vel használom a PhysX-et és meg kell, hogy mondjam marha egyszerű a használata. Szinte ugyanúgy betöltöm a mesht, csak ittt annyival több, hogy vannak fizikai paraméterek is. Más fizikai engine-t nem ismerek mélyrehótan, de nagyon tetszenek a ezek a szabályozások: sűrűség, súrlódás, rugalmasság stb. Csináltam egy rugalmas testet és teljesen olyan volt mintha gumiból lenne. Még bizonyos szinten össze is nyomódott, persze csak látszólagosan.


Nekem is ez az egyetlen és első fizikai motor amit használok és tökéletesen meg vagyok vele elégedve. Tényleg egyszerű használni, a sebességére nem lehet panasz és a szimuláció minősége is teljesen korrekt.
Reality is almost always wrong. - House

   
~Cre@tine~> - Tag | 702 hsz       Online status #37346   2006.11.18 08:57 GMT+1 óra  
Hmm, hát én se tudok magyar leírást, de talán már hozzá is szoktam, hogy általában mindent angolul kell nézni.
Szerintem elég szép számú tutor van hozzá az SDK-ban. Nem sok fizikai engine-t láttam ahol ilyen sok tutor lenne. Én mondjuk Ogre-vel használom a PhysX-et és meg kell, hogy mondjam marha egyszerű a használata. Szinte ugyanúgy betöltöm a mesht, csak ittt annyival több, hogy vannak fizikai paraméterek is. Más fizikai engine-t nem ismerek mélyrehótan, de nagyon tetszenek a ezek a szabályozások: sűrűség, súrlódás, rugalmasság stb. Csináltam egy rugalmas testet és teljesen olyan volt mintha gumiból lenne. Még bizonyos szinten össze is nyomódott, persze csak látszólagosan.

Ezt a hozzászólást ~Cre@tine~> módosította (2006.11.18 09:09 GMT+1 óra, ---)

   
TPG - Tag | 3402 hsz       Online status #37205   2006.11.17 07:48 GMT+1 óra  
Idézet
ANg :
HI!

Én innen értesültem arról hogy a motor ingyenes és egyből le is szedtem még a kódolásig nem jutottam el csak a lesson-öket néztem meg és hát ööööö.... elég ütős na és ingyenes is úgyhogy én biztos mellette voksolok. Lenne egy kérdésem tudtok hozzá valami magyar doksit mert láttam hogy angol az oldalon van egy rakat de hát én meg az angol.....ha vki tudna adni megköszönném.by


Én nem tudok róla hogy lenne magyar leírás de lehet hogy a többiek jobban értesültek és ismernek ilyet.
Reality is almost always wrong. - House

   
ANg - Tag | 9 hsz       Online status #37199   2006.11.17 07:19 GMT+1 óra  
HI!

Én innen értesültem arról hogy a motor ingyenes és egyből le is szedtem még a kódolásig nem jutottam el csak a lesson-öket néztem meg és hát ööööö.... elég ütős na és ingyenes is úgyhogy én biztos mellette voksolok. Lenne egy kérdésem tudtok hozzá valami magyar doksit mert láttam hogy angol az oldalon van egy rakat de hát én meg az angol.....ha vki tudna adni megköszönném.by

   
TPG - Tag | 3402 hsz       Online status #37077   2006.11.16 10:37 GMT+1 óra  
Idézet
~Cre@tine~> :
Itt a pontos licensz:
" Free:

* Commercial & non-commercial use on PC
o Must keep registration information currect
o Must agree to the EULA at the time of download (pops up, but is copied below)
o Available for Windows & Linux (soon)
o No PhysX HW support requirement
* PS3 platform (through Sony pre-purchase)
* All platforms through some of our middleware partnerships, such as UE3, Gamebryo 2.2, and others

$50k per platform:

* Xbox 360
* Fee may be waived at our discretion for multi-platform developers providing PC HW support
* Fee may be waived at our discretion for some Tools & Middleware providers"


Nincs ezzel probléma. Regisztrálva vagyok, pontos adatokat adtam meg és elfogadtam az EULA-t más meg nem kell.
Reality is almost always wrong. - House

   
Seeting - Törzstag | 2306 hsz       Online status #37047   2006.11.16 09:00 GMT+1 óra  
Pöpec
   
~Cre@tine~> - Tag | 702 hsz       Online status #36978   2006.11.16 03:19 GMT+1 óra  
Itt a pontos licensz:
" Free:

* Commercial & non-commercial use on PC
o Must keep registration information currect
o Must agree to the EULA at the time of download (pops up, but is copied below)
o Available for Windows & Linux (soon)
o No PhysX HW support requirement
* PS3 platform (through Sony pre-purchase)
* All platforms through some of our middleware partnerships, such as UE3, Gamebryo 2.2, and others

$50k per platform:

* Xbox 360
* Fee may be waived at our discretion for multi-platform developers providing PC HW support
* Fee may be waived at our discretion for some Tools & Middleware providers"

   
~Cre@tine~> - Tag | 702 hsz       Online status #36570   2006.11.14 02:49 GMT+1 óra  
Na megnéztem az NxOgre tutorokat is és jól fut ez.

   
~Cre@tine~> - Tag | 702 hsz       Online status #36562   2006.11.14 00:04 GMT+1 óra  
Tegnap azért leszedtem az sdk-t, drivert megnéztem az exéket. Szépek meg minden, de szemmel láthatóan lassúak. Anno még kipróbáltam egy kockás demót Irrlicht-el az pöpecül ment, de ezek az új demók, mintha nagyon belassultak volna. Van valami beállítás amivel be lehet állítani, hogy PPU nélkül is normálisan fusson, vagy az új ingyenes verziók már csak PPU-val futnak normálisan?
Még Ogre alatt megnézem a demókat, de ha azok is így fognak szaggatni akkor nincs értelme ezt használni. (Még ott lesz a grafika, normal mapping AI meg minden, nem lenne jó, ha NASA gép kéne egy GP-hez) A Newton sokkal gyorsabb ettől legalábbis eddig így láttam azán lehet fordul a kocka a szó szoros értelmében.

(Picit fura, hogy eddig milliókat kellett fizetni a kiadóknak, stb cégeknek most mem nagyhirtelen ingyenes lett. )

   
~Cre@tine~> - Tag | 702 hsz       Online status #36551   2006.11.13 13:48 GMT+1 óra  
Hát igen. Ez az erőforrásos dolog azért érdekes. Itt a cell factor nevű játékról 1-2 infó:
"From my point of view, CellFactor: Combat Training is a next-next-generation game. I can barely run it on lowest details in 800x600 on my Intel Pentium 4 3GiHz, 1024GiB RAM and nVidia GeForce 6800GT with about 15-20 fps. Explosions reduce the framerate even further. "

Recommended (Run "CellFactor Low Graphics":
2 ghz Pentium 4
1024 mb system RAM
256 MB GeForce 6800 or Radeon X800 (game will scale down the Texture Size to 50%)
AGEIA PhysX Hardware with 2.4.9 driver installed
The demo is no longer playable when I enable bots (5-10 fps)... "

A cellfactor demóról készült videót láttam, de azonkívül, hogy supermant játszik egy robot és röptet pár tucat tárgyat, nem láttam különösebb dolgokat benne. Ahhoz képest marha lassan megy, egy nem gagyi gépen is. Picit dejavu érzésem volt, mint anno a Doom3-nál. Az is csak egy engine bemutató volt maga a játék felejthető volt erősen... (ajánlott gépigény ott ugye 512 mb os VGA volt a maximális textúrákhoz ez még azért ma sem kevés és ehhez képesz elég kockafejűek mai szemmel a figurák benne ) Nem tudom tényleg az lenne a jövő játékok irányadója, hogy most tucatnyi tárgy röpköd meg esik az amber fejére, de mindenestere érdekes volt. Valószínűleg ennek is meglesz a helye, mondjuk egy hangyaszimulátor vagy akvárium szimulátor vagy valami ilyesmi. Mondjuk egy sima focis játéknál nem tudom ennek milyen hasznát lehetne venni, mert a rongybaba és a labda szimulációt már akármelyik mezei free engine is csuklóból lekezeli...

Szerintem a direct physics olyasmi lesz, mint a direct sound, tehát mondjuk a newton, vagy, ode, is tudja majd ahasználni, ahogy az openal a direct sound-ot.

   
TPG - Tag | 3402 hsz       Online status #36525   2006.11.13 11:48 GMT+1 óra  
Idézet
~Cre@tine~> :
Ez azért érdekes mert én meg úgy tudom a PS3 fejlesztés ingyenes a PC meg nem. De ha tényleg PC-re is ingyenes, akkor már érdemes lesz mindekinek ebben fejleszteni! Végül is logikus lépés lenne, tekintve, hogy az MS DX10 physics szintén ingyenesen elérhető lesz, amikor kijön. A PPU kártyát meg bőven gyártási költségen felül fogják adni igyis-úgyis. Még nézegetem a híreket és persze az ogrenewt mellett mostmár akkor elvileg az NxOgre is egy alternatívává válhat.


Nemrég módosították az EULA-t, az tartalmazza hogy a jelenlegi legfrisebb 2.6-os verziótól felfelé ingyenes lesz az összes SDK verzió minden célra PC-n. PS3-on valószínü azért lehet ingyenes mert a Sony kiperkálja a megfelelő összegeket érte (gondolom egyébként fogalmam sincs róla hogy működik PS3-on az egész dolog). Az MS-féle Direct Physics egyenlőre sztem még közelsem jár ahhoz hogy elkészüljön, az AGEIA egyenlőre erősen vezet. Viszont ha egyszer ez az MS-féle cucc elkészül és eléri azt a szintet hogy használni is érdemes legyen akkor sztem tarolni fog legalábbis DX-es körökben tuti. Eleve úgy tervezik a cuccot hogy a D3D-vel teljesen együttműködjön és nem is kell hozzá gyorsító kártya mert a GPU-t lesz képes fizikai gyorsításra is befogni (és mint láttuk a PH!-s tesztekből egy DX10-es kariban van kakaó bőven, maradni fog még ott a fizikának is).
Reality is almost always wrong. - House