Curious if someone could explain why one might want to use a Static-mesh vs a Skeletal-mesh in the context of equip-able items?
One of the free weapon-packs comes with skeletal-meshes for weapons, as do some of the infinity-blade weapons. Others like 9000 swords are static meshes. Either way, I can seem add them to my ARPG guy but I find collision with the skeletal-meshes to be more difficult…
If I would like to make a combat-style 3rd person RPG, what’s the trade-off between the two types of meshes? Does using a skeletal-mesh mean I would be better served with using the physics engine to track hits?
If you start with static and want to switch to skeletal for whatever reason you need to do a ton of work to make it happen.
swords bend. Static meshes do not (save for material shader stuff).
If you want to make super special effects you may need them to bend.
physics are physics.
If you add 8 bones to the sword and try to use PHAT to make it behave you will be swinging a noodle.
luckily you can increase the tensor scale to offset this, but i would suggest 2 or 3 bones max on the blade.
Obviously the static mesh will never bend no matter what.
And perhaps less obviously you can always enable/disable simulate physics on the sword mesh so that it could act as static or animated until the simulation is needed.
regardless of what asset type you use, all the animations should be handled with weapon bones on the character so, you should still be able to allow to switch between one type and the other, even if the base asset/blueprint might end up being almost completely different…
Right now I am using the SK_Blade_BlackKnight skeletal mesh from the infinity blade weapons set. It’s part of a BP I spawn and then attach/weld to a socket in the Manny’s hand. It seems to work well enough. Animations from the player make the sword move along as appropriate, I can run collision traces, etc. I get that this isn’t ideal, some of the animations are not so tight…
Otherwise, given your experienced approach, anything jump out as a gotcha, or a suggestion?
Socket it to the IK bone to animate the weapon outside (or even In editor).
Doing so gives you the possibility to do crazy stuff like hand swaps, without needing to detach/pray on physics working right/reattach.
you can give my plugin for blender a try if you want to make custom animations. http://mosthostla.com/gamedev/bonebreaker/
why? simply because if you parse an animation trough it, the exported result will automatically align the IK bone to the hand for you.
If you need to disable that, consider adding a different bone. (I should really add an option to the UI, but haven’t had any issue, complaint, or reason to update since the last blender version issues cropped up).
Normally I add custom bones to handle weapons, so I never had to use IK bones, but simplicity and the fact they are there is really reason enough…
I’ll consider doing this in the next update for sure.
Or, you can edit the source code and simply remove the IK bone name from the arrays. There should not by too many side effects if you just change it to another bone name that is already present, as a quick “don’t know, don’t care” edit…
Hello, and thanks again for all the help here and elsewhere. IIRC, you suggested to skip using the landscape layer nodes in place of material blends and that’s consistently given me 20+ FPS back, so yeah…
I’ll try to socket to an IK, but it SEEMS to animate for me; or maybe it’s just well positioned and since it’s attached moves along ‘well enough’ to work for my current state of affairs. I can get box-traces running via animation notifies and push damage around; so that part all works functionally enough.
Ultimately, I was hoping that if I could generate, obtain or otherwise get the manny to make the attack motion, I could ‘just-stick-a-weapon-in-his-hand’ type of thing and push all the relevant stats, animations, etc to the weapon itself. Taking apart the Close Combat content seems to be their approach as well.
LOL, anything you wanna comment on, I’ve got Q’s but as above, thanks for everything, and yes, it made you legendary.
I’m sure it animates just as well attached to the hand, you only get a clear benefit from using an ik bone if you plan to do interesting attacks where the weapon is passed on to another hand.
However, I always had issues when adding in a new weapon, since they need to be aligned with the socket if your weapon mesh is made differently.
using a specific weapon bone helps to standardize all this, since if you test the weapon within the 3d program you’ll already know if you did it wrong…
But yes, standard localized information - even about the attachment rotation/location are a good way to make it so anything can work with your mesh.
Thanks for helping me clarify this. I’m planning on including a local-offset var on each weapon to adjust and make sure each fits well enough.
One last Q. What if I wanted to make a sword into a whip, like Bloodborne’s cane-weapon or Ivy’s sword (Soul Calibre). Would a skeletal mesh be a benefit here? Is there a way to separate the bones?
I’d try out a skeletal mesh first.
you can get some interesting effects by adding in a physics profile and using simulate all bodies below.
Its far more control then a cable component in terms of art direction - simply because, yes, you can play with inertialized animations…
If the weapon needs to transform from solid to a whip, the skeletal mesh simulate physics option also becomes ideal.
though, from the 30sec clip I watched of Ivy, there is almost absolutely no simulation involved there. Which makes sense for a fighting game really.
I would think the end point of the whip uses IK to solve position of the bones for the final hit of the attack.
Essentially the initial animation can be whatever, but what you see is adjusted to always be on target - maybe.
Never played her character, and the last soul calibur I remeber is probably 2.
pure speculation but I think the bloodborn cane is exactly a nice combo of simulation and physics.
Most of the slashing you see is a particle effect, but at times you can clearly spot the chain and that is probably where the animation is in use.
The path the weapon takes is predictable enough that there likely is an animation driving it.
I would say this.
Simulate physics is great if you expect the hit to be final. Meaning you won’t be going through the target.
if you want to combo into something else, you need to drive the thing through with some sort of animation…
This was discussed on another thread, too. The short of it is: Skinned meshes allow you to merge animated components in ways that static meshes don’t, but static meshes are cheaper per-vertex to render. https://docs.unrealengine.com/en-US/…ers/index.html
Given I’m working on an ARPG with a limited number of on-screen enemies, I’m going to conclude I wouldn’t have to worry about too much overhead. Maybe at best, 20 actors/soldiers in a given area at a time.