Oprindeligt skrevet af Artfunkel:

Can you upload the scene please.

I suppose so. *Tries* ...Nope, I can't. Try asking again in some hours or something, and I'll try again. The file-sharing service I use is a bit broken right at this moment.

Oprindeligt skrevet af xDShot™:

You probably applied Armature modifier for one of the parts accidentally. Check it.

I checked it before posting the thread (I checked every single object, one by one, if they were parented to the armature (they all are) and if they had the armature deform modifier (they all have), and posing the armature does deform the mesh). And besides that, how come an object would work in one object group export, but not another if an applied modifier was the case?

When doing stuff in Source FilmMaker, I've decided the lighting of a custom HWM-style Team Fortress 2 model's head is weird when using multiple flexes, and decided to try re-exporting it from Blender and then re-compiling it. But something's wrong! http://sta.sh/02fvdp6o4yal

The model has lots of bodygroups (a total of 64512 different combinations, or 6x4x6x14x8x4 bodygroup options), set up by splitting the model into lots of different objects, and making lots of groups for each object so it can be combined with other related pieces as one wishes.

Yet, a thing consisting of three objects may work perfectly well, despite the same three objects not working in their own exports by themselves. The affected exports have no bone data at all, besides vertex group assignments of mesh vertices. (If they do, they're not read by StudioMDL, and Blender gives an error when importing them.)


This seems a lot like a return of that issue long ago with making a scene export where a group consists of only objects that have already been exported previously in other groups in the same scene export.


Blender Source Tools version: 2.6.2
Blender version: 2.76, 64-bit, Steam version
Operating System: 64-bit Windows 10

Oprindeligt skrevet af Pte Jack:

As this isn't a BleST problem, I can close this thread down and bring it into the CrowBar discussion/Bug report area if you want.

Personally, I'm going to make a thread there once I make some evidence. I forgot to do so today.

And someone who is sort of new at modding would be very confused about every face looking so weird, and would probably not know how to deal with it nor what it means.

Oh. My mistake. Then I'll try to acquire and show some once I get home later today or something.

Edit: Though I am fairly certain I have reported it at the very least once, but if not, I'll do that (which I will either way, once I get some evidence stuff).

And Crowbar. Shouldn't Crowbar produce files as accurate to the source files as possible? I (still?) have evidence most affected model files don't have folders in their material names.

ZeqMacaw. I've reported it (at least twice), and each time they has said "it's intentional, that's what the source files look like", while dis-regarding my evidence that it's not.

Neither. It's just ZeqMacaw who for some reason spawned a bug where material folders are (often) included in material names when decompiling through Crowbar, and somehow not noticing nor fixing it (not even when told about it).

Oprindeligt skrevet af I_AM_NOT_PUNCAKE:

But everything was rendered successfully in Blender, including the correct texture.

So? Blender Source Tools ONLY exports MESHES (and animations), not materials nor textures.

You don't set them up in Blender so they appear correctly in Source. The only things exported from Blender with the Blender Source Tools are meshes and animations, not materials nor textures.