Compiling many objects as one model from SoftImage?

Here’s what the model looks like:

The problem I’m getting with exporting this model is that the compiler/process I’m using is only exporting a fraction of the model. I’ve double-checked and I’ve frozen all my parts, reset all their transforms, grouped all the objects into one group, and put all the models into one Model called ‘lighthouse’. Yet, despite this, the file still fails to compile. If it is relevant, during compile, I receive a:

WARNING: Unknown command $concave} in collision series
Model has 1 convex sub-parts

Error/Warning message. This is what the “exported” model looks like in the Model Viewer (also note that it doesn’t even have the texture I was using applied to it:

And this is what it looks like if I try to ‘force’ the model to be in the right position.

What am I doing wrong here that’s causing the whole works to foul up?

My QC File:

// Output .MDL
$modelname lighthouse\lighthouse.mdl 

// Directory of materials that the model uses
$cdmaterials models\lighthouse

// Model properties

// model is a static prop

// Material properties
$surfaceprop "wood"

// Scale all units by a factor of 40
//$scale 40.0

// Base or Reference .SMD
$body studio ".\lighthouse" 

// sequences: all sequences are in $cd
$sequence idle "lighthouse_idle" loop fps 15 

// Physics data
$collisionmodel "lighthouse_phys.smd" {
$Mass 5
$maxconvexpieces 32

Merge them all as a single mesh.
Remember to press “Merge UVs” or something like that at the bottom of the dialog aswell so you don’t get stuck with a single tex

When I merge them, I get screenshot #2. :s
Am I merging them incorrectly?

No idea

That is one messed up QC try this:

$modelname "lighthouse\lighthouse.mdl"

$scale 40

$body ranged "lighthouse.smd"
$cdmaterials "models\lighthouse"

$surfaceprop "wood"

$sequence idle "lighthouse.smd" fps 1

$collisionmodel "lighthouse.smd" {
$mass 100.0
$inertia 1.00
$damping 0.00
$rotdamping 0.00

Theres so many things wrong with that QC you put up i’m not going to even bother telling you all of it, just try the one i’ve put above and it should work if your model is not a ragdoll.

Still not exporting properly; still no textures.
Looks like screenshot 1 again.

Can you export as .obj? If so I could take a look at it for you.

Sure thing. I assume that the modelers on the modeling team for Iron Cast knew what they were doing when they made the models but… I’d like a second opinion.

I already had to cull perhaps 80 unused materials so I am open to the possibility that they just don’t know how to model things properly, even though they think they do. Steps to prevent whatever has gone wrong in this model would be greatly appreciated so that this isn’t a pain in the arse again.

Just the OBJ:

could to with the .mtl and textures aswell if your expecting me to be able to prove the textures work or not ¬.¬

The “Everything” link has the MTL and all the base textures included.

I see sigh


Did you convert your materials to .vtf’s? Beacuse what you’ve given me here are TGA’s, which is fine for .obj files, but doesn’t work for Source.

Yep. And they all have VMTs associated with them, they’re all using VertexLitGeneric, and they’re all pointing to the same folder which the textures are in (which is to say they’re just saying “the texture’s right here in this directory that I’m in”).
Nothing too fancy going on in the VMTs either. Just your regular ol’ diffuse model texture.

Right, well it looks fine so far, i’ll export and compile it in a min, i’ve repositioned it as it was weirdly centred and also you really don’t need scale 40 in the QC as it massive already (about 9 times taller than a vortigaunt, which I put in to check the scale).

Thanks bunches, Silver Spirit. This problem with getting models in-game has been plaguing our classroom for more than eight months now and I’ve been grappling with Source the whole time. I’ve only ever successfully compiled a model into Source once and that took me six agonizing hours of painstakingly testing every single kind of directory structure there could possibly exist, constantly recompiling, making and fixing and recreating and testing and retesting just about every kind of QC configuration that exists, and constantly re and re and recreating the VMTs and VTFs with every setting imaginable.

I’m getting so darn tired of wrestling with Source just to get models in, and it’s got me real fired up and frustrated, that some days I just want to throw in the towel and say ‘fuck it, I’m never going to get these models into the game’. And that’d be a darn shame too. We’ve got great models and fantastic concept art but if none of it can show up in the game then what’s the point.

ok, i’m not sure why you’ve been finding it hard :S Static models are pretty easy to do, its ragdolls and weapon models that are, shall we say…difficult.

All you have to do is use that QC i’ve put there and alter the name of the SMD to the name of the SMD of whatever you want to compile, the VMTs are the same (so long as you don’t want fancy stuff, just alter the name/path in it to the texture your wanting to use). However there is a bit of fiddlyness in the modelling side before you can alter things to a point where they will actually comply with the strict and sadistic rules of the compilers ¬.¬ (which have pretty useless error messags tbh).

Also can you pass me the VTFs/VMTs as otherwise i’ll have to convert them all and i’m bound to screw at least one of them up :confused: (which would just make it take longer).

np, i’m glad to help and if you need any after this is sorted (If I don’t get the same problem), just send me a PM and i’ll try to help ya ^^

These were pulled from:
C:\Program Files\Steam\steamapps\firgofumbra\half-life 2 episode two\ep2\materials\models
Here there be VTFs/VMTs

Now you’ve said that, I think i might know what your problem is, but we’ll see once i’ve got them.

Yea thought so:

	"$baseTexture" "models\dome"

Should be:

	"$baseTexture" "models\lighthouse\dome"

(thats for all of them not just this one) and be in the “models/lighthouse” folder, i’ll port this through for you anyway, but I think that will fix your issue.

Well, there shouldn’t be any problems. Heck, I followed the tutorials I found to the letter every time before. Only difference this time was I used VTEX directly instead of VTFLib, which is what I usually use.

Unless it did something really funky (which it shouldn’t? it’s Valve’s tools after all) then I can’t see where I’m going wrong. :\

Edit: Well, hell. Nobody told me it was looking from root. I was told the VMT looked for files based on what directory it was in. If it were in C:\A\B\Model\ then I should be able to just say lighthouse as the VTF and it goes 'oh, okay, well that must be in “C:\A\B\Model\lighthouse.vtf”. Dag nabbit. That would be the root of all the problems, now wouldn’t it.

Still, even with the textures fixed there’s the ridiculousness which is the compilers explicitly ignoring my custom physboxes (aye, they’ve got textures applied and all) and then proceedin’ to completely annihilate the model itself, leaving only random bits and pieces scattered about.

Nope, the “cdmaterials” line in the qc is your definition of the path for the materials so your materials must be in the folder you’ve defined (in this case models/lighhouse), your textures however can be where ever you want, but the path would have to be defined to where it is in the VMT.

Yea, no idea what thats about but I wouldn’t bother with custom collision models or hboxes on static props, way more hassle than its worth.

May be so but simulating the physboxes by doing invisible clipzones in Hammer isn’t ever ‘precise’ in my experience.