Problems adding skins to an existing model

[msleeper]

I am trying to add a few new skins to the existing metal_box model in Portal. I am compiling a new model as opposed to just overwriting the existing skins because I need more than 2, and also the players will need to run into the normal metal_box's aswell.

I have followed Jesta's reskinning tutorial to the letter, and I am having some problems. Last night, after I recompiled the model, all I kept getting was the standard pink and black checkerboard on the model, indicating that the textures it was trying to use weren't valid or didn't exist. This wasn't the case though, since I could load up Hammer and view and use the textures fine.

So I decided to call it a night and try again later. I started from scratch and re-modified the .qc, deleted the old model and textures, recompiled the model and moved the textures to the correct location. Now I have a new problem, the model will only display the old box skin. It still lists 3 possible skins to choose from, but they are all the standard gray skin.

Which doesn't make any sense, since none of my VMTs reference the old skin VTF, and the .qc doesn't either.

Here is my .qc:

Code: Select all

$cd "E:\models\box"
$modelname "props_rgb/metal_box_rgb.mdl"
$model "Body" "metal_box_reference.smd"
$lod 15
 {
  replacemodel "metal_box_reference" "lod1_metal_box_reference"
}
$lod 35
 {
  replacemodel "metal_box_reference" "lod2_metal_box_reference"
}
$lod 60
 {
  replacemodel "metal_box_reference" "lod3_metal_box_reference"
}
$lod 80
 {
  replacemodel "metal_box_reference" "lod4_metal_box_reference"
}
$cdmaterials "models\props_rgb/"
$texturegroup skinfamilies
{
   { "metal_box_red.vmt" }
   { "metal_box_green.vmt" }
   { "metal_box_blue.vmt" }
}
$hboxset "default"
$hbox 0 "polymsh" -19.796  -19.797  -19.795  19.796  19.795  19.795
// Model uses material "metal_box_red.vmt"
// Model uses material "metal_box_green.vmt"
// Model uses material "metal_box_blue.vmt"
$surfaceprop "metalpanel"
$keyvalues  { prop_data { "base" "Metal.small"  } }
$illumposition -0.000 0.000 -0.001
$sequence idle "idle" ACT_IDLE 1 fps 30.00
$collisionmodel "phymodel.smd" {

   $concave
   $mass 40.0
   $inertia 1.00
   $damping 0.10
   $rotdamping 0.00
}

And here is one of my VMTs, they are all identical with the exception of the exact VTF name:

Code: Select all

"VertexLitGeneric"
{
   "$basetexture" "models\props_rgb\metal_box_red"


   "$bumpmap" "models\props\Metal_box_normal"
   "$phong" "1"
   "$phongexponenttexture" "models\props\Metal_box_exponent"
//   "$phongexponent" "25"
   
   "$phongboost" "3"   
   //"$lightwarptexture" "models\props\Metal_box_lightwarp"
   "$phongfresnelranges"   "[5 1 2]"
//   "$halflambert" "1"

//   "$envmap" "env_cubemap"
//  "$normalmapalphaenvmapmask" 1

  "$selfillum" 1
}

[Kubata]

This is almost IDENTICAL to the problem I am also having with the Combine Soldier model. Thank you for also bringing this to the attention of interlopers!

I hope somebody can answer this, I'd be very grateful to anyone that can.

[msleeper]

After some fiddling and recompiling, I've found that:

- Changing the materials folder to "models/props/blah" makes the default metal_box texture appear no matter what.
- Changing the materials folder to "models/props_rgb/blah" makes the pink/black checkerboard appear.

I wish there was some sort of error output I could look at to see what it is trying to do, and where it is trying to look for stuff.

[Jest@]

If you're in dev mode in-game you should see errors in the console if a texture can't be found/loaded. ("developer 1" in console, then reload your map)

I can't see any problems with your qc/vmt...just to check, your VMTs and VTFs are in the game_name\materials\models\props_rgb\ folder, right? And the VMTs have the same names as the originals?

I'm gonna take a guess here and say the problem isn't that it can't find the materials/textures..it's that they're in the old VTF format. I would have though portal would still support old-format vtfs, but perhaps not. You'll need to use the new SDK version of vtex to convert (unless the 3rd party ones have been updated, I haven't checked yet myself)

[msleeper]

I honestly didn't even think of the VTF version, I'll give that a try tomorrow when it isn't 4am. I have seen a "7.3" version in VTFedit but I haven't given that a try.

About the paths and file names, they are named correctly and everything is where it should. As I said, I can view and apply the materials to brushes in Hammer, so I know that part is atleast working.

[msleeper]

Okay, I converted the VTFs to the 7.4 format and overwrote the old skins. I still received the pink/black checkerboxes.

I then tried to recompile the model using a different VTF location and got some weird errors. I will have to troubleshoot this a bit later since I had to run out the door right after that, and I'll take a look in-game and see what the console says about my faulty skins.

[dr_smith]

I had the equivalent problem and found the fix for it.
Original problem:

I have decompiled metal_box.mdl, created from metal_box.vmf my custom texture, then modified .qc file and compiled a customized version of metal_box which I called orange_box.
In both editor and portal game there appeared just old gray texture metal_box.vtf even though my orange_box.vmt pointed to orange_box.vtf.

Reason of the problem: I checked orange_box.mdl and discovered that it still refers to the old gray material metal_box.vmt even though my .qc file did not reference metal_box.vmt. It also included my new material orange_box.vmt and required its presence, but never displayed it.

The problem is that when metal_box.mdl is decompiled with MDLDecompiler, five files are created:
lod1_metal_box_reference.smd
lod1_metal_box_reference.smd
lod1_metal_box_reference.smd
lod1_metal_box_reference.smd
metal_box_reference.smd

They all contain the reference to the old texture metal_box.mdl (actual string is "metal_box.bmp").

FIX:
1) in all those five files from above replace substring "metal_box" to your material name (in my case it was "orange_box");
2) compile again your model
3) close and restart Hammer
4) recompile your map, because checksum of your mdl file should correspond to the sum registered in you map .vmf file
5) close and restart Portal game.

Then it should work.
Good luck.

P.S.: I have no answer why metal_box.bmp is included in .smd files and why everything works fine when you replace metal_box with your material name.

[crazycarl]

First off: the line

Code: Select all

// Model uses material "metal_box_red.vmt"

Doesn't do anything. It's a comment that mdldecompiler puts in there to help you. Anything that starts with // is non-functional. You can just delete it.

The .smd file specifies the material name for each triangle; this makes it possible to have multiple textures on one model. Any file extension that's there is irrelevant. The game will always look for .vmt files.

Any time you use $texturegroup, the first material in the column must be one that's referenced in the .smd file. Any textures below that will replace the original when the skin changes.

You could have your skins set up like this:

Code: Select all

$texturegroup skinfamilies
{
   { "metal_box.vmt" "metal_lid.vmt" }
   { "metal_box_red.vmt" "metal_lid_red.vmt" }
   { "metal_box_green.vmt" "metal_box_green.vmt" }
   { "metal_box_blue.vmt" "metal_box_blue.vmt" }
}

If you had a separate material for the box and the lid.

You can use $cdmaterials more than once. So you could do:

Code: Select all

$cdmaterials "models/props/"
$cdmaterials "models/props_rgb/"

and it will search both those folders for materials.

[Groxkiller585]

Did you ned the VMT's correctly?

The skin to be replaced NEEDS to be named what the texture used on the model upon conversion to SMD was. In the box's case it is called metal_box. So your FIRST VMT should be "metal_box". This tells the engine whch material to change. Now the others can be whatever, so long as it refrences the FIRST VMT.

AKA:

Metal_box.vmt -> Metal_box_RED.vmt

Metal_box.vmt -> Metal_box_GREEN.vmt

etc...