Hi. Currently i'm writing my first 3D engine based on DirectX 11 and i have some question: my engine loads to memory .obj models  and extracted material structures from .mtl material libraries which are exported from 3DS Max. The name of each material from .mtl is set up in Material Editor in 3DS Max, and it looks like "shaderName__textureName". The part before "__" contains the shader's name. I use it to find shader in Shaders Table class (this class has vector of shaders) and set it via device context. The part after "__" contains texture, which i select while rendering via device context. I think it is horrible organization and i'd like to find out another better one. Can i make shaders in such programs like 3DS Max? If yes, how could i link some shader to material in .mtl? If no, couldn't you advice me how to organize shaders to materials linking in better way? Thank you for replies.

3 hours ago, cozzie said:

Hi there. There are a lot of things in your question   I believe you have to take a number of things into account, defining a good solution:

- realtime obj mesh loading versus your own best fit mesh format (file), if your planning for bigger, I’d go for that

- creating unique ID’s for all your assets, shaders, meshes, materials, textures etc

- if you add a reference/ id of a shader to a mesh, you can use any shader. It’s Also not mandatory to have a shader per material (it’s Up to you to define that criteria, I personally don’t use one per material, because besides the used maps, they’re mostly similar)

- Yes, shaders can be made in max, but also in many other (and ‘lighter’) tools

I guess there’s much more to this topic, but I’ll leave that to others to add on top of the above.

Good luck on this journey

Thank you)

So, as i understood:

1. I should create new own format for objects.

2. I can use one shader for lots of objects, which will calculate lighting,normal bump etc depending on material constants and maps that are loaded?

Your current approach of encoding shader name and texture name into the material name you use in Max is reasonable, but it is very limited. I'd suggest a good iteration would be to move to a scheme where the material name in Max maps to a material definition that fills all your requirements.

E.g. you might have your runtime materials defined in a structured format like JSON:

[
	{
    	"name": "Gravel",
        "vertexshader": "rigid",
        "fragmentshader": "normalmapped",
        "diffusemap": "gravel_d.png",
        "normalmap": "gravel_n.png",
        "ambientmap": "gravel_ao.png"
	},
	{
    	"name": "Orc",
        "vertexshader": "skinned",
        "fragmentshader": "normalmapped",
        "diffusemap": "orc_d.png",
        "normalmap": "orc_n.png",
        "ambientmap": "orc_ao.png"
	}
]

Then in Max you just use the material names on your meshes and you can simply look up the corresponding runtime material when loading the .obj/.mtl files.

This approach will scale pretty well for, you can readily extend it to specify vertex attribute requirements and so on. 

I'd hold off on creating your own format for models/meshes until you've got a clear idea of what your requirements are. If you keep loading obj files, you'll probably end up doing quite a bit of processing on the data post-load, possibly triangulating quads, probably generating tangent basis space vectors for normal mapping, definitely laying out data in GPU buffers and so on. At some point moving that post processing into an offline tool which outputs your own data format will make good sense and what you need to do will be obvious.

Thank you for replies.

And i have also misunderstanding in other question: if i store shaders in some table, and choose them depending on the material's name, it's good, but each shader may need different input data, how to handle this situation?

7 hours ago, romashka911 said:

Thank you for replies.

And i have also misunderstanding in other question: if i store shaders in some table, and choose them depending on the material's name, it's good, but each shader may need different input data, how to handle this situation?

All of that information could be included in your material definitions. Uniform data can be defined by the materials,  for varying data the material definition can tell your engine what data the shader requires, where to bind it, and possibly how to generate it. 

If you have a particular requirement in mind and can't see how it would work ask about it specifically, talking through an example might be beneficial to grasping the idea.