Custom model woes, smds badly made?

MoonUnit

L1: Registered
Aug 12, 2008
12
0
So I've collected some knowledge from various locations around the net. Starting first and foremost with this tutorial by Noesis:

http://www.moddb.com/engines/source...stom-props-for-source-powered-games-with-maya

And a few weeks back I successfully completed the tutorial and happily had the skull in game. Buuuuuuuuuuut, now I can't get a damn thing to work and I can't figure out what I'm doing wrong.

So I'm using the prall exporter from maya and that seems to be a part of the problem, here's a comparison. I had to put these as attachments because it's a lot of text.

Looking first at the good compile; Its happily detected that the physics model is a load of crap, compiled the smds and so on.

Now looking at the bad compile; It's not even noticed any problems with the physics model and so many fields are listed as 0 bytes when they shouldn't be. Something is wrong with my smds.

Anyone whose had experience working with importing custom models, how are you creating your smds? Using the prall plugin for maya, can you think of what I'm missing here? etc.

ANY help is appreciated, I've been pulling my hair out over this for a while now but I just can't figure it out.
 

3DRyan

L2: Junior Member
Aug 29, 2008
57
6
funny thing, I was just in your position a few days back. I thought that I had the process down, but I had to sort of relearn it again due to technical setbacks. Not sure if you've seen it, but here's a great tutorial that explains the process step by step and might have some info that activates a light bulb or two in your head.

http://forums.tf2maps.net/showthread.php?t=838&highlight=custom+prop

Personally, my knowledge is a combination of many resources spread throughout the net. Noesis got me familiar with some of the workflow, but there were many unexplained aspects that they didn't address. Prall gave me problems so I abandoned that. I gave up on getting my physics models to work, and decided to handle collision with clip brushes inside hammer. MUCH easier. There's almost always more than one way to do something with this process if you just can't seem to get things working.

As for SMDs, I model, texture, and UV within Maya. I combine all of the objects into one, freeze transformations, delete the history, and make sure my uvs are correct.

VERY IMPORTANT: Make sure that all of your geometry has uvs. No jagged lines. Otherwise, they will not transfer into many other programs, I'll get to that more soon. All of your geo also has to be convex. Sometimes people delete faces that you can't see, but Source cannot read it. All of your geo must be 100% clean. No unmerged vertices or anything like that.

After all of this looks good in maya, I export it as an OBJ file, and import it into XSI Mod Tool. If you don't have it, there is a link in the Source SDK menu that takes you to their website. You can read in the tutorial I gave you how to move around in the program as I can't remember off the top of my head. Once you can do that, import the obj, and apply the texture to it. If part of your geometry is missing uvs, then they won't show, which is why I mentioned it earlier, so get it right before you export it from maya. Hawk's tutorial covers getting the material onto it perfectly. You must have the texture applied to the model when you export it from Mod Tool or your MDL won't compile properly. Once you have that, go to the valve tab at the top of the UI and choose "export SMD". Default options should be fine. Do it for whichever ammounts of LOD you have. If you don't do LOD, it'll just be one SMD. As for the QC, here's the code I use that works every time:

// Output .MDL
$modelname tf2models/chair.mdl

$cdmaterials "tf2mat"

$staticprop

$surfaceprop "wood"

$body "studio" "chair_1.smd"

$sequence "idle" "chair_1.smd" fps 30

// LOD 1
$lod 25
{
replacemodel "chair_1.smd" "chair_2.smd"
}

$collisionmodel "chair_c.smd"
{

$Mass 100
$concave
}

Just ignore everything ab out collision and use hammer for that, trust me. This part is for the LOD which you may not need in this case:

// LOD 1
$lod 25
{
replacemodel "chair_1.smd" "chair_2.smd"
}
Also, use your regular reference SMD for the animation, unless you want it to animate, which is different. I can't remember how to deal with it, but the noesis tut on mod tool's site covers it correctly. All in all, use Maya and then Mod Tool. It works very well and saves me quite the headache.

Let me know if you have any questions about any of this. I hope it helps, and good luck!
 
Last edited:

Sgt Frag

L14: Epic Member
May 20, 2008
1,443
710
I've made several objects in 3dsMax and I can see one thing in 3dRyan's post that is not a hardline truth.

Models don't need to be convex. I made several support posts that work fine but they don't have polys at their bases. That would make them an 'incomplete hull'.
Also, the shape of them is like a pitchfork which is concave.

But I did make collision models for them which ARE convex. It is made of 3 cubes to fit the 'pitchfork shape', but all three pieces themselves are convex even though together they make a concave shape.

I think the problem you might be seeing is that you are failing to get your collision models to work so the export is trying to make a collision model out of your model. Most likely it is trying to make it concave which is causing problems.

I recommend instead of by passing the collision and using world spawn to just figure out the collision model problems first and use them as intended.

They really aren't that hard, but as 3dRyan said you might find it easier to export an obj and import that into XSI for an smd export.

The collision models just need to be convex (ie a cube is convex, a horseshoe is concave). You can use a bunch of simple cubes to get a decent mesh.
They don't need uv'es but they do need a material applied (just use the material you use for your model).
Each piece of the collision model needs it's own smoothing group (although I have heard that they can all have the same one as long as they have one, I haven't tested that).


Maybe you can post pics of you model and collision model and we can see more from that.
 

3DRyan

L2: Junior Member
Aug 29, 2008
57
6
Yes! That would help us to help you a little better. What Frag says is most likely true. I guess I'm just anal retentive about my modeling, but unless you're cutting alot of polys off your model, deleting unseen faces won't make much of a difference anyway. Different people, different methods. What you say about collision models could possibly help me to make them work, but making clip brushes is the way I prefer at least for now. As for more advice to Moonunit, after you get this model working, try another. You might find new issues with new models, and after a couple of tries with different ones, it'll all be second nature no matter what you make.
 

MoonUnit

L1: Registered
Aug 12, 2008
12
0
Hey guys, thanks for putting the time into those responses. Ok so one by one;

Aye I have seen that tutorial to go through XSI. I tried that one but annoyingly when I took my model into XSI the UVs wen like... 10 pixels to the left. Making them borked and broken. So I figured out how to move them in XSI and exported my smds. And then it did it again on the export.... -_- they were off again when I got it in hammer. I actually got the Noesis tutorial to work that one time, so that's why I've been trying to go through this method (essentially getting smds from the prall plugin rather than XSI export options).

Ive attached a picture of the model I've been trying to use, as I said I'm trying to do the Noesis tutorial so its just that skull. It in itself as a model works fine, I know because as I said in my first post I've gotten it in hammer before. I don't mind that the whole collision model thing is borked and it'll just wrap over it, That's not so much the issue. Again as i said in my first post the compile log where it complains about the collision model is the good one, because in the other compile using the new smd's it doesn't even notice that the collision model is buggered (when it should, but the data just doesn't appear to exist in the smd and its kind of a blank).

So in culmination from the content of this post;

Do you know why I would be having my UVs shift on me when I export to OBJ and import to XSI, and have it happen again with the exported smd?

Do you know why, using the prall plugin, my smd's are basically blank?
 

3DRyan

L2: Junior Member
Aug 29, 2008
57
6
Wow, this is very odd. As I have not had any luck even getting smds out of maya with prall, I have no idea about that problem. Same thing with the moving uvs, never heard of that problem. Any takers? Sorry I couldn't be more help.:(
 

MoonUnit

L1: Registered
Aug 12, 2008
12
0
Ok so just did another test with going through XSI to get SMDs. So first I put the Noesis skull through, worked a charm and I've got a happy skull in game. Its texture is kind of... bland though. So you can't really tell if the UVs shifted but I don't think they did....

So then I tried the model I actually want to do this all with, which is this window (or at least this is the first I'm _trying_ to get to work). And my obj/XSI problems are still present. I've attached a picture to better illustrate my point. Does anyone know why this would be happening?
 

Sgt Frag

L14: Epic Member
May 20, 2008
1,443
710
Weird, I don't know why the UV's would shift either. I don't use maya and don't care for learning/need to learn XSI so I'm afraid I can't be much help there.

I do know that lately I have imported alot of Maya exported obj files into max. When I do I have alot of options to choose from, do you have alot of obj export options in Maya, could be something there that needs checked/unchecked.
----------------------
First, in both your compiles I notice this:
WARNING: $modelname key has slash as first character. Removing.
Looks like it fixes it but you might want to fix that to start.
----------------------
2nd,
In your good compile you do have issues with collision:

WARNING: Model has 2-dimensional geometry (less than 0.500 inches thick on any axis)!!!
WARNING: COSTLY COLLISION MODEL!!!! (45 parts - 20 allowed)

All that stuff is about it trying to make your model (which is concave) into a collision.

It's been awhile since I've done this stuff myself but I believe the Max export allows you to export model only. Then you export collision seperate.
Does your plugin give those options/are you exporting model (No collision)only? Maybe you are exporting wrong?

=========
along those same line in your good compile at top

SMD MODEL skull.smd
SMD MODEL skull_idle.smd
SMD MODEL skull_phy.smd

Those are the models your QC is looking for, if it doesn't find a skull.phy.smd it tries to make one, thus the concave errors, it can't find it (or you have one which is concave).
-----------------

OK, sorry I 'm tired. Not really sure how you are getting the good and bad compiles.
To me it looks like the 'bad compile' is doing something, in that text it listed bytes for each part of the model. The collision is alot lower of course.

Maybe explain how you are doing that, I looked back through posts but didn't see explanation.

---------------
As a hack you might be able to just nudge your UV's to the left a few pix. I know it's a hack and I wouldn't like to do it myself, but if it gets the job done...
 

MoonUnit

L1: Registered
Aug 12, 2008
12
0
Thanks for keeping the replies coming guys.

Ok so to be very clear basicaly at the end of the day, however its done I just want my models in game. I'm currently facing problems with two differen't methods I am using to try to making this happen:

1. Using the prall plugin from maya: The smd's that are exported appear to contain little to no data. This is evident in the compile logs posted above, where the bad compile is the log from using this method.

For example; It SHOULD be complaining about the physics smd being a mess, concave issues and such. But it doesn't because the physics smd seemingly is not properly made.

2. Importing an OBJ into XSI and exporting SMDs from there: The UVs move off to the left slightly when importing into XSI (I've checked the obj by re-opening it in maya, it shows up fine there). If corrected manually, they do it again when exporting to smd anyway.

Now....

Method 1 related:
First, in both your compiles I notice this:
WARNING: $modelname key has slash as first character. Removing.
Looks like it fixes it but you might want to fix that to start.

yeah that's sort of a mistake on my part, but it doesn't cause issues in the compile that worked so it's not a part of the problem (and as you can see the compile fixes it anyway)

Method 1 related:
2nd,
In your good compile you do have issues with collision:

WARNING: Model has 2-dimensional geometry (less than 0.500 inches thick on any axis)!!!
WARNING: COSTLY COLLISION MODEL!!!! (45 parts - 20 allowed)

All that stuff is about it trying to make your model (which is concave) into a collision.

It's been awhile since I've done this stuff myself but I believe the Max export allows you to export model only. Then you export collision seperate.
Does your plugin give those options/are you exporting model (No collision)only? Maybe you are exporting wrong?

Don't worry, I'm very much aware of how collision works. I actually made that happen on purpose, exporting a collision model which was just the reference model because at the time of making the good compile I didn't mind that it would create a wrapped collision model, its a pretty solid shape.

This however highlights a point, doing the exact same thing later in the bad compile; it is not complaining about the collison model. Which goes to show that there's an issue with the SMD because it should be complaining as the circumstances are exactly the same. Well except for obviously my SMD has not been exported correctly.


Method 1 related:
along those same line in your good compile at top

SMD MODEL skull.smd
SMD MODEL skull_idle.smd
SMD MODEL skull_phy.smd

Those are the models your QC is looking for, if it doesn't find a skull.phy.smd it tries to make one, thus the concave errors, it can't find it (or you have one which is concave).

Oh I know, those models are very much present. The thing being that it actually finds them in both the good and bad compile. In the good compile it finds it and thus complains about the concave errors it produces. But in the bad compile, despite finding the model it appears to not notice that the concave issues it SHOULD be having.

Method 1 related:
To me it looks like the 'bad compile' is doing something, in that text it listed bytes for each part of the model. The collision is alot lower of course.

Maybe explain how you are doing that, I looked back through posts but didn't see explanation.

I'm confused as to what you mean by this. The bytes in the bad compile are often listed as zero. Notice in the good compile almost all fields the bad compile has listed as zero, the good compile has values for. It should, these files should contain that data but seemingly they don't because there was a problem with exporting.

What exactly is it you are trying to get me to explain?

Method 2 related:
As a hack you might be able to just nudge your UV's to the left a few pix. I know it's a hack and I wouldn't like to do it myself, but if it gets the job done...

Unfortunately I've already tried this. I nudged them and corrected the issues inside of XSI and then exported my SMDs. When opening it up in hammer, I noticed that it had moved them back again when it exported out of XSI... :glare:
 

Hawk

L7: Fancy Member
Dec 3, 2007
419
213
I can't tell why taking the "OBJ through XSI" route is shifting your UVs.... that's quite bizarre. But I might try looking into the Prall exporter. If anything can eliminate XSI from my workflow, I'm all for it. Maybe I can get experienced enough in it to be able to tell you what's going wrong. I work with Maya, too.
 

Sgt Frag

L14: Epic Member
May 20, 2008
1,443
710
Well, I was trying to get you to explain why you are exporting 2 models of the same name and why you get a good compile and a bad one.

Are you doing something different? Or is it random?
-------------
The rest of the stuff- just so you know I'm not questioning what you know ;)
Just going through the list one by one and trying to check stuff off, I was tired so it turned into rambling, I apologize for that.
-----------
I think I'm with Hawk here, it's gotta be the exporter from Maya. He'll probably be able to help more with that.

Good luck.
 

3DRyan

L2: Junior Member
Aug 29, 2008
57
6
Yeah, there aren't really any export options to speak of if you're exporting an obj out of maya. At least not for my 2008 version. I know this sucks to say, but make another model and try it instead. If it works, then you know that it was something with the UVs or geometry of the skull model. If it does the same thing, then you know it's an application error. This is sort of a last ditch effort to find out sort of what is wrong. Hope this helps.
 

MoonUnit

L1: Registered
Aug 12, 2008
12
0
Ok, so there's been a thing or two said that I'm going to skip over because I've had a bit of progress. But thanks for all your replies! So...


Using the second method (that is, Hawks. Thanks for dropping by!):

I did a few tests, and it seems that its just THAT model that's having the UVs jump in XSI. Why? I've still no idea, but I quickly re-did them and it imported without a jump. What did I do different? Bugger all, but I guess it works right... :glare: Anyway so with that, I happily made my smds and took it into hammer.

And now the texture won't show up.

I've attached a picture of both the model and texture in hammer in their relevant browsers. Happily refusing to acknowledge each others existence. I've also included a screenshot of the vmt and vtf files sitting in the appropriate directory. And for even more clarity here's

My vmt:
=====================================

"VertexlitGeneric"
{
"$basetexture" "grapes/models/model_villawindow1"
"$envmapmask" "grapes/models/model_villawindow1_spec"
"$model" 1
"$surfaceprop" "rock"
"%keywords" "tf villa window"
"$envmapcontrast" .5
}


=====================================

My models qc:

=====================================

$modelname grapes/model_villawindow1.mdl
$cdmaterials grapes/models/
$surfaceprop "rock"
$staticprop
$scale 1
$body studio "model_villawindow1.smd"
$sequence idle "model_villawindow1" fps 1
$collisionmodel "model_villawindow1_phy.smd"
{
$Mass 10
$concave
}

=====================================

Incidently I tried both:
$cdmaterials grapes/models/
and
$cdmaterials grapes/models
and
$cdmaterials grapes\models

and it doesn't seem to make a difference. Is there something I missed, a typo somewhere I haven't seen? If we can ever get this model in game I'll start growing my hair back, and it getting awful cold under my hat...

Thanks so much for all the help so far
 

3DRyan

L2: Junior Member
Aug 29, 2008
57
6
Wow, I think your model is cursed by the devil or something, lol.

Very strange that it shows the file in the texture browser and not on the model itself. The only logical explanation is that the uvs got tossed out somewhere in the pipeline. To my knowledge, if a texture shows up in the hammer browser then the texture file is being found and read correctly, no problem with the file path. I think it's a smd or mdl problem, personally. I really think I don't have any more advice that I could possibly give on this one except for showing an example of my qc file format:

// Output .MDL
$modelname tf2models/chair.mdl

$cdmaterials "models"

$staticprop

$surfaceprop "wood"

$body "studio" "chair_1.smd"

$sequence "idle" "chair_1.smd" fps 30

// LOD 1
$lod 25
{
replacemodel "chair_1.smd" "chair_2.smd"
}

$collisionmodel "chair_c.smd"
{

$Mass 100
$concave
}

*****keep in mind that my collision model doesn't work on this one*****

Hope this helps!:)
 

MoonUnit

L1: Registered
Aug 12, 2008
12
0
SOLUUUUUUUUUUUTIOOOOOOOOOON

OK, so this saga is for now basically over. Thanks to everyone who chipped in. Its been a while since I last posted on it but I had someone look at the files and they eventually found the source of the problem, thank fucking christ. So now, using hawks method I can get the models in game.

SO! Here's the follow up for anyone who may encounter this issue and stumble on this thread:

I used the wrong file as the texture file in XSI.

See I figured that the file you used in XSI was just to make sure the UVs had shown up alright, but apparently this information also gets carried over to the smd. Specifically the file name. I thought that you denoted the directory whereby the vtf would be found in the qc and it would look for something with the same file name, apparently not true. It takes the directory from the qc, and the file name to look for from the file name associated with the shader in XSI that was applied to the model.... intuitive huh! And not at all at odds with the vmt/vtf system... nope.....

anyway, that's that. Thank again everyone.

EDIT: Oh my oh my... maya to XSI via OBJ still enjoys shifting my UVs to left slightly... just sort of randomly for no reason, forcing me to redo the UVs randomly for no reason...
 
Last edited: