|
|
|
|
én nem használtam nxogre-t,a newton sdk szimpatikusabb,nem veszi ki a kezed alól a mesh managementet sem, ezzel a wrapperrel próbáld ki.
|
|
|
|
Idézet
ibax :
nem FPS játék lesz, csupán a diplomamunkámat folytatom...
nekem az is elegendő lenne, ha lenne egy két alap kód(részlet), amiben megmutatják, hogy hogyan kell integrálni az ogre-ba a physX-et, mert azzal már talán el tudnék indulni.
az általad javasolt link talán segít majd ebben, köszi szépen
esetleg te (vagy itt bárki más) foglalkoztál már NxOgre-vel?
Próbálgattam már igen. Annyi, hogy a befordított libet kell linkelned és használni, mint bármilyen más libet.
dynamic calc = GetCalculator();
var sum = calc.Add(10, 20);
|
|
|
|
nem FPS játék lesz, csupán a diplomamunkámat folytatom...
nekem az is elegendő lenne, ha lenne egy két alap kód(részlet), amiben megmutatják, hogy hogyan kell integrálni az ogre-ba a physX-et, mert azzal már talán el tudnék indulni.
az általad javasolt link talán segít majd ebben, köszi szépen
esetleg te (vagy itt bárki más) foglalkoztál már NxOgre-vel?
|
|
|
|
Ha már tárgyakat szeretnél lökdösni, amik gurulnak, nekimennek a falnak stb. ahhoz már kell a fizika. És ha már kell, akkor egyszerűbb egyúttal a mászkálást is azzal megoldani.
Ez most FPS játék lesz?
Idézet
ibax :
igazából az NxOgre-t találtam (keresgélés után) a legmegfelelöbbnek, csupán tutorialokban hiányos. fórumjai persze vannak, de ha lenne egy olyan wiki-s oldala, mint az ogre-nek, egyszerübb lenne a "kezdők" dolga is...
Hát az sajnos nem nagyon van így marad az intellisense és a forrás elemzése + fórum. Kis kezdemény már alakul.
Padló, grav már helyből van. Ehhez csak be kell tölteni a modelleket és kész.
dynamic calc = GetCalculator();
var sum = calc.Add(10, 20);
|
|
|
|
teljesen jó MaximumViolence meglátása... ezzel megoldható lenne...
ezt a tutorialt már ismertem, sőt ezeken már végig is mentem, és nagyon hasznosnak bizonyultak. esetemben azonban egy házban kéne sétálnom, lépcsőknek, bútoroknak, falaknak ütközve. ehhez kéne nekem az ütközésdetektálás, sőt a kisebb objektumokat akár "odébb" is lehetne tolni. persze ez nem tudom milyen erőfeszítéseket igényel, mindenesetre lényegesen "életszerübb" lenne...
igazából az NxOgre-t találtam (keresgélés után) a legmegfelelöbbnek, csupán tutorialokban hiányos. fórumjai persze vannak, de ha lenne egy olyan wiki-s oldala, mint az ogre-nek, egyszerübb lenne a "kezdők" dolga is...
Igy marad az olvasgatás, keresgélés, fórumozás, stb...
Minden segítséget szívesen fogadok...  ))
|
|
|
|
Idézet
ibax :
ezek szerint találnom kéne tutorial-okat a physX telepítése után...
nemsokára hazaérek, utánanézek, köszönöm a tippet.
nekem collision detection amiatt kell, hogy egy házban tudjak mászkálni... vagyis ne essek le a semmibe (ütközésdetektálás a talaj és köztem), valamint ne tudjak átmenni a falon, dolgokon. a ház modell maya-ban már megvan, gondolom valahogy majd át tudom exportálni ogre által emészthető formátumra, utána meg beolvasni, és ebben a házban szeretnék mászkálni...
köszi a tippet
ha csak ütközésvizsgálat kell,semmi komolyabb,akkor nem kell physX,egyszerűbb ez a tutorial
|
|
|
|
Pályához:
Kód: _aScene->createBody("", new TriangleMeshShape("myHouse.mesh"), Ogre::Vector3::ZERO), "mass: 1, static: yes");
Dinamikus labda objektumhoz::
Kód: ballMaterial = _aScene->createMaterial("ballMaterial");
ballMaterial->setAll(1.0, 0.1, 0.1); //bounce, dFriction, sFriction;
ball1 = _aScene->createBody("ball.mesh", new SphereShape(1.0, "material: ballMaterial"), pos, "mass: 100.0");
ball1->setLinearVelocity(Ogre::Vector3::ZERO);
ball1->setLinearMomentum(Ogre::Vector3::ZERO);
ball1->setAngularVelocity(Ogre::Vector3::ZERO);
//stb
A szintaxis alapjaiban változik verzióról-verzióra, szóval ki tudja most milyen. Fórumon biztos van rá tipp.
Na most a pályánál nem mindegy mit töltesz be. A fenti példában láthatatlan a fizikai object ezegy nagyonlow poly model. És ami látszik azt sima ogre betöltéssel lehet hype-osabbra. Így lehet optimalizálni.
Szerk.: Ami talán az elején zavaró, vagy nekem legalábbis újszerű volt elsőre, az az, hogy fizikai modellt ha betöltök, akkor a mesh is hozzá van csatolva. Mozgatni, növelni, vagy bármit csinálni innentől kezdve csak a body-val lehet a mesh automatikusan frissül hozzá pozicióban, méretben stb. Képzeletben mindig egy láthatatlan fizikai objektumot kell odaképzelni a láthatóban, csak ez valamikor egybe van csatolva máskor meg célszerű külön választani/különkezelni egymástól.
Ezt a hozzászólást Csizmás Kandur módosította (2008.11.04 07:28 GMT+1 óra, ---)
dynamic calc = GetCalculator();
var sum = calc.Add(10, 20);
|
|
|
|
Idézet
ibax :
ezek szerint találnom kéne tutorial-okat a physX telepítése után...
nemsokára hazaérek, utánanézek, köszönöm a tippet.
nekem collision detection amiatt kell, hogy egy házban tudjak mászkálni... vagyis ne essek le a semmibe (ütközésdetektálás a talaj és köztem), valamint ne tudjak átmenni a falon, dolgokon. a ház modell maya-ban már megvan, gondolom valahogy majd át tudom exportálni ogre által emészthető formátumra, utána meg beolvasni, és ebben a házban szeretnék mászkálni...
köszi a tippet
Ja, ahhoz semmit nem kell külön csinálnod. Egyszerűen createBody, meg create static mesh meg ilyenek a többit a PhysX elintézi. NXOgre fórumon vannak kódtöredékek azokból össze lehet rakni,mivel ez a physX-re épülő wrapper aphysX-et csak akkor kell tanulmányozni, ha valamit nem értesz.
dynamic calc = GetCalculator();
var sum = calc.Add(10, 20);
|
|
|
|
ezek szerint találnom kéne tutorial-okat a physX telepítése után...
nemsokára hazaérek, utánanézek, köszönöm a tippet.
nekem collision detection amiatt kell, hogy egy házban tudjak mászkálni... vagyis ne essek le a semmibe (ütközésdetektálás a talaj és köztem), valamint ne tudjak átmenni a falon, dolgokon. a ház modell maya-ban már megvan, gondolom valahogy majd át tudom exportálni ogre által emészthető formátumra, utána meg beolvasni, és ebben a házban szeretnék mászkálni...
köszi a tippet
|
|
|
|
Idézet
ibax :
sziasztok,
Tudnátok nekem Ogre-hoz valami tutorialt ajánlani, amiben foglalkoznak a Collision Detection-nal?
letöltöttem, telepítettem az NxOgre nevü PhysX kiegészítést Ogre-hoz, még nem sikerült teljesen lefordítani (nem jutott tegnap időm rá), tehát elvileg az előkészületek megvannak, most már csak látni kéne, hogy hogyan müködik...
folyamatosan guglizok is, persze
az ogre-s tutorialokon túl vagyok már, szeretném megvalósítani az ötleteimet, ehhez collision detection is kell... ha esetleg tudtok valami példaprogramot, kódrészletet küldeni, nekem az is megfelelő lenne...
köszi előre is a segítséget
PhysX-ben keress rá Touch és a Trigger tutorokra, mert többféle ütközés detektálás lehetséges. Trigger az a focikapu és focilabda esete, onTouch meg mondjuk két dinamikus objektum ütközése, érintkezése. Színtiszta ogre-ben pedig bounding box van, de az megint teljesen más.
Kód: _aScene->mContactReporter->addReporter(new Collision());
_aScene->createContactPair(ball1, ball2, false, true, false); //on touch
Kód: bool onTouch(body *a, body *b)
{
if(a->getName() == "ball1" && b->getName() == "ball2") //itt most nagyot ütköztek
return true;
}
Ilyesmi.
Ezt a hozzászólást Csizmás Kandur módosította (2008.11.04 06:54 GMT+1 óra, ---)
dynamic calc = GetCalculator();
var sum = calc.Add(10, 20);
|
|
|
|
sziasztok,
Tudnátok nekem Ogre-hoz valami tutorialt ajánlani, amiben foglalkoznak a Collision Detection-nal?
letöltöttem, telepítettem az NxOgre nevü PhysX kiegészítést Ogre-hoz, még nem sikerült teljesen lefordítani (nem jutott tegnap időm rá), tehát elvileg az előkészületek megvannak, most már csak látni kéne, hogy hogyan müködik...
folyamatosan guglizok is, persze
az ogre-s tutorialokon túl vagyok már, szeretném megvalósítani az ötleteimet, ehhez collision detection is kell... ha esetleg tudtok valami példaprogramot, kódrészletet küldeni, nekem az is megfelelő lenne...
köszi előre is a segítséget
|
|
|
|
Sziasztok!
Van itt valaki, aki ért a játékfejlesztéshez és profi 3D megjelenítéseket tudna csinálni egy programhoz (c++)?! Fizetös munka lenne, azaz 50-75e Ft-ot fizetnék.
Akit érdekel, az írjon nekem egy e-mailt az attila_nagy@hotmail.com -ra és bövebb infókat is adok.
Üdv.
Attila
|
|
|
|
// Előbbinél a hátterek úgytudom előre rendereltek, kissé megtévesztő a videó.
|
|
|
|
dynamic calc = GetCalculator();
var sum = calc.Add(10, 20);
|
|
|
|
Idézet
Csizmás Kandur :
OpenAL az sokminden csak nem egyszerű.
Esetleg egy próbát megér a BASS audio lib. is. Szinte mindenhez van: C/C++, Delphi, Visual Basic, és MASM.
http://www.un4seen.com/
I, Robot
1. A robotnak nem szabad kárt okoznia emberi lényben.
2. A robot engedelmeskedni tartozik az emberi lények utasításainak.
3. A robot tartozik saját védelméről gondoskodni.
|
|
|
|
Tudom hogy ez nem ide tartozik, de akkor összehasonlításként mondom, hogy az irrLicht-tel csak egy bajom volt: hogy nem sikerült normálisan megjelenítenem a fényeket és az árnyékokat. És emiatt elég csúnya lett a kinézet. Az irrLichtben elég alap fénytípusok vannak, a Maya-ban alkalmazott fénytípusaim pedig "elvesztek" a konvertálás során.
Elvileg az Ogre ezeket a dolgokat sokkal jobban kezelik, ezért döntöttem a váltás mellett (a megfelelő kinézet miatt)
|
|
|
|
Idézet
ibax :
Oké, örülök a válasznak.
Pár helyen azt olvastam, hogy maga az Ogre csupán egy 3D-s renderelő (ami lényegében akkor igaz is), viszont a megfelelő addonok (irrKlang, OIS) segítségével pedig már hangot is le tudok játszani, illetve tudom kezelni az egeret/billentyüzetet (valahogy)
Ezért vannak a tutoriálok, köszönöm a tippet.
SQLite-val pedig akár adatbázist is pillanatok alatt hozzá lehet csapni a progihoz (tapasztalat!)...
így lesz a semmiből NeedForSpeed ))
Elvi lehetőséged megvan sokmindenre, csak azért olyan komoly szinthez már szét kell patkolni a motort, meg kell pár miller a grafikusoknak is. A galériában egyre komolyabb kinézetű játékok vannak, többek közt kereskedelmiek is.
Egyébként Irrlicht-hez is csatolhatsz, ami jól esik, tök mindegy, hogy párhuzamosan még pluszban megy a zenelejátszás, hálózat, vagy a fizika is.
dynamic calc = GetCalculator();
var sum = calc.Add(10, 20);
|
|
|
|
Oké, örülök a válasznak.
Pár helyen azt olvastam, hogy maga az Ogre csupán egy 3D-s renderelő (ami lényegében akkor igaz is), viszont a megfelelő addonok (irrKlang, OIS) segítségével pedig már hangot is le tudok játszani, illetve tudom kezelni az egeret/billentyüzetet (valahogy)
Ezért vannak a tutoriálok, köszönöm a tippet.
SQLite-val pedig akár adatbázist is pillanatok alatt hozzá lehet csapni a progihoz (tapasztalat!)...
így lesz a semmiből NeedForSpeed ))
|
|
|
|
Idézet
ibax :
ezek szerint úgy fogható fel ez az egész, hogy az Ogre a megfelelő pluginekkel már lehetőséget ad egy 3D-s (vagy másmilyen) alkalmazás létrehozásához?
Audiónal az openAL-t olvastam szinte minden fórumon.. de már nem emlékszem, hogy az egyszerü telepítés, használat, vagy mi miatt...
az OIS segítségével lehet kezelni az input eszközöket?
OGRE-hez azt használsz szabadon, ami jól esik. Vannak addon-ok is.
OpenAL az sokminden csak nem egyszerű. Az irrlicth-es múltaddal a helyedben az IrrKlang ot nézném meg. Hihetelenül egyszerű akár 3D hangokhoz is.
OGRE OIS önmagáért beszél, de az ogre példákban is benne kell lennie.
Ezt a hozzászólást Csizmás Kandur módosította (2008.10.18 02:31 GMT+1 óra, ---)
dynamic calc = GetCalculator();
var sum = calc.Add(10, 20);
|
|
|
|
ezek szerint úgy fogható fel ez az egész, hogy az Ogre a megfelelő pluginekkel már lehetőséget ad egy 3D-s (vagy másmilyen) alkalmazás létrehozásához?
Audiónal az openAL-t olvastam szinte minden fórumon.. de már nem emlékszem, hogy az egyszerü telepítés, használat, vagy mi miatt...
az OIS segítségével lehet kezelni az input eszközöket?
|
|
|
|
Idézet
ibax :
Sziasztok
Én amolyan NEWBIE lennék az Ogre-hoz. Szeretném megtanulni a használatát... Régebben irrLicht-et használtam, de kevésnek bizonyult (fények, árnyékok nem megfelelő használata, beépített fények minimális beállítási lehetőségei,stb). Úgy tudom, az Ogre jóval többet tud (?), de nehezebb az elsajátítása is...
Viszont lehet olvasni az Ogre-ról is negatívumokat. Van, ahol azt írják, hogy "csak" egy renderelő... Nekem egy olyan 3D Engine kell, amiben a bemeneti eszközöket tudom figyelni (egér, billentyü), zenefileokat tudok lejátszani, 3D modelleket tudok betölteni, megjeleníteni, kattintani rájuk, stb. Tehát egy teljes 3D Engine...
Engem is érdekel a téma. Amit tudok ezzel kapcsolatban írni:
OGRE az magában 3D render és van benne egyalap 2D GUI is.
input az OIS: egér, bill, joystic (xbox?), beépített
komolyabb GUI: CEGUI, beépített
audio: openAL, irrklang, fmod, de ezt neked kell hozzárakni, wrapperelni, ami irrklang-nál kb 10 soros class. Ez ismerős lehet az irrlicht-ből.
fizika: ode beépített, nxOgre pedig Nvidia PhysX, ha jól tudom, ogre-hez van wrapperelve
hálózat: raknet
OGRE demók: OGRE precompiled samples
Itt vannak az SDK-ból lefordított példaprogramok. Árnyék az nem valami gyors. Úgy olvastam, hogy directX 10-et is fogjatámogatni, úgyhogy ott biztos lesz jobb megoldás. direcx9-nél nemtudom mik a shaderes lehetőségek.
dynamic calc = GetCalculator();
var sum = calc.Add(10, 20);
|
|
|
|
Sziasztok
Én amolyan NEWBIE lennék az Ogre-hoz. Szeretném megtanulni a használatát... Régebben irrLicht-et használtam, de kevésnek bizonyult (fények, árnyékok nem megfelelő használata, beépített fények minimális beállítási lehetőségei,stb). Úgy tudom, az Ogre jóval többet tud (?), de nehezebb az elsajátítása is...
Viszont lehet olvasni az Ogre-ról is negatívumokat. Van, ahol azt írják, hogy "csak" egy renderelő... Nekem egy olyan 3D Engine kell, amiben a bemeneti eszközöket tudom figyelni (egér, billentyü), zenefileokat tudok lejátszani, 3D modelleket tudok betölteni, megjeleníteni, kattintani rájuk, stb. Tehát egy teljes 3D Engine...
Szerintetek az Ogre ezekre megfelelő? A hivatalos oldalon ezt olvastam:
OGRE (Object-Oriented Graphics Rendering Engine) is a scene-oriented, flexible 3D engine...
http://www.ogre3d.org/index.php?option=com_content&task=view&id=19
Továbbá lenne egy kérdésem is Ogre-val kapcsolatban...
Elkezdtem ezt a tutorialt:
http://artis.imag.fr/~Xavier.Decoret/resources/ogre/tutorial1.html
Amikor odáig jutok, hogy begépelem a
Kód: if (!mRoot->restoreConfig())
{
if (!mRoot->showConfigDialog())
{
return 1;
}
}
RenderWindow* mWindow = mRoot->initialise(true,"Application");
sorokat, akkor futás után elvileg meg kellene jelennie az Ogre által felismert renderelők listájának, hogy kiválaszthassam, melyiket használjam?? Csak mert miután begépeltem szépen a "STEP A" részt, a progi annyit csinál, hogy lefut, és egy fekete képernyőt látok, amiből az ablak bezárásával tudok csak kilépni...
Annak már utánaolvastam, hogy ha egyszer kiválasztottam egy renderelőt (mondjuk OpenGL), akkor többször már nem kínálja fel a renderelő-kiválasztó ablakot, csak ha törlöm a konfig file-t. Itt is ez lehet a dolgok háta mögött?
|
|
|
|
Idézet
gaborlabor :
OIS-t szeretném használni a progimban input kezelésére. A gond az, hogy tutorialokból van vagy 2 db, az is mind ogre-s.
Ezzel kezdtem volna, de már az elején elakadtam. 
Az inicializálásban van egy ilyen sor:
Kód: m_win->getCustomAttribute("WINDOW", &windowHnd);
Magyarázatként pedig:
Line 4 populates the size_t object with the window handle. 'm_win' in this example is a pointer to an initialised Ogre::RenderWindow
Nekem nincs initialised Ogre::RenderWindow-om, nem is lesz.
Ezért az ogréhez értő embereket kérdezném, hogy mégis mit csinál az említett sor, hogyan/mivel tudom helyettesíteni akkor ha csak szimplán winapi-val hozok létre ablakot.
Elsőre azt gondoltam, hogy a létrehozott ablak hwnd-jét adja meg, de a példában a windowHnd változó size_t típusú.
Any idea?
Irrlicht-el való házasítás Initialize fv-je (az eleje a lényeg):
Kód: int COIS::initialize()
{
int result=0;
unsigned int* p=(unsigned int*)&m_windowHandle;
char buf[32];
ParamList pl;
if(!m_device)
return 1;
m_gui = m_device->getGUIEnvironment();
#ifdef _IRR_WINDOWS_
//
// replace irrlicht wndproc with ours to make ois work properly.
//
HWND hwnd = (HWND)(m_device->getVideoDriver()->getExposedVideoData().OpenGLWin32.HWnd);
m_oldWndProc = GetWindowLongPtr(hwnd, GWL_WNDPROC);
SetWindowLongPtr(hwnd, GWLP_WNDPROC, (LONG)((LONG_PTR)_wndProc));
m_windowHandle = (void *)hwnd;
//Default mode is foreground exclusive..but, we want to show mouse - so nonexclusive
pl.insert(std::make_pair("w32_mouse", "DISCL_FOREGROUND"));
if(m_showCursor)
pl.insert(std::make_pair("w32_mouse", "DISCL_NONEXCLUSIVE"));
else pl.insert(std::make_pair("w32_mouse", "DISCL_EXCLUSIVE"));
#else
m_windowHandle = (void *)m_device->getVideoDriver()->getExposedVideoData().OpenGLLinux.X11WindowId;
m_display = (int)m_device->getVideoDriver()->getExposedVideoData().OpenGLLinux.X11Display;
pl.insert(std::make_pair("x11_keyboard_grab","false"));
if(m_showCursor)
{
pl.insert(std::make_pair("x11_mouse_grab","false"));
pl.insert(std::make_pair("x11_mouse_hide","false"));
}
else
{
pl.insert(std::make_pair("x11_mouse_grab","true"));
pl.insert(std::make_pair("x11_mouse_hide","true"));
}
#endif
sprintf(buf,"%u",*p);
pl.insert(std::make_pair( "WINDOW", buf ));
//This never returns null.. it will raise an exception on errors
m_inputManager = InputManager::createInputSystem(pl);
unsigned int v = m_inputManager->getVersionNumber();
if(m_debugEnabled)
{
printf("OIS Version: %d.%d.%d\n", (v>>16 ),((v>>8) & 0x000000FF),(v & 0x000000FF));
printf("Release Name: %s\n", m_inputManager->getVersionName().c_str());
printf("Manager: %s\n", m_inputManager->inputSystemName().c_str());
printf("Total Keyboards: %d\n", m_inputManager->getNumberOfDevices(OISKeyboard));
printf("Total Mice: %d\n", m_inputManager->getNumberOfDevices(OISMouse));
printf("Total JoySticks: %d\n", m_inputManager->getNumberOfDevices(OISJoyStick));
}
//List all devices
OIS::DeviceList list = m_inputManager->listFreeDevices();
for( DeviceList::iterator i = list.begin(); i != list.end(); ++i )
if(m_debugEnabled)
printf(" Device: %s, Vendor %s\n",g_DeviceType[i->first],i->second.c_str());
//Create all devices (We only catch joystick exceptions here, as, most people have Key/Mouse)
m_keyboard = static_cast<Keyboard*>(m_inputManager->createInputObject( OISKeyboard, m_buffered ));
m_mouse = static_cast<Mouse*>(m_inputManager->createInputObject( OISMouse, m_buffered ));
m_keyboard->setEventCallback( this );
m_mouse->setEventCallback( this );
try
{
//This demo uses at most MAX_JOYS joysticks
m_numSticks = m_inputManager->getNumberOfDevices(OISJoyStick);
if(m_numSticks > MAX_JOYS)
m_numSticks = MAX_JOYS;
for( u32 i = 0; i < m_numSticks; ++i )
{
m_joys[i] = (JoyStick*)m_inputManager->createInputObject( OISJoyStick, m_buffered );
m_joys[i]->setEventCallback( this );
if(m_debugEnabled)
printf("\nJoystick %d - ", i+1);
//Check for FF, if so, dump info
m_ff[i] = (ForceFeedback*)m_joys[i]->queryInterface( Interface::ForceFeedback );
if( m_ff[i] )
{
if(m_debugEnabled)
printf(" Has FF Support!, Effects:\n");
const ForceFeedback::SupportedEffectList &list = m_ff[i]->getSupportedEffects();
ForceFeedback::SupportedEffectList::const_iterator i = list.begin(),
e = list.end();
if(m_debugEnabled)
{
for( ; i != e; ++i)
{
printf(" Force=%s, Type=%s\n",SForce[i->first].c_str(),SType[i->second].c_str());
}
}
}
else if(m_debugEnabled)
printf("No FF Support\n");
}
}
catch(OIS::Exception &ex)
{
if(m_debugEnabled)
printf("Exception raised on joystick creation: %s\n", ex.eText);
}
//
// set OIS display size
//
dimension2di dims = m_device->getVideoDriver()->getScreenSize();
setDisplaySize(dims.Width,dims.Height);
return result;
}
Reality is almost always wrong. - House
|
|
|
|
OIS-t szeretném használni a progimban input kezelésére. A gond az, hogy tutorialokból van vagy 2 db, az is mind ogre-s.
Ezzel kezdtem volna, de már az elején elakadtam.
Az inicializálásban van egy ilyen sor:
Kód: m_win->getCustomAttribute("WINDOW", &windowHnd);
Magyarázatként pedig:
Line 4 populates the size_t object with the window handle. 'm_win' in this example is a pointer to an initialised Ogre::RenderWindow
Nekem nincs initialised Ogre::RenderWindow-om, nem is lesz.
Ezért az ogréhez értő embereket kérdezném, hogy mégis mit csinál az említett sor, hogyan/mivel tudom helyettesíteni akkor ha csak szimplán winapi-val hozok létre ablakot.
Elsőre azt gondoltam, hogy a létrehozott ablak hwnd-jét adja meg, de a példában a windowHnd változó size_t típusú.
Any idea?
|
|
|
|
|
|
Bár most nálam nem aktuális a téma, csak felfigyeltem az oldalon a directX 10 és a geometry shader ficsörökre. Kijött az Ogre 1.6.0. 
|
|
|
|
Köszi, akkor ez így egyszerűbb mint gondoltam.
|
|
|
|
Azt automatikusan csinálja -> leírás alapján
mSceneMgr = mRoot->createSceneManager(ST_GENERIC);
Ez Octree-t használ, ha be van töltve a Plugin_OctreeSceneManager(.dll), automatikusan. Az Octree-t pedig entity/subentity szintből készíti.
|
|
|
|
Köszi, eredetileg a nem látható dolgok szűrésére kellett valami módszer, azt hittem a static geometry csinál valami ilyesmit, de ezek szerint ez nem jó erre. Viszont rájöttem, hogy octree/terrain scenemanagerben lehet octree-t építeni, ami pont jól jönne, viszont nem találtam leírást, hogy azt hogy is kell hesználni. Nincs valami tutor vagy sample amiben objektumokhoz octreet generál?
|
|
|
|
Kicsit utánaolvastam (nekem is jól jött):
- StaticGeometry-re nem szabadít rá semmilyen térfelosztást: ha jól értettem úgy működik, hogy kérsz 1 static geometry-t a SceneManager-től, majd ehhez hozzáadsz jó sok Entity-t v 1 SceneNode-ot, amiből az összes Entity-t ki fogja szedni (még a gyerek SceneNode-okból is). Ezeket az Ogre EGY OBJEKTUMKÉNT kezeli innentől, azaz ha bármelyik benne van a view-frustum-ban akkor az összeset kirajzolja. Ez elvileg nem teljesen van így, SceneManager implementációtól függően szűrhet rajtuk még. Az egész lényege az lenne, hogy sok objektumot 1xre rajzol ki/ küld át a GPU-nak. Ez kb. azt jelenti, h a StaticGeometry-nek átadott objektumokat material alapján szétválogatja majd a vertex adatokat optimalizálja és egyesíti (ha van 100 széked ugyan azzal a materiallal 1 szobában akkor összeszedi őket és egyben átküldi az összeset, de ha mondjuk a széken 2 material van, akkor 2 draw hívással rajzoltatja ki (tehát az átadott objektumokat material alapján még _automatikusan_ szétválogatja).
Vigyázni kell vele, mert megvan az előnye, de pl. a Pro Ogre 3D Prog könyv azt is írja, h néha jelentős lehet a memória használat is, mivel ilyenkor az azonos objektumokat többször is tárolja a memóriában (alapból ugyebár a MovableObject-ek megosztják a mesh adatot, azaz csak 1x töltődik be a memóriába).
Arról, hogy animált obj kerülhet e bele nem ír semmit, de ha jól értelmeztem, akkor nem, mivel valószínűleg nem hívja meg az Entity update függvényét. Pontosan azt írja a könyv, h CSAK world transform-ot hajt végre az egész SG-n és külön már nem lehet elérni a befoglalt objektumokat.
És persze arra is vigyázni kell, hogy a lehető legritkábban építsd fel a SG-t, mert ez elvileg egy elég lassú folyamat (lehet).
-> Ha jól értelmezem/gondolom akkor a láthatóságot sem lehet állítani, pont azért, amit írtam: elv. ha kész a StaticGeometry azt onnantól 1 objektumként kezeli, azaz ha bármi változik újra kell építeni SG-t.
Ha pedig mesh-alapján akarsz WorldGeometry-t létrehozni (azaz magát a terepet/terrain) ahhoz spéci SceneManager kell -> elv a Paging Landscape Scene Manager támogatja a mesh alapján történő felosztást, de ezt még nem próbáltam (azt hiszem van már PLSM2 is).
Ezt a hozzászólást ShAdeVampirE módosította (2008.08.27 00:26 GMT+1 óra, ---)
|
|
|
|
Hello
Tudja valaki pontosan hogy működik a static geometry?
Nekem az jött le, hogy a static geometryként beállított objektumokra rászabadít valamiféle térfelosztást, ezáltal gyorsabb lesz a láthatóság vizsgálata, illetve, hogy ez objektum szinten működik és nem poligononként (tehát ha a pálya egy nagy mesh, akkor azt mindíg egészben kirajzolja).
Na most az érdekelne, hogy a static geometry lehet-e animált modell (mondjuk egy nagy forgó szélkerék, animált, de a pozíciója statikus, tehát lehet térfelosztánál használni), illetve a láthatóságát lehet-e állítani (pl izometrikus játék, karakter hazba bemegy, háztető eltűnik, hogy látszódjon a belseje, és mind a ház és a tető static geometry).
|
|
|
|
Ha nem ír error-t/exception-t akkor nem (log-ot azért még nézd át). De sztem simán delete-tel kell törölni, persze ettől még mesh megmarad (ha jól sejtem, főleg ha másik entity használja az adatait).
|
|
|
|
Törölni lehet, működik is, arra voltam igazából kiváncsi, hogy Ogre beregisztrálja-e valahova magának az entitást, nehogy delete-tel valami dangling pointert hagyjon így maga után.
|
|
|
|
elvileg delete-tel lehet törölni; ha mégsem írd meg és utánanézek, de úgy emléxem én is úgy töröltem
|
|
|
|
Köszi, intellisense-ben nem találtam meg a pointeres verziót.
ui.: akkor entitást hogy lehet törölni? szimplán delete akarmi? API doksiban nem igazán sikerült rálelni...
Ezt a hozzászólást dvorgaz módosította (2008.06.30 10:37 GMT+1 óra, ---)
|
|
|
|
Ogre - API
virtual Node * removeChild (unsigned short index)
Drops the specified child from this node.
virtual Node * removeChild (Node *child)
Drops the specified child from this node.
virtual Node * removeChild (const String &name)
Drops the named child from this node.
virtual void removeAllChildren (void)
Removes all child Nodes attached to this node.
Tehát van név alapján, van pointer alapján és van index alapján törlő metódus is. A leírás szerint pedig azért nem törli őket automatikusan, mert lehetséges, hogy utána máshova akarod átcsatolni (pl. a karakter leszáll a lóról/kiszáll az autóból).
|
|
|
|
Ki lehet törölni egy SceneNode-ot/Entity-t simán egy pointer alapján, vagy a scenegraph-nak kell valami remove függvényét használni?
Egyrészt ahogy néztem, a rekurzív remove/destroy függvények az entity-ket csak detach-olják de nem törlik, másrészt egy node gyerek node-jának törlésére csak olyan fv-t találtam ami valami int index-szel vagy névvel működik, de nálam nincs a node-nak neve, és fingom nincs mi az indexe.
|
|
|
|
Közben véletlenül abba is belefutottam, hogy a magunk által létrehozott erőforrásokat h lehet unload-olni/reload-onli -> ManualResourceManager osztály leírásából:
Ogre - API - ManualResourceManager
Resources are usually loaded from files; however in some cases you want to be able to set the data up manually instead. This provides some problems, such as how to reload a Resource if it becomes unloaded for some reason, either because of memory constraints, or because a device fails and some or all of the data is lost.
This interface should be implemented by all classes which wish to provide manual data to a resource. They provide a pointer to themselves when defining the resource (via the appropriate ResourceManager), and will be called when the Resource tries to load. They should implement the loadResource method such that the Resource is in the end set up exactly as if it had loaded from a file, although the implementations will likely differ between subclasses of Resource, which is why no generic algorithm can be stated here.
|
|
|
|
|
|
Nem játékot készítek, ez most céges project, bár nem áll nagyon messze, 3D-s progi.
Fallback-et már használtam, csak most lassan kéne bővíteni az engine/prog képességeit azzal, h manuálisan lehessen kapcsolgatni h pl. fog az shader-esen v FFP (Fixed Function Pipeline)-on legyen, fény az per-pixel/per-vertex/FFP legyen, bump-> shaderesen v dot3bump stb. A kérdés igazából erre irányult, h h lehet ogre-val legegyszerűbben csoportokat kialakítani és ott az összes material-nál ki/be kapcsolni valamit (pl. fog/köd-öt).
|
|
|
|
Az Ogre a material szkriptekben automatikusan tud fallback-et, és az adott kártya képességeinek megfelelő "legkomolyabb" anyagleírást használni.
Az én ötletem az lenne, hogy mivel programból is lehet a materialokat manipulálni, így gondolom simán meg lehet csinálni, hogy menet közben azt teszel/veszel ki/be a materialba, amit szeretnél.
Talán érdemes, lehetőleg mindent belepakolni és megírni előre, amit lehet a lemezen lévő .material fájlba, és utána elvenni belőle, ami nem kell egy adott konfignál.
(Olyan jól áll a játék, hogy ezzel kell már csak foglalkozni?  )
|
|
|
|
És ti ezt h csinálnátok meg?
Egy olyan rendszert kéne létrehoznom, ami megy FixedFuncion-nel és Shader-rel is, abból is 2-esre és 3-masra optimalizálva.
A kártya képességeit már lekérdezem, azaz már a fő shader verziót meg tudom adni, illetve azt is ha nincs olyan.
Na most ez alapján kéne nekem a shader-eket állítgatni, de nem csak így, hanem lesznek egyéb optimalizációs lehetőségek, azaz a prog először kiszámolja a kártya maximális képességeit, az alapján bekapcsolgatja az effekteket/shader-eket, viszont ha ez túl lassú, akkor ki is lehet majd kapcsolni
-> ezt hogy lehet ogre-val a legkönnyebben elérni? + Bool típusú kapcsolókat hogy tudok globálisan a legkönnyebben állítani? (pl. az összes aktív entity-re, v azoknak egy csoportjára, mert pl. az egérre/GUI-ra nem kell, stb.)
|
|
|
|
(Khm. Boost-ban van pooled allokátor, amit lehet használni mindenféle stl konténerhez )
|
|
|
|
Hi
Ide is ))
Anno pont a projectile ok miatt (lövedékek) írtam egy manager osztályt, mert ha belegondolsz ez az ami rengetegszer létrejön, megszűnik, stb...
Szerintem érdemes, eléggé sokat lehett potimalizálni azon, hoyg másodpercenként nem hoztunk létre X projectilet, hanem induláskor betöltöttünk 100 at, majd ezeket használtuk. Ha épp 100 nál több volt "játékban" ) akkor növeltük a méretet.
Mikor kilőssz 1 lövedéket ebből a listából egy már létrehozottat lekérsz, ami éppen nem aktív. Annak beállítodd a paramétereit (sebzés, sebesség) (ha model, effect is különböző, akkor kategóriákba kell szervezni, és adott kategóriától lekérni), bepozícionálod és felhívod a show-t, majd a többit a projectile driverje kezeli (menés és becsapódás ) amint becsapódott, semmi mást nem csinálsz, csak el hide olod és inaktiválod. Ezzel eléggé sokat spórolsz.
|
|
|
|
Elvileg azért vannak (többek között) a különböző erőforrásmanagerek, hogy minden adat egyszer legyen a memóriában (többen is hivatkoznak rájuk, ezért smartpointer-ek mellesleg!). Az már egy másik kérdés, hogy az adott scenemanager/renderer hányszor nyomja az adatokat kártyára.
|
|
|
|
Ha 1 mesh-t több entity-nek is megadsz akkor azt leoptimalizálja az engine? Olyanra gondolok, h ha adatok megegyeznek akkor összeszedi mondjuk 1 vertex/index bufferbe az összes előfordulását és egyben tölti át (azaz h a shader kód legkevesebbszer fusson le)? Lehet hülyeséget kérdezek, 1ébként annyira nem is lényeges, legalábbis egyelőre sebesség terén még nem volt gondom ogre-val, csak felmerült bennem.
Ja és persze, 2^32-en az bőven elég, főleg ha úgy használod h a lövedék amíg él (max 2 másodperc) csak addig foglalsz le neki a bufferben helyet -> 2 másodperc alatt nem lősz ki 4 milliárd golyót, de még 1 perc alatt sem (ha másodpercenként 10 golyót lősz ki, akkor 1 perc alatt 600 a maximum -> ez alapján 32bit-es int-tel 7158278 ilyen fegyverrel lőhetsz 1 percig folyamatosan és akkor még pont nem telik be ) utána meg úgyis eltűnik a golyó és kezded előről).
|
|
|
|
Ok, köszi; tehát akkor ID túlcsordulással nem lesz gond 
ui.: egyébként úgy tudom az újabb Ogréból már kifogják szedni ezt a hülyeséget, hogy mindennek egyedi név kell.
|
|
|
|
4 miliárd golyót egy világháború alatt nem lőnek el, de ha ezeket amúgysem törlöd futás közben akkor az memory-leaket fog eredményezni. Ha csak a golyók koordinátáját tárolod a memóriában és felhasználad az összes ID-t az kb 63gb memóriát emészt fel. Ha jól számoltam
"Mondjuk ha "újrahasznosított" lövedékeket használok, akkor csak annyi kell, amennyi lövedék egyszerre létezik a játéktérben, ugye? Annak két marék ID is elég lehet."
Persze, itt a kérdés inkább az hogy egyszerre mennyi létezhet(aktívan) a játékban. A 32-bites int bőven elég lesz
█▓▒░ All system gone, prepare for downcount! ➡ ➎➍➌❶ Offblast! ➔
|
|
|
|
Akkor gondolom ez egy átlagos lődözős játéknak elég?
(fogalam sincs mennyit lőnek egy játékban általában)
Mondjuk ha "újrahasznosított" lövedékeket használok, akkor csak annyi kell, amennyi lövedék egyszerre létezik a játéktérben, ugye? Annak két marék ID is elég lehet.
|
|
|
|
2 a 32-ediken = 4294967295 az unsigned int hossza (+- 1)
█▓▒░ All system gone, prepare for downcount! ➡ ➎➍➌❶ Offblast! ➔
|
|
|
Legutóbb frissített
project:
RogueLite Dungeons
Friss kép a galériából:
|
