I’ve taken some time to do a small update to my 3D Studio Max SMD export plug-in and have nailed (I think) one bug and added a couple of user-requested features.
To start off the additions include support for exporting HL1 format unweighted SMD files. I underestimated how many people out there were using Max 9 and still modelling for Goldsrc games so per request I added the option to export files in the old format.
The second addition is a crude but useable “batch mode” which lets you configure and call the plug-in from Maxscript. One user had all their animations in one continuous sequence and was looking for a way to batch export them by specifying specific ranges. It’s fairly simple to use and I’ve included a basic example Maxscript in the ZIP file.
As for the bug, you may recall in previous blog posts that I was having considerable problems with Export Selected. After a lot of debugging and tracing I *think* I’ve nailed the problem. Certainly under the tests I’ve done you can now select part of a chain of bones and it will export and not lose position or destroy the animation. As always these things have a habit of blowing up in my face so I’ve retained the link to the old version of the exporter just in case people need to roll-back.
I’ve also marked this version as for 3D Studio Max 2008 too as users reported that it worked fine in both Max 9 and 2008 without problems.
I’m still getting e-mail/MSNs regarding problems with old Max 8 rigs that don’t work quite right with this exporter. In 99% of all cases it’s been simply been down to shoddy rig construction. I’ve said before and I’ll say it again, when you mirror part of your rig, reset the transforms before you use it! It really messes up the 3D transformation matrices and while the code tries to fix it, it’s not that clever. Oh and please, stop trying to use splines as bone nodes…
- 3D Studo Max 9/2008 32/64-bit SMD Export plug-in version 1.1
Related posts
Oh lord. It looks like I’ve caused a bit of a stir in the Day of Defeat:Source Modelling forums this past week – custom player models that actually work on-line.
Back in the days of Day of Defeat on the Goldsrc engine, we had a really busy custom player model scene. People were producing models for different countries, armies, regiments, units, etc. There were lots to choose from and customising DoD to your liking was a big thing.
When Valve released Day of Defeat:Source they implemented a file consistency checking system which is designed to prevent people from cheating by using heavily modified models that might give an advantage on-line. This consistency check, in it’s earliest incarnation, pretty much blocked all custom player models and led to a lot of talented character modellers quitting the scene. Why waste all those man hours making a kick ass player model if no-one can ever use it?
A little later, Valve released an addition to the consistency check called pure servers which in theory allowed server admins to permit custom player models or force the player to use the defaults from the GCF file. This is all well and good, but the consistency check is still invoked and your custom model can still fail at that!
Well I love a challenge and seeing people struggle to make even the smallest of edits to the default player models I figured I’d have a go at solving this mystery once and for all.
I’m lucky because I have a reasonably good relationship with some of the guys at Valve so Matt Boone, DoD’s main coder, gave me some of the numbers specifc to DoD and Mike Durand was kind enough to show me the source code for the entire consistency check function. Pure gold when it comes to figuring this stuff out and what exactly is making these models fail.
My test case, which proved successful, was to compile one of the default HL2 NPC characters from the Source SDK to work on-line with DoD:S. It worked, but took a fair bit of hacking and experiementation to not trip the check. From that experiment came a simple “proper” hack – replace the steel helmet on the German assualt class with a M43 field cap – a throw back to the DoD 1.3 days.
After posting a breakdown of how the consistency check works and then a kit of files for correctly compiling custom models so that they pass the check, things have started to take off again. Already people have started re-skinning and improving my cap model, people are starting to suggest other modifications to the player models and a few have actually started re-working and customising new ones.
I really hope this sees a resurgence in the custom player model scene of old and gives DoD:S a healthy shot in the arm.
I posted full details on the consistency check on the Day of Defeat:Source forums, but for those that want to know, heres a brief summary of how the consistency check works:
- Models are CRC checked against those on the server. This is skipped though when pure servers allow custom models.
- Models have their bounds checked against a pre-defined set of ranges. These bounds are calculated when the model is compiled and represent the absolute limit that any part of the models mesh reaches during any animation sequence. These limits can be represented as a bounding box, which is compared against a bounding box defined in game. If any part of your models bounds exceed the game’s, it fails.
- All materials used on the model must be “simple” – i.e. they use only the VertexLitGeneric shader, a diffuse, normal and phong maps. Certain other paramters are allowed but anything else results in the material being rejects and the model failing.
I believe all the current Valve Source based multiplayer games use this check so it may prove useful for CS:S and HL2:DM too.
Related posts
