Is there any way, to download the template and load into the unreal 4 engine editor without compiling anything? Doesn't matter if 4.16.1 or4.15.2. It doesn't matter which commit I try it just says missing plugins [*VR_Example*dll] . When I start my own project it works. Or is there a way to download the blueprint code for climbing / teleporting objects / picking up / showing hands (or controllers) seperately?
Announcement
Collapse
No announcement yet.
VR Expansion Plugin
Collapse
X
-
Originally posted by rohezal View PostIs there any way, to download the template and load into the unreal 4 engine editor without compiling anything?
You went through the image-based tutorial yeah?
I know of 2 people, with not so much experience at all in UE4, that have verified it got them building.
I'll post a link to a pre-built VR Package Template that runs with UE4 4.16.1. (I think latest is best, so I'll make that and send you a gdrive link.)Last edited by kusogaki77; 06-16-2017, 08:21 AM.
Comment
-
Originally posted by kusogaki77 View Postrozehal,
You went through the image-based tutorial yeah?
I know of 2 people, with not so much experience at all in UE4, that have verified it got them building.
I can PM you a link to a pre-built VR Package Template that runs with UE4 4.16.1. (I think latest is best, so I'll make that and send you a gdrive link.)
Originally posted by rohezal View PostIs there any way, to download the template and load into the unreal 4 engine editor without compiling anything? Doesn't matter if 4.16.1 or4.15.2. It doesn't matter which commit I try it just says missing plugins [*VR_Example*dll] . When I start my own project it works. Or is there a way to download the blueprint code for climbing / teleporting objects / picking up / showing hands (or controllers) seperately?
You can actually directly transfer the uassets over, but it would be a little difficult to know the exact ones you want.
BTW for everyone else, the reason that climbing and movement "logic" are not built into the code and are handled in blueprints is two-fold
#1: I wanted anyone to be able to play with and modify how they work easily so they can get it working how THEY want.
#2: For blueprint users it gives them examples of how to achieve different things, for c++ users, they can convert blueprints to c++ at will anyway.
I have been considering building some common objects into a c++ "pack" in the plugin, like levers and buttons and dials and the like, haven't made up my mind yet.
Consider supporting me on patreon
My Open source tools and plugins
Advanced Sessions Plugin
VR Expansion Plugin
Comment
-
Originally posted by mordentral View PostThe pre-packaged binaries as long as the date on them isn't too far from the templates last update should also work, the downside being that the template also uses the sessions plugin which has its own pre-packaged binaries....
You can actually directly transfer the uassets over, but it would be a little difficult to know the exact ones you want.
[MENTION=428570]rohezal[/MENTION]
If you just want to see the plugin with minimal effort, dgaf about anything else, and just want to move around like a VR madman climbing on stuff and scaling/gripping/flinging isht (none of which you made) to kingdom come, here's a link to a prebuilt template for UE4 version 4.16.1.Last edited by kusogaki77; 06-16-2017, 09:21 AM.
Comment
-
Originally posted by mordentral View PostI have been considering building some common objects into a c++ "pack" in the plugin, like levers and buttons and dials and the like, haven't made up my mind yet.
Comment
-
Sorry to sidetrack this.
I got a socket prob.
tl;dr
Custom Static/Skeletal Grippable Mesh actors aren't oriented/positioned exactly mirrored in each hand, but the Template Gun_Base is.
What things might I need to make sure are good?
I have custom-made hands, and equippable items (all made in Blender). When I use them hands to pick up the grippable static mesh gun_base in the template, the gun orients perfectly! To be more specific, the position is just a little bit off, but it's off identically so for each hand, which I assume means it's because the pivot point on my hand is not the same as that on the mannequin hands in the template. That's totally cool. The important thing here is that they are angled/oriented perfectly regardless of the hand I grab it with; the gun always faces forward exactly at the same angle.
I'm not getting this same, exactly mirrored orientation on my own grippable static mesh and 2 grippable skeletal meshes though. The static mesh's orientation is perfectly mirrored along UE4's Y, but its location isn't if I move the socket's Y position (it'll be distanced good from one hand but not the other).
The skeletal meshes are more effed. I spent about 6 hours today mucking with the root's roll of the 2 skeletal items, tried orienting the entire armature in the exact same direction as that of the GunBase mesh (facing down -Y in Blender, +X in UE4) but still no luck.
Anyone familiar with Blender/UE4 reimporting know how to fix this? I think it's likely a roll or root/armature rotation problem, but I'm not sure. I do know for a fact though, that reimporting fbx in some cases doesn't implement all changes between the fbxs (specifically in regards to Anims, possibly armatures too I'd suspect).
The Static Grippable Mesh position prob is maybe because the origin/pivot is off from. I'm away from the work computer for the weekend (Japan time). I'll be able to try any other solutions 2.5 days from now.Last edited by kusogaki77; 06-16-2017, 10:35 AM.
Comment
-
Originally posted by kusogaki77 View PostSorry to sidetrack this.
I got a socket prob.
tl;dr
Custom Static/Skeletal Grippable Mesh actors aren't oriented/positioned exactly mirrored in each hand, but the Template Gun_Base is.
What things might I need to make sure are good?
I have custom-made hands, and equippable items (all made in Blender). When I use them hands to pick up the grippable static mesh gun_base in the template, the gun orients perfectly! To be more specific, the position is just a little bit off, but it's off identically so for each hand, which I assume means it's because the pivot point on my hand is not the same as that on the mannequin hands in the template. That's totally cool. The important thing here is that they are angled/oriented perfectly regardless of the hand I grab it with; the gun always faces forward exactly at the same angle.
I'm not getting this same, exactly mirrored orientation on my own grippable static mesh and 2 grippable skeletal meshes though. The static mesh's orientation is perfectly mirrored along UE4's Y, but its location isn't if I move the socket's Y position (it'll be distanced good from one hand but not the other).
The skeletal meshes are more effed. I spent about 6 hours today mucking with the root's roll of the 2 skeletal items, tried orienting the entire armature in the exact same direction as that of the GunBase mesh (facing down -Y in Blender, +X in UE4) but still no luck.
Anyone familiar with Blender/UE4 reimporting know how to fix this? I think it's likely a roll or root/armature rotation problem, but I'm not sure. I do know for a fact though, that reimporting fbx in some cases doesn't implement all changes between the fbxs (specifically in regards to Anims, possibly armatures too I'd suspect).
The Static Grippable Mesh position prob is maybe because the origin/pivot is off from. I'm away from the work computer for the weekend (Japan time). I'll be able to try any other solutions 2.5 days from now.
As for skeletal meshes and root bones, due to a bug with physically simulating objects and root bones I have to add the root bones extra rotation into physics grips to support objects with a rotated root (the engine does not account for this and the object will be orientated incorrectly otherwise). It may be that Epic finally fixed this and I was unaware of it but you seem to be saying that the preview of the mesh is incorrect not the gripping of it for this.
If you get a chance and want to pass me a PM with one of the problem Static and problem Skeletal meshes I could look at them.
The whole point of how I handle it currently is to avoid requiring people to orient meshes a specific way in order to work with the plugin.
Originally posted by tiagovignatti View PostIt's the only practical and viable way I see for developers collaborate to the plugin. I absolutely support this idea!
*Edit* I guess they could still implement them in blueprint as well if they wanted custom ones, and I could leave the current blueprint versions intact.Last edited by mordentral; 06-16-2017, 11:09 AM.
Consider supporting me on patreon
My Open source tools and plugins
Advanced Sessions Plugin
VR Expansion Plugin
Comment
-
Originally posted by Starkium View PostOk I see teleportation and navigation are technically the same thing, but where are you doing the magic for the navigation part???
I ported some of the AIControllers navigation functions to the VRCharacter and setup client side navigation for VR (engine by default is server sided navigation only). If the movement mode is set to navigation when it ends the teleport arc it calls ExtendedSimpleMoveToLocation instead of teleport, its the SimpleMoveToLocation node with a few more features/options.
The out of body movement does the same thing except it also switches the camera during the movement part, I added a "NavigationEnded" event that fires when navigation ends (end of path, error, ect).
Consider supporting me on patreon
My Open source tools and plugins
Advanced Sessions Plugin
VR Expansion Plugin
Comment
-
Originally posted by Fantasifall View PostJust a reminder that you wanted to expose "Set Crouched Half Height" as this has not been implemented by Epic. Thanks!
Consider supporting me on patreon
My Open source tools and plugins
Advanced Sessions Plugin
VR Expansion Plugin
Comment
-
Originally posted by Haircut View PostThe low gravity mode feels amazing. Thanks again for making this so accessible!
Pushed a new commit to the plugin, this is a few days worth of changes and sadly will cause c++ users to make a change (GripInterface has a new function).
I intend to leave it as is for awhile for bug fixes with movements and grips due to some sweeping changes made here, during this down time from the major
systems I will likely be converting the interactible components from blueprint to c++ and making them cleaner (the button already saw considerable cleanup
recently in blueprint).
Post the interactibles conversion I would like to get to some of the feature requests. The Force constraint setting was actually a feature request, I implemented it first
due to being close to another one of my wishlist items already.
Plugin changes
Code:Added advanced physics settings for the interface, by default they are turned off however when turned on they can be used to change constraint settings beyond the normal acceleration based with stiffness/damping for angular being auto calculated. One use would be to change it from an Acceleration based constraint to a force based one. This would create better behavior with manipulation grips in some scenarios as well as offer a method of delayed / weight simulated grips (would likely need the custom angular stiffness and damping set then as force values for these are far higher than acceleration values). I have plans to add more features to the advanced settings in the future. When deactivated the additional grip property costs 1 bit to replicate. When activated the replication cost is dependent on what in it has been enabled. I have been wanting to expose the physics settings more to the user and this is probably the best way to do it (Like auto center of mass setting on grip). I would love to merge the normal stiffness and damping into the same structure but it would break many projects so it may never happen. C++ Actors/Components using the interface will need to implement the new getting function for the advanced physics settings (if ever merged it would replace the separate stiffness and damping functions instead). Now using a nearly check for better precision safety when checking for replicated changes for stiffness and damping. Added optional angular stiffness / damping setting to the SetGripConstraint blueprint function Added visual and editable indicators to grip interface settings that are controlled by a boolean (IsInteractible / UseAdvancedPhysicsSettings). To make it easier to work with them. Made some WalkingCollision override changes to be more reliable and consistent as well as use more custom logic and less hackish workarounds. Will need feedback on how it behaves now. New ClimbingStepUp fixes (for VR Char only ATM) appear to help a ton with step up issues. Adds a configurable variable to the StepUp settings that sets a seperate threshold for when a capsule is considered within stepup range making it significantly harder to accidentally fall back off backwards when stepping up. Should not be increased beyond the radius of the capsule (is noted as such on the variable comment).
Consider supporting me on patreon
My Open source tools and plugins
Advanced Sessions Plugin
VR Expansion Plugin
Comment
-
Hello,
(I'm running a version of the plugin from a couple weeks ago.) I opted to convert all of my user equippable items into grippable skeletal/static meshes so to retain all those checks and balances mordentral implemented.
tl;dr
2 Questions:
① Is it OK to consolidate the Grip Enum (Hand_State_Left/Right) with my custom one? Afaik, it looks like that Enum is only used for the Hand Blendspace1D.
② I want to change the gripping controls such that climbing is enabled when pressing triggers while hands are Empty, and those special Equipment Grip Interface objects I made are equipped/Unequipped by pressing Thumpad face button 1/3 (respectively). In order to accomplish this, would it be best to do separate grip checks (each of which are modified checks based on all the logic in the GripOrDrop flow) for all of those buttons? (Once an item is equipped, I have that actor do all the trigger_value and grip pressed checks in order to execute item-specific behavior)
Currently, gripping/ungripping in the Vive_Pawn is based (solely?) on the triggers. I want to change those gripping controls a bit without getting rid of those C&Bs, but I'm a bit lost on how I should go about it.
My VR_char has 4 things parented to holsters on different parts of the body (RR-style).
I want to accomplish the following 3 things, but I'm afraid I'll mess up the current Checks that are already in place.
①Enable gripping&climbing only if Trigger is pressed while hand is Open.
(This works perfectly currently, using the default grip logic, but it conflicts/overlaps with the 2 things I want to do below)
②Equip holstered item if Face Button 1 is pressed & Hand_State is Open & Grab Sphere collision is overlapping & Item_Type == Empty.
lerp its pos/rot back to the calling hand's socket, set Hand_State is Grab & Hand Item_Type = <itemtype>
③Unequip item if Face Button 3 is pressed & Hand_State is Grab & Hand Item_Type != Empty
Then lerp its position back to its holster, set Hand_State is Open & Hand Item_Type = Empty
(The reason why I want equip/unequip on the thumbpad is so I can use the trigger and grips for item-specific actions when an item is equipped.)
I gave each Equippable item an Equipment interface that just monitors its respective Equipment's Holster position/ID and sets the respective hand Item_Type; this is so I can play item-specific grab animations)Last edited by kusokuso1; 06-21-2017, 03:17 AM.
Comment
-
Originally posted by kusokuso1 View PostHello,
(I'm running a version of the plugin from a couple weeks ago.) I opted to convert all of my user equippable items into grippable skeletal/static meshes so to retain all those checks and balances mordentral implemented.
tl;dr
2 Questions:
① Is it OK to consolidate the Grip Enum (Hand_State_Left/Right) with my custom one? Afaik, it looks like that Enum is only used for the Hand Blendspace1D.
Do whatever you want with those, those are just epics template hands, they don't have anything to do with the plugin and so they shouldn't receive any changes from me.
② I want to change the gripping controls such that climbing is enabled when pressing triggers while hands are Empty, and those special Equipment Grip Interface objects I made are equipped/Unequipped by pressing Thumpad face button 1/3 (respectively). In order to accomplish this, would it be best to do separate grip checks (each of which are modified checks based on all the logic in the GripOrDrop flow) for all of those buttons? (Once an item is equipped, I have that actor do all the trigger_value and grip pressed checks in order to execute item-specific behavior)
I don't know how you intend the specialty items to work, if they block normal interactions when active then you can just insert logic for them prior to the normal gripping code, this way they are handled if active and if not then it falls back to the normal gripping and climbing logic.
Currently, gripping/ungripping in the Vive_Pawn is based (solely?) on the triggers. I want to change those gripping controls a bit without getting rid of those C&Bs, but I'm a bit lost on how I should go about it.
My VR_char has 4 things parented to holsters on different parts of the body (RR-style).
I want to accomplish the following 3 things, but I'm afraid I'll mess up the current Checks that are already in place.
①Enable gripping&climbing only if Trigger is pressed while hand is Open.
(This works perfectly currently, using the default grip logic, but it conflicts/overlaps with the 2 things I want to do below)
②Equip holstered item if Face Button 1 is pressed & Hand_State is Open & Grab Sphere collision is overlapping & Item_Type == Empty.
lerp its pos/rot back to the calling hand's socket, set Hand_State is Grab & Hand Item_Type = <itemtype>
③Unequip item if Face Button 3 is pressed & Hand_State is Grab & Hand Item_Type != Empty
Then lerp its position back to its holster, set Hand_State is Open & Hand Item_Type = Empty
(The reason why I want equip/unequip on the thumbpad is so I can use the trigger and grips for item-specific actions when an item is equipped.)
I gave each Equippable item an Equipment interface that just monitors its respective Equipment's Holster position/ID and sets the respective hand Item_Type; this is so I can play item-specific grab animations)
I set up the button mappings in the input settings, you can feel free to change what goes to them, or directly link new logic instead. You won't be able to do anything super custom with the template without deleting and refactoring a bit, its just the nature of the beast. Even if I consolidate every little bit of the logic into functions that you can just call from subclassed characters there will still be instances where its not going to work with something special you are doing, the template isn't gospel, it is supposed to be an example of how to set up things, there is a lot in it that you can likely remove and the gripping logic is based around just pick/place/use interactions.
If you have really custom button mapping that you wish to use then you'll want to copy the VRCharacter and work off of the copy instead of the original or a subclass. Then you can delete and rework as you wish without losing your references, it will also let you compare with future examples.
Consider supporting me on patreon
My Open source tools and plugins
Advanced Sessions Plugin
VR Expansion Plugin
Comment
Comment