I was able to implement a pick up an drop item system by attaching the object to the player’s hand socket. But the issue is that I have to give the object a location to drop to and since I’m basing it on the camera’s direction vector, the object can end up either floating in the air or merge into the ground.
The way I want the dropping system to work is that it takes the player camera’s forward direction and drops the object at the tip of the forward vector’s head. However, instead of it locking into the 3D location, I want the item to ‘fall down’ in the z-axis and rest on whatever solid surface lies below it. And it should be a quick snap to the surface, rather than a slow drop due to gravity.
Is there a way that I can implement the object to snap down to any solid surface below it once it gets the location of the head of the player camera’s forward vector? Ik how to implement the latter but just not the former.
Thank you! (sorry if the wording of the question doesn’t make sense, I can try to rephrase it better if you want me to)
I want the item to ‘fall down’ in the
z-axis and rest on whatever solid
surface lies below it. And it should
be a quick snap to the surface, rather
than a slow drop due to gravity. Is
there a way that I can implement the
object to snap down to any solid
surface below it once it gets the
location of the head of the player
camera’s forward vector?
Trace down from the held object until you hit the ground, storing the hit location. When you’re ready to drop, stop tracing and start interpolating during Tick from object’s location to stored location, moving the object along the way. Once the location is reached, terminate the Tick.
Timeline is not really suitable for this as the distance from the object to the ground will vary and that would require you to additionally calculate play ratios if you want to maintain same drop speed across various objects.
One thing this does not account for is how steep the resting surface is - the objects may end up resting in precarious spots.
Beat me to it.
you would run a line trace. start location is the camera’s forward vector * vector length + camera location. end location is the start location minus a few hundred units on the z value. the hit result is the ground location, depending on where the actor’s origin point is you may need to offset it a bit back up on the z.
there’s a video on a similarish system over here.
you could also evaluate how level the surface is by taking the dot product of the hit result normal and 0,0,1. if you didn’t want to drop it on a steep incline.
How do I get the new location from the LineTraceByChannel function? do I break result and take Location?
Thanks that worked! But I have one last issue: how do I prevent vectors from going through actors?
The issue that I ended up running through is that if I stand right in front of a wall, the item I drop is placed on the other side. How can I tell it that the forward vector of the camera cannot hit or interfere with another object?
So in that scenario, the object would drop at the player’s feet if there is no room in front of the player (if the player stood in front of a wall for example) ?
yeah, if you do a line trace location and impact point are the same. if you do a sphere trace the location is the center of the sphere, while the impact point is the surface of the sphere that is touching whatever was hit.
I didn’t think about that… but it’s an fairly easy fix.
before you do the line trace to the ground you will need to do a spheretrace from the camera out along it’s forward vector.
So the start is the camera location, and the end is camera’s forward vector * vector length + camera location.
The sphere radius should be about the same size as the pickup actor.
then you would do the ‘to ground’ line trace.
I would set it up like this. if the spheretrace doesn’t hit anything linetrace from the end of the trace to the ground. if the spheretrace does hit something linetrace from the hit location to the ground.
optionally, you could also add a branch check to see if the distance of the spheretrace is higher than some value. just so it doesn’t release if your too close the a wall.
Thats exactly what I had in mind, adding more linetraces to check if there is an object blocking from the front then from below.
But I have to ask why use spheretracing rather than line trace?
the spheretrace hit location will be offset a bit from wall. whereas a linetrace will hit result will be against the wall, so when you linetrace down the end location will be too close to the floor/wall corner.
if you want to visualize this you can add a couple arrow components to your bp, uncheck hidden in game and set location to absolute, set to different colors. then after you fire the sphere trace set their world locations. one to the impact point and the other to the location.
I’m adding a pic of where you can change the location to world/absolute. basically it stops the components from inheriting their position from their parent.
Although your suggestion sounds perfect, its not working well with me. When I put the radius of the spheretrace to 10, the object moves a bit to the right. When I put a radius of more than 20, it completely shifts the object to the right and places it on the floor.
I have here screenshots of my blueprint and how I’ve set it up, I just don’t know what’s causing that offset to the right.
I’m not sure what’s wrong in your bp. It may have something to do with the normalizing a position vector, I haven’t used normalize that way so it looks odd to me.
the traces should look something like this.
you could also do it with a line trace and add an offset based on the normal. gives you a slightly different position, not sure if it’ll feel closer to the expected location.
there may be edge cases where it tries to offset the location from a wall but then another obstacle gets in the way like in a narrow alleyway. I’m not sure the best way to deal with that. maybe another line trace for the normal offset, and spawn a invisible version of the pickup mesh to the end location check for overlaps and then destroy.
Thank you so much! the first suggestion solved the problem! And did I misunderstand the use of normalization? I thought it just turns a vector into a direction with a magnitude of 1 no ?
But I seriously cannot thank you for the time and effort that you’ve put to help me out!
Edit: It turns out that the addition of the 500 units in the z-direction made it that we don’t need a linetrace if the sphere trace didnt hit anything because the spheretrace range is so large it hits the ground when we look down. Would it then be a good idea to omit the function “DropObjectAhead” and keep the 500 units long spheretracing as the default ?