resources and directory structure
Author
Hy.
I'm still creating a little 3d engine with dx 10.
I have for the resource and meshes a directory structure like this:
-resource |
|-shader1 |
| |- mesh1----->goblin.dae,goblin.jpg,goblin.dds ecc...
| |- mesh2
| |- mesh3
|
|-shader2 |
| |- mesh3
| |- mesh4
every mesh folder have inside the texture, normal map ecc...(every resources)and a .dae(collada)file model.
the mesh folder is also under the shader folder thath contain the .fx shader that the mesh must rendered by.
then mesh1,mesh2 and mesh3 is rendered by the shader1 and mesh3,mesh4 is rendered by the shader2.
I have created a resource management singleton that traverse this directory structure and create all the meshes and the shaders.
The problem is that each mesh can have a different render logic for example a mesh can change the color every 10 frame(and for do this set the color in the relatiove shader)and i can't list all the cases.
I think to create a logic mesh class that do all the drawing logic work and incapsulate it in the mesh with the shader.
The problem is: how the directory structure can expose this drawing logic properties and how save the classes?
Can i use a script language?
Thanks.
I don't think that the directory structure should reflect the data relations. In fact, you're already not doing it for textures. Shaders would normally be part of the material, like textures are, so why give them a significance by sorting by them in the first place?
Author
Because in my management sistem the shader have a role before the textures, the texture can be assigned at a shader , also the shader can't be assigned to a texture.
Then , first i have a shader for the draw ,then i can assign to it a texture.
Is common to have the same shader for many meshes model(is a model mesh, not an instance of a mesh , i can have a lot of meshes from a single model) is more,more difficult to have the same texture or normal map for many meshes model, and in this case if arleady exist the texture is not recreated , is taked from a the management map of texture in the management system.
By
Then , first i have a shader for the draw ,then i can assign to it a texture.
Is common to have the same shader for many meshes model(is a model mesh, not an instance of a mesh , i can have a lot of meshes from a single model) is more,more difficult to have the same texture or normal map for many meshes model, and in this case if arleady exist the texture is not recreated , is taked from a the management map of texture in the management system.
By
Personnaly, I prefer to organize my engine directories by taking each resource type as its own. Example :
- Data
--- Models (Meshes)
--- Textures
--- Shaders
--- Sounds
--- ect..
The way they act together and the hierarchy of the structure belongs to the code, not to the directories. In my case, shaders aren't "on top" of the meshes in the render hiearchy, but even if it was the case, my directories structure would stay the same. Way more simple to manage and navigate if you ask me. That's my two cents.
EDIT : I forgot to mention that I then use a personal file structure to describe complex objects made from those resources. For example, here would be a file structure for a character model :
[VISUAL]
Model = filename (in Models)
Texture1 = filename (in Textures)
Texture2 (normal map for example) = filename
Shader = filename (in Shaders)
etc..
[STATS]
stat1 = ...
whatever
So for the goblin that would look like :
[VISUAL]
Model = goblin.dae
Texture1 = goblin.jpg
Texture2 = goblin.dds
Shader = RenderShader1.fx
etc..
In your case, the shader surely could not be stated in this file, but I'm not sure what would be best.
- Data
--- Models (Meshes)
--- Textures
--- Shaders
--- Sounds
--- ect..
The way they act together and the hierarchy of the structure belongs to the code, not to the directories. In my case, shaders aren't "on top" of the meshes in the render hiearchy, but even if it was the case, my directories structure would stay the same. Way more simple to manage and navigate if you ask me. That's my two cents.
EDIT : I forgot to mention that I then use a personal file structure to describe complex objects made from those resources. For example, here would be a file structure for a character model :
[VISUAL]
Model = filename (in Models)
Texture1 = filename (in Textures)
Texture2 (normal map for example) = filename
Shader = filename (in Shaders)
etc..
[STATS]
stat1 = ...
whatever
So for the goblin that would look like :
[VISUAL]
Model = goblin.dae
Texture1 = goblin.jpg
Texture2 = goblin.dds
Shader = RenderShader1.fx
etc..
In your case, the shader surely could not be stated in this file, but I'm not sure what would be best.
You're going to shoot yourself in the foot later on down the road with that arrangement. While it may work fine for small levels/setups, you're pretty much going to have to rework the whole thing from the ground up if you plan on supporting multiple levels/regions or even plain larger areas.
For starters, sharing resources is out of the question. Say you want to make a small variation in the goblin mesh that has a slightly different set of armor. You can't recycle the texture for the goblin's skin at all; you're forced to make a redundant copy of the exact same data. This, in turn, will likely lead to redundant state changes and will decrease performance. In addition, you're using twice as much VRAM with no real reason/benefit for doing so-- this also decreases performance.
You also hit another wall with resource setup, though this is actually very solvable. Your resource parsing/creation scheme will pretty much explode once you start to make more creature types, variations, etc. There's no logic dictating which ones you actually *need.* I would personally suggest making a list of what your scene will actually use and saving it (prime candidate for toolset feature, if you ever get around to making some sort of editor) Your resource creator can then just read through it and load exactly what you need, no guesswork.
The answer to your initial question is actually pretty simple, however, and has already been suggested. For completeness' sake, I'll do my best to explain one of the best answers to this I've come across-- Valve's material system.
Each mesh/submesh specifies which material it uses. The one I've posted is actually from Counter-Strike Source, specifically belonging to the ct_urban player model. There's actually a little line inside that file that reads
"models/player/ct_urban/ct_urban" which the engine knows is a .vmt file located in the materials directory. So it goes and opens up
<install directory goes here>/materials/models/player/ct_urban/ct_urban.vmt
and does whatever it needs to in order to convert that text file into the binary representation the Source Engine renderer uses for drawing.
Much of it makes a lot of intuitive sense, actually. The little "vertexlitgeneric" line means that the model uses a shader named "vertexlitgeneric.vcs" (Valve's proprietary compiled shader format, basically a tricked-out FXO file) and specifies a number of different parameters.
The line
"$baseTexture" "models/player/ct_urban/ct_urban"
means that the shader should use the texture named ct_urban.vtf located in
<install directory goes here>/materials/models/player/ct_urban/
as a diffuse map, likewise for the $bumpmap texture. The $envmap parameter is where things get interesting. The Source engine supports models and map brushes having cube map-based specular highlights. The neat thing is that you have the option of using either a static one loaded from a file (along the lines of what gets done with the Master Chief's armor in the Halo games) or a dynamically-generated one picked by the engine based on some internal logic. Setting this parameter to env_cubemap does the latter, though you can set it to to use one you made yourself just like any other texture.
Similar deal with material parameters/switches. You can turn Phong specular on and off by changing the value of the $phong option and control the various BRDF properties via the $phongexponent, $phongboost and $phongalbedotint and similar material properties. It's extremely flexible.
Seeing as you don't appear to have too much experience with systems like these, I would suggest grabbing Steam and picking up the demo for Portal. You get a decent chunk from one of the best games in recent memory and a whole library of examples to check out, all for the low, low price of $0USD. You'll need this program to open up the archive files the game uses, but it too is free. Finally, this wiki is probably the best reference out there for all the things you can do with the system, and may be helpful for making something of your own.
For starters, sharing resources is out of the question. Say you want to make a small variation in the goblin mesh that has a slightly different set of armor. You can't recycle the texture for the goblin's skin at all; you're forced to make a redundant copy of the exact same data. This, in turn, will likely lead to redundant state changes and will decrease performance. In addition, you're using twice as much VRAM with no real reason/benefit for doing so-- this also decreases performance.
You also hit another wall with resource setup, though this is actually very solvable. Your resource parsing/creation scheme will pretty much explode once you start to make more creature types, variations, etc. There's no logic dictating which ones you actually *need.* I would personally suggest making a list of what your scene will actually use and saving it (prime candidate for toolset feature, if you ever get around to making some sort of editor) Your resource creator can then just read through it and load exactly what you need, no guesswork.
The answer to your initial question is actually pretty simple, however, and has already been suggested. For completeness' sake, I'll do my best to explain one of the best answers to this I've come across-- Valve's material system.
"vertexlitgeneric"{ "$baseTexture" "models/player/ct_urban/ct_urban" "$envmap" "env_cubemap" "$bumpmap" "models/player/ct_urban/ct_urban_normal" "$phong" "1" "$phongexponent" 1.75 "$phongboost" "1.25" "$phongfresnelranges" "[.35 1.25 6.65]" "$phongalbedotint" "1"}Each mesh/submesh specifies which material it uses. The one I've posted is actually from Counter-Strike Source, specifically belonging to the ct_urban player model. There's actually a little line inside that file that reads
"models/player/ct_urban/ct_urban" which the engine knows is a .vmt file located in the materials directory. So it goes and opens up
<install directory goes here>/materials/models/player/ct_urban/ct_urban.vmt
and does whatever it needs to in order to convert that text file into the binary representation the Source Engine renderer uses for drawing.
Much of it makes a lot of intuitive sense, actually. The little "vertexlitgeneric" line means that the model uses a shader named "vertexlitgeneric.vcs" (Valve's proprietary compiled shader format, basically a tricked-out FXO file) and specifies a number of different parameters.
The line
"$baseTexture" "models/player/ct_urban/ct_urban"
means that the shader should use the texture named ct_urban.vtf located in
<install directory goes here>/materials/models/player/ct_urban/
as a diffuse map, likewise for the $bumpmap texture. The $envmap parameter is where things get interesting. The Source engine supports models and map brushes having cube map-based specular highlights. The neat thing is that you have the option of using either a static one loaded from a file (along the lines of what gets done with the Master Chief's armor in the Halo games) or a dynamically-generated one picked by the engine based on some internal logic. Setting this parameter to env_cubemap does the latter, though you can set it to to use one you made yourself just like any other texture.
Similar deal with material parameters/switches. You can turn Phong specular on and off by changing the value of the $phong option and control the various BRDF properties via the $phongexponent, $phongboost and $phongalbedotint and similar material properties. It's extremely flexible.
Seeing as you don't appear to have too much experience with systems like these, I would suggest grabbing Steam and picking up the demo for Portal. You get a decent chunk from one of the best games in recent memory and a whole library of examples to check out, all for the low, low price of $0USD. You'll need this program to open up the archive files the game uses, but it too is free. Finally, this wiki is probably the best reference out there for all the things you can do with the system, and may be helpful for making something of your own.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
