Jump to content
  • Advertisement
Sign in to follow this  
Solid_Spy

Loading Shader data from models?

This topic is 2130 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hey, i was just wondering. I know how one is supposed to load 3d models and textures into a game, however, how does one load in extra data such as the name of the shader they want to use to render the model?

 

For example, lets say that i create a custom shader called: blue_shader.glsl. If I want to load 1000 3d models, and only have certain ones use the shader, how should I specify which ones? Should I manually type it into the 3d file? Or is there an easier way? What is the most commonly used method?

Share this post


Link to post
Share on other sites
Advertisement


For example, lets say that i create a custom shader called: blue_shader.glsl. If I want to load 1000 3d models, and only have certain ones use the shader, how should I specify which ones? Should I manually type it into the 3d file? Or is there an easier way? What is the most commonly used method?

 

Usually, in that regard, from the combination of textures, shader and probably other properties (reflectivity, etc...) you are talking about a "material". So if you already load the textures from the model file, then yes, it could make sense to store the name of the shader in the model file.

 

Me personally, though I can't say if thats a common approach, however I've been using a system where I load materials externally at the point where I also load the actual models, in form of a resource file, like this:

<Resources>
	<Textures path="../Textures" >
		<Texture name="Island" file="Island.png" read="0" />
		<Texture name="IslandBump" file="IslandBump.jpg" read="0"/>
	</Textures>
	<Materials>
		<Material name="Island" perm="0" >
			<Effect name="BaseActor" />
			<Texture name="Island" />
			<Texture name="TowerBump" />
		</Material>
	</Materials>
	<Meshes>
		<Mesh name="Island" type="file" file="../Meshes/Island.acm" />
	</Meshes>
	<Models>
		<Model name="Island" mesh="Island" >
			<Pass id="0" material="Island" />
			<Pass id="1" material="Shadow" />
		</Model>
	</Models>
</Resources>

Note that I'm using a name dispatch system (shader is referred by a registered name instead of file name), and define what you call a model as a mesh; and the actual model the combination of mesh & material. That allows me to re-use the same geometry with different materials, but whether this makes sense depends on your requirements.

Share this post


Link to post
Share on other sites

Well, obviously you haven't indicated any notation for what differentiates the models between shaders, so *obviously* this will have to manually specified... SOMEWHERE. SOMEHOW.

 

Either within the model files themselves, to be used upon loading/reading... Or as a parameter to the load function (which is what i do)

Share this post


Link to post
Share on other sites

What is the most commonly used method?
I don't think there's a "commonly used" method at all.


For example, lets say that i create a custom shader called: blue_shader.glsl. If I want to load 1000 3d models, and only have certain ones use the shader, how should I specify which ones?
The question, in this form, makes no sense at all from a practical workflow.

Most (99%) of the models are authored with a specific shading in mind. A certain model will use a certain shader. Whatever this setting can be overridden is a different question and I'd leave it for the future. Anyway, there are two main mindsets here:

 

The material based approach.

This means each model refers to an external resource ("material") specifying appearance in full detail. It's an high-level approach stemming from (I guess) cheap DCC tools where for each different result, you need a different material name. It's relatively convenient after all but a bit inflexible for logic.

At the lower end the material is a combination of shader code (to be compiled to GPU) and its parameters specified in full which are the values to put in GPU registers to execute the shader. Textures are special values but besides the special mangling, they are just values like others.

 

The decoupled approach.

Something similar to what's above, although I cannot say I understand the example in full detail.

When using this system, models reference a shader code to load. The code exposes a set of parameters (uniforms) and cannot run on its own so the resource also includes a blob of data for shader processing. The blob of data could be the <Texture> tags above... but again, I'm not 100% sure of what the above example is to be intended.

This approach requires quite some care as data validation way more critical.

 

In my experience, material-oriented systems provide great value at a reasonable cost. I had to switch to the decoupled approach due to some non-technical difficulties but I'm still not sure I had my payback.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!