Break Constraint seems to have been exposed to blueprint in 4.12
Link seems to 404 now. Reupload?
This is no longer needed, as the engine now has the function “Break constraint” which does the same.
Oh right, thanks!
The neck stretching is because some vertices of the neck part of the mesh are weighted to the head.
BTW guys, I’m doing some tests to see if I can repurpose my foray into trying to get a L4D2 style dismemberment system in order to make the bonebreak style dismember much easier to use.
Basically, it would make it so that instead of having to re-author the source character mesh to have the pre-broken joint art, you’ll set up “hole punching” ellipses in the area that is to be broken, then put in “cap” art to cover the hole.
For example, this would make it easy to make the above image of the example character work right when breaking the head off - you’d place your (squished on the z-axis) ellipse at the neck area so that it hides all the vertices that are weighted to the head bone. Then when doing the break, you enable the ellipse hole punch, and boom no stretching.
I’m still testing it out but if it works I’ll provide directions for installing it and some examples.
Unfortunately it’s not plug-n-play because two .usf shader files need to be edited (and thus all the shaders recompiled) in order to make the hole punch effect work correctly.
Break Constraint only separates two bodies from a PhysicsAsset. the plugin from might no longer be needed, but a solution to handle the rest is still wanted 
n00854180t: I see you went the other way from what I was trying to do 
unfortunately for the dismemberment/gore efforts I’ve been focused much more on my UDK game, and it doesn’t help that Epic hasn’t fixed per-poly Tracing against SkelMeshes with MasterPoseComponent. but well, you’d still benefit from the HitMask thingy
@Chosker - Any chance you could share your HitMask system? The way I’m doing it with the ellipse mask doesn’t seem to cut it. Basically, the problem is that as the detached part of the mesh gets further away from the base, the more the verts are stretched, and the more area needs to be hidden to cover the stretched verts/hide them.
I might be able to find and fix the per-poly trace against SkelMesh + MasterPoseComponent.
I see what you did there 
check your PM
@Chosker - So thinking about it, I don’t think any masking system will make this work due to the vertex stretching.
That said, I thought of a way to make it work, though it’s much less elegant overall. Basically involves spawning a proxy and hiding the whole part to be broken on the main mesh, then the inverse on the proxy mesh. I’m going to give it a try with both your HitMask and the ellipses and see how it goes, and release an example if it works out properly.
@n00854180t - the issue with spawning a proxy is how to handle parts that break on two ends.
maybe I don’t fully understand your proposed solution. take for example if you can cut an arm at the shoulder and at the elbow. if ingame you cut the elbow, the shoulder needs to remain in place.
so if you hide the entire arm to spawn a proxy it needs the shoulder area to still be fixed to the torso. therefore you’d need different versions of each proxy depending on which side gets broken.
for a torso with multiple breaking ends (head, 2 arms, waist) the maintainability would be a pain.
my proposed solution is equally not very elegant but solves that issue a bit better.
once again my proposed solution: every cuttable body part would need duplicate polygons at the cuttable zones (with exactly the same vertex normals). the duplicate polygons would be invisible at first, and would be skinned to the bones so that BreakConstraint doesnt produce any stretching. and then at the moment of the cutting the polygons visibility would need to be swapped. the polygon visibility could be handled via a mask with a 2nd uv set.
workflow and maintainability are similarly bad though. but the amount of work seems to be less
Aye, sadly I don’t know if there’s a good way to make it work without always having to go back and mess with the source art. I’m going to keep messing with it, though.
If you can provide a character mesh that’s built to your specifications there I could probably try and make that work - it would be easiest if the parts to be shown when breaking were their own skeletal mesh, I think.
Progress!
Using a proxy does indeed work - though I don’t know how to duplicate a skeletal mesh component from Blueprint (e.g., with its properties), so right now I’m using a design-time created component.
While you’re right in that you lose the ability to (easily, anyway) multi-chop limbs like cutting off an arm then cutting it again at the elbow, the proxy mehs system does work for a very basic decapitation/dismemberment system. It’s semi-flexible with the constraint of not being able to sub-break components, in that you can break anywhere and it works.
The only remaining thing is to figure out how to disable all the bodies but the one actually needed in the proxy mesh.
nice to hear you got something to work 
how about the torso though? it’s the more obvious place with multiple chopping areas
come to think of it, why don’t we just implement what UE3 was doing?
sure we won’t get the fancy import tools but all we need is to import the alt weights skelmesh separately and keep a reference to it somewhere.
then the weight swapping part is just that… copying the weight info from one mesh to another one, of all the vertices that are weighted to the bones whose constraint gets broken.
it doesn’t seem hard to be done now that I think of it, and the workload, workflow and maintainability seem the best IMO
I may just make it so that stuff can be multiply-broken. To be honest there’s no reason it can’t do that, it’s just that it would require an additional proxy and ellipse for each sub-break.
I’m completely fine with implementing the UDK method, it’s just that
-
I don’t know how it works exactly in terms of the code - e.g., did UDK have a broken mesh and an unbroken one, or just the pre-broken one, and it was up to the user to hide the seams themselves (see this post earlier in the thread for issues w/ that)
-
I don’t have any art to test it, and I’m not an artist, so going into a character mesh and cutting the limbs, making caps etc is beyond me.
-
The pipeline is problematic for me personally - copying the weights/updating each character mesh to have broken joints isn’t really feasible for me personally as I have no idea how to do that, and have about 20 character meshes that would need to be redone, and I don’t have the source art for almost any of them.
So if you want to supply a mesh I can try this with (base and alt-weights), I can go ahead and investigate implementing a node or some other helper functionality for swapping the weights during break.
I would indeed like to have an alternative to the L4D2 ellipse hiding method because it’s not ideal having to edit the two .usf files. Nor is it very good that the vertex parameters have to carry an extra 12 bytes (float3) of data for every mesh despite only needing it for very few skinned meshes.
yeah that would work.
these proxies, are they also having ragdoll, or how would it look for example a cut arm?
-
the code itself is what I described earlier: it modifies the vertex weight data at runtime to swap it with the ‘broken’ version of it.
as for the assets, UDK has an unbroken mesh and a broken one, stored in the same mesh asset (internally it’s probably just a diff list of those vertices that have different weights). as it keeps track of which vertices are associated with which bone, it allows partial swapping (i.e. you can cut an arm at the torso and the other arm will be fine).
the user had to hide no geometry seams because the bodypart-adjacent vertices are skinned exactly the same (the issues from the screenshot didn’t occur). the only seams came from vertex normal discrepancies and that was only because UDK’s FBX import of SkelMeshes didn’t support custom vertex normals (hope it’s supported in UE4).
then again vertex normal seams are common in games with paperdolling, like in Skyrim. -
I have my own art from my UDK game, where I fully use dismemberment. I can provide you with this but only for private testing.
-
for me the pipeline is easier than having to do “pre cut” versions of every body part to use as proxies.
the requirement is that your meshes need to be separated into detached sub-objects, so that the cut can be clean.
the other hard requirement is that the broken and unbroken meshes need to have exactly the same amount of vertices/faces, as the swapping is done 1:1 using the vertex indices.
usually they should also have “stumps” to avoid holes, already as part of the original mesh, but you wouldn’t need them if you do the l4d-style hole filling.
for me it works like this: for every mesh that can be cut, I make a copy in my 3d software. then I modify the weighting of the vertices at the cutting zones so they only belong to one or the other bone. export, done. for me it’s like 3 minutes per mesh but I’m used to the workflow.
I myself would stay away from anything that modifies the engine source or the shaders.
I can provide you with some source art. but actually I’d just do it with the unreal mannequin so you could provide it as an example if you release the code.
but only if you’re convinced that the workflow would suit you
It’s not anything special - just a copy of the complete regular (no special art preparation) character mesh. The only thing is that you need to set a special physics asset up for the proxy depending on which part of the body it will be representing (e.g., so if it’s the arm + hand, you’d make it so only those bodies are in the physics asset).
Hmmm alright, that’s sort of what I suspected - the problem for me is that I suspect making all that work would take a lot of time since it’s going to mean digging into potentially both FBX stuff and the SkeletalMesh class itself.
That said, I’m still interested in getting it going as it’s sorely needed for many games. I just don’t know how much time I can devote to it vs just using the quick and dirty method I have. If any other programmers reading the thread are interested, let me know so we can work together on it.
Of course, I absolutely only meant for private testing to get the functionality working.
The system I have doesn’t require you to pre-cut anything, which is the main thing I wanted out of it. That said, it does require some in-engine preparation, e.g., to place the cut and set up the proxy to be right for a given cut.
I’ll look into the code and see if I can determine how much work it would be to add the functionality.
Sadly, I don’t know if it’s really possible to do as a plugin, but I’ll investigate and see.
So… progress. The last part I was having trouble with before packaging this up as an example is now fixed. I was having trouble figuring out how to properly scale the mask area (it was inversely coupled to the scale of the sphere I use to position the mask - making the sphere larger made the mask smaller). This is now fixed and the placement sphere now properly matches the mask edges (though if the mesh is being animated they may not match up, so it’s important to place it while the mesh is in T-pose (just uncheck the anim asset basically).
Also I should mention, and I was confused about this too - the L4D2 wound filling isn’t procedural at all, they actually built out static wound meshes and then selected from among them in order to do the wounds, so they were effectively “pre-broken” as well. I do wish there were a way to procedurally fill the ellipse mask with wound geometry but I’m not aware of a way to do it (without, say, volumetric materials).
Anyway, now that the placement sphere works I’m going to fix up the system so that it’s generic, as right now it only supports one ellipsemask for all materials (just for ease of testing).
One thing I could never figure out is how to add their blood mask to the texture - the white paper says that they use the XY of the ellipse position as a UV for the blood mask, but that wasn’t enough to get it projecting like they had it.
@Chosker or anyone else, if you have any ideas how to correctly blend in the blood mask to the edges of the ellipse mask, I would love that, and it would make it possible to bring the results of this system (or even the pre-break UDK system) up that might higher.
This is the code that gets the per-vertex distance from the ellipse center, which is then used as an input to texkill/clip:
float3 vLocalPosition = (actorpos.xyz - inp.xyz);
float3 vEllipsoidPos;
vEllipsoidPos.x = dot( -right.xyz, vLocalPosition.xyz);
vEllipsoidPos.y = dot( -forward.xyz, vLocalPosition.xyz);
vEllipsoidPos.z = dot( -up.xyz, vLocalPosition.xyz);
float2 ellipseUV = vEllipsoidPos.xy;
return length( vEllipsoidPos.xyz);
Where actorpos is the pre-skinned vertex position (so basically always in T-pose), inp is the ellipse origin position, and right/forward/up are the basis vectors of the ellipse.
ellipseUV is the code from the whitepaper they say is used as the UV coords for the bloodmask texture, which is blended in along the edges of the masked area in order to break up the silhouette.
Edit: Here’s a little (crummy, sorry for messiness) gif of the breaking process in action:
To break that down:
I’ve got a sphere that determines where the mask is placed. The character has two skeletal meshes. The normal one, and the proxy one. The proxy one has the same materials but inverted, so that anything hidden by the ellipse on the base mesh will be visible on the proxy mesh (e.g., the head in this example). The proxy mesh has a secondary physics asset in which the root body is positioned/scaled for the head.
When I break the mesh, I set the proxy to simulate physics (the whole thing, rather than “all bodies below”) and unhide the cap meshes.
meh I also thought the L4D cap filling was somehow procedural. if it isn’t, you can’t really have procedural ellipse shapes and you end up having a very pre-defined system
to blend the blood mask to the edges of the ellipse all you have to do is blur the ellipse in 2D (UV space) to get a somewhat smooth gradient, then use that gradient to bias/pow your blood alpha. this way it gets more dense as it walks through the gradient. it’s what I did in my game with the HitMask. is that what you mean with your question?
also, looking good!
so if I understand correctly:
- you need proxy meshes for every cuttable body part. this includes variations if the cuttable part has sub-parts (i.e. the full arm, or the arm also cut at the elbow, etc).
- you need a new physics asset for every proxy mesh.
- you need specific cap meshes for every area that you can cut.
that all?
That’s the easy part. Figuring out how they projected it so that the texture is always centered at the center of the ellipsoid with nice UVs is another story. I think I have an idea but I’ll have to spend more time testing.
As to your other question, I think you’re overthinking it, the proxy mesh is just a copy of the normal character mesh SkeletalMesh component but with a different physics asset with just the one part set up with a body. It works essentially identical to the L4D2 paper about it - they spawn a copy of the skeletal mesh as well, I just don’t have fancy wound geometry, or have the projective blood mask working. Also the flexibility in their system mainly comes from being able to N wounds, and have them placed in arbitrary places. In the UDK system, for instance, there’s no real facility for shooting a hole into the torso and then decapitating the same character.
For L4D2 they made I think 7 wound meshes, but you probably wouldn’t be able to tell that from the resulting graphics. They limited it to two active wounds of any type per zombie, but that’s not a hard limitation at all - you could have a wound for each bullet, arrow, bolt or sword hit.
Both systems have tradeoffs. Personally I’d like to use both together, as they work best at different things: UDK style vertex swapping works good for breaking limbs, while the ellipse method works well for long slashes, holes and punctures, or diagonal or vertical slicing or mid-limb breaks and cuts.