Search

[Orvid]

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?

[wallworm]

I guess the first question is whether you are using WWMT to create the QC or if you are creating it? I know this error can happen if you use $massorigin and $collisionjoints in the QC.

Post the contents of the QC here.

[EDIT] Sorry I was distracted and did not answer your actual question. There are not many requirements for the bones except I'd make sure that you never Scale them. In fact, I'd not scale the meshes either. The only way for me to answer definitively about model problems is to open the files. You can always send me a Max file via my email listed in the WW Zip readme file.

[Orvid]

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.

[wallworm]

I don't recall the origin of the "f" format. I believe there was some bug a couple years ago that was alleviated by using it in one of the exporters. I'll test some of my files and see if switching back to g is fine in all the files I have.

In terms of the scaling... the problem is that SMDs do not contain scale information for the mesh or bones. There is no way to export the animated scales with SMD.

Some mods (like TF2) have a scale property in prop entities. But the scale is handled by the entity and I/O in the level and not in the MDL itself.

Another option is to look as using Flex animations, but this is probably not the most viable option.

[Orvid]

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.

[wallworm]

So I looked at this model and I think that the problem is that it isn't practical as a single asset for multiple reasons.

There is a hard-coded bone limit in the compilers of 128 bones. Each node exports as a bone. I guess this is a limitation I should have mentioned earlier. I also see why it is so slow to export ... the Skin modifier automatically slows down the exporter significantly. When I removed the skin modifier, it exported and compiled in around 10 seconds. Pretty much you should never use a Skin modifier for mechanical rigs unless it is necessary--and a Skin without any bones in it doesn't actually do anything (except slow things down at export time).

Anyway, I did get the model to export with the animation when I reduced it to one layer thick and removed the edge bricks so that the bone count dropped below 128. But the model still has a couple unexpected quirks that I don't have time to investigate right now.

At this point, the best resource for making a mechanical animation might be this video:

[Orvid]

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.

[wallworm]

I'm glad you've got it working. Share a screen shot/video for the users when you've got some time. I wish more users would start doing that :)

Regarding a notice about scale/bone count, it's something I can look into. I've got several error checking TODOs for users, but since it's hard to tell how many people bother to take notice of those that I do have or take the time to understand them before sending my irate emails about them... it sometimes seems like wasted effort. But I will add them both to printed notices or into the general WW function for Check for Problems in the scene. There is a very large update to the general structure of WW coming in a week or so, and maybe I'll have time to add these in for that.

[Orvid]

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.

[wallworm]

The collision hull will only use bones that are in your main model. So your best method is to skin each convex object of your hull to a specific node in your main model. The fastest way to do this is to remove the skin on the hulls now. Then select all the hulls (keeping them all separate object but select all at once) and click the Add Skin to Selection button in the Hull Helper floater (Wall Worm > Wall Worm Model Tools > Hull Helper). Then for each individual hull, skin it to one and only one object from the original model (each convex part of the hull must be weighted 100% to a single bone... which is why this method is used as it is fasted to setup).

Hopefully this answer the question. I believe the video above demonstrates the skinning of hulls to the original mesh nodes, though it may have been before I added the Add Skin to Selection in Hull Helper.

[Orvid]

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.

[wallworm]

Ahh... I guess I did misunderstand. It's been a long week and my brain is pretty sluggish at the moment. Which also explains why I'm not entirely following the last edited section explaining how you got it working. It seems overly complex. Although I do not completely understand it, my best guess is that one or more nodes were scaled or had offset transformations. Just in case, I'd read this article: My Model Scale is Wrong.

You might eliminate the offsets by turning on the Use Local Origin As World Origin in WWMT as well as the Calculate Origin in SMD option. Not sure, as it is dependent on exactly what is going on. For animated models, you usually want to keep Rotate Origin off.

Another thing to keep in mind is that once an object is Skinned, you'll often get unexpected results if you then transform the skinned meshes. If you've already skinned an object but need to transform a mesh, you can save your skin weight settings in the advanced rollout of the skin into an external file, delete the skin, then transform the mesh, then reapply a skin and load the saved weights.

Also, for future reference, if you want to use geometry nodes as bones but do not want their geometry to export, you can Right-Click the node, click Object Properties and uncheck the Renderable checkbox. So long as the global WW setting for Export Non-Renderable Mesh as Bone is turned on, the node's geometry will be skipped in the SMD. But keep in mind that this can conflict with another global WW setting called Processed Hulls become Non-Renderable. These two options should not be used simultaneously, and if you turn on the Export Non-Renderable Mesh as Bone option, you may have to manually make your hull nodes renderable if the other setting was on.

Hopefully these tips help.

[Orvid]

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.

[wallworm]

I've never seen that error before. You may have to send me the current state of your scene. Use the File > Save As... Archive function as it will collect any needed asset.

[wallworm]

I received the file you sent and looked into it. I never got any error or crashed as mentioned above but see the offset you mentioned in the email when exporting the level.

The reason the model is offset is because, for simplicity, WW exports a prop's position in a WWMT helper based off of the transformation of the model's "root node". In this model's case, it is the node $Editable_Mesh:Box139 @ [-176.000000,8.000010,184.000000] which has a transform of (matrix3 [-1,3.89414e-007,0] [-3.89414e-007,-1,0] [0,0,1] [-176,8.00001,184]) . That becomes the point where the model will export to in the VMF.

In reality, the VMF exporter should check that you are not using Local Origin and manually calculate the offset. But that doesn't happen right now (and adding that adds one more layer of calculations and possibly slow the VMF Exporter...)

You have a few solutions in order of what I recommend (the last would be too much work).

* Recommended: Turn on the Use Local Origin as World Origin and re-export the model.

* Add a new Bone to pos [0,0,0] and add that to the WWMT helper as you would a mesh. Then, with the WWMT UI open, open the Wall Worm > Wall Worm Model Tools > Bone Tools floater, select that new bone, then click the Root Bone button (which rearranges the node list and will assign the bone as the new root node). Then re-export the model.

* Move the current root node's pivot to [0,0,0], use Reset XForm on the node, then reanimate it. Then re-export the model.



Generally speaking, when building props in 3ds Max to be exported with the WW VMF Exporter, I recommend using the Local Origin as World Origin (which might be renamed to Pivot as Origin at some point to make more sense from a Max perspective). That, or make sure that the root node's pivot is aligned to the world origin.