Wall Worm Forums

I had this same issue before (it showed up purple instead of red though... no idea) and as soon as I tried to reexport the model (or was it vmt/vtf?), it wouldn't let me saying there wasn't a texture assigned. Which there was.

I solved it by deleting the WWMT helper for the model entirely and recreated it, adding the settings I had before. It let me export it after that so I assuming something got stuck.

I think the $scale command in the .qc file needs to be before the reference file as it affects everything below it. Check the .qc file that WWMT generates and see if that is the case and if not, just move it before the $model command. If doing both this and recreating the WWMT helper doesn't fix it, I'm out of ideas.

If it were only that easy... no, it behaves exactly as it appears in Hammer. I believe I showed a screenshot of this already... though maybe I should upload a video instead since it is physics we're talking about.

I'll probably add that to this post but for the moment, I'll say this is in need of a fresh install of Hammer. I'll post again once I tried it there.

Edit:

...okay, this is embarrassing. I just found out that there is a particular entity known as prop_ragdoll that does exactly what I was looking for. I was under the assumption that prop_physics handled ragdolls but it turns out it only handles RIGID AKA NON-JOINTED objects.

So... yeah. The whole collision collapsing thing was because I was trying to force a ragdoll onto an entity that didn't support it and forcefully ditched the joints and collisions to make it compatible. I can't believe it took me this long to find that out.

...I guess I was being more stubborn then stupid in this case and I apologize if I wasted your time on this... twice if you remember. So, I suppose the bug here is human error XD.

That's fine, I keep the original brushes for that purpose anyway.

Of course, now I'm curious about the new quad displacements and the older triangulated displacements in the same map... technically, Hammer has them triangulated anyway but I don't want to see it have a fit about it and toss alot of them out. If that's the case, I'll stick with the older version if I have to for the current map I'm working on.

I have been working on a displacement heavy map using the method of blocking out with simple boxes similar to Hammer. I tend to keep the base brushes in another layer in case I need to do some drastic changes later but anyhow...

When I pick the faces that I want to convert to displacements, it does its thing without error. However, it also disables the undo function somehow. I can partly understand why since a script is doing a number of operations but it is aggravating to find yourself sculpting the displacements afterwards just to find you can undo anything!

Also, a side bug is that sometimes the planes that should appear when Move Mode is on are sometimes unhidden. Fortunately, I can easily hide them, especially with the help of the script Outliner that makes it alot easier to manage layers so it's more of a nuisance than anything else.

Oh, and I'm using 3ds Max 2013 (64-bit) with Product Update 6 installed if that helps.  :)

Sorry about not responding for awhile, got rather tied up with something.

Anyway, I'm using 3ds Max 2013 with the latest product update which is 6 I think. They don't seem to have barely any service packs at least by name so yeah. This is the version that the bug is being tested on... but I don't think it's actually Max's fault. It's Hammer.

While this may not be a good lead, I notice that when I turn on collision model visibility in Hammer, it tints it a different color depending on what prop it is. For static, it's red and for physics it's purple. As you seen from the screenshots, it's a physics prop with the collision tinted red.

What I think Hammer is doing is trying to treat it as a static prop when it isn't and tosses out all except the collision hull skinned to the root bone. This also occurs with a dynamic prop that has animation on it but the animation is perfectly fine. It is the collision hulls it is apparently tossing out.  :-\

I probably have to blow Hammer away and reinstall it to see if that solves the issue. If that don't work, I'll put the models in using another game such as Counter Strike and then open the map up in the game I'm mapping for.

Again, the model and collision appears perfectly fine in both the stand-alone model viewer and Hammer's model browser. When it is put into the level is where the problem appears to start. There may not be anything you can do in this regard so... yeah. I'll let you know if that fixes it.

Rotate Origin off... nope. Xform modifier.... no. Both model and CMs pivot at origin and aligned to world... nope. Tried combining the CMs thinking it just keeps the root CM... it still gets rid of the other ones so this may be bone related... so why does it look fine in HLMV?

That's the thing, the model looks fine in HLMV and it's equivalent in Hammer but once it's in the level, it ditches all but the root CM and turns it 90 degrees. It does the same thing with animated models intended to be prop_dynamic. The model is animating beautifully right in front of my eyes in HLMV and in Hammer but the CM just keeps being destroyed.

However, Hammer did leave it alone 3 days ago before if there is only one single CM hull in the model and only skinned to one bone... which it doesn't do anymore.

Maybe I'm looking in the wrong place if this is a Hammer issue.

I never needed to change the SMD exporter to anything else so I know that isn't a problem.

Here's a set of images of what is happening.


In both HLMV and the model browser inside hammer show the collision model just fine...


...but that's not the case once you drop it into the map and run it.

I tried checking if the bones or mesh was causing it but I still get the same result regardless. I have no clue what's causing this issue.

It also just started to do this to rigid physics objects as well though if you set it to be $staticprop with physics properties, it'll still use it as a prop_physics and the collision mesh is actually fine. Not that simple for ragdolls though.

Oh, and your example is still broken on my end. Out of curiosity, what game did you test your ragdolls on? It is clearly not working for 2007 and 2013 SDKs for me... or it could be studiomdl. I have no idea.

It looks like it's an issue with the SDKs themselves as some other ragdoll props are not working correctly such as the mattress from hl2... maybe that's why it's not working. I tried everything that I know of to get this to work and got nothing.

I guess I'm stuck with physics entities for now.

I decided to try out ragdolls again after some time trying to get them work before and... I know this time it's not me. I ensured the model had a collision box for each bone, the bones have constraints and $jointconstraint is checked, the collision mesh seems fine and is marked in yellow, etc.

When I put it into hammer and turn on the collision mesh visibility, the collision mesh appeared to have either collapsed to the root bone or all the others except the one on the root bone vanished. This holds true when I test the model in-game with the model passing partway into the floor.  :'(

I also tested your ragdoll example and a similar scenario occurs. I have tested this using the latest version of Wall Worm to date on two computers using Source SDK 2007 and 2013 respectively.

I been trying out CAT for a hands view model and while the bones export, there's all sorts of nonsense going on. Since you asked for feedback on how well CAT plays with WWMT then .

After having luck with have the models attached as one model and aligning it's pivot to world at origin, I thought I have averted unwanted offsets. This doesn't appear to work with CAT.

Here's what it looks like in Max:



Both the CAT parent and model are at origin and oriented the same way (aligned to world). Only from the elbow down is skinned to the CATbones. I then assigned both the CAT parent and the model to the WWMT helper, created a simple handshake animation and left CAT in animation mode when I exported.

The result looked something like this:



The model is on it's side and the bones have been flipped upside-down and forced all the digit bones to the palm bone.

I have tried contraining bones to the CATrig, skin and export, but instead of them staying in place they go all over the place. After some troubleshooting I found that having a position constraint causes an offset even when the bones xform has been reset.

The only thing that worked at all is just simple bones with the model skinned to them. If nothing else, this has the least amount of problems.

Okay, I updated the link in the first post with the latest file as well as the one prior just in case.

Recreating the target from scratch, I got as far as getting the CM and RM working correctly before adding the bones and skinning them. Once I did, a whole new batch of problems start to occur. I can't even focus on testing if the physics work correctly until I can get all the bones, RM, and CM working together.

I made sure that the pivots of all the RM and CM objects matched both position and local orientation of the bones then skinned them to each bone, made the CM with multiple elements and skinned it to the root bone, and gave them all an Xform modifier before skinning them. The result winded up like this. (See attachment)

The CM was split into multiple objects in this attempt with elements attached such as the rings after the single CM failed to recognize the separate elements as concave (Is 42 too much?). I'm starting to wonder if this is a limitation of the ragdoll physics system.

Now again, this is more for testing purposes so if I can't find a way to get this to work at all then I'll just have it as a static prop instead.

------

This is abit unrelated but I been noticing that using Bridge to create the inner portions of the rings causes bad vertex data to occur. What's even stranger is that it was occurring on the sides but now is happening on the front. ??? Still haven't figured out how to get around it.

It seems to work fine when the reference model (RM) is the collision mesh (CM) but not when both are different. I'm getting some odd behavior such as the root object in the CM is being ignored and the ring CMs are exported at world origin even if it has Xform and looks fine in the model viewer. I even did half and half by having the rings from the RM be part of the CM as well as a simple box around the pole... it's a mess.  :(

I'm assuming the hierarchy is on the RM and the IK limit on the CM? If I have the CM in a hierarchy, it doesn't work and gives me an error in the model viewer so I'm quite puzzled.

At least your example worked as intended so there's that. If all else fails, I can just have the target glow instead using Skins.

That's nice to hear, man. I'm pretty much the only one on my mod team who's the most acquainted with this great tool but all I'm doing is reading the manual with some trial & error. Chances are, you might hear from me a few times.  ;)

I'll let you know if it works out or not tomorrow.

I been fiddling around with trying to get a target attached to a pole with 5 rings that spin when shot via physics. While the model does react to being shot, it just falls over and none of the rings even move. The bones and collision show up fine in the model viewer

I get the feeling I'm doing something wrong here but I can't figure out what it is. :-\ Maybe you got some idea what's going on here.

Here's the file