Announcement

Collapse
No announcement yet.

VR Expansion Plugin

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • started a topic VR Expansion Plugin

    VR Expansion Plugin

    VR Expansion Plugin

    *Updated: 06/13/2019*


    Playable Template Demo
    Template Packaged Download

    Plugin Website:
    https://vreue4.com/

    Plugin Partial Features List:
    https://vreue4.com/features

    Documentation
    https://vreue4.com/documentation

    Website Hosted Patch Notes
    https://vreue4.com/patch-notes


    This plugin is intended to ease the creation of VR games/experiences in UE4. It is up to quite a few different additions now and has a fleshed out wiki to help ease into it (may be a version or two behind at times, I attempt to update it when I can, the template is generally the best informational tool). It is also intended to be compatible with multiplayer experiences without any direct changes from the end user, most of the relevant components / actors replicated themselves over the network with some customization included.

    It is fully Blueprint implemented but can be manually linked to and used in c++ if needed.

    Consider Supporting Me On Patreon

    Latest informational video


    Some Games In progress or released that currently use the plugin (These are just ones I know about)
    https://vreue4.com/games


    Plugin Pre-built Downloads
    https://vreue4.com/binaries


    Plugin Repository
    https://bitbucket.org/mordentral/vrexpansionplugin

    Plugin Example Template Repository
    https://bitbucket.org/mordentral/vrexppluginexample


    Open Input Module (Knuckles/ect until its a main part of the engine it will be a separate module)
    https://vreue4.com/ovri-howto


    Repository Installation articles By Community Member kusogaki77

    Basic Installation Step-By-Step


    Specific Commit Download Tutorial


    Pre-built binary useage

    Template Note:

    I would like to note by the way that everything currently in the template is an example of what I think is best practices (though maybe not implemented as well as I would for an actual game), not everyone is going to need the same set up and not everyone is going to need a full VRcharacter. Custom pawns that just use the motion controllers and camera / parent relative component would be useful to people that don't want gravity / collision. It also has to give examples of far more things than an average game is likely to use, so there WILL be refactoring involved if it is used as a base for one (input bindings for one).

    Template Change Log
    Code:
    04/26/2019
    
    Brought the manual interface implemented objects up to the new IsHeld changes and switched to querying with GripIDs where IsHeld is used elswhere.
    
    11/07/2018
    
    Changed the Gripping sphere trace to use HitLocation instead of ImpactLocation for the socket in range checks, while impact location is supposed to
    fall back to hit location if it wasn't able to be validated, there was an instance with a specific user where that behavior
    was not being shown (even though it works as intended for everyone else...). Since I don't know the engine level cause for this
    inconsistancy and since the actual difference is only up to the radius of the trace sphere (generally very small) I moved to the
    other variable.
    
    08/22/2018
    
    Re-wrote how the character / player controller is initialized to be far cleaner.
    
    Added Knuckles EV2 default controller profile and changed some of the character logic to check for it in OpenVR.
    
    Changed the FPS test pawn to load its profile in a different area
    
    Removed a corrupt BP and prepped everything so that packaging with PackageAllDirectorys works without issues on the template.
    
    Removed unused content that was just bloating the repository (left over EpicVR template content)
    
    Reference BP Grip script will be coming later.
    
    Changed Sedan actor to use a Boxmesh around it for the navigation modifier.
    
    07/18/2018
    
    Added a filter to "CanBeClimbed" to always ignore grip interfaced objects.
    
    Added a VRPlayerStart to the template level in place of the PlayerStart that
    was there before.
    
    Changed drawer actor to use sliders and the new momentum settings
    
    Changed the player controller to wait around for tracking before
    spawning. Checks for valid tracked position and if it isn't valid yet it
    waits before sending the players HMD info to the server (so server delays itself).
    
    05/25/2018
    
    Overhauled how the teleport controllers get the player state and set themselves up a bit.
    
    Added socketing capability to the sample gun for the body component on the example pawn.
    
    Added a socketing check to the VivePawnCharacter in the CallCorrectDropEvent area of the event graph (really simple).
    More complex implementations could skip querying the object and check themselves, or do other things.
    
    05/20/2018
    
    Remade the controller model loading and controller profile support to use the new bOffsetByControllerProfile option
    on the GripMotionControllers.
    
    05/16/2018
    
    Changed controller model loading to be per hand and safe for oculus platform in the template
    
    Corrected Epics roomscale rotation for teleport boundries (unsure if they fixed this in their base template ever).
    
    Added optional tracking sensors to the teleport outline
    Plugin Change Log
    Code:
    06/24/19
    
    Removed Physx and Apex dependancies, massive overhaul to the new physics interface added to the engine, prep work for Chaos
    
    Path notes here: https://vreue4.com/patch-notes?secti...actor-06-24-19
    
    06/13/19
    
    Added some prelim physics changes and replication improvements prior to the more major physics changes coming down
    
    Path notes here:
    https://vreue4.com/patch-notes?secti...eanup-06-13-19
    
    06/04/19
    
    Put out a revision for the LerpToHand grip script
    
    Patch Notes Here: https://vreue4.com/patch-notes?secti...nd-gs-06-04-19
    
    05/16/19
    
    Pushed a fix for throwing with SetAndGripAt center of mass setting with physics grips (the default one)
    
    Patch Notes Here: https://vreue4.com/patch-notes?secti...m-set-05-16-19
    
    05/08/19
    
    Added a new COM (center of mass) calculation / setting setup, this fixes some weird engine interactions with how
    Epic intended that you set COM and welded attachments (it doesn't work correctly with welded children).
    
    Patch notes here: https://vreue4.com/patch-notes?secti...-change-5-8-19
    
    04/26/2019
    
    Pushed another commit to both repositories, I figured that as long as I was requiring some re-factoring of how people connect to IsHeld, that I might as well finish it out fully with where I wanted it to be.
    
    Patch notes here: https://vreue4.com/patch-notes?secti...tor-04-22-2019
    
    04/22/19
    
    Added a beta FlightStick mode to the VRLever class
    
    See Patch Notes:
    https://vreue4.com/patch-notes?secti...de-for-vrlever
    
    04/18/19
    
    Changed the IsHeld Implementation and added AllowsMultiGrip to the VRGripInterface to prepare for some future features.
    
    See Patch Notes:
    https://vreue4.com/patch-notes?secti...anges-04-18-19
    
    04/16/19
    
    Pushed a new update live to both repositories yesterday, forgot to update this thread. I made a bucket updating system for 4.22 to manage the client auth throwing addition and when I saw the new subsystem engine capability I decided it made more sense as one of those. Figured that as long as I was cleaning it up and generalizing it more that I would add some blueprint accessibility to it as well for others to use if they choose too.
    
    Patch notes here: https://vreue4.com/patch-notes?secti...date-subsystem
    
    04/02/2019
    
    Added the GrippablePhysicsReplication class that overrides the default PhysicsReplication class in engine
    to allow for server side smoothing. If "bUseClientAuthThrowing" is enabled (On a grippable actor, not available
    for grippable components) and the grippable is set to a Client auth movement mode. The object will sends
    its state to the server at "UpdateRate" speed and the server will smoothed the replicated physics state
    and replicate back down to the other clients. After the thrown object hits a sleep state or hasn't changed
    status for a time-out period or is picked up it will end the replication.
    
    This is a very alpha feature and will need improvements likely over time.
    
    
    Ported epics 4.22 late update race condition fixes
    
    its also generally cleaner overall now
    
    
    Moved to using epics new local auth check that came in with 4.22, HasLocalOwner is a new component function
    and walks up the ownership chain for authority.
    
    
    Improved oldmove sends missing some special movement flags with CMC's.
    
    Added initial replication state to the button component.
    Fixed initial replication somewhat with the VRSlider.
    
    Made all interactibles and grippable components turn off movement replication when gripped.
    This makes it significantly safer to keep them replicating movement.
    
    
    Fixed some initialization issues with the lever on initial replication of the
    initial transform (specifically not re-calculating the angle correctly).
    
    
    Removed the bReplicatesMovement requirement on InitialRelativeTransform for
    all interactibles. Having that was pretty counterproductive. Just turning off
    replication for the component is better if this is needed to be disabled.
    
    
    Large header function body refactor, was about time that I committed to doing this, removing
    function bodies out of headers and moving them into the .cpp.
    
    
    Switched unique render commands with new format in 4.22
    
    
    Added EndPlay to grip scripts to allow people to manage timers and cleanup better.
    
    Move Grip Script Beginplay to a seperate function being called so that I can run custom logic in the
    future (like tick event registration) without the user being able to override the parent
    and delete it.
    
    Removed Grip Script BeginPlay being blueprint callable, that was never intended.
    
    Fixed a display issue with instanced objects in 4.22 and their property
    categories.
    
    
    Added a colorspace check to the openVR library texture creations
    
    02/11/2019
    
    Now caching the secondary attachment pointer, this lets me
    make sure that the server gets a valid pointer on release of secondary grips, also lets me throw drop events
    when the secondary attachment changed but its still a secondary.
    
    Changed to sending the full transform on drop with client auth grips instead of just position / rotation.
    
    Fixed a Z axis bug introduced with the lever angle re-write
    
    Moved EVRInteractibleAxis to the VRInteractibleFunctionLibrary header,
    it belongs there instead.
    
    Switched levers over to use the Interactible library functions
    
    Also made the dial use the same basic logic as the lever for rotation,
    with an option to revert back to direct hand sampling.
    
    Added new grip type "EventsOnly", will skip ALL extra logic of grips and only store the grip
    data and fire the events for it. Whether you do anything else with it or not is up to you.
    Like a CustomGrip except even more barebones as it does not fire TickGrip or obey any of the
    dropping simulation logic, it is also auto excluded from late updates.
    
    Stopped calling "StopSimulating" on Custom Gripped objects automatically.
    It is legal to start and keep a custom grip simulating, that call should have
    never been there. Anyone who needs their custom grips to auto stop simulating on grip
    will need to call it in the OnGrip event themselves.
    
    02/02/2019
    
    Fixed a net smoothing bug with linear smoothing that could cause crashes
    when rotating. Exponential smoothing is the engine default when using smoothing
    and smoothing is off by default in the plugin so this took awhile to run into.
    
    Now initializing some vars that Oculus may not be setting on mobile
    This would be a bug in the base engine source, engine source is still bugged but plugin motion controllers
    should function. Issues happen when tracking is lost on oculus platforms (IE: Oculus GO controller and app loses focus)
    
    
    Made GunTools virtual stock settings part of the global settings structure
    this makes it easier to store a copy in the character and replicate it to the server
    as well as from the server to the gripped object for setting.
    
    Also added the option to UseGlobalVirtualStockSettings in the gun tools grip script.
    When enabled it will load the current settings from the global settings (default true and only for locally controlled).
    When disabled it uses local settings of the script.
    
    
    Added custom movement events for climbing and low grav movement modes. (EventUpdateClimbingMovement/LowGrav)
    
    Is a better way of getting the hand offset than in the actors main tick, run the same logic but here so that it is taken in
    the same frame instead of the next.
    c++ projects can still override PhysCustom_Climbing to do the same or they can overide the EventUpdateClimbingMovement_Implementation
    
    Also am now properly setting / clearing the climbing variables, the time moments when it
    was being done wouldn't work with the new placement of the query.
    
    
    Many lever improvements on the back end
    mostly fixing Axis_Y issues since it is the last order of operations with Quats.
    Also added SetLeverAngle function
    
    Moved button overlap bindings later in init to avoid an editor copy error.
    
    
    Added a BP Accessible IsLocallyControlled to the motion controllers, it can be very useful, mostly
    with avoiding extra casts to check for local owner OnGrip ect.
    
    
    Changed LerpToHand to be a fixed time period of lerp, not speed based.
    
    Added a control distance variable to the LerpToHand gripscript
    If the distance to the hand is smaller than this value then the lerp
    script won't activate on grip.
    
    Default of 0.0f means that it will always activate.
    
    Also added a curve editor to it that is optional.
    
    
    Added some brief descs to the headers for the Grip scripts and removed the
    SHOULD NOT BE USED warning from gun tools.
    
    Fixed a scaling bug with the auto SnapToSocket setup when gripping.
    
    01/04/2019
    
    Many of these changes go for 4.20 and 4.19 versions as well (except for the new gun tools, it is 4.21 only)
    
    Finalized beta version of GunTools Grip Script, supports pivot offsets, recoil instances, virtual mount settings, extended smoothing.
    
    Moved smoothing settings out of default grips and into the gun tools grip script.
    This will lower default grip overhead and also let me specifically fine tune
    the smoothing for gunplay.
    
    Added "WantsDenyLateUpdates" to grip scripts allowing grip scripts to deny late updates when they don't want them.
    
    Opened up Grip Scripts to be editable per instance again instead of just in defaults.
    
    Added remote grip pivot setting to the motion controllers, allows easier remote gripping and custom operations / mobile VR ease of use.
    
    Fixed it so that attachment grips will now have full use of the late update settings
    and features. Also moved the interface late update deny checking to the end of the logic checks
    to save some perf on grips that will be denied anyway.
    
    Also fixed it to support Custom pivot component for attachment grips
    
    Move setting collision on to post moving capsule in seated mode
    Also use teleport for movement from seated position. Fixes some collision issues exiting a physics vehicle.
    
    
    Made bDenyGripping defaults visible for all interactibles.
    Also made BreakDistance be ignored if value is 0.0f on all interactibles (to match
    general grip settings).
    
    Added new DeltaTeleportation, a new teleport type added to help alieviate teleporting with physics simulating skeletal bodies in hand.
    
    Am now filling in the Component Velocity member of the GripMotionControllers.
    
    Added OnStartedTracking and OnEndedTracking events to the motion controllers.
    
    Added prelim OnBeginInteraction and OnEndInteraction events to the button component.
    Also added the Interacting Component to the button events as it is useful in itself.
    
    Removed IgnoreActorWhenMoving from grip inits, it was causing overlap spam as the primitive bodies
    were not correctly clearing overlap passes.
    
    11/07/2018
    
    Set multiple variables to initialize due to 4.21 warnings, regardless of if they really needed to be or not....
    
    Fixed multiple missing includes that UBT was hiding.
    
    Updated openVR tracked device properties to openvr .16
    
    Am now turning off physics simulation locally on all clients on Socketing operations to cover some edge cases / packet miss issues.
    
    The attachment grip type now calls attach on all clients to cover some edge cases / packet miss issues.
    
    Moved the NavMoveCompleted event into BaseMovementComponent so that SimpleCharacters can trigger it as well.
    
    Added teleporting flag to the "Exit Seated Mode" event so that the pawn teleports physics bodies (can't throw things in the way around)
    
    Seated mode now replicates and throws the OnSeatedModeChanged event to ALL players, not just the server and owning client.
    This allows you to react to it locally on simulated proxies as well.
    
    No longer using Epics TimeTick in phys_walking, this causes errors when the framerate gets really high (like when oculus rift is removed
    and the rendering is paused). This actually appears to be a potential bug in general with the root motion addition that I was basing my
    original implementation on.
    
    Changed the gesture components material that you can set for spline drawing to be a material interface instead of a UMaterial *.
    This way you can pass in material instances.
    
    Added in a bool to ignore gesture scaling for specific gestures, Also the ability to save gestures without autoscaling them to the database.
    
    Merged in a client authed movement mode fix that Epic added.
    
    Fixed multiple replication issues with grip scripts and net relevancy, they should be solid now.
    
    Removed dropping a grip if killing the motion controller and we are not the grip authority.
    
    Added a flag to grip scripts that allows the user to notify the gripping controller that it should drop the object as soon as possible.
    It is not safe to directly drop inside of a grip script due to some memory management that the engine is doing when passing back into
    c++.
    
    Added bIsForTeleport to grip scripts GetWorldTransform variables, useful to know on the grip end.
    
    Added BlueprintType to the base grip script class so that they can be directly referenced in BP.
    
    Fixed multiple bugs in the new Interactible Settings grip script.
    
    
    09/21/2018
    
    Added UAISense_Sight_VR, a drop in replacement for UAISense_Sight that offsets to a VR characters HMD location.
    
    09/16/2018
    
    4.19 and 4.20 changes (got back ported to 4.19)
    
    Simplified and improved the HybridWithSweep grip type.
    It should now performs less operations while also being of a higher quality.
    
    
    Allow gripping static mobility objects if the grip type is custom..why not
    Corrected a bad commit on the dial component that was causing some incorrect rotations.
    
    
    Moved SetHeld being called when an object is dropped to before OnGripReleased
    is called.
    
    Also moved it before OnSecondaryRelease is called
    
    Also moved the call to the objects own OnRelease to before its parent
    OnChildGripReleased as it makes sense that the object performs actions on
    itself first.
    
    This brings the flow of execution for dropping to parity with how it is done on grip.
    
    
    4.20 only
    
    Added GripStruct input Add/Remove Secondary Attachment point functions
    
    Many many optimizations and clean ups regarding the gripping and dropping functions, lowering code bloat.
    
    Added GripID as an input to DropObject and DropObjectByInterface, if the passed in object is
    empty it will attempt to use the grip ID to drop instead.
    
    I also added INVALID_VRGRIP_ID = 0 define for code use and locked out index 0 from being
    used as a grip id, this lowers the total number of possible simultanious grips per hand from 127 to 126.
    
    
    Exposed the GripMotionControllers DefaultGripScript pointer to blueprints so
    that people can access it and set variables on it (if it is a blueprint base script that is).
    
    Also Changed the default and gun tools grip scripts so that the pivot point is attained
    from the ParentTransform instead of getting the controller location again. This is not
    only slightly faster, but it also allows people to override the parent transform with something
    else (say a remote component) so that the grip doesn't have to be based on the controller
    itself.
    
    (force/remote grips for instance could provide a proxy components transform instead)
    
    
    Took a byte out of the positional replication for controllers and camera
    by making the logical assumption that 419.43 meters is a size big enough for any
    current roomscale technology.
    
    THEN Took back 1 of the 8 bits that I saved everyone in order to add a
    flag for quantization of the rotation on controllers / cameras.
    
    You can now set it from its default Short quantization to a 10 bit per axis
    quantization method, effectivly saving 2.5 bytes per rep and with 4x the granularity
    of the engine BYTE rotator quantization.
    
    This makes up for the lack of precision on the BYTE method but still allows for some
    decent savings.
    
    Also dropped a byte out of the CustomVRInputVector and RequestedVelocityVector.
    41,943.04 UU's should be MORE than enough leg room for these values.
    
    Also am now rounding MoveAction_Custom vector values to 2 digit precision. I was
    already doing this for all built in movement actions but the custom ones should
    also be restricted like this.
    
    08/22/2018
    
    Added GripScripts fully into the master branch with four reference c++ implementations
    GS_Default (default gripping logic)
    GS_LerpToHand (lerp initial grips to the hand)
    GS_InteractibleSettings (Functions like the removed InteractibleSettings options)
    GS_GunTools ( Currently unfinished set of tools for advanced gun interactions)
    
    Removed rollback on custom movement modes
    This is to remove "climbing mode" hanging in place and seated mode issues.
    Really only an issue in really high packet loss situations, but wanted to cover it.
    
    Also added a GetReplicatedMovementMode function that returns the current Conjoined movement
    mode.
    
    Set OnClimbingSteppedUp to a BlueprintNativeEvent so that c++ users could use it.
    
    Set GetOpenVRModelAndTexture node to not fail out if a texture is missing and to just pass out a nullptr now.
    It was failing on Knuckles Left controllers as they are missing a texure in full model mode from the OpenVR
    RenderModels api.
    
    Corrected an oversight with the new OnDropped event on the motion controllers having a possibly stale variable (thanks SlimeQ)
    
    08/14/2018
    
    GripScripts mostly final form has been added to 4.20 GripScripts Dev branches in
    both repositories. They need some testing and to be put through their paces prior
    to merging into the master branches.
    
    
    Initial knuckles porting and profile setup - (not public for awhile)
    
    
    Skipping some calls to slightly speed up nav agent retrieval
    
    
    Adding OnFinishedLerping events to the slider and lever
    Also enabling throwing slider progress events during lerping by default
    
    Added dial lerping, lerping speed, Finished lerping event
    Also added SetDialAngle function
    
    
    Corrected the HMD offset for the dynamic navigation mesh generation with
    a VRRootComponent.
    
    
    Correcting an oversight where a grip could not simulate on client side
    if replicate movement was never on the object.
    
    Also if a child component is supposed to simulate on drop, we need to also set it clientside
    if the component is not the root component, non root components do not replicate simulation
    state by default so in that case the client also calls it now.
    
    
    Defaulting welding to true for plugin attachment operations, didn't realize that the
    default setting is inverse between c++ and BP.
    
    Fixing socketing by adding a one tick delay after the socket and re-applying
    the relative transform. This is only done if both the parent and the child are simulating
    and is only there to avoid a race condition with the physics thread where the
    original grip constraint can reset the transform out of order prior to destruction.
    
    
    switched sweep detection on grips to component multi instead of sweep single.
    That function automatically accounts for the pivot offset / collision local pose.
    
    
    Worked around a physics replication issue that
    Epic introduced in 4.20, physics replication period is acting kind of badly now. They moved to
    a different (more efficient) system of handling the simulating position replication that
    they ported from Fortnite, however it has some little issues like not ending a targeted
    physics frame position setting when replication is turned on/off / when simulated or
    unsimulated.
    Last edited by mordentral; 06-24-2019, 09:10 PM.

  • replied
    Originally posted by thelazylion View Post



    And here's a quick preview to the current progress of the game in case you're interested, or would like to add it to the roster of WIP projects using the plugin..
    Yeah sure, it looks cool, I'll add it to the use cases list under WIP.

    Leave a comment:


  • replied
    Originally posted by mordentral View Post

    I found the issue, when porting to the new physics interface I missed passing in the gripped bone name to a function, which is why this was only happening with PerBoneGripping enabled.
    It wasn't removing a delegate binding and was causing it to re-trigger every grip creating a loop.

    Its fixed, just testing in 4.22 and then updating both branches, it will be live in a couple of minutes.

    Think I should add a per bone gripping element in the example template to throw some tests at periodically.

    *Edit* Patch is live on both repositories
    You're an absolute legend, amigo.. That was much faster than I expected. I'll re download that module and give it a try when I get back.

    And here's a quick preview to the current progress of the game in case you're interested, or would like to add it to the roster of WIP projects using the plugin..


    I'll link an updated one later if you'd like, after I'm done porting over the updated NPC grip interactions.

    Again, thanks so much for the prompt fix, I wasn't expecting that, and really appreciate it.


    **Edit: Tested, GrippableSkeletalMeshComponent seems to be fully functioning now, with per bone grip set as well. Thanks again!
    Last edited by thelazylion; 08-22-2019, 12:54 AM.

    Leave a comment:


  • replied
    Originally posted by thelazylion View Post

    Interesting, good to know it's not a widespread issue, I'll keep working on debugging further. What kind of property changes could you be referring to that could be causing sth like this? Only thing I can think of, off the top of my head is switching sim physics enabled on/off.
    I found the issue, when porting to the new physics interface I missed passing in the gripped bone name to a function, which is why this was only happening with PerBoneGripping enabled.
    It wasn't removing a delegate binding and was causing it to re-trigger every grip creating a loop.

    Its fixed, just testing in 4.22 and then updating both branches, it will be live in a couple of minutes.

    Think I should add a per bone gripping element in the example template to throw some tests at periodically.

    *Edit* Patch is live on both repositories
    Last edited by mordentral; 08-21-2019, 12:37 PM.

    Leave a comment:


  • replied
    Originally posted by mordentral View Post

    Mmmm, no that is not common / known, there are actually a lot of people gripping skeletal meshes and NPC's for that matter. However I did recently switch a lot of the backend code to the engines new physics interface in order to prep for Chaos support and don't know how many of those users are on that new of a version.

    I'll see if I can reproduce that, engine shouldn't be calling OnGripMassUpdated over and over unless you are changing a body property.
    Interesting, good to know it's not a widespread issue, I'll keep working on debugging further. What kind of property changes could you be referring to that could be causing sth like this? Only thing I can think of, off the top of my head is switching sim physics enabled on/off.

    Leave a comment:


  • replied
    Originally posted by thelazylion View Post
    Hey there, Been working on a project for the passed year, using this plugin. Recently, been trying to switch over to using your custom grippable skeletal meshes, for our NPC interactions, However, after some testing in the vr expansion plugin example, it seems grabbing the GrippableSkeletalMeshComponent has about a 50% chance to cause a freeze/crash. Is this common/known? I can't really maneuver around C++ too fluently to make this seem like it's worth the hassle of fixing. Meaning I might have to go back to our own custom grabs for Npc's which is a shame, because having our games grip's be universal would round things off much better in terms of development.

    This loops out in the crash report about 1000x


    Can post some gameplay footage later if you'd like. But generally, 4.22.. Just go ahead and try grabbing a physics mannequin a bunch of times.. Crashes on a new template as well.

    Any help would be much appreciated, thanks in advance
    Mmmm, no that is not common / known, there are actually a lot of people gripping skeletal meshes and NPC's for that matter. However I did recently switch a lot of the backend code to the engines new physics interface in order to prep for Chaos support and don't know how many of those users are on that new of a version.

    I'll see if I can reproduce that, engine shouldn't be calling OnGripMassUpdated over and over unless you are changing a body property.
    Last edited by mordentral; 08-21-2019, 11:18 AM.

    Leave a comment:


  • replied
    Hey there, Been working on a project for the passed year, using this plugin. Recently, been trying to switch over to using your custom grippable skeletal meshes, for our NPC interactions, However, after some testing in the vr expansion plugin example, it seems grabbing the GrippableSkeletalMeshComponent has about a 50% chance to cause a freeze/crash. Is this common/known? I can't really maneuver around C++ too fluently to make this seem like it's worth the hassle of fixing. Meaning I might have to go back to our own custom grabs for Npc's which is a shame, because having our games grip's be universal would round things off much better in terms of development.

    This loops out in the crash report about 1000x


    UE4Editor_VRExpansionPlugin_0005!UGripMotionControllerComponent::SetUpPhysicsHandle() [C:\Games\VR_Contracts\Plugins\VRExpansionPlugin\VRExpansionPlugin\Source\VRExpansionPlugin\Private\GripMotionControllerComponent.cpp:4148]
    UE4Editor_VRExpansionPlugin_0005!UGripMotionControllerComponent::UpdatePhysicsHandle() [C:\Games\VR_Contracts\Plugins\VRExpansionPlugin\VRExpansionPlugin\Source\VRExpansionPlugin\Private\GripMotionControllerComponent.cpp:3958]
    UE4Editor_VRExpansionPlugin_0005!UGripMotionControllerComponent::OnGripMassUpdated() [C:\Games\VR_Contracts\Plugins\VRExpansionPlugin\VRExpansionPlugin\Source\VRExpansionPlugin\Private\GripMotionControllerComponent.cpp:4093]
    UE4Editor_VRExpansionPlugin_0005!TBaseUObjectMethodDelegateInstance<0,UGripMotionControllerComponent,void __cdecl(FBodyInstance *)>::ExecuteIfSafe() [F:\Epic\UE_4.22\Engine\Source\Runtime\Core\Public\Delegates\DelegateInstancesImpl.h:679]

    Can post some gameplay footage later if you'd like. But generally, 4.22.. Just go ahead and try grabbing a physics mannequin a bunch of times.. Crashes on a new template as well.

    Any help would be much appreciated, thanks in advance

    Leave a comment:


  • replied
    Originally posted by guidkal View Post
    Hi all,
    i have slight problems understanding how to get hold of the c++ sources from https://bitbucket.org/mordentral/vre...in/src/Master/ (the ones you put into a project and then compile them by yourself) and at the same time also get all the stuff implemented in blueprints and the example levels from https://bitbucket.org/mordentral/vrexppluginexample/src and/or the exampe binaries. While i managed to compile the vrexpansionplugin source for version 4.20.3 i could not do so for the current source at vrexppluginexample https://bitbucket.org/mordentral/vre...e/src/default/. I suppose this is because the latter are meant to be used for the newest engine version of 4.22?

    So to sum it up: I would like to have full access to the c++ stuff as well as to the example blueprints and levels from vrexppluginexample. And all of that for engine version 4.20.3. Could someone give me a hint on which sources i would have to download how i would need to throw everything together? Thx so much in advance and cheers all!
    Download the example template locked branch from 4.20, generally later engine versions of the plugin are not compatible with earlier engine versions due to how much changes in engine between versions. I back port fixes to earlier source builds when I can directly do so though.

    https://bitbucket.org/mordentral/vre.../?tab=branches

    Has the current branches listed for the example template, the template comes with the plugin source as well.

    Leave a comment:


  • replied
    Hi all,
    i have slight problems understanding how to get hold of the c++ sources from https://bitbucket.org/mordentral/vre...in/src/Master/ (the ones you put into a project and then compile them by yourself) and at the same time also get all the stuff implemented in blueprints and the example levels from https://bitbucket.org/mordentral/vrexppluginexample/src and/or the exampe binaries. While i managed to compile the vrexpansionplugin source for version 4.20.3 i could not do so for the current source at vrexppluginexample https://bitbucket.org/mordentral/vre...e/src/default/. I suppose this is because the latter are meant to be used for the newest engine version of 4.22?

    So to sum it up: I would like to have full access to the c++ stuff as well as to the example blueprints and levels from vrexppluginexample. And all of that for engine version 4.20.3. Could someone give me a hint on which sources i would have to download how i would need to throw everything together? Thx so much in advance and cheers all!

    Leave a comment:


  • replied
    Thanks, I understand what to do now.

    Leave a comment:


  • replied
    Originally posted by Decriment View Post
    mordentral I get that attaching them to the skeletal mesh seems kind of backwards, but I got the idea from some forum thread (https://forums.unrealengine.com/deve...-with-download). Someone in that thread said that they got the solution to work with the vr expansion plugin, but I'm not sure how they did it.

    I currently have my mesh attached to the ParentRelativeComponent, thanks for that clarification. Thanks for pointing me to the animation blueprints as well. That seems nicer than just using the character Tick.

    P.S. People sometimes interpret all caps as yelling. I did that one time when I first broke into the software industry and got an ear full from a coworker. You probably shouldn't do that if you want to come off as "professional".
    Marco's tutorial didn't attach tracked devices to the skeletal mesh either, he ran base IK nodes to the relative positions. As for how they got it working with VRE, the same way, attaching to the parent relative component and running IK.

    As for the FPSPawn, that is mostly for out of VR testing as you don't have to make code changes and can test with parity, I wouldn't suggest using a VRCharacter for FPS unless it is really required due to the additional overhead, if you must then at least you would want to turn ticking off on the root capsule (template fps pawn has it on for replication and depenetration testing emulating room scale).

    I know of a few games using a vrcharacter for AI as well as the player and possessing back and forth between them, but its just something where you would want to profile heavily. Some parts of the VRCharacters are actually cheaper than the stock characters, but there are a lot more ticking elements due to the trackers and root offset and some of the movement logic is switched around to avoid extra costs that VR doesn't need that may effect FPS behavior (mouse latency).


    P.S: Caps is a dirty habit I picked up for word emphasis in text boards where there was no underlining back in the day, here underlining could work so i'll try to remember to use it, but you likely shouldn't read too much into text formatting.

    Leave a comment:


  • replied
    mordentral I guess I should have also mentioned that I'm trying to get something figured out for VR and nonVR setups. After thinking about it more it seems like the animation blueprints could be used for the VR and nonVR cases. I really liked your FPS_VivePawnCharacter blueprint because it was a nonVR character that emulated a VR character. In the same spirit, the keyboard/mouse/gamepad controls could control the positioning of the HMD/controllers. That would then allow the same IK animation blueprint system to be used for the nonVR case.

    I'm far from mastering UE4. I might be a bit off, but those are my ideas so far. Let me know what you think if you have any thoughts.

    I found a pretty neat IK project on Github. I learned quite a bit about the IK animation blueprints. The project seems abandoned, but there's a pull request for some 4.2x compile errors. I got it working with 4.23 pretty easily. All you other people might be interested.

    https://github.com/hacoo/rtik

    Leave a comment:


  • replied
    mordentral I get that attaching them to the skeletal mesh seems kind of backwards, but I got the idea from some forum thread (https://forums.unrealengine.com/deve...-with-download). Someone in that thread said that they got the solution to work with the vr expansion plugin, but I'm not sure how they did it.

    I currently have my mesh attached to the ParentRelativeComponent, thanks for that clarification. Thanks for pointing me to the animation blueprints as well. That seems nicer than just using the character Tick.

    P.S. People sometimes interpret all caps as yelling. I did that one time when I first broke into the software industry and got an ear full from a coworker. You probably shouldn't do that if you want to come off as "professional".

    Leave a comment:


  • replied
    Originally posted by Decriment View Post
    mordentral Hey, I'm trying to figure out how to get the VRCharacter class rigged up with a SkeletalMesh, but I'm having difficulties figuring out the best way to do it. I'd like to get the VRReplicatedCamera to be attached to the head bone in my skeletal mesh and the motion controllers attached to the hands. However, it doesn't seem like I can just detach the inherited camera and motion controllers and then attach them to my skeletal mesh.

    I can use my character's Tick to make the head and hand bones follow the camera and motion controllers. That route seems possible, but it still seems like there's a better approach. I'm just looking for the most maintenance friendly path for adding skeletal meshes to the VRCharacter class. Do you have any suggestions? I'm not looking for anything perfect, but reasonable at the least.
    Why would you want the motion controllers and camera to be attached to a skeletal mesh? That is entirely besides the point of what they exist for, the motion controllers and the camera track to the VR systems tracked space, generally you want other things to follow THEM, not the other way around.

    You should be adding the skeletal mesh to the ParentRelativeComponent (set to foot mode for it to be locked to the floor) and using an animation blueprint with IK nodes or an IK plugin to rotate the bone chains to follow the camera and controllers. There are some marketplace VR IK solutions available if you want a shortcut, I cannot attest to their individual quality though.

    Leave a comment:


  • replied
    Originally posted by StarBusta View Post
    Hey I'm kinda dumb, so um,I thought these were all blueprints? I installed it and I just have folders that say C++ plugins??
    Help?
    Its a c++ plugin with a blueprint example template for implementation reference for those that don't use c++, its actually not possible to pull many of the features off only in BP. You shouldn't have to touch c++ to use it though, but you WILL have to learn to compile to it unless you really restrict yourself to the pre-packaged binaries.

    Leave a comment:

Working...
X