Thank you again for the reply, is there any instructions on how to link to the module correctly? Or is just my lack of C++ knowledge?
I would normally link to some wiki tutorials, but those are lacking at the moment due to the official one shutting down. You need to add the plugin module to your build.cs’s dependency module list and make sure that you have the correct header includes.
Yes! was the little push i needed. It’s working, good grief that took a long time! Thank you so much for helping.
I have a question; how would i use the physics grasing hands in the templatein my project. Porting the files leaves thousands of errors. Is there a specific file i have to copy over other than the grasping hand file?
There are many, including the left and right meshes, skeletons, animations, blend spaces, animation blueprints, some enumeration types, and the blueprints themselves. I would recommend using the entire content directory and then picking out what you don’t need.
Yeah…it has a lot of content revolving around it. They would also be simpler scripting wise if they weren’t remotely spawnable options. If you were to make them a default part of your game character then a lot of the setup and edge cases would just not be needed.
Hey there, sorry for constantly coming back here with random issues… But is there a way to get the VR character to adhere to root motion montages? Since the main “mesh” is not in use. We are using a custom mesh attached to the parent vr tracker for body tracking. However, during some moments we require root motion animations on the skeletal mesh, but since it’s not the original “inherited” skeletal mesh of the character pawn, root motion doesn’t seem to be applied.
Any suggestions on how to over come ? Worst case is we can apply movement input based on the estimate of the animation, but that’s a bit of a hassle for the amount we have planned on incorporating.
Again thanks for your time, and any suggestions in advanced
Asking questions is what forum is for!
I personally never did manage to get root motion to work, though it was early on in my project that I attempted it, so I didn’t have a lot invested in it and just dropped the idea. I also didn’t get a lot of “default” animations to work ideally - there was always some motion of the upper body that I didn’t want. What I ended up doing was taking my animations (not root motion), exporting, removing keyframes on all bones above the pelvis, then making those bones assume base pose. It was a little time consuming, but not very, considering I only ended up using 6 animations total - turn in place right and left, walk forward and backward, strafe left and right. is enough for a first-person view, in my opinion - as long as your arm IK and leg IK are set appropriately. You do look a bit like a doofus in third person, though, if your game is muiltiplayer - but that’s a problem that I’m not sure I’ve seen anyone solve completely. A lot of games seem to completely remove hand tracking from the third-person animation set during things like movement and canned animations, to avoid the fact that, unless you’re using run in place motion (which, lets be honest, is a bit passé now,) your arms are usually in some static resting position while you fiddle your thumbsticks (unless you’re holding a gun or something of the like.)
I’m not sure how viable is, but have you considered making your full body character it’s own actor and using a ChildActorComponent attached to the ParentRelativeAttachment? While it’s not used very commonly, that may be able to work around some of your limitations. You won’t be able to completely decouple the two, as I imagine you’d need to reference the parent actor quite a bit in the child actor. I haven’t tried it myself, so I may be talking out of my behind.
The root motion checks were actually mostly ripped out to save performance in some of the character movement modes, so even if the original mesh was in it wouldn’t be driving CMC locomotion currently.
I have a pathway to set the custom mesh being used so that the CMC knows which one to reference so a custom mesh could be used for such a thing if the code was in place.
I’m curious about why you intend to use root motion with VR though, considering its essentially direct control over camera movement most shouldn’t use it. I wouldn’t be entirely against putting the root motion code back in if there was a qualified reason for it. It would just have to be re-written to handle the offset capsule.
I’ve been back and forth over adding the default mesh back and re-parenting it as well. A lot of these were early decisions made a couple of years ago when first starting the character re-write.
I’m just one person, and the people who have mentioned on forum I’m sure are just a subset of your userbase, so take with some bias. After the breakout success of Boneworks showing that there is a market for more immersive, less comfort-focused VR games - I think having some sort of physical body that reacts with the world is going to be the target for a lot of developers. Many popular VR enthusiasts/curators/influencers top-ten lists feature HL:A (physical hands), Walking Dead: S&S (physical hands, mesh arms), Boneworks (full physical body), and Blade & Sorcery (full physical body.) Obviously there is still room for experimentation, and even just having the physics hands example is enough to get people started, but I can’t help but feel like the ultimate “version” of the VRCharacter (maybe not the base?) would function more or less the same as the base character. would better enable thinking of the VRCharacter as a traditional game character, and less like a floating camera and set of hands from which the base character must be a marionette.
Just my biased opinion, however, as one of those developers targeting such an experience.
What exactly does that have to do with root motion?
Also not entirely sure what not having the default mesh in currently does to prevent any of that, the default mesh is not used as a movement collider anyway in engine. Were you going to attempt to inject root motion to move the character based on collisions? Because the physical body is possible as is, currently, I have users doing it. Boneworks isn’t even a fully physical body for that matter, its still a capsule with physical arms, you can test that yourself, same with B&S for that matter, it also isn’t fully physical.
Using the physical animation component and any random skeletal mesh setup correctly will perform mostly the same (minus the nice puppeting plugin that Unity has). I can add the default mesh back and was likely going to soon anyway, its just never been high on my list as it provides nothing you can’t already do, but was more specifically asking around why root motion would be asked after, as modifying that for the offset collision and replication will be a bit of a PITA and I wanted to weigh tasks.
[USER=“3764716”]Benjamin Paine[/USER]
Do you really think a physical body is the ideal condition for VR games? I played Bonework and Blade and Sorcery. 50% of situations in Bonework, the arm part is off collision, for example in climbing, carrying long, complex weapons. Blade and sorcery only have physical hands, and physical mechanics are only activated when the player is in the air state. I tried a lot, and I found that a completely physical body is superfluous and sometimes annoying to the player, although as a developer, you find it very good.
Physic Anim is really not good, in fixed situations, the player does not collide or collisions need not be precise, physic anim is acceptable. But in situations that need precision, such as climbing, your hands need to cling to a point, the physic arm is now a real nightmare. Trust me because I’ve already done it. Bonework also has to turn off the arm’s collssion to be able to climb freely. Even when holding a gun, if the grip touches the player’s arm, and that arm acts on the gun, causing the hand part to be back, time the gun’s position will be skewed, causing a sense of Irritating to the player. So that they turned off the collision of the hand with the gun.
Sorry, I think I misinterpreted what you meant. I’m well aware it’s not preventing any of that from happening, I got it working a couple of weeks ago doing exactly what you described!
I’m in the process of generalizing it so I can save myself some hassle when implementing other characters (I have multiple distinct VR PCs that are similar in presentation and movement but very different interactions, and perhaps most importantly at different scales) so I’m mostly just thinking through how I’m going to achieve that in a way that doesn’t hamstring me in like 6 months when I’m implementing the other PCs.
Hello all,
after having the base character of the open world starter include the VRcharacter in the header, my VR character seems to work great and inherits the ability system. One issue I am trying to understand now, is that the enemy character, which is based off the same class as VRcharacter, has a reference to the character movement component in the animationBP which is returning none- the enemy character now also inherits the VRMovementComponent and I am not quite sure if I need to update the function in the animationBP or somewhere in the files. Thanks as always.
-omfg
An entire physical body, no. A physical body that is convincing enough to the player that it is a physical body, yes. The player doesn’t care if it’s 100% physical or not, they’ll only notice when things behave strangely. One of the implementations I’ve tried (and I think I like) doesn’t use a full physical body, either, just hands and feet (when foot tracking.)
I wouldn’t have your AI also base off of the VRcharacter, it will add some additional overhead to it. The VRMovementComponent is still a movement component, but re-parenting might have broken the reference, you can re-set it.
I’m using the openvr plugin to get finger tracking working with the index controllers. The left hand looks perfect but the right hand looks terrible. The right hand bends in on its self and my fingers don’t match up. I have tried adjusting the axis of the joints, messed with the hand offset rotation. The skeleton is the unreal Skeleton on a custom character. I mirrored the joints from the left hand to right. So all the joints are equal.
You have to enable the mirror hand option for the left hand.
Hmm, strangely enough, after I enabled the original inherited mesh, (i just commented out a specific super construct to not spawn mesh)… I was able to get the root motion working, however on replicated clients for some reason, the inherited mesh would remain at 0 degree z axis rotation, instead of the needed -90 adjustment most skeletal meshes need, even though it was setup that way in bp. Not fluent enough in cpp to figure out what went wrong, but it was enough to back out and rid of the original inherited again.
The reason we want root motion on our vr characters body is, we want the vr character to perform various “cinematic actions” that would be viewed by someone else, or the vr camera that remains locked in third person. Similar to watching yourself ragdoll after dying in Pavlovs, but we want more actions than just a ragdoll flopping down…
Also to , by overhead you mean performance? How much exactly. Because I kind of did , incorporated the Advanced locomotion system, onto the vr base character, then our custom vr player on top of the ALS with some ik blending for VR, now our characters blend in and out of NPC idle or VR interactivity smoothly. way our Vr character can run around and mimmic any other npc in the game, to blend in and hide from other players. Would there have been a better way to do ?
Benjamin up there,mentioned to have the Locomotion kit be attached as a Parent Child Actor, however the hassle to translate all code to replace all the references was a bit heavy, but after doing so, there seemed to be an increased lag between the IK following and the variables it was pulling through a child actor.
Switching it back to model and our IK is back to normal.
Its only a little heavier than a standard character, and that is mostly from the root offset logic and PRC. I just wouldn’t do it with a ton of AI all at once is all, also you can remove ticking from both of those components and it is slightly faster on CPU than a normal character then due to some optimizations (still slower on extra replication overhead).
As for the replication, that is what isn’t currently implemented for the root motion, i have to re-make the RPCs that send information out for the offset root.
I did go in today and add the default mesh back in though, i’ll take a loot at re-adding root motion. They re-worked a lot of how it was used and i’m not as against it anymore.