Help with SMD exporter for source engine.

Game Engine, Players & Web Plug-in, Virtual Reality, support for other engines

Moderators: jesterKing, stiv

Post Reply
Posts: 3
Joined: Sat Sep 15, 2012 12:03 pm

Help with SMD exporter for source engine.

Post by Ynek_Slender » Sat Sep 15, 2012 12:31 pm

Good evening, ladies and gentlemen of the Blender community.

I have been playing with and using Blender for the better part of six years, creating little videos to amuse friends at special occasions. I'm well versed in most of the fundamental areas of Blender, and am reasonably competent with creating, rigging, and animating characters.

After impressing the project leader with a few models that I had created for various other projects, I was recently accepted to assist with creating character models for a rather prestigious Source Mod, which was known as Slender: Source, until recently. For those who are not familiar with this project, it is a source engine re-envisioning of the popular minimalist survival horror game "Slender," by Parsec Productions.

Using the Source Developers Wiki's guidelines with regard to making models for Source in Blender, I dutifully created a number of 3D models, complete with textures, rigging, and armatures. In an attempt to make this plea for help a little less wordy and a little bit easier on the eyes, a small cross-section of the models I have created for this project are shown below:



Image ... d_tell.png

Image ... _TABLE.jpg

However, upon exporting these models into SMD format, and compiling them into the required MDL, VTF and VMT files, I was dismayed to discover that something had gone terribly wrong somewhere along the line. The models had lost all of their rigging information, and as such would just scoot around the map n the default "spread eagle" position. Additionally, something had gone wrong with the UV mapping, resulting in the models being rendered with a black and pink chequered pattern instead of the texture. A little research has informed me that this is how an untextured model is rendered by Source.

At first, I was convinced that I had done something wrong in the compiling stages, and meticulously pored over my work. After finding nothing wrong, I handed over the original SMD model and PNG texture files over to one of the other 3D artists on the mod team, asking them to try to compile it and report back to me with his findings. Like a champion, he agreed, and within half an hour, he reported back that the texture and rigging information was gone.

I decided to do a little experiment, and re-exported one of the character models from Blender into SMD format, before importing it back into Blender. As predicted, the model had lost it's UV mapping, and it's weight painting/rigging, proving that something was going wrong in the SMD conversion/export. It turns out that all of the vertex groups had been wiped clean. The names were still there, but they related to no vertices, and instead, everything had been hard-rigged to the root bone. I am led to believe from other sources that this is what SMD export does to models which do not appear to have any rigging present - they get rigged to the root bone at 100% strength. However, I DID have some complicated rigging in some of my models, as shown by the above pictures demonstrating different poses.

I have gone through the Source Developers Wiki pages regarding creating models for Source in Blender with a fine toothed comb, and can't find anything that might indicate what the problem might be, and the other members of the mod team are beginning to get impatient with the lack of usable models coming from my end, and understandably so. I have now spent more time trying to find what the problem is than I ever spent making the models in the first place, and I think that I have now reached a stage where I need help from someone more experienced with using Blender as a creative tool for Source.

Is there any critical information regarding SMD export that is left out of the wiki? Perhaps some sort of trade secret? (set all faces to 'smooth', or put everything into one big vertex group, or something?)

I'm hoping, praying, and pleading that some of you may be more experienced in this matter than I am, and will thus be able to assist me in this manner, and graciously thank you for your time and patience in advance.

Thank you for your time listening to my pleas,

Posts: 1264
Joined: Wed Apr 21, 2010 6:21 am
Location: Iowa

Post by Tehrasha » Sat Sep 15, 2012 6:13 pm

You might want to contact the developer of the blender-smd addon.
He is very active in its developement and a big help to the community.

He maintains a thread on Facepunch which discusses all of the latest changes to the addon...

or you can contact him directly on the addon's homepage...
Spacemice Wiki -- Input devices for a 3D world.
Spacemice / Blender Compatibility

Posts: 3
Joined: Sat Sep 15, 2012 12:03 pm

Post by Ynek_Slender » Mon Sep 17, 2012 8:32 pm

Today, my attempts to fix the problem went something along these lines:

I imported a sample decompiled SMD file into Blender using the SMD import/export plugin, to see if it's rigging and UV mapping information managed to survive an import, since those of my models were failing miserably to survive an export.

To my surprise, I discovered that the decompiled SMD, a Half Life 2 citizen, survived import perfectly, and I was able to bend/pose his body around into a variety of amusing shapes. This proved that the SMD importer, and therefore, the SMD exporter, must have been working fine. It's just that the online tutorials, (in following the traditions of online tutorials) of how to use the SMD export tools were missing some crucial piece of information that I was obviously needing. However, purely as an experiment to see how this would pan out, I went ahead and parented my Slenderman model to the HL2 citizen model, and joined the objects. This meant that all settings for the HL2 citizen would be carried across to Slenderman.

Then, in editing mode, I deleted the HL2 citizen, leaving behind the Slenderman model, complete with all of the settings that the HL2 citizen had. It's material data, it's render settings, and so forth. I then tried to export the resulting "hybrid" model, wondering if this would help to solve the problems I have been facing.

I then re-imported the model to Blender, and to my delight and surprise, I found that the UV mapping and the weight paint/rigging had survived the export and re-import process. After a little bit of tidying up, I painstakingly put myself through the mind-wrecking horror of writing a QC file, and compiled the Slenderman model into MDL format.

All of the file pathways "leading" to and from the QC were, to my knowledge, correct. I have included the QC below in case anyone can spot anything that I've done wrong with it.

$cd "C:\Program Files (x86)\Steam\steamapps\sourcemods\Faceless\models\ynek"
$modelname "\ynek\slendy.mdl"
$model "Body" "slendy.smd"
$cdmaterials "models\ynek\"
$hboxset "default"
$scale 1.0
// Model uses material "Slendy.vmt"
$surfaceprop "zombieflesh"
$illumposition 0.097 0.175 43.743
$sequence idle "slendy_idle.smd" fps 1.0
$collisionmodel "slendy_phys.smd"

However, when I loaded the model into the HL2 model viewer, a part of the Source SDK, I was dismayed to see that the model was still blighted by the bright pink and black squares which indicated a missing texture, or a texture not found.

I have since spent virtually all day trying to fix the infamous "pink and black squares missing texture" problem. Unless there's something wrong with my QC (not entirely likely, since other, more experienced modellers on the mod team have tried compiling my models with their own QCs, none of which have met with any success in solving the texturing issues), the only other thing I could find which shed any sort of light on my problem was a single, ambiguous sentence in the Source Developer's Wiki, on this page:$cdmaterials

The sentence simply reads: "Material filenames are defined by the reference mesh" which implies that the SMD containing the model, which I had made in Blender, somehow contains the name of the material file that the MDL expects to find, but the source developer's wiki, being it's usual helpful self, (and perhaps taking a leaf out of the traditions of online tutorials,) had little more to say on the matter at all.

I googled the ambiguous sentence to see if anyone else had quoted/put it up anywhere in the hopes that someone had a more exhaustive explanation of what the problem was, and how to solve it, but alas, no such luck.

I continued in my ceaseless digging around, until I came across this page: ... ile_Models , which makes the statement: "Note: the actual name of the material file it will be expecting is defined within the modeling program you used. Whatever the name of the texture it uses will be the one it will be looking for. You cannot define the name of the material inside the QC file."

Thinking that I had found the source of the problem, I changed the name of the texture file that Blender used during my WIP stages of making the Slenderman model. I then instructed Blender to bring in the new, renamed texture file and substitute out the older version for the new, renamed one in all instances where that texture made an appearance. I also changed the Blender material names, texture names, and layer names in Blender to match those of the source texture files, i.e. the VTF and VMT (they have the same name) just in case any of these names were the ones that the article was referring to. I then re-exported and recompiled the model, but alas, no luck. I was still seeing the pink and black squares.

I continued for a couple more hours digging through the internet in search of some sort of ray of light, or some sort of enlightenment, until I came across this page:$texturegroup , which states that "If no $texturegroup is specified, then the model's VMT must be the name of the texture which was UV mapped onto the reference .SMD." Thinking that this also meant, by extension,: "If a $texturegroup is specified, the model's VMT doesn't have to be the name of the texture which was UV mapped onto the reference .smd," I went ahead and incorporated a $texturegroup function into the QC file which was used to compile my model, referring to two variations of the same texture as being the "texture group." I then recompiled the model and stuck it under the microscope of the HL2 modelviewer to see if the problem had been fixed, and the result was, once again, a big, depressing negative. I was still getting the soul-destroying pink and black squares.

And that's what I've done for the last 4/5 hours.... Doing lots and achieving little.

I'm basically regaling you with this tale in case any of you spot something that I've done wrong, or if there is anything else which you can think of that might help me...

@Tehrasha - I daresay I could try getting in contact with him, but since my latest findings have kinda proven that the problem is with something I'm doing wrong, rather than the SMD exported being at fault, I don't really know if he'll be able to help me very much.

On the flipside of the coin, I could always ask him which texture/material/name gets imprinted onto the SMD file as the expected texture, which might shine some light on this issue....

Posts: 1264
Joined: Wed Apr 21, 2010 6:21 am
Location: Iowa

Post by Tehrasha » Tue Sep 18, 2012 1:02 am

Ynek_Slender wrote: On the flipside of the coin, I could always ask him which texture/material/name gets imprinted onto the SMD file as the expected texture, which might shine some light on this issue....

If you open the SMD with a text editor, you can see it define each individual polygon, its associated UV map, and the name of the texture file it is looking for.

It is entirely possible that something is getting lost in translation between the texture name used in Blender and the actual file which is causing the issue. in which case, a simple text search/replace on the SMD file would fix it.

You are not alone though. QC, VMT, VMF, and SMD files, and their nightmare directory structure can be a real pain.

Its been over a year since I have played with SMD files, so I am working from shaky memory. :)

The Facepunch forum is a great place for questions about his. They deal with nothing but Source based models/textures. It might all come down to a missing comma(,) somewhere. :)
Spacemice Wiki -- Input devices for a 3D world.
Spacemice / Blender Compatibility

Posts: 3
Joined: Sat Sep 15, 2012 12:03 pm

Post by Ynek_Slender » Tue Sep 18, 2012 1:59 pm

Tehrasha wrote:
Ynek_Slender wrote: On the flipside of the coin, I could always ask him which texture/material/name gets imprinted onto the SMD file as the expected texture, which might shine some light on this issue....
After taking your advice, and taking a look *inside* the actual SMD file, I managed to find the root of all my troubles.

It appears that the model was looking for a file named "slendy," wheras Windows, in it's infinite wisdom, had autocorrected the titles of the corresponding files to "Slendy," adding a capital letter where none was required.

The change was so subtle that it completely slipped by my attention until your expert advice pointed me in the right direction. I have now made the necessary corrections, and as of five minutes ago, the model appears to be working perfectly.

If I could hug and kiss you right now, and buy you a drink for saving me so much bother, I wouldn't hesitate for a second.

Thanking you unreservedly,
Kenny Gardner.

[As an addendum, I attach this screenshot, to show the model, working perfectly, in HL2's model viewer.]

Post Reply

Who is online

Users browsing this forum: No registered users and 0 guests