Dem bones, dem bones…Thu, May 29th, 2008 @ 23:36
I’ve not had a lot of free time this week but I’ve managed to make a bit more progress with my Max SMD importer. Mesh import seems to work fine and it now imports the materials and UV mapping too which is nice.
I did have one colossal panic when suddenly Max would start crashing when you tried to add a modifier to the mesh or when you actually exited. Lots of error messages about corrupt heap which is never good for your heart pressure. After much debugging it was down to an out of range index which wasn’t my fault. A rather vague description in the SDK docs had me putting the wrong value somewhere. Doh!
So Sunday afternoon I decided it was time to tackle the part I’d been dreading – importing the bones and animation into Max. There’s very little decent information on making bones in the Max SDK and I don’t know many people who’ve found it easy.
My first task was just to template out some code to actually just create a bone in 3DS Max. I think having my teeth pulled is less painful. To illustrate, lets imagine a conversation between MaxScript and I…
MaxScript: Sure, here you go.
Me: Great! Can I move it over there?
MaxScript: No problem. *moves*
Me: And rotate it a little to the left?
MaxScript: Anything you want! *turns*
Me: Fantastic!
Now, lets re-enact that little scene as it went for most of Sunday afternoon between myself and the MaxSDK:
MaxSDK: What sort of bone? *shifty eyes*
Me: Well you know. Regular bone in Max that you make skeletons with.
MaxSDK: Like a helper?
Me: Err I guess, if that’s what it is.
MaxSDK: Ok. *creates*
Me: That’s not a bone! It’s just an object!
MaxSDK: That’s what you asked for a helper object bone!
Me: No, I meant a blue normal bone in Max.
MaxSDK: Oh you want a geometric object derived bone.
Me: Err yeah, whatever. Just make one please.
MaxSDK: Well you’ll have to tell me it’s class and super class.
Me: What? How the hell do I know that? Don’t you?
MaxSDK: Oh yes, but I just like to hear it. *sniggers*
Me: Oh FFS. *looks in SDK docs* I can’t find anything about that class!
MaxSDK: Well try harder!
Me: A clue? Nothing’s coming up when I search for “bone” or “bones”.
MaxSDK: Maybe I put it somewhere else…
Later that same afternoon…
Me: Ha! Found it! Make me a bone please.
MaxSDK: Oh very well….
Me: Can you move it over there?
MaxSDK: If you wish.
Me: And turn it a bit?
MaxSDK: Ok.
Me: What the hell? Why did you move it again?
MaxSDK: I didn’t!
Me: Yes you did it’s over there now!
MaxSDK: Oh yeah. Well I decided to reset the translation component of the matrix.
Me: Why you do that?
MaxSDK: …
Me: I f***ing hate you MaxSDK…
MaxSDK: What? Oh sorry I wasn’t listening, I was just over there eating some more memory.
Me: Sod this, I’m going to the pub…
MaxSDK: Can you get me some chips on the way back?
The above was then followed by two more hours of wondering why I wasn’t allowed to alter the appearance of the bone. Oh I’m sorry MaxSDK, you said when I made the bone you would make it as an Object. You didn’t tell me that you wanted to make ita SimpleObject2. See I thought a SimpleObject would be somewhat LESS than a normal Object but no, in fact it’s more. Well bugger me. You are a tease!
I think you understand my frustrations thus far.
Related posts
GUIStudioMDL2 updated for EP1/OrangeboxThu, December 27th, 2007 @ 23:41
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.
- GUIStudioMDL2 version 2.2.0
Back to the grindFri, October 26th, 2007 @ 03:22
Finally, two weeks after returning from my short break in England, I’m just about back on top of things. The enormous backlog of mail almost drowned me and things to follow up after my trip are done. Of course, the need to play TF2, E2 and Portal ranked highly on my to-do list…
With EP2 et. al. came a new VTF format which means changes to VTFLib to add compatibility. Nem and I already added partial VTF 7.3 support but Valve also has version 7.4 out there which needs to be added. We’ve been promised the final spec in a few weeks by Valve, so hopefully we’ll roll out a new version then and you’ll see up-dates to my VTF apps.
So apart from that it’s back to coding and modelling for Ham and Jam and trying to get it one step closer to a public beta. As usual it’s mostly art assets that are holding us back but at least we got the British player models done at last.
3DS Max 9 SMD Exporter for 32 & 64 bitThu, September 13th, 2007 @ 01:08
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.
- 3DSMax 9 SMD Export Plug-in version 1.0
DoD:S – Custom player models and Pandora’s box.Thu, September 6th, 2007 @ 13:40
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
- None Found
