I’ve now re-compiled my 3DS Max plug-ins to support 3DS Max 2010. Grab them while they’re hot! 🙂
The only change has been to the SMD exporter where I’ve added support for spline objects after user requests. I left it out on purpose to stop people using splines in place of bones or dummies in model skeletons. The reason being is that they are very quirky and it often results in the animation in Max not matching the rotation on export. They are fine to use to as controllers to influence the rotation of a bone or dummy but don’t use them as bones themselves. You’ll put yourself in a world of pain.
I’ve testing the plug-ins in the 32-bit version of 3DS Max 2010 but I’m assuming that they’ll work fine in the 64-bit version too.
As always, any problems let me know.
Been a while since I made any posts about what I’m up to these days so I thought it was about time I did. Not that I made many before but anyway…
In what little free time I’ve had over the past three months I’ve been hitting the Ham and Jam code pretty hard, doing what feels like a huge amount of coding to try and nail all the bugs we found in our last play test. There’s still some small niggles but if the hlcoders mailing list is to be believed, their inherent SDK bugs and hard to fix and not likely to go away.
Anyway, of the new thing to add was the deploy system for weapons with a bi-pod which, after two false starts, actually works now. The process of doing the deployment and swapping animations wasn’t too hard – it’s just all the other crap you have to deal with like the logic to check if you should be allowed to deploy and limiting player movement, preventing weapon selection, etc.
Still, apart from the art asset side of things, game play wise Ham and Jam is really starting to come together and resemble a proper game now.
I’ve been working quite a bit with 3DS Max plug-ins over the past week too and finally found a couple of hours to do some more work on the SMD importer I’m writing for Max 9, 2008 and 2009. I made a bit of a breakthrough today in that I made the first successful test run of the mesh re-construction code and apart from a small few snags at first, it actually works!
This may not seem like a big deal, but when you consider how an SMD file stores data it’s actually pretty cool. SMD files store each polygon in your model as a separate un-joined triangle. The problem with importing data like that is you get a huge number of duplicate vertices and your polygons aren’t actually connected together. As a result, you can’t smooth them out or set the normals properly as anyone who’s tried to use the MaxScript importer will know. The code I wrote analyses the data coming in from the SMD and uses some logic to reconstruct the mesh as one continuous mesh rather than separate triangles.
Lastly, you’ll probably of noticed over the last month or so I updated all my VTF tools to support the 7.4 texture version which started shipping with the Orange Box games. It took a while to do, mainly due to VTFLib which they rely on being a bit out of date. Nem usually handles the releases and while the code was there, he’d got really busy and didn’t have a chance to get it out as quickly as usual. Still, not biggy, it’s done now so hopefully everything should handle EP2/TF2 textures just fine now.
That’s all for now. Back to work…
I made a small update to my SMD exporter plug-in to fix a bug in the batch mode that a user reported. While I was at it I used it as an opportunity to tidy a few bits of code up and port it to Max 2009 at the same time.
I’ve tested it with the 64-bit version of Max 2009 under Vista so I’m assuming it works under 32-bit fine. Naturally let me know if there’s are any problems.
Seems a small bug slipped through the net with the VTF Shell Extensions which was causing problems with VTF textures generated without MIP maps. I’ve made and update so you can download and update to the latest version to fix it.
In short, images without MIP maps were showing strange, interlaced looking thumbnails. There was also an issue with really big non-MIP images crashing explorer. This was due to the large ammounts of memory needed to generate thumbnails from the fullsize image rather than a MIP level. As a get-around for now the extension won’t attempt to generate thumbnails for non-MIPmapped images greater than 512×512 pixels.
Following on from yesterdays update of the VTF Shell extensions, I’ve now update my 3DS Max VTF plug-ins. These now support 7.3 and 7.4 VTF formats and I’ve included a 64-bit build. The Max 9 version should work in 3DS Max 2008 as well.
Sorry it took so long, but I finally updated my VTF Shell extensions to support the 7.4 VTF format as found in Team Fortress 2/The Orangebox.
The delay was due to both Nem being busy with real-life stuff and unfortunately losing the code to the Photoshop plug-in which meant a re-write. This lead to the new version of VTFLib being delayed and as so many of our tools rely on it, we couldn’t update without it.
Anyway, everything is updated now – Nem has released the new VTFLib, VTFEdt and his Photoshop VTF plug-in with 7.4 support and I’ve updated my XP/Vista Shell extensions. I’ll update the 3DS Max plug-ins hopefully in the next couple of days. I’ve also updated the documentation for VTFLib.
One new feature though that’s worth mentioning. Since VTF 7.3, the VTF format has added support for “resources” embedded inside the actual VTF file. This was originally added, I believe, to better support features on the XBox360. What’s nice is that developers can add any custom resource and data they might need.
This gave me a brainwave.
Often you find VTF textures all over the place and if you’re creating a Mod it can be a right pain-in-the-arse to keep track of texture assets. Wouldn’t it be great if there was some sort of metadata inside the actual file containing useful information about who made the texture, how to contact them and what game/mod it came from? Basically EXIF for VTF files.
Well that’s what we implemented. Using a custom “Information” resource you can now embed useful information into VTF files for TF2/Orangebox using VTFEdit. You have the basic author and contact info, your texture version number, what game/mod it’s for and include a short note. My VTF Shell extensions can show this info as part of the detail columns in XP or in the properties view in Vista.
So you know the drill – un-install any previous versions of the shell extensions you have installed and make sure you have the Visual C++ 2005 SP1 runtimes installed if you don’t already.
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…
I’ve updated GUIStudioMDL2 and added better support from the new Orangebox SDK. Basically you can now configure it for both Source SDKs at the same time and switch between them at the flick of a switch.
It works pretty well, apart from the inherent bugs with the actual SDK compilers…
*edit* Oops. I farked up the link.
I’ve made a quick update to Jed’s Half-Life Model Viewer to try and resolve some problems with it running under Vista. To be honest, I didn’t realise people were still using it! I’ve re-compiled it in VS2005 and updated some of the libraries which seems to fix the problems. Give it a go and let me know if it’s still causing problems.
I’ve made another update to my 3DS Max 9 SMD exporter and have decided it’s robust enough to take out of beta and make version one-point-oh.
The changes I made weren’t significant but I did nail one irritating bug where it would crash if the diffuse texture on a mesh wasn’t of a Bitmap type. Once again Autodesk’s recommended 3DXI interface suffers an epic fail in blindly assuming the user has one.
Oh, I also removed the crappy “log to file” feature and replaced it with a proper combined progress/log dialog and compiled a version for the 64-bit edition of 3DS Max 9 as a few people asked for it.