Skip to main content
GameDev.net gamedev.net
🔒 Locked

Assimp question

Started by Pilpel Mar 14, 2015 at 10:49 AM 6 replies 2.7k views
Original Post
Pilpel
Pilpel

It is said in assimp's docs that each mesh can contain only one material, but is the material unique to that mesh?

In order words, can one material be used by multiple meshes?

L. Spiro
L. Spiro

but is the material unique to that mesh?

While I haven’t used Assimp, I can say with 99% certainty that materials are shared.
It is always safe to work under that assumption.


L. Spiro
I restore Nintendo 64 video-game OST’s into HD! https://www.youtube.com/channel/UCCtX_wedtZ5BoyQBXEhnVZw/playlists?view=1&sort=lad&flow=grid
ongamex92
ongamex92

Each mesh has a member mMaterialIndex which is an index used for aiScene::mMaterials, so basically yes, one material could be used on multiple meshes.

Pilpel
Pilpel

Another question regarding Assimp.

I downloaded many 3d model files and used assimp to import them to my application.

I noticed that in some formats, assimp can't find the textures for its materials.

For example there's this barbarian model I downloaded, which contains many 3d formats (.dae, .x, b3d etc...). The barbarian folder contains diffuse, normal heightmap and even more textures. When importing the data from the .dae file, assimp can't grasp the textures at all.

When I import the .x file, assimp only notices the diffuse texture.

The folder file list is as follows:


barbarian_h.tga
barbarian_high.b3d
barbarian_high.dae
barbarian_high.dbo
barbarian_high.fbx
barbarian_high.lwo
barbarian_high.ms3d
barbarian_high.PSK
barbarian_high.u3d
barbarian_high.x
barbarian_high_animation.PSA
barbarian_low.b3d
barbarian_low.dae
barbarian_low.dbo
barbarian_low.fbx
barbarian_low.ms3d
barbarian_low.PSK
barbarian_low.u3d
barbarian_low.x
barbarian_low_animation.PSA
barbarian_n.tga
barbarian_op.tga
barbarian_s.tga
export_high.mb
export_low.mb
armor_a.tga
armor_d.tga
armor_g.tga
armor_h.tga
armor_n.tga
armor_s.tga
barbarian_a.TGA
barbarian_d.tga
barbarian_g.tga

What's the cause of this "unstable" behavior?

Edit:

BTW, this is the code I run to see how many textures (of each type) each material has.


cout << "aiTextureType_NONE: "         << mat->GetTextureCount(aiTextureType_NONE) << endl;
cout << "aiTextureType_DIFFUSE: "      << mat->GetTextureCount(aiTextureType_DIFFUSE) << endl;
cout << "aiTextureType_AMBIENT: "      << mat->GetTextureCount(aiTextureType_AMBIENT) << endl;
cout << "aiTextureType_EMISSIVE: "     << mat->GetTextureCount(aiTextureType_EMISSIVE) << endl;
cout << "aiTextureType_HEIGHT: "       << mat->GetTextureCount(aiTextureType_HEIGHT) << endl;
cout << "aiTextureType_NORMALS: "      << mat->GetTextureCount(aiTextureType_NORMALS) << endl;
cout << "aiTextureType_SHININESS: "    << mat->GetTextureCount(aiTextureType_SHININESS) << endl;
cout << "aiTextureType_OPACITY: "      << mat->GetTextureCount(aiTextureType_OPACITY) << endl;
cout << "aiTextureType_DISPLACEMENT: " << mat->GetTextureCount(aiTextureType_DISPLACEMENT) << endl;
cout << "aiTextureType_LIGHTMAP: "     << mat->GetTextureCount(aiTextureType_LIGHTMAP) << endl;
cout << "aiTextureType_REFLECTION: "   << mat->GetTextureCount(aiTextureType_REFLECTION) << endl;
cout << "aiTextureType_UNKNOWN: "      << mat->GetTextureCount(aiTextureType_UNKNOWN) << endl;
ongamex92
ongamex92

If the texture data is directly embedded into the model file then the assimp wont be able to give you the texture. But this is not the case for the *.x files. Could you give us a bit more context, maybe paste the code where you parse the material?

Pilpel
Pilpel

COLLADA files don't contain image binaries as well afaik. Here's the material parsing code (note its an ugly debugging function)


void procNode(aiNode *node, const aiScene *scene, int recursion=0)
{
	cout << "Node name: " << node->mName.C_Str() << "  ----  num of recursions: " << recursion << "\n";
	cout << "mNumMeshes: " << node->mNumMeshes << "\n";
	for(unsigned int i = 0; i < node->mNumMeshes; i++)
	{
		unsigned int meshIndex = node->mMeshes[i];
		aiMesh *mesh = scene->mMeshes[meshIndex];

		cout << "mesh->mName: " << mesh->mName.C_Str() << endl;
		cout << "mesh->mTextureCoords[0]: " << TRUEFALSE(mesh->mTextureCoords[0]) << endl;
		cout << "mesh->mTextureCoords[1]: " << TRUEFALSE(mesh->mTextureCoords[1]) << endl;
		cout << "mesh->mMaterialIndex: " << mesh->mMaterialIndex << endl;

                aiMaterial *mat = scene->mMaterials[mesh->mMaterialIndex];

		cout << "mat->GetTextureCount(aiTextureType_NONE): " << mat->GetTextureCount(aiTextureType_NONE) << endl;
		cout << "mat->GetTextureCount(aiTextureType_DIFFUSE): " << mat->GetTextureCount(aiTextureType_DIFFUSE) << endl;
		cout << "mat->GetTextureCount(aiTextureType_AMBIENT): " << mat->GetTextureCount(aiTextureType_AMBIENT) << endl;
		cout << "mat->GetTextureCount(aiTextureType_EMISSIVE): " << mat->GetTextureCount(aiTextureType_EMISSIVE) << endl;
		cout << "mat->GetTextureCount(aiTextureType_HEIGHT): " << mat->GetTextureCount(aiTextureType_HEIGHT) << endl;
		cout << "mat->GetTextureCount(aiTextureType_NORMALS): " << mat->GetTextureCount(aiTextureType_NORMALS) << endl;
		cout << "mat->GetTextureCount(aiTextureType_SHININESS): " << mat->GetTextureCount(aiTextureType_SHININESS) << endl;
		cout << "mat->GetTextureCount(aiTextureType_OPACITY): " << mat->GetTextureCount(aiTextureType_OPACITY) << endl;
		cout << "mat->GetTextureCount(aiTextureType_DISPLACEMENT): " << mat->GetTextureCount(aiTextureType_DISPLACEMENT) << endl;
		cout << "mat->GetTextureCount(aiTextureType_LIGHTMAP): " << mat->GetTextureCount(aiTextureType_LIGHTMAP) << endl;
		cout << "mat->GetTextureCount(aiTextureType_REFLECTION): " << mat->GetTextureCount(aiTextureType_REFLECTION) << endl;
		cout << "mat->GetTextureCount(aiTextureType_UNKNOWN): " << mat->GetTextureCount(aiTextureType_UNKNOWN) << endl;
	}

	cout<<endl;
	if(node->mNumChildren > 0)
		for(unsigned int i = 0; i < node->mNumChildren; i++)
			procNode(node->mChildren[i], scene, recursion+1);
}

I call this in the main function and pass the root node.

ongamex92
ongamex92

probably assimp fails to recognize the semantics of the data

see what is stored in aiMaterial::mProperties

Pilpel
Pilpel

I added this code:


aiMaterialProperty *prop;
for(unsigned int i = 0; i < mat->mNumProperties; i++)
{
	prop = mat->mProperties[i];

	cout << "prop " << i << " key: " << prop->mKey.C_Str() << endl;
}

I get the next output for every material (when importing from .ms3d):


prop 0 key: $tex.file
prop 1 key: ?mat.name
prop 2 key: $clr.ambient
prop 3 key: $clr.diffuse
prop 4 key: $clr.specular
prop 5 key: $clr.emissive
prop 6 key: $mat.shininess
prop 7 key: $mat.opacity
prop 8 key: $mat.shadingm

When importing from .x:


prop 0 key: ?mat.name
prop 1 key: $mat.shadingm
prop 2 key: $clr.emissive
prop 3 key: $clr.diffuse
prop 4 key: $clr.specular
prop 5 key: $mat.shininess
prop 6 key: $tex.file

.b3d:


prop 0 key: ?mat.name
prop 1 key: $clr.diffuse
prop 2 key: $mat.opacity
prop 3 key: $clr.specular
prop 4 key: $mat.shininess
prop 5 key: $tex.file

.dae: (notice that in COLLADA there are many properties but not a single texture file property [$tex.file], like I mentioned earlier)


prop 0 key: ?mat.name
prop 1 key: $mat.shadingm
prop 2 key: $mat.twosided
prop 3 key: $mat.wireframe
prop 4 key: $clr.ambient
prop 5 key: $clr.diffuse
prop 6 key: $clr.specular
prop 7 key: $clr.emissive
prop 8 key: $clr.transparent
prop 9 key: $clr.reflective
prop 10 key: $mat.shininess
prop 11 key: $mat.reflectivity
prop 12 key: $mat.refracti
prop 13 key: $mat.opacity

This is really weird. Could this just be specific to the model and the artist that exported these files? However I did get unstable results like these with downloaded models.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.