| Zobrazit předchozí téma :: Zobrazit následující téma |
| Autor |
Zpráva |
koso
Založen: 28. 05. 2009
Příspěvky: 110
|
 Zaslal: 8. březen 2013, 18:33:58 Předmět: Mesh management |
 |
|
Zdravim
Tato moja otazka je skor teoreticka. Rozhodol som sa implementovat nejaky na zaciatok jednoduchy resource manager. Zaujima ma aka je bezna prax s manazovanim mesh-ov v pameti. Potrebne meshe sa ulozia do pameti jeden krat a potom vsetky entity podla nejakej referencie pristupuju k tym spravnym VBO? ako potom riesit ked napriklad nejaka entita potrebuje mesh modifikovat ale ostatne potrebuju povodny mesh? Urcite to prinasa aj ine problemy ale zatial som sa zamislal len nad tymto... |
|
| Návrat nahoru |
|
 |
nou
Založen: 28. 07. 2007
Příspěvky: 1047
|
| Zaslal: 8. březen 2013, 19:22:06 Předmět: |
|
|
najdi si nieco o copy on write
_________________
Najjednoduchšie chyby sa najtažšie hľadajú. |
|
| Návrat nahoru |
|
|
Vilem Otte
Založen: 18. 09. 2007
Příspěvky: 462
Bydliště: Znojmo - Sedlesovice, Kravi Hora
|
| Zaslal: 8. březen 2013, 19:22:29 Předmět: |
|
|
Ad managing:
Obvykle chceš každý mesh nějak identifikovat (ať už stringem, jeho hashem, etc. - e.g. nějaký identifikátor), a k němu přiřadit ukazatel ... toto je obvykle řešeno jednoduchou mapou (dictionary, v našem případě např. mapa postavená na B+ tree) ... tedy budeš mít něco jako:
| kód: |
template<class T>
class Manager
{
Map<String, ManagerNode<T>*> data;
...
} |
Kde ManagerNode může obsahovat různé věci, ukazatel na daný mesh, a třeba reference counter (auto-managing těchto zdrojů se obvykle hodí).
Při načítání poté provádíš něco cca. takového (ManagerNode obsahuje reference counter a pointer na daný resource):
| kód: |
T* Load(const char* mFilename)
{
// Ziskej filename ve tvaru v jakem bychom jej chteli jako identifikator
char* name = GetFilename(mFilename);
String strName = String(name);
// Zjisti zda jiz v nemame nacteny resource ktery chceme nacist
typename Map<String, ManagerNode<T>*>::Iterator it = mData.find(strName);
// Jestlize existuje, pouze zvysime reference counter o 1 a vratime to co chceme (v nasem pripade pointer na dany resource)
if(it != mData.end())
{
it->second->mReferenceCounter = it->second->mReferenceCounter + 1;
return it->second->mData;
}
// Pokud neni nacteny, nacteme jej
ManagerNode<T>* data = (ManagerNode<T>*)Alloc1(sizeof(ManagerNode<T>), 1);
data->mReferenceCounter = 1;
data->mData = new T(mFilename);
// A vlozue do manageru
mData[strName] = data;
return data->mData;
} |
Pro smazání postupuješ podobně (zjistíš jestli existuje v manageru), poté snížíš jeho reference counter (a pokud je roven 0, tak daný resource odstraníš).
Takový velice jednoduchý manager resources ti může velmi usnadnit práci. Pro statické zdroje funguje úplně ideálně.
Ad modifikovatelné meshe:
Přijde mi docela prasácké takto modifikovat meshe (jak popisuješ ty), jelikož dynamické VBO se používají např. pro částice - a ty rozhodně nechceš odkazovat na jediný mesh.
Nicméně pokud bys to chtěl provádět tak jak popisuješ, tak by stačilo do podobného manageru jako výše zmíněný vložit funkci "Duplicate" a pro danou entitu začít odkazovat na duplikát.
*prasácké především pro začátek - ono to může mít své opodstatnění (soft-bodies simulation např.), nicméně není to až tak běžné.
_________________
Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration. |
|
| Návrat nahoru |
|
|
koso
Založen: 28. 05. 2009
Příspěvky: 110
|
| Zaslal: 8. březen 2013, 19:55:29 Předmět: |
|
|
no to s tou modifikaciou zatial nic neplanujem len ma to tak napadlo ze keby raz noahdou  ale ano tak nejak som si to predstavoval ako si to popisal
ze nejaky "node" v scene obsahuje len referencie na nejake prvky(particle emmiter, sound... ) medzi ktorymi je aj mesh, ale ten je fyzicky v pameti len jeden krat(+mesh ma nejaky ten reference counter). |
|
| Návrat nahoru |
|
|
TeaTime
Založen: 17. 06. 2011
Příspěvky: 264
|
| Zaslal: 9. březen 2013, 23:46:27 Předmět: |
|
|
| citace: |
| Map<String, ManagerNode<T>*> data; |
Doplňující otázka k tématu:
Proč se u těchhle resource managerů používá vždycky jako klíč String? Proč tam není radši třeba enum nebo int přes konstanty? Nebo třeba ještě něco mazanějšího? Napadá mě pár možných důvodů, ale zajímalo by mě, jaký je faktický důvod. |
|
| Návrat nahoru |
|
|
Vilem Otte
Založen: 18. 09. 2007
Příspěvky: 462
Bydliště: Znojmo - Sedlesovice, Kravi Hora
|
| Zaslal: 10. březen 2013, 04:40:05 Předmět: |
|
|
#TeaTime - jelikož do Manageru pak načítáš modely jako:
g_mMeshManager->Load("crate.mesh");
g_mMeshManager->Load("barell.mesh");
etc.
Jejich identifikátor poznáš již podle názvu - a tedy je příklad relativně názorný.
Např. u nás to máš trochu složitější, v praxi svět má několik resource managerů (mesh manager, material manager, texture manager, etc. etc.), každý takový zdroj je někde uložen - a v daném bloku souboru má své ID dané relativně k projektu do kterého daný zdroj patří (e.g. všechny resources u nás musíš přidat přes editor do projektu) - práce s nimi poté probíhá přes tento ID (který obsahuje nejen ID objektu, ale také informaci o tom čím daný objekt je - je to jedno 64-bit číslo rozdělené na 2 32-bit části, kdy horní udává typ objektu (tím i testujeme zda se nesnažíme načíst mesh jako texturu, apod.) + další info (zda je např. duplikátem - abychom náhodou nikdy neměnili původní objekt) a dolní udává ID objektu).
Ovšem pro názornost je String v tomto případě opravdu super - jelikož se s ním snadno pracuje.
_________________
Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration. |
|
| Návrat nahoru |
|
|
|
Hlavní strana
FAQ
Test
Hledat
Seznam uživatelů
Uživatelské skupiny
Registrace
Ke Stažení
Nastavení
Přihlášení
Calendar
