The 3ds Max Pipeline for the Source Engine

Np. You're welcome. Can you tell me what game you are making this for? Do you want a l4d2 door with fallbacks and break models? Or is this just for CS:GO where you aren't worrying about breaking, gibs and fallbacks? Either way it isn't all that complicated. To start with make your model the way you normally would, i.e mesh, hull, materials etc. However there is one extra thing you need to add and that is a DoorRootBone, just add a single bone node and call it DoorRootBone and place it on the axis you want the door to rotate around. You'll need to include this in your smd export so your smd has 2 nodes, your model node and the bone node. After that you also need to go into PropData and select Door.Standard with Phys Mode "Auto" and then Override Base... Allow Static and Block LOS all checked. It is possible that this is all you have to do in order to get your model to work as a prop door rotating. When I made mine because I was also adding break models I had to lock the QC in WWMT at this point and add the rest of the info by hand.

My final .qc file is pasted below. You can see it is all pretty standard with the important stuff being in the $keyvalues "prop_data" section. If you are making a non-breakable door then in the door options you can remove the damage1 damage2 etc fallbacks. The only thing I am not sure about is whether the "breakable_count" part will count for anything. This controls the gibs the model gives off in its breakable format when changing between base models... the base model changes for a more damaged one and x number of gibs are spawned to give the impression of bits flying off. The thing is the starting model in l4d2 door doesn't give off a visible gib the first time it changes to a more broken version, it just forms cracks... nonetheless there is still (as you can see here) a break count of 1 and it actually throws off an invisible gib (an untextured cube 8 units square). Its like it had to be put in there for the system to work. Now in GO this may be completely disabled/ignored as the door never tries to break, that said however Source can be weird so you never really know.

Hope this makes sense, i have no idea what level you are at with models etc. which can make explaining things tricky. If there is anything you don't understand here just ask. If you are trying to make a fully breakable door with gibs and fallbacks I will send you my scene file, however if you are trying to make a simple non breakable door looking at that may just confuse things for you as 95% of it you wouldn't require.

$modelname   "gmaps/props_doors/slatted_door.mdl"

//$staticprop

$body slatted_door "slatted_door.smd"

$cdmaterials "models/gmaps/props_doors"

$texturegroup "slatted_door_skins"

   {

    {  "slatdoor1" }
    {  "slatdoor2" }
    {  "slatdoor3" }
    {  "slatdoor_custom1" }
    {  "slatdoor_custom2" }

   }

$hboxset "default"

$surfaceprop "wood"

$contents "solid"

$cbox 0 0 0 0 0 0

$keyvalues {

      "prop_data"
      {
         "base"      "Door.Standard"
         "allowstatic"      "1"
         "breakable_count"   "1"
         "blocklos"      "1"

      }
      "door_options"
      {
         "defaults"
         {
         "open"      "Doors.Wood.FullOpen1"
         "close"      "Doors.Wood.FullClose1"
         "move"      "Doors.Wood.Move1"
         "pound"      "Doors.Wood.Pound1"
         "surfaceprop"   "wood"
         "damage1"    "gmaps\props_doors\slatted_door_dm01"
         "damage2"    "gmaps\props_doors\slatted_door_dm02"
         "damage3"    "gmaps\props_doors\slatted_door_dm03"
         "damage4"    "gmaps\props_doors\slatted_door_dm04"
         }
      }
   }

//$illumposition 27.5 0 55.5

$sequence ref "slatted_door_base_ref" fps 30

$collisionmodel "slatted_door_base_hull.smd" {

   $mass 50.0
   $inertia 1.00
   $damping 0.0
   $rotdamping 0.00

}

$collisiontext {
   "break" { "model" "gmaps/props_doors/props_null.mdl" "health" "100" "fadetime" "10"}
   }

This is about as step by step as you can get.

NB: It should no longer be necessary to contact Zeq about Crowbar as he has since released a public update.

CopyCat has given a clear explanation. Tbh it isn't making a lot of sense to me when you say that you are getting "extra" materials. In your smd a material name is given on a per triangle basis, with each tri starting with the name of the .vmt of the applied material. You cannot have more than one material applied to a tri within the smd. Any other materials would come from the .qc

When reexporting/compiling a model using WWMT you need to set the correct path names for the materials. I would recommend always assigning materials by using the eye-dropper tool. That will set up all the correct nodes for you in slate.

As for weld verts you can do it manually if it isn't importing welded. A lot has changed since Wunderboy/cannonfodder last updated their tools and anyway the whole process of decompiling and importing has never been 100% reliable. Smd importer would often also have problems with welding and smoothing groups which would have to be fixed manually.

So long as the names and paths are correct there is no reason why adding the materials using CopyCats method above should add extra materials to the exported .smd

The principles are the same for all Source games, just make sure you set the correct directories for your content in CS:S.

Did u get my reply to your message, Onur?

I haven't tried it for a while but in the past I also would have some skin/weighting problems when importing certain models, tbh it has never worked 100% perfectly for all models. Some models would work fine whilst others wouldn't, and oddly I would sometimes get different results depending on which version of Max I was using.

Historically, the whole Source model decompiling and importing has always been a little bit unreliable, a problem which has only gotten worse with more and more engine versions, game variations, DMX files etc. It seems to effect rigged characters or weapons models more than anything else, but that makes sense as they are generally the most complicated models a game will use, having the most variables/parameters... if just one of these gets mis-translated between the mdl/smd file and Max it is likely to throw everything off.

If you happen to still be running Max2012 you can try using Wunderboys importer instead until Shawn gets a chance to look at it, or try importing with WW in different versions of Max if you have them.

I sympathize though, I have suffered frustration in the past because it has turned out to be completely impossible to get certain game models into Max as a correctly rigged object.