I’ve talked with oogaboogaman a little about this, and whilst he kindly provided some interesting hints about making ragdolls as a whole, this concept sadly seemed a little too “out there” for any plans to be made for it, I guess spending time making stuff that isn’t entirely experimental might be a wiser.
Also I don’t recall saying thanks for the help, so if you’re reading this, thanks. Also before I go any further, I’m using 3DSmax 2011.
Still, this is my problem:
I have made a chest of sorts, one that is empty and has a lid on it. I’ve made it a ragdoll so that it can be opened and closed in a more analogue, Amnesia/Penumbra way rather than the robotic func_door_rotating option.
This opening thing works using two bones, one for the lower section, and one for the lid. Bone02 and Bone01 respectively.
Everything compiles without problems, the top opens and closes properly, the limits work and altogether all is well. With the possible exception of the “cavity” being physically solid, but visually hollow.
Now, After some latent research and some changes to model to make it empty rather than full of junk, and therefore with the need of the lower part not being a solid collision model, I’ve found that source actually does not support Concave phys models on ragdolls. Blast.
Being a determined little bastard, I haven’t quite given up, as one, it would be a useful model if done right, and secondly I’ve spent long enough on it already.
After some thought, I found one interesting thing; Source does support concavity *between *bones, meaning that If I was to split each side of the chest into a separate bone, the “inside” would be considered between the bones, and would as a result be a containing space.
So that’s what I’ve done, I’ve split the model into a total of 6 parts, the top, left side, right side, front, back and bottom. Each has a bone assigned to it. As well as Bone01 and Bone 02, there is now RightBone, LeftBone, BottomBone and FrontBone. Each are correctly skinned and the like. I have used the linking tool to link them to Bone01, which I have made the parent bone in the .Qc.
The bones look like this (I’ve removed the front bottom and sides for this picture, obviously)
So if you’re with me so far, this is what the schematic view of the bone hierarchy looks like:
As far as my limited bone-knowledge goes, that seems about right.
I also make the appropriate physmodel parts, and rig those up and export everything as normal.
The result is of course, awful:
All of the physmodel parts that where attached to the new bones have jumped to Bone01.
Here’s what it looks like if I don’t link the bones:
Which is of course, perfect. Only problem is that when I go ingame with that, this happens:
Which is as tragic as it is hilarious.
This proved really handy for another model I made months ago, but I digress.
Upon closer inspection, GUIStudioMdl is “Collapsing” the new bones to Bone01, so that the different panels use only one bone, which is understandable.
The only problem with this, is that now that it’s one bone, the concavity is lost and the extra bits of physmodel jump to the single bone.
So, after wading through all of those sentences which are about as concise as someone desperately trying to meet a word count, here are my actual questions:
1.) How would I prevent StudioMDL from Collapsing the bones?
2.) If there is no way, how would I make it so that the model’s different parts work as separate props, but so that they act like they’re “Parented”, or immovable from each other?
3.) Am I crazy for trying such a thing? Is there a reason why I haven’t seen anything like this before?
Any bits if insight and I’d be hugely grateful