model compile help

ive got my model smd's for all the lod of this model in the C:\Steam\SteamApps\name\sourcesdk_content\cstrike\modelsrc\cable_runner FOLDER

ive got the material for it in C:\Steam\SteamApps\name\counter-strike source\cstrike\materials\fact FOLDER

here is what my qc looks like right now

$cdmaterials materials/fact/cable_runner
$origin 0 0 0 90
$scale 1.0
$body "Body" "cable_runner_collide.smd"
$surfaceprop "metal"
$staticprop
$noforcedfade

$lod 18
{
replacemodel "cable_runner_1" "cable_runner_2"

}

$lod 40
{
replacemodel "cable_runner_1" "cable_runner_3"

}

$lod 80
{
replacemodel "cable_runner_1" "cable_runner_4"

}

the only thing i think i need to do is get studiomdl to work but i do not know how

unlike materials i cannot just drag the file over it and it will do its magic

and i am very forign to using command prompts, but i am willing to give it a try if its the only way

---

the only problem with steam updating things every week is it doesent give the developers an incentive to playtest thier work, so we do it for them

a couple of things to mention about the .qc file. first, the value for $cdmaterials should be the folder that your vmt is in, relative to your materials folder, so yours should look like $cdmaterials fact

your lod setup is almost right, but your trying to replace cable_runner_1 in each lod line. should be like this

$lod 18
{
replacemodel "cable_runner_1" "cable_runner_2"

}

$lod 40
{
replacemodel "cable_runner_2" "cable_runner_3"

}

$lod 80
{
replacemodel "cable_runner_3" "cable_runner_4"

}

once you've got your .qc sorted, all you need to do is drag and drop it onto studiomdl.exe

---

i eat paint

well i do the drag part and it opens up the compiler, but it doesent stay open for more than a split second. so i cannot see if i am getting any errors or not.

and besides after i do supposedly compile it, i do a search and i cannot find the compiled mdl

should the texture file be in the materials folder in the sdk directorys or in the cs source directories?

---

the only problem with steam updating things every week is it doesent give the developers an incentive to playtest thier work, so we do it for them

and as far as my qc file went, i used the contents of the hl buggy qc and just removed what i diddnt think was nessassary,

and i said that to say this

the lod parts all say the same smd was brought down to each level

but if thats how you do it and it works than ill do it that way

---

the only problem with steam updating things every week is it doesent give the developers an incentive to playtest thier work, so we do it for them

your .qc didn't say what your model should be named, or where it was to go, so that may have been a problem. :rolleyes: there were one or two other things that i noticed, so i've re-written your .qc with some comments. everything after double slashes '//' is a comment and will be ignored by the compiler, so you can copy paste the whole thing as a new .qc file. but you'll need a sequence smd before it will work. see below.

$modelname warlord/cable_runner.mdl // this will name the compiled model, and place it in the models/warlord folder. change as desired, but make sure the folder you name exists in your game directory.

$cdmaterials fact // looks for the material(vmt, not vtf) in the materials/fact folder (of your game dir.)

$scale 1.0

$body studio "cable_runner_1.smd" // the .smd here should be your highest poly reference smd. it should also be the same as the 1st smd to be replaced in your lod commands, so i've changed it for now, and used your lod1 smd. the 'collide' name from the original line that was here suggests that it may have been your physics model that was referenced, so i've used it as a collision smd (below the lod's)

$surfaceprop "metal"
$staticprop
$noforcedfade

$lod 18
{
replacemodel "cable_runner_1" "cable_runner_2" // moving away from the model, at 18 units(?) the lod1 will be relpaced by lod2

}

$lod 40
{
replacemodel "cable_runner_2" "cable_runner_3" // as lod 2 will be the model rendered at a distance of over 18 units(as above) , then its lod 2 that gets replaced by lod 3 at a distance of 40.

}

$lod 80
{
replacemodel "cable_runner_3" "cable_runner_4" // and when you get to 80 away, then lod 3 gets dropped in favour of lod 4

}

$sequence idle "idle" fps 1 // every model needs at least one sequence. export another smd as a sequence named idle, and put it next to the ref.smd's.

//if cable_runner_collide.smd isn't your collision model, then delete everything below here, or replace the reference with the right name.

$collisionmodel "cable_runner_collide.smd" {
$Mass 50 // Mass in kilograms
$concave
}

//[edit]open a command prompt and drag studiomdl.exe onto it. hit spacebar before dragging your qc onto it, and then hit enter. the box will stay open after the compile, showing any errors if it fails.

---

i eat paint

ok ive managed to get it to compile thanks to your help

however ive had to change all the starting lod's back to the first cable_runner1 and now that part works the only things that are not working is the collision model and the texture

, path cable_runner
Working on "cable_runner.qc"
SMD MODEL cable_runner_1.smd
SMD MODEL cable_runner_2.smd
SMD MODEL cable_runner_3.smd
SMD MODEL cable_runner_4.smd
SMD MODEL idle.smd
SMD MODEL cable_runner_collide.smd
Lod 1: vertexes: 800 (60 new)
Collision model completed.

---

writing c:\steam\steamapps\vze1u5dy@verizon.net\counter-strike source\cstrike\mo
dels/fact/cable_runner.mdl:
bones 708 bytes (1)
animations 104 bytes (1 anims) (1 frames) [0:01]
sequences 220 bytes (1 seq)
ik/pose 164 bytes
eyeballs 0 bytes (0 eyeballs)
flexes 0 bytes (0 flexes)
textures 72 bytes
keyvalues 0 bytes
collision 0 bytes
total 1464

---

writing c:\steam\steamapps\vze1u5dy@verizon.net\counter-strike source\cstrike\mo
dels/fact/cable_runner.vvd:
vertices 38400 bytes (800 vertices)
tangents 12800 bytes (800 vertices)
total 51264 bytes

---

Generating optimized mesh "c:\steam\steamapps\vze1u5dy@verizon.net\counter-strik
e source\cstrike\models/fact/cable_runner.sw.vtx":
body parts: 8 bytes
models: 56 bytes
model LODs: 48 bytes
meshes: 36 bytes
strip groups: 100 bytes
strips: 108 bytes
verts: 21942 bytes
indices: 15984 bytes
bone changes: 64 bytes
everything: 38334 bytes

---

Generating optimized mesh "c:\steam\steamapps\vze1u5dy@verizon.net\counter-strik
e source\cstrike\models/fact/cable_runner.dx80.vtx":
body parts: 8 bytes
models: 56 bytes
model LODs: 48 bytes
meshes: 36 bytes
strip groups: 100 bytes
strips: 108 bytes
verts: 21942 bytes
indices: 15984 bytes
bone changes: 64 bytes
everything: 38334 bytes

---

Generating optimized mesh "c:\steam\steamapps\vze1u5dy@verizon.net\counter-strik
e source\cstrike\models/fact/cable_runner.dx90.vtx":
body parts: 8 bytes
models: 56 bytes
model LODs: 48 bytes
meshes: 36 bytes
strip groups: 100 bytes
strips: 108 bytes
verts: 21942 bytes
indices: 15984 bytes
bone changes: 64 bytes
everything: 38334 bytes

Completed "cable_runner.qc"
Memory leak: mempool blocks left in memory: 48

---

the only problem with steam updating things every week is it doesent give the developers an incentive to playtest thier work, so we do it for them

ok nevermind the physic model part, ive gotten it to work, it had something to do with the texture i used (which was none) but i put one on and now it works

now im down to just the material alltogeter not showing up, ive got the purple and black checkers so i know im close

---

the only problem with steam updating things every week is it doesent give the developers an incentive to playtest thier work, so we do it for them

there's a good tut here on creating physics models. basically, you make the phys model from convex blocks, just like you would do in hammer, and each block must be assigned its own smoothing group.

if the texture you're using is called cable_runner, then the reference models must have been wearing it (the filetype/extension is unimportant, only the name) when you exported them as smd's. once the model is compiled, hl2 will look [in the folder specified as the $cdmaterials value] for cable_runner.vmt

if you've moved the vmt and vtf from some other folder, did you remember to change the $basetexture value in the vmt?

---

i eat paint

the texture showes up in hammer

im gonna try and tweak the qc a little more

---

the only problem with steam updating things every week is it doesent give the developers an incentive to playtest thier work, so we do it for them

nope nothing is working i either get the checkerboard or just a wireframe but no texture

im thinking it has something to do with where the texture is located but i cant figure it out

---

the only problem with steam updating things every week is it doesent give the developers an incentive to playtest thier work, so we do it for them

post your textures .vmt file, there may be clues in that.

---

i eat paint

its in C:\Steam\SteamApps\name\counter-strike source\cstrike\materials\models\fact

"LightmappedGeneric"
{
"$basetexture" "models/fact/cable_runner"
"$bumpmap" "models/fact/cable_runner_norm"
"$surfaceprop" "metal"
"$model" "1"
}

and ive changedd the qc to read this

$cdmaterials models/fact/cable_runner

and like i mentioned earlier the material does show up in hammer

---

the only problem with steam updating things every week is it doesent give the developers an incentive to playtest thier work, so we do it for them

Hahah, for source of course, it rhymes.

ok fishy ive read in another forum that you too model with milkshape

how do you put collision model pieces into smoothing groupes with that?

and i am still stuck on the texture not showing up. ive must have tried everything

---

the only problem with steam updating things every week is it doesent give the developers an incentive to playtest thier work, so we do it for them

1st post

ive got the material for it in C:\Steam\SteamApps\name\counter-strike source\cstrike\materials\fact FOLDER

last post

its in C:\Steam\SteamApps\name\counter-strike source\cstrike\materials\models\fact[color=white]

[/color] haha, one of you is telling lies :razz:

as the qc i made was based on the first quote, i used $cdmaterials fact

[color=white]if the second quote is right, it should be $cdmaterials models/fact [/color]

:smile:

---

i eat paint

well ive tried both of them

ive moved it to the models fact folder to keep with the pattern with official model textures being in there

ive chainged all the code in both the qc and the vmt's to match the change so it should not get in the way

could i get a copy of a qc file of yours, and a vmt code that you have for one of your textures?

i know i am close tho, because the model does show up with the checkerboards, so that means that it know to look for a texture, but either it cannot find the texture or my texture isnt properly made for a model and just refuses to work

---

the only problem with steam updating things every week is it doesent give the developers an incentive to playtest thier work, so we do it for them

i must have been convinced that it was the path to your textures folder was the culprit, because i didn't notice you were using the wrong shader type in the vmt file, you should be using VertexlitGeneric instead of LightmappedGeneric. i dunno if that would cause the purple checks though.

and ive changedd the qc to read this$cdmaterials models/fact/cable_runner[color=white]

[/color] you neeed to drop the cable_runner bit. it's only thepath to the folder that the texture is in, relatiive to your materials folder, that you put there.

for smoothing groups in milkshape. on the bottom half of the groups tab you'll see 2 buttons(assign/select) with lots of numbered buttons below them. with the 'assign' button depressed, select one of the blocks that make your collision model and hit the number 1 button. all the faces for that block are now in smoothing group 1. deselect that block and select another before hitting button number 2. repeat with each block, assigning a different number each time.

---

i eat paint

great that did it

it was a combination of the vertex lit thing and the $cdmaterials thing

the only reason i diddnt remove it before was because when i did the model would only show up wireframe reguardless of what rendering i chose

but ok it all works now thanks fishy

---

the only problem with steam updating things every week is it doesent give the developers an incentive to playtest thier work, so we do it for them

ah, tis good then :smile:

because you started the thread, it means that you have the option of marking suggested answers (the one in the yellow frame)as right or wrong. doing that updates the boards to mark the question as answered and help with future searches etc. (and gives me snarkmarks :dorky: , so gogogo)

---

i eat paint

i intended to mark it correct, however i wanted to mark the correct thing right so if others look at it they know what solved it.

that being said can you edit this one to be a possible solution so i can mark it?

fishy said:
i must have been convinced that it was the path to your textures folder was the culprit, because i didn't notice you were using the wrong shader type in the vmt file, you should be using VertexlitGeneric instead of LightmappedGeneric. i dunno if that would cause the purple checks though.

<DIV class=quote>
<DIV class=quotetitle>? quote:</DIV>
<DIV class=quotetext>and ive changedd the qc to read this$cdmaterials models/fact/cable_runner[color=white]

[/color] you neeed to drop the cable_runner bit. it's only thepath to the folder that the texture is in, relatiive to your materials folder, that you put there.

for smoothing groups in milkshape. on the bottom half of the groups tab you'll see 2 buttons(assign/select) with lots of numbered buttons below them. with the 'assign' button depressed, select one of the blocks that make your collision model and hit the number 1 button. all the faces for that block are now in smoothing group 1. deselect that block and select another before hitting button number 2. repeat with each block, assigning a different number each time.</div></div>

---

the only problem with steam updating things every week is it doesent give the developers an incentive to playtest thier work, so we do it for them

those were only the final 2 things. there was the missing sequence too, and the missing lines from the qc file. then the bit about the collision model, all of which were just as important.......

---

i eat paint

yea but the lod part of it was incorrect

---

the only problem with steam updating things every week is it doesent give the developers an incentive to playtest thier work, so we do it for them

warlord said:
yea but the lod part of it was incorrect

i beg to differ

---

i eat paint

well the way i dod the lod worked for me, however ive marked it correct so this thread id answered and to give you the points for your help

---

the only problem with steam updating things every week is it doesent give the developers an incentive to playtest thier work, so we do it for them

as far as i know, the way that you've done it will work, but only for the first change of lod. did you encounter some sort of compile error concerning my method?

---

i eat paint