Originally posted by Basswav3:

Cant that comprimise the way the textures are assigned when compiling it?

I'm not sure what you mean by that.

When you compile a model for Source, it will look for a VMT file (material) for a material of the model. If the DMX/SMD model has a material called "body", that's what the Source engine will look for when trying to load the Source model in question.

Originally posted by Basswav3:

- Well also, the slots the textures go into are named with [][] characters and whe i try to export it as an smd it says those characters can cause compiling issues, -

Then just rename them to something you find appropriate for the texture in question (such as "body", "gold", et cetera).

Originally posted by Basswav3:

But the textures dont show up i the uv map, i had to adsign them by clicking a bodypart in the list under the textures rab, then scroll to the texture in the folder amd click on it, my current problem is that i cant find out how to get the textures onto the uv map so i can make it into a single applicable material for the model and if they dont autoassign i dont think i can leave them separate or without a single material. Do you have a discord? Maybe i can screen share to show you when i get a chance.

No, I don't. But again, if this is for the Source engine, there's no need for you to bother combining the textures into a single texture, as again, Source supports up to 32 different materials per model, which can all reference completely different textures.

Does the model use multiple different materials in Blender? If so, it should already be set up correctly, you just have to assign each VMT material in Source the correct texture(s).
If not, does the model use multiple different objects in Blender, one for each texture? If so, assign a different material to each object.
If not, does the model use multiple different textures in Blender already? If so, select each face belonging to a specific texture, then make a material for that texture and assign those faces to it, and do this for each texture.

I repeat: There is no reason to want to combine the textures into a single texture for Source engine models.

Originally posted by Basswav3:

- im trying ti compile it for porting into [a Source engine thing] -

Then there should be no need for combining the textures, as long as less than 32 different textures(/"sets" of textures) are used. The Source engine supports up to 32 materials per model, and each material can reference its own texture(/"set" of textures). (By "set", I mean that a diffuse/colour texture for pants and a normal map for the same pants would belong together, meaning they would be referenced by the same material.)

Originally posted by Basswav3:

- By tangled uv mesh i mean when looking at the wrapped mesh its just a billion crissing lines, and for the textures, each bodypart has its own texture which all came as tgas and dont automatically apply when the model from its folder is imported to blender. -

If you have texture A and texture B, then look at the UV coordinates for both, you will find that they will likely cross over each other. Even though Blender will show both textures' UV coordinates simultaneously, they won't necessarily belong to the same texture, meaning that though they appear to cross over each other, they may very well be entirely separate from each other due to using different textures from each other. The same goes for 20+ textures, of course. And there's not really anything that appears to be that "wrong" about how the "before unwrap" thing looks in the 3D viewport in the screenshot you posted.

Originally posted by Basswav3:

The uv is all tangled till i unwrap it, -

Are you sure? Where did you find the model in question?

Originally posted by Basswav3:

- How would i turn [20+ textures] into a single texture for compiling?

Firstly, compiling for what? Secondly, I explained that in my previous comment, though only for 2 textures, but you can easily just do what I explained further than what I explained, with tiling more textures beside each other and scaling the UV coordinates to lower half multiples and moving them appropriately.

Exactly why are you trying to do a UV unwrap when the UV coordinates have already been set up? Doing a UV unwrap basically resets the UV coordinates to whatever Blender thinks would be nice for you to make a completely new texture from scratch for.

If we say there are two 512x512 textures, you should just use a simple image editor to put them beside each other in a new 1024x512 image, and use that as a texture. Then you should select the part(s) of the mesh that use(s) texture A, and scale its(/their) UV coordinates to be 50% the previous size, on the X axis, and then move them to the left half of the texture. Then do the same for the part(s) of the mesh that use(s) texture B, but moving those UV coordinates to the right half of the texture instead of the left one.

Originally posted by sonicjeremy:

I wish the exports done with and before 2.10 could be salvaged somehow, as now many of the models on https://www.models-resource.com/ which have smd exports are now unusable.

If you just update to version 2.10.1 of the Blender Source Tools and then import the SMDs, they should appear correctly now (provided that you did not import them with 2.10 and then export and overwrite them with the broken UVs that 2.10 get).

If fully re-downloading the SMD file(s) and importing them in Blender with version 2.10.1 of the Blender Source Tools results in broken UV maps, that should be reported here, and then if Artfunkel or someone else says that the problem is with the SMD(s) and not the Blender Source Tools, you can try asking about it where you downloaded the model from.


But again, the first thing to do is to make sure you have the latest version of the Blender Source Tools (2.10.1) and the latest version of Blender (2.79b), then import the SMD into a new Blender session. If the UV mapping is wrong, re-download the SMD fully and try again.

Originally posted by Pte Jack:

Are you sure those were corrupted of did you do a new UnWrap.

After the Blender Source Tools update that made SMD imports support custom normals without every triangle being a separate piece of mesh, I have seen several reports about this issue, so I don't think this is just some sort of coincidence thing.

However, that issue was supposedly fixed in version 2.10.1 of the Blender Source Tools, likely meaning that either this SMD has been imported in version 2.10 and exported from that (with the UV issue "intact") and now imported again in the latest version, or sonicjeremy is using version 2.10 of the Blender Source Tools right now.

This is line 78 of the SMD file, part of the "skeleton" > "time 0" block:-1.#QNAN0 is not a number, so I don't see what the Blender Source Tools is doing wrong here. (In other words, I'd say it's the SMD that's the problem, not the Blender Source Tools.)

Originally posted by Artfunkel:

You could select all vertices and then deselect all vertex groups in turn. You'll be left with the unweighted vertex.

Not necessarily. If a vertice is weighted 0.5 to a bone, then deselecting that vertex group will also deselect that vertice, even if the weight sum of the vertex only adds up to 0.5. The same goes even for infinitely little more than 0.0... and as far as I remember, even 0.0 itself if it's still part of the vertex group.

(Unless blender_implicit is only added to completely weight-less vertices?)