Wall Worm Forums

For those who find this in the future, the last of my problems was caused by source not being able to generate hitboxes for the single-tri objects that I was using as bones. Changing those single-tri objects into boxes solved my problem.

While working on a rewrite of the SMD exporter in C#, as a way of boosting the speed of the exporter for skinned materials (no idea if it will actually be faster or not, might actually be slower, we'll see), I was porting wallworm_getMaterialName in common\matfuncs1.ms, and, in the code working with XRef materials, I noticed that on line 574 you check if "r" is not undefined, yet on line 577 you proceed to use "r", even though it's the else case, and you've already proven that "r" is undefined.

I believe you intended for it to be "m.name" rather than "r.name" on line 577 of common\matfuncs1.ms.

Also, is there a better place I should be posting this rather than in this topic?


Edit:
I'd also look at common\matfuncs1.ms line 538, because the checks that it does there, all but one of them anyways, will only ever have one result, due to the code before it.

Edit 2:
Line 643 of common\matfuncs1.ms should be returning undefined, not "unknown". This looks to be just a copy/paste error.

Well, more information about the collision model issue; Enabling collision model drawing in hammer does show the collision model as it is in-game. It appears that only 1 of the collision meshes is actually getting loaded, and it's rotated 90 degrees and the center of it is at the origin of the model. Is there anything you know that the engine does differently in a map setting when dealing with vphysics of models vs. when working with them in HLMV?

I think something may be up with the hull count button, because there are no poly's that are un-accounted for in the objects, and there are only 16 objects in the exported hull SMD.

I also noticed that the bones make it into the SMD for the collision mesh, but nothing is parented to them, should they even be there at all?

Lastly, how exactly is HLMV determining that the collision model's parents are the bones? Because that's not specified anywhere in the SMDs, yet it still works for some reason.

I was compiling with the $maxconvexpieces option disabled, I've now enabled it, and at least *think* I've been able to run the map without crashing TF2, but, as I can't actually see the fullscreen game via remote desktop, I can't be certain. I'll also update my installation of WW before trying again when I get home and can actually see the screen.

I did notice one odd thing about the scene, I have 16 collision bodies that I created, but WW counts 17 hulls, and only the 16 objects I created get selected when I tell WW to select the objects in the collision hull. Could this phantom hull be the cause of the error?

There is also something a bit odd about L1-Right-CM1, the primary collision model for the first layer of the right side of the door, inside 3ds Max it doesn't actually move as you navigate the timeline, but it does export as being properly animated. (as shown in the model viewer) Could this be a symptom of the cause of the problem?

Edit:
Well, with $maxconvexpieces set with a model compiled with the previous version of WW, I didn't get any errors in-game, and the collision model shows up correctly in the model viewer, but the collision model in-game was nowhere near correct. It was roughly a 32x64x192 unit block in the center of the model that didn't move at all. I will try with the newest version of WW, but I don't think that will make a real difference. I'll also note that the model was compiled with not the latest TF2 update originally, will compile it with the updated TF2 as well now.

Edit 2:
Well, recompiled with the current updated tools doesn't change anything. It did however make me realize that the broken in-game physics for the model isn't the only physics that get messed up by having the model on the map, in TF2 throwing a cleaver or hitting a ball into map geometry normally causes the ball or cleaver to just bounce off, but, if a map is compiled with that model in it, the cleaver or ball will simply go right through. The environment is still solid to the player and to bullets, but projectile weapons just go right on through.

Edit 3:
The same error is back, and I've just sent you an email with the .max, compiled model, materials, .smd's, and the map compiled for TF2 (I don't believe the model is currently embedded in the map).

I'm using the model exporter, not the vmf exporter. I'm using the most up-to-date version of TF2 to compile the model. I do know for a fact that the scene has a rather larger number of -0 points, which, while a valid floating point value, doesn't make much sense in a scene. Is it possible that these are the cause of the error in the console in TF2?

Alright, the issue with the position and rotation of the physics meshes is now fully resolved, but when I put the model on a map, then compile and run the map, the console complains about `Invalid initial position` on the model, and then proceeds to crash once the opening animation finishes. The vphysics also don't seem to be working at all, even though they are exported correctly and show up animated correctly in the model viewer.

I suspect you've missed something about my last post. Due to the way the model is made, I can't simply attach my collision model to existing parts of the mesh. Because of this, I instead added a pair of bones to the base model, but didn't skin the base model, and skinned the collision model to those bones. The collision model should be scaling down due to the distance between the bones getting smaller, but that isn't the case once I export it. In fact, the collision model moves with the final block that opens instead of the bones.

Edit:
After a bit more checking, the bones I added are making it into the smd, but are being eliminated from the .mdl, causing the collision model to use the first remaining bone to be used instead...

Edit 2:
Well, I was able to get it working by converting the bones I had into editable meshes. I also removed all but one tri from those meshes, as they will never actually be seen to begin with. Now I just have to figure out why the collision mesh is the wrong size. (It's 1.5 bricks wide in HLMV, but 2.75 in 3ds max) It also appears that the bone's initial position relative to the origin of the collision model isn't taken into account when exporting, although that might just be a symptom of the odd scale.

Edit 3:
Fixed the scale oddity, now to figure out the transform issue.

Edit 4:
I did finally get it working, but, for it to work properly the collision hull's origins have to be at (0, 0, 0).... Not entirely sure why this has to be the case, but, if I get the origin at (0, 0, 0), the animation works like it should. In order to get the origin to (0, 0, 0) I have to first transform the origin only of the object to (0, 0, 0), then I have to compile the SMDs, which will cause the object's model to move to where it appears in the compiled .mdl file. Once it's in this position, I reset the pivot, then I transform the object only to be in the position I want it, and finally reset the pivot again, which should result in the pivot being at (0, 0, 0). At that point the animation works like it should.

Well, I have it mostly worked out, but am having minor problems when I go to try to do the animating of the collision model. Due to the way the model functions, I can't simply attach a collision model to one of the existing objects in the model, so I instead created a pair of bones that I skinned to the collision model. I then am able to effectively resize the collision model by moving one bone towards the other, which works fine in 3ds max. However, after adding the bones that I animated into the model being exported, the collision mesh doesn't resize, and instead actually spins with the final brick that's being moved.

Any idea why this would be? I suspect I'm missing something about how bones are dealt with in source, but can't seem to figure out what exactly that is.

Awesome I now have it exporting properly, perhaps it would be a good idea to add warnings / errors to the SMD exporter if it encounters too many bones, or else encounters a case where a bone is being scaled?


Also, I did end up getting the model to do what I wanted in terms of hiding certain pieces to avoid clipping issues by simply moving the parts of it that I had been scaling to nothing to a place where they would never be visible to the user instead. (The model is a door that only opens at the start of a round, after which I remove the entity from the map, so I don't have to worry about it still being rendered.)

The problem with the bone count was that, as I was unaware of the limit, I hadn't combined various parts of the model that could easily have used the exact same bone, and had almost 500 bones. After combining various parts of the model into single objects, I was able to get it down to 96 objects, without having to change the animation or deleting any of the visual parts.

I also was looking into the performance of the exporter, due to it taking nearly 5 minutes to export the model and it's 152 frame animation, and noticed that you're appending to a string rather than a StringStream, is there any particular reason for this? (a string has to be entirely re-allocated and copied every time you append to it, a string stream doesn't have to for most append operations) I'll send you the model via email for testing in a bit.

Also, the QC I'm using is the one generated by WWMT, I haven't modified it at all.

Well that would probably be why, as part of my animation scales the meshes to 0 (I have it set to do the change in 1 frame, so there's no frames with a scale in-between 0 and 1) to get rid of them without clipping. Any idea how I could this without the scaling?

As an extra suggestion, I was looking at the generated SMDs and noticed the large number of extra decimals that aren't needed, so I looked at source for wallwormSMD.ms, and noticed that you're using the f format specifier, which forces all decimals, including trailing zeros, to be output up to the specified precision (6 and 12 depending on where). If you change that to a g specifier, it won't output those trailing zeros, and, in my case the change cut the smd size by over half.

I have a model that I'm trying to get imported properly into source, and I believe I have WWMT configured correctly, but every time I try to compile the smd files into mdl files, I get an access violation when studiomdl goes to process the skeleton section. (specifically it's trying to multiply 2 matrix's, but the first matrix is at an invalid point in memory) Because of this, I'm wondering if there is any specific requirements for bones in animated models? I originally had no bones and had the pieces animated via basic transforms, but then, after I figured out where studiomdl didn't like in the smd, I tried adding a couple of bones and skinning the entire model to be attached to them, but it still gives me the same error at the same part. Any suggestions?