Search

[Orvid]

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?

[wallworm]

So I misread you again :) The email title was Invalid Object Position and when I exported the scene the issue I saw was the offset, so my laziness let me be confused.

The update that I just loaded (WW version 2.31) now truncates the SMD values again with the g format as discussed earlier. It doesn't seem to affect the results. I don't think that the floating values are part of the problem. I exported several other animated props as tests this evening with similar kinds of values without incident.

The animation seemed to play correctly in CS:GO. I did not get the error you mentioned, but I did get this message in console:

Uncached query for bone (1) transform. Please verify that there is an attachment or bounding box associated with this bone.

That message was printed many times.

I'm not confident about the cause at this point. I've never seen that message before. A brief search on Google shows that other people have discussed it but I didn't find any useful input on it. I'm not sure what is unique about the model. The only thing you've done in it that I avoid is using the Group function (grouping nodes together). I did add support for grouped objects, but it's something I generally avoid.

I'm not seeing anything that sticks out that is bad in the SMD.

It is possible that it is the number of hulls that are animated that is the problem. When WWMT exports a model with animated hulls the QC gets the $collisionjoints parameter. According to the VDC, the limit for simulated hull bones is 32 in the current Source. But it also says the limit for Animated Models (which this is) is unknown. For animated models, $collisionjoints is a requirement.

My gut tells me that the hull count is related to this problem.

You may want to check that the global WW setting has the Match $maxconvexpieces to Hull Count option turned on, as it could play a roll in how the compiler handles the hulls.

[Orvid]

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).

[wallworm]

I will try to look at your files tomorrow as I just got back in.

The hull count of 17 while there are only 16 objects is normal because there is no 1-to-1 relationship. A hull is defined as a convex element of an object. That means you can have one object that is composed of 20 hulls, for example. So if you expect only 16 hulls, then it probably means that one of the objects is composed of two elements.

As for the hull not moving in Max. Honestly, I have no idea what is causing that. All the vertices are weighted fully to your animated bone... so it should follow. But regardless of that, the exported hull moves because it's exporting how it should. There could be something odd going on, certainly.

My best advice as this moment is to break it down into a simpler model (maybe just 1 row on one side for now) and get it working at a simpler level. Then you work it up to a more complex rig. And I advise that you avoid using Groups for now, especially while building it up. One problem with using a Group is that you cannot as easily visualize/traverse relationships in the scene without opening the schematic view. I would only apply a group to those systems you are certain about working.

In any event, I'll give it some more thought tomorrow when I get a free minute.

[Orvid]

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.

[wallworm]

The hull count function is working correctly as long as the hull list is made of unique nodes. It appears that the same node was added to the hull list more than once and the WW functions were not set to sanitize the list (removing duplicates). I'll update the code to fix this.

If you select the WWMT helper and type this into the MAXScript listener:

Code Select Expand

for obj in $.hulls do print obj.name

You'll see that L1-Left-CM2 is listed twice.

I'll push a fix for this on the weekend so that cannot happen.

To clean the WWMT data now, select the WWMT Helper and type this into the listener:

Code Select Expand

$.hulls = makeUniqueArray ($.hulls as array)
Then type:

Code Select Expand

$.getWWMT refresh:true

Now close WWMT and reopen it and look at the hull count.

Regarding the bones in the SMD files. All nodes will export as a node in the SMD. This is for both geometry nodes and bone nodes. The SMD exporter does not know what the intended usage of the bones/nodes are. So it cannot just delete the node simply because it isn't weighted in the current SMD. For example, the node/bone might be used for attaching other geometry based on the QC setup, etc.

But that isn't a worry. In terms of the actual compiled model, those bones that were not used at all were thrown away. If you look at the bones in HLMV in the Bones tab, you'll see that only the actual bones exist. And to my knowledge, the hull model can only utilize bones that were defined in the reference model; this may be why the hull nodes never appear.

The bones are animated properly because each is weighted 100% to a specific bone. This information is contained in the vertex data of the SMD (in the triangles).

[Orvid]

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?

[wallworm]

Yes, I see the error with this model.

I'm doing some test right now to see if I can figure out what is causing this issue specifically. I think that the issue if related to either the XForm of a node, the number of bones, or some other related issue. In any event, I'm trying to reproduce the error in a fresh model with less components to see what can cause this. I'm starting with a smaller system because it will be easier to find issues.

[wallworm]

During the tests, I found some circumstances that can cause some models to have incorrect offsets for geometry or bone orientations. This may very well play a role in this case. So I'm working on a fix for this issue in the SMD Exporter.

That being said, I see that the collision hull displayed in Hammer does not always match that in game if the model is animated with a concave hull with elements weighted to bones. It appears that Hammer often displays only one element in this case, though in-game it displays correctly with wireframe on. (This isn't to say that your issue isn't happening, just that you cannot trust the Hammer CM display as I've discovered in several tests today).

I'll post info on the current fix I'm working on when it's ready to test.

[Orvid]

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.

[wallworm]

Ah yes... some of those lines are copy pasta or relics of older versions that get covered in layers and layers of changes over years. The r undefined is funny; I guess I've never run across an XRef material that was undefined reached that error. Yeah I think that another thread id probably in order for code-related things. I'll add another board for that purpose tomorrow. Feel free to just email me too.

In terms of the problems listed above, there are even more updates in the WW Dev link that should alleviate all the offset and orientation problems in about as many circumstances as I could think of testing. I have to do more tests before it's official, though. And I have too much work the rest of the week to test much more until the weekend. But feel free to test it.

[Orvid]

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.

[wallworm]

Thanks for finding the reason for this.

Now that we know, an even better solution is to not even use geometry nodes for them. Instead, use Bone geometry objects because their geometry is not exported at all--just the bone node transformations and hierarchy. In the case, skin the geometry to the bones and not geometry.

[Orvid]

And when you do so, if you use the "Export Non-Renderable as Bone" option, make sure that your collision hulls aren't set to be non-renderable.

[wallworm]

And when you do so, if you use the "Export Non-Renderable as Bone" option, make sure that your collision hulls aren't set to be non-renderable.

Thank you for sharing this advice. I added this option early in WW development when I was collaborating with Wunderboy on a version of his exporter because I wanted to use CAT rigs. And although it serves the purpose well, I have learned that almost no WW users takes the time to understand this feature nor the global settings that effect it. :/