跟N2比起來, N3的資源子系統更加開放, 給予了程序員對資源的創建和管理更多的控制. 

Nebula3的資源有下面向個屬性:

• 包裝了一些其它Nebula子系統需要的數據
• 可以用ResourceId共享
• 可以在任何時候加載(初始化)和卸載
• 可以同步或異步加載

例如典型的圖形資源有網格和紋理, 但資源子系統并不局限于圖形資源. 

資源子系統有兩個操作層次( 可能以后會把他們放入兩個不同的命名空間, 現在他們都是在Resources命名空間下 ):

低層提供了真正的資源對象, 處理資源的共享, 加載和(次要的)保存. 低層的資源類有:

• ResourceId
• Resource
• ResourceLoader
• ResourceSaver
• SharedResourceServer. 

高層資源子系統提供了資源管理, 這意味著根據用戶的反饋動態的加載和卸載資源. 高層資源子系統的類有:

• ResourceProxy (又名: ManagedResource)
• ResourceProxyServer (又名: ResourceManager)
• ResourceMapper

下面說明資源子系統的各個類是怎么協同工作的:

一個ResourceId是一個唯一的資源標識符. ResourceId用來共享和定位磁盤上的數據(或者資源保存在哪). ResouceId是一些原子字符串(string atoms). Atom是一個常量字符串的唯一32-bit標識符, 這可以大大加快拷貝和比較, 并且可以減少內存占用, 因為標識符字符串只保存一份. 為了定位磁盤上的數據, ResourceId常常分解成一個合法的URL(例如一個ResourceId “texture:materials/granite.dds”, 會在運行時被分解成”file:///C:/Programme/[AppName]/export/textures/materials/granite.dds”. 

一個Resource對象實際上是資源數據的容器. 像紋理和網格這樣特定的資源類型都是Resource類的子類, 并且實現了特定的接口. Resource子類通常都是平臺相關的(如D3D9Texture), 但是通過有條件的類型定義使其變成平臺無關的. 并不像Nebula2那樣, 資源對象并不知道怎樣去組織, 加載或保存自己. 取而代之的是, 一個合適的ResourceLoader或ResourceSaver必須附屬于Resource對象. 因為Nebula程序很少輸出數據, ResourceSaver只 是為了完整性而存在的. 換句話說, ResourceLoader是必須的, 因為他們是啟用Resource對象的唯一途徑. ResourceLoader具有整個資源裝載過程的完全控制. 它們可以是平臺相關的, 而且也許會依賴于相關聯的特定平臺的Resource類. 這使得程序員可以對資源的裝載過程相比Nebula2有更多的控制. 典型的資源加載類有StreadTextureLoader, MemoryVertexBufferLoader和MemoryIndexBufferLoader(從內存中加載頂點緩存和索引緩存).

Resource類也提供了一個共同的接口用來同步和異步的資源加載. 同步加載可以這樣做:

1. res-> SetResourceId("tex:system/white.dds");
2. res-> SetLoader(StreamTextureLoader::Create());
3. res-> SetAsyncEnabled(false)
4. res-> Load()
5. if (res-> IsValid()) ... 這時資源加載已經成功了, 否則LoadFailed會返回true.

異步資源加載也很相似:

1. res->SetResourceId("tex:system/white.dds");
2. res->SetLoader(StreamTextureLoader::Create());
3. res->SetAsyncEnabled(true);
4. res->Load();
5. 資源這時進入等待狀態...
6. 只要 IsPending() return true, 就要重復地調用Load()... 當然真正的程序會在這時做一些其他的事情
7. 接下來的某個調用Load()后時刻, 資源的狀態要么是Valid(資源已經準備好了), Failed(資源加載失敗)或者Cancelled(等待中的資源被取消加載了)

一個應用程序甚至是Nebula3的渲染代碼通常都不需要關心這些, 因為資源管理層會處理他們, 并把異步加載的這些細節隱藏到資源代理后面. 

SharedResourceServer單件通過ResourceId來共享資源. 通過SharedResourceServer創建資源確保了每個資源只在內存中加載了一份, 而不管客戶端的數目. 如果客戶端的數目降低到了0, 資源會被自動卸載(這并不是合適的資源管理, 而應該是ResourceProxyServer應該關心的). 資源共享完全可以直接通過標準的Nebula3的創建機制來繞過. 

ResourceProxy(或ManagedResource)是對于實際資源對象的資源管理包裝. 它的思想是包含的資源對象會受資源用途反饋的控制. 例如, 一個紋理代理會在被請求的紋理在后臺加載時提供一個占位紋理, 屏幕上所有使用這個資源的物體都很小的話會被提供一張低分辨率的紋理, 一個X幀沒有被繪制的紋理會被卸載, 等等. 

ResourceProxyServer(或ResourceManager)單件是資源管理系統的前端. 除了管理附屬于它的ResourceMapper的工作外, 它還是ResourceProxy的工廠, 并且把ResourceMapper跟Resource類型聯系到了一起. 

ResourceMapper是一個有趣的東西. 一個ResourceMapper跟一種資源類型(如紋理或網格)相關聯, 并被應用程序依附到ResourceProxyServer. 它負責從渲染代碼的使用反饋來加載/卸載資源. ResourceMapper的子類可以實現不同的資源管理策略, 也可以通過派生特定的ResourceMapper和ResourceLoader來創建一個完全定制的平臺和應用相關的資源管理方案. 目標是顯而易見的, Nebula3提供了一些好用的ResourceMapper來加載需要的任何東西. 

資源使用反饋是由渲染代碼寫入ResourceProxy對象的, 而且應該包含這個資源的一些信息:是否會在不久后用到, 是否可見, 并估計物體占用的屏幕空間大小. 特定的反饋依賴于ResourceProxy的子類, ResourceProxy中沒有公有的反饋方法. 

基于資源的使用反饋, 一個ResourceMapper應該實現下面的一些操作(這取決于具體的mapper):

• Load: 根據level-of-detail異步加載資源(如跳過不需要的高分辨率mipmap層次)
• Unload: 完全卸載資源, 釋放珍貴的內存
• Upgrade: 提高已加載資源的level-of-detail(如加載高分辨率的mipmap層次紋理)
• Degrade: 降低已加載資源的level-of-detail(如跟上面相反的情況)