Yeah, I see your point with the output of the slicing function… Perhaps it’s conceivable to make a separate node for such a copy (or to set the pointer)? Similar to the existing “Copy Procedural Mesh from Static Mesh Component”. That way you wouldn’t have to touch the slicing and the code remains clean (would still be inefficient… but so are all the other solutions it seems).
I found that:
Copying the Mesh from the ProcMesh after slicing will make you lose the collision (as you highlighted in the example project). The only way around I can see is to mirror the actor, do the slicing twice, and delete one half from either actor. It’s really collision that is creating issues…
Parenting to a Grippable Sphere (with Welding), messes up completely the collision of the ProcMesh (also made a bug report to Epic for …), so that’s not a solution either
Ideally, we would remain with one actor – also because after slicing we need some logic to determine which sliced part was held by a hand and so on…
After copying you just need to generate convex collision, the slicing does that part automatically so you likely just weren’t aware that it was part of making a proc mesh and has its own node.
The example template doesn’t “lose collision” it loses the body instance of a physics grip which wouldn’t matter anyway with a sweep grip type. Also as of 4.22 I added a way to detect a physics body being ripped out from underneath the physics constraint and re-init it with the new body context so that doesn’t happen anymore anyway.
As for a node for the slicing with a different base class? The problem wasn’t the copy, the problem was the slicing function automatically spawning and filling a new procedural mesh component, and then having to spawn yet another procedural mesh component and copy the results over before destroying the one that slicing had made. You can limp along by making a manually interfaced subclass of the procedural mesh component and copy after slices, I just would rather not make that an official part of my plugin or keep a re-write of the slicer around that is a seperate function.
Would be better off reporting it as an issue with the suggestion that the class type of slicing be either copied from its parent class during creation or allowed to be passed in. would get it fixed in engine, after which a grippable form of the procedural mesh component would “just work”.
If you make a grippable actor and set its root component to a procedural mesh, then do your sliced copies duplication off of its children on a subclass with a manual interface integration (see pickup cubes) then you should be fine. You’ll want the original to be the root of a grippable actor anyway for most uses if you intend to work with replication.
So I guess I’m stuck with the “duplication” that I’m doing wrong… so far I’m doing the “Get Section from Proc Mesh” of the sliced copy, and “Create Mesh Section” in the spawned actor, where I have to re-create collision. I did not find a way to copy a ProcMesh over to a new component (in the same actor or in a new one… or even copying a static mesh the same way). How do you duplicate/copy? In c++ I guess that’s possible, but in BP?
(thanks for your patience on , by the way…)
Some additional info: After slicing, the MultiSphereTraceForObjects does not detect the resulting objects. The default Vive_PawnCharacter has to fall back on overlap detection for the grip (which messes with the grip prios a bit)
Copying mesh sections is the correct way of doing it, there is no direct “copy” no, but copying the sections IS copying the mesh.
As for tracing not working, you need to enable collision with the VRTracechannel likely, you still have to manage collision settings on spawned objects, if you are copying to a new subclass then that subclass can have the collision settings already defaulted.
What you are doing for copying is literally what I would have to do “officially” unless I re-made the slice function, its a result of the procedural mesh component not being very flexible is all. Rather the engine improve here than patch on a hacky fix that you can do yourself anyway.
Ok good. I’ll make sure to send you my solution when I’m done, in case you want put it in the example project.
That was the first thing I tried… Perhaps I made a mistake somewhere, but it might also have to do with the collision bug that is present in ProcMeshes.
I’m using a VRCharacter, but for some reason, the VRRootReference is not following the HMD. It remains at 0,0,0. I’m wondering if I switched something off by accident.
When I spawn as a fresh VR character (e.g. empty blueprint), the capsule follows as expected.
When I duplicate my VRCharacter, then delete everything so that it’s got only the inherited components and no code, the capsule still remains at 0,0,0.
I’m hoping is an easy fix before I start migrating my character code to a new blueprint.
It looks like I somehow did. When I check if “Is Component Tick Enabled” on my character, it returns false. when I check it on the fresh character, it returns true.
I’m uncertain how I disabled tick on component.
When I “Set Component Tick Enabled” on VRRootReference to True, “Is Component Tick Enabled” still returns false.
Might be a bug with the engine… I’ve just read that sometimes components don’t tick, need to remove them and readd the component.
Since component is inherited, I’ll probably end up having to migrate all the code over to a new bp
Yes, manage your collision settings to not do it, the character obeys the collision settings of the engine, you can turn off anything to not block them that you want.
You can also setup bWalkingCollisionOverride to have collision channels that only are active during locomotion and are off during “walking” around.
Could you provide some advice on how to use the Gameplay Tags, specifically the “DenyFreeGripping” tag? Just from the title, it appears to be what I am looking for to prevent accidentally “free gripping” another part of the root component that has collision when I’m actually trying to grab a child component. However, in my testing, I’m unable to actually get it to trigger - so far I can’t see a difference between it being enabled or disabled.
4.23 going over video, not much to “show” most of the start of 4.23 is all going to be backend and stability work. There is a lot going on in the back end of the engine itself that I need to keep an eye on at the moment and stress test against.
Was looking to put game up on Oculus Store but game cannot reference steam or steam openvr. Do you have an OpenVRExpansionPlugin based on Oculus instead of Steam? Or should I just be trying to remove all use of OpenVRExpansionPlugin.
You can just disable the module, you need to disable the engines steamVR module as well for it to not ship the binaries though. As for the nodes, unlinking them for the oculus build should be enough, though generally you would likely want to keep a seperate blueprint for the oculus and non oculus versions.
There really shouldn’t be much that you would be using the openVR specific module for though, generally controller properties and rendering overlays are the main use of it, shouldn’t be too hard to seperate that out for the seperate builds.
Also there is no such thing as OpenVR based on oculus…OpenVR can work with oculus, but oculus doesn’t let you even have the binaries in your package when uploading to their store to ensure that it is on its native platform.
I have two one questions when you get a chance! – (answered my own first question - I was missing one of the input events, I’m an idiot)
1st –
I saw your response a few months ago about changing controller inputs for rotation and I figured out how to get that working (both smooth and snap)
What I’m wondering is - how can I actually use a hover version of that? Seems like the incoming Axis Value for ->InputAxis ControllerMovement is based on Pressing the pad (I’m using vive controllers), so it won’t register as > 0 if hovering.
Seems like maybe the hover settings are somewhere in the Motion Controller Component script? I’m only … let’s say “intermediate” level for C++ and while I did find a couple references (when “Searching”) for “hover,” I didn’t spot anything obvious.
Tips / suggestions?
2nd –
I THINK I have a solution for but trouble-shooting… and it’s not quite getting me there…
Can I force-call a grab on a controller?
The example- I want to use a secondary Grip for a 2-handed weapon. However, that grip also needs to be a slider (shotgun pump, in case).
My thought was - have the Grip action go to the secondary grip socket for the weapon. Then, on TRIGGER pull for the second hand, actually use the Blueprint to force the grip over the slider (which would be in the exact same spot, so visually the hand wouldn’t move), to allow for the Slider to move… then when the TRIGGER is released, for the grip back to the Secondary Grip socket.
Thanks in advance, I realize it’s not always easy to find time to answer questions!
If you are secondary gripping the object anyway then its kind of a waste to also grip the slider, if you don’t want to run custom logic to move the slider though with it then yeah its a viable method.
As for manually gripping, call GripObjectByInterface from the controller and pass in the object you want to grip.
