Here is a modified version of BST that has a export scale setting for Source 2 DMX:
https://github.com/Moonded/BlenderSourceTools

Try using a MixRGB node with the mode set to multiply instead. If the item has a tint mask (usually in the base alpha), plug that into the factor input.

Have you tried using Valve Resource Format to decompile the model? It seems to have support for exporting animated models now.
https://github.com/SteamDatabase/ValveResourceFormat

The Source model formats (and most other) only support a single material assignment per face. Layered textures are usually handled on the shader level, so unless you are in a situation where you can write custom shaders, your best bet is to look for material attributes that let you blend textures togther (like $detail, although that is limited to one additonal texture).

Otherwise the common solution is to apply different materials to different parts of the model, and use $texturegroup to create combinations for each skin.

As a solution to exporting as FBX, you can rename per-vertex attributes in ModelDoc by adding a RenameStream node to the mesh. So you could try exporting to FBX with vertex colors, and use a RenameStream node to rename color$0 to VertexPaintBlendParams$0.

Selecting the mesh from the outliner in ModelDoc lets you preview all the streams in it using the magnifying lens icon in the preview window, so you can check if an what everything gets exported as.

Not sure if a better FBX exporter would help with the vertex colors. Valves FBX workflow seems to be using a lot of propietary parameters, and it's possible any specific vertex color channels are exported as some custom per-vertex attribute. The Source 2 FBX importer reads the first vertex color channel as color$0, and I don't think it does anything to any additional ones.

I could be wrong though, Valves Maya exporter has never been released publicly, and I've never seen any FBX files using any custom attributes or vertex colors made by it in the wild.

Also, I think BST exporting objects with the transforms reset is an intentional design choise.

That looks like my fork, unless someone has modded it further.

It's available here:
https://github.com/Rectus/BlenderSourceTools

Noone is trying to discredit the concept. Wallworm already already has a tool to do it for 3DS Max.

What I mean is that I would find a tool like this hard to use effectively, and I imagine a lot of others would as well.

If you've ever gotten invalid brushes from using the vertex tool in Hammer, you know how tedious that can be to find and fix. With a general polygon workflow like in Blender, pretty much every tool can cause this. From my perspective it seems to add a lot of limitations on what tools can be used, and how to use them safely.

If you think it's a good idea, you could always try Wallworm, or write an exporter to test it out.


Disclaimer: I'm not a Blender expert, so it's always a possibility that I'm completely wrong about things.

I guess the hardest part of implementing it would be how to make it user frendly.

Sticking to a CSG workflow in an editor not designed for it severly limits what you can do with it. Unless you want to make everything out of discrete cubes, you'd need to either be really careful to not make any convave bits, or some kind of real-time invalid shape detection.

Maxwell_Edison a écrit :

I know this is a damned old forum post but I just can't help myself. What exactly do you mean by this?

The basic "Brushes" that Hammer uses are simple shapes with defined faces.
I would assume that, especially since Blender prefers working with Quads rather than tris, the exact opposite of what you're saying should in theory be true. A cube in Blender shouldn't be hard at all to interpret into a Brush.

Not sure if there are further limits, but brushes are limited to convex hulls without holes. To make a converter you'd have to shrinkwrap or decompose any concave geometry, or you'll get invalid brushes either Hammer or the compiler can't interpret.