引用自 Artfunkel：

Could you possibly stick the common directory into the QC as $cdmaterials instead?

I agree.

Plus, if you (ZeqMacaw) want to give people what's used to compile the models, you shouldn't include it, since with DMXes, one can set a material directory root (like $CDMaterials, except not used in texture groups), such as models/player/scout/, and then the materials will be named scout_blue for example, which StudioMDL will interpret as models/player/scout/scout_blue even though the material name is only scout_blue. At least I'm fairly certain that's what's going on. Why would people give the full material path as the material name in a modelling tool when also using $CDMaterials and a material root thing, anyway?

If you need me to confirm that material root thing does this, I can try, but I won't do it if you don't ask me to.

引用自 ZeqMacaw：

I made the change in Crowbar 0.24 to write the full path if that is what was found in the MDL file because that's the data that was used to make the MDL.

Oh, so that's actually completely intentional. I think it's a stupid change, since $CDMaterials...

I assume it takes Blender long to import these mega-material-filled meshes because it needs a little time to set up each and every material, and with thousands of materials...

I've had this happen with a Team Fortress 2 cosmetic or two before (but not many), however I think it's more a fault with the decompiler than the Blender Source Tools (although I admit I didn't check the affected cosmetic meshes in Notepad++, so it could be either).

引用自 Akuba：

Are you sure it has to be zero?

No, because if the dimensions were 0x0x0, that would mean every single thing would be at the exact same point, basically invisible. Dimensions/Size has nothing to do with being able to export or not.

Try clicking "Check for updates" in the "Source Engine Export" tab.

Maybe Internet Explorer corrupts the Zip archive or something. Try using another browser, unless you already were using another browser. But if it keeps being annoying... The Steam version of Blender has the Blender Source Tools pre-installed, plus it also auto-updates.

Maybe "idle.smd" doesn't have that bone at the right spot. Try changing $sequence idle "idle.smd" to $Sequence idle "neighbor_hater.smd"

By the way, $StaticProp removes ALL bones, and replaces them ALL with a static_prop at 0 0 0 with a rotation of 0 0 0, so that also removes Bone.Noz_01, Bone.Noz_02 and Bone.Wig (and all other bones).

You probably very well know what I mean by that. But in case not...


When importing SMDs/DMXes, there could be a checkbox for "Import normals" or so, which would default to on.

For DMX, either do as it does right now (import the normals and turn on auto-smoothing on the model) if on, or do nothing about normals (and don't turn auto-smooth on) if off.

For SMD, normals (and the auto-smooth thing) should be ignored if "Import normals" is off and/or "Preserve SMD polygons" is off, but if "Import normals" is on, and "Preserve SMD polygons" is on, then... import the normals.


I was very surprised to import a decompiled SMD with "Preserve SMD polygons" on, and find that the normals weren't imported. After all, you've said the reason normals aren't imported on SMDs is because "Remove doubles" messes it up... but "Preserve SMD polygons" skips that.

If you wouldn't like to clutter up the interface with that checkbox, it'd also be fine if normals are just imported to SMDs if "Preserve SMD polygons" is on, with no changes to DMX importing, and with SMD normals still ignored if "Preserve SMD polygons" is off.

Could you use Source FilmMaker's model viewer instead? It has an important thing in the bottom-left of the Model tab the model viewer you used didn't.