If you scale yourself small the object in front of you should feel bigger than it was before scaling. But that is not the case. You see the object like it was before, just from a different perspective. Basically the camera does not scale down.
Ah, so you aren’t getting the perspective difference.
Yeah you might want to check that in a standard 4.18 UE4 VR template. I need to report the controller issue anyway but if the camera suffers from the same thing it should be part of the report.
Trying the default template, but there the Checkbox “DisableLowLatencyUpdate” does not even fix the dispositioning. Camera seems to have the same issue as described above.
Had my try on the default template but it seems so broken I don’t even know what real anymore. Camera seems to have the same issue.
Had a try on your StereoWidget (UE4.16)
-Renders nicely in StereoLayer, but it does not acount for the pivot property of the widget component. The widgetcomponent itself is where it should be (pointer interaction), but the render in StereoLayer is always with Pivot(0.5;0.5).
-I attached the StereoLayer widget to the controller. The render into the StereoLayer was rotating realy weird and does not stay fix like a normal relative component. (World locked? What ever that means. Just came about it in the patch notes)
-StereoLayer component of Unreal renders into -x, your StereoLayerWidget renders in +x direction. I know, Unreals WidgetComponent renders in +x as well. Weird stuff.
I’m currently working on a pump-action shotgun using this plugin, and it seems that grippable child components in the GrippableStaticMeshActor blueprint aren’t able to move the parent actor as a whole. For example, if the pump alone is gripped it can be moved back and forth in its constraint on the blueprint, but the gun as a whole stays stationary and cannot be picked up or moved unless it is gripped directly. Ideally I would like to be able to ■■■■ the gun using the handle alone with the gun’s inertia as seen
Yeah I reversed the render direction so that the widget and stereo layer would line up, otherwise when switching between stereo and 2D mode they would be inverse.
As for being attached to the hand, it would need to be set to track the motion controller instead of the HMD then, currently it assumes the HMD, it would also have to be switched to relative space, should be fairly simple, though getting it with the late updates is another matter, you are seeing offsets because the controllers late updates are enabled.
I’ll check on the pivot, forgot that it existed
Thanks though, not too many people test the stereo layer widgets.
I have an experimental branch up where I have been thinking about the best way to make the car seat setup a native part of the VRBaseCharacter and implement it cleanly and correctly over the network. It has accumulated several changes besides that from me fixing / changing things as I go, so if I don’t finish the seating part before the holiday I will likely strip those out separately and push them live.
The most notable change is stripping out all reliance on the VRExp module from the OpenVR module so that it can be used by itself (no more tracked device requirement so I can finally do this). This happens to be just in time for 4.19 bringing in true model loading for VR tracked devices natively built into the engine ;p so I will at some point be removing the code for loading the SteamVR models as well when their implementation proves stable.
Just wanted to give a heads up why no commits were happening lately.
Good afternoon. Thank you for your work. Thank you for the opportunity to access your plugin. I’m new to UE4. I wanted to ask you a question: “How should look like (EventGraph), the interaction of” laser pointer “with” static mesh. " That it worked as well as with the “Widget buttons” (Navel laser pointer on the “Static Mesh” pressed the “trigger manipulator” - “Static mesh” performs the specified action.
Example 3d widget. Has included “Laser Pointer”. I chose the menu button. I pressed “Triger”. With that, I understand. How to do the same, only not with the menu button, but with the “Static Mesh” ?.
Sorry for my english
I hope my request, you will not be hindered.
Thank you for your contribution.
Hello. What is correct way of making slot gripping? I’ve put slots on mesh and named them VRGripP#. It was okay for one hand, but another is rotated towards its forward axis by 180 deg. I use Vive_PawnCharacter with my hand meshes, where one is scaled -1 on z but motion controller components are unchanged. Thanks.
So I was trying to achieve the following, and wondering if you might have any insights. I created some subclasses of the Vive Pawn Character each with a different skeletal mesh assigned under parent relative attachment, and I’ve added an box overlap trigger with the idea to possess on overlap characters placed around the level. Problem I’m running into is that even though tick is disabled for those characters placed around the level, the parent relative skeletal meshes are moving around with my default possessed character, and I have duplicate controllers following me around as well. Is there a way to completely disable the vive pawn character until possessed? Or any other way of achieving this type of interaction with the vive pawn character?
You have to stop the controllers and camera from ticking as well. They don’t automatically stop ticking when unpossessed and setting the actor to not tick doesn’t make the components not tick.
To do it best, set the
Controllers, Camera, MovementComponent, RootComponent, Actor, ParentRelative, to tick disabled by default, this will remove as much overhead as possible, then on Possession re-enable tick on them.
The one caveat is that you may need to also disable LateUpdates on the motioncontrollers when not possessed, as turning off tick doesn’t remove the SceneView that runs the late updates so they may visually look like they are still moving.
I would assume that you may be wrong about only the mesh being inversed? In the template the gun has a few different slots and the hand that uses them doesn’t matter. It by default uses the slot as a relative transform from the motion controller.
Components don’t “move” their parents unless they are all simulating and constrained to each other, that isn’t how the engine works. Parents move their children in this engine.
You are free to grip the pump as the primary slot location and visually have the handle change with an addition offset or skeletal animation and have the rear hand be the secondary, or you can run it with multiple physics grips and the gun as simulating, or you could run a custom grip and sync the gun to the grip somehow taking into account it sliding in relative space…
However, moving a sub component, never moves its parent, you’ll have to re-think how you want to implement it, game engines aren’t real life and some things don’t “just work”.
Guy on youtube requested some slicing action and I always wanted to make a demo with it (only played with slicing like 1.5 years ago when i first started the plugin).
Thought the concept of a blade that would only cut on the sharp edge and only with an angle range was interesting. Short project so it didn’t really take any time away from the other beta branch work, but was a fun break.
Apparently 4.17 version of the Example scene still gives me the “incompatible” warning ( I have UE4.17.2 version ), which is unfortunate, while 4.16.3 works ok…I’ve opened the latest version with 4.18.1 and it works, but for technical reason I can’t use the latest version of the engine, so I used the Commit download instruction to use the previous example scene.
Am I the only one with this issue?
Many thanks for the tip on the component ticks. That’s working very well, and it’s pretty fun to possess different characters by walking into their bodies. I do still have an issue with the controllers doubling up due to the late updates you mentioned. Seems to happen even when they’re set to not tick and with late updates turned off, but it’s easy to work around this by hiding them until possessed.
The other big issue I’m seeing now though is that the world space is changed to have the new characters location as the origin when i possess a new character. By that I mean the chaperone bound is now centered from the newly possessed character’s location, with hmd being relative to that. It’s a sudden pop, and feels incorrect.
I suppose I can try to get around this by calculating the offset from the previous possessed character’s origin to the new character’s before possessing, and then adding that offset to the new character, and doing the same with control rotation. I think I can handle that, but it feels a bit hacky, and like it’s going to break things in the long run if i possess a lot of characters etc. I’m wondering if there’s a proper way to reset the origin to my original character’s origin on possession for each character I possess so that the origin remains 000. Or, maybe there is a way to add an offset for each character placed in the level such that they are placed from 000 to achieve the same? I’m not sure if my terminology is correct but i hope you get the idea. Just wondering your thoughts on this.
hi mordentral, had some testing session today and I found that vr camera attached components are still lagging significantly.
Any suggestion to fix it?
Offsetting by the HMDs relative location IS the proper way to do it. The Orientation/Position reset sadly is a permanent change and nulls out Z as well so it is pretty much unusable in roomscale.
Teleporting / Rotating / The car stuff/ initial spawn in, all of that already offsets by the HMDs relative, its not hacky, it is how you handle things with the default setup.
Edit I’ll note that I added SetRot, SetRotAndLoc, AddRot functions in my alpha branch to help people out, they won’t have to manually pivot around the HMD anymore they can just call the VR version of the standard engine nodes instead.
Over and Above the default template? Because the code is matching now line by line. I also have had some attached components without that problem. What specifically are you attaching?
Edit Yeah, I just confirmed it, attached objects behave correctly currently. So the only thing that should be causing issues for you is if you are attaching something that is losing its scene rendering object and being re-created (this kills late updates for the frame it is being re-made) or if you are on a very old build right after I was porting some of the changes Epic made over.