Exporting And Multitexturing

[luke-z]

I'm writing an exporter and I have become stuck with the following problem:

I'm wondering how to find a link between a uv set and the texture it corresponds to. More specifically if I'm looking at a poly, I know how to get the material its referencing as well as the uv sets it uses. How than to I know which uv set applies to which of the materials textures?

There is a MEL command uvLink which does exactly what I want. Is there a way to do this without mel commands.

Thanks in advance for any help!

[joojaa]

theres no way of doing ANYTHING in maya without mel! Do you perhaps mean is tehre a way to acces this info in gui? (wich offcourse IS mel!)

[luke-z]

I meant in the api

I'm almost getting it using MGlobal::executeCommand with the mel command but that seems like a hack

can i access this information through the nodes in the dependecy graph?

[joojaa]

MFnMesh:: getAssociatedUVSetTextures

have you ever used the search feature of maya odcs

if taht does not cut it you can allways analyze the node network,its a bit winded you probably will find uing the mel easier then doing , unless yoru purpose is to mask what you do.

A 2d texture is connected to a the default uvset UNLESS its place 2d node is connevcted to a uvchooser (the place node is what defines). so now you must find all textures and their respective place 2d nodes, NOw if there is a uvchoosetrthen the texture uses whatever uvset that is connected to the uvchoosers bitipuhuu attribute wich is one connection per object that connect to the texture (now a texture can be connected to dsomething that des NOT shade it so you msut account for thet too), again if its not connected then it use s default uvset.

[luke-z]

i'm an idiot!

Thanks!

[jcardussi]

I am getting a bug with this call. I have 3 UV sets in a tree model:

Light: lightmap.dds

Base: bark.dds, bark-bump.dds

Map1: leaves.dds

When I make the call: getAssociatedUVSetTextures(), leaves.dds and lightmap.dds are associated with Light and Map1 does not have any textures associated with it. Base is fine.

Any thoughts at what might be happening?

[jcardussi]

Here is my code for getting the texture file names associated with a UV set:

---

fnMesh.getUVSetNames(uvSetNames);
pShape->m\_nNumUVSets = 0;

for ( UINT i=0; i<fnMesh.numUVSets(); i++)
{
	char temp[256];

	strcpy(temp, uvSetNames[i].asChar());
	fnMesh.setCurrentUVSetName(uvSetNames[i]);

	if (fnMesh.numUVs() > 0)
	{
		MObjectArray uvTxtNames;
		fnMesh.getAssociatedUVSetTextures(uvSetNames[i], uvTxtNames);

		for (UINT n=0; n<uvTxtNames.length(); n++)
		{
			MFnDependencyNode* pTextureNode = NULL;
			MString msTextureFile;

			if (uvTxtNames[n].hasFn(MFn::kFileTexture))
			{
				pTextureNode = new MFnDependencyNode(uvTxtNames[n]);
				pTextureNode->findPlug("fileTextureName").getValue(msTextureFile);
				
				MFileObject mFile;

				mFile.setFullName(msTextureFile);

				UINT name = pShape->m\_nNumUVSetTextureNames[pShape->m\_nNumUVSets];
				pShape->m\_UVTextureFileNames[pShape->m\_nNumUVSets].m\_szTextureFile[name] = GetNameArray()->AddName(mFile.name().asChar());
				pShape->m\_nNumUVSetTextureNames[pShape->m\_nNumUVSets]++;
				pShape->m\_UVSetNumber[pShape->m\_nNumUVSets] = i;
			}
		}
		
		assert(pShape->m\_nNumUVSetTextureNames[pShape->m\_nNumUVSets] < MAX\_NUM\_TEXTURES\_PER\_UV\_SET);

		if (pShape->m\_nNumUVSetTextureNames[pShape->m\_nNumUVSets] > 0)
		{
			pShape->m\_nUVs[pShape->m\_nNumUVSets] = (UINT)fnMesh.numUVs();			// uv count (not the same for all sets)
			pShape->m\_aUVs[pShape->m\_nNumUVSets] = new DtVec2f[fnMesh.numUVs()];
			if (!pShape->m\_aUVs[pShape->m\_nNumUVSets])
			{
				hr = E\_OUTOFMEMORY;
				OUTPUT\_MSG("LoadPolyMesh(): Could not allocate memory for tex-coords.");
				goto e\_Exit;
			}
			pShape->m\_nNumUVSets++;
		}
	}
}

if (pShape->m\_nNumUVSets == 0)
{
	OUTPUT\_MSG2("*** ERROR ***  NO UVs for polyshape: ", fnMesh.name().asChar());
}

---

It returns that there are three UV sets, but the texture file names are not with the right UV set. Is this a bug in their code? I think is has to be.

Is there a way to get a look at their source? Or get an update to it? We do not pay for support anymore because it became too expensive.