I am using Xbox-Unity and am trying to make a Kinect game. I need to be able to know when a player's foot is in the air and when it comes back down on the ground. I thought that this would be as simple as tracking the Joint Positions but the foot's Y changes based on the proximity to the Kinect Camera (Taking the foot joint position from Kinect). If I lifted my left foot up far away from the camera, it's Y would be high(let's say 10). If it were to land close to the camera, the Y would be low(let's say -20). What I had hoped was that I could just say 0 is the floor and have an easy time knowing when a foot was in the air and when it was on the ground. Does anybody have any ideas on how I can correctly tell when a foot is grounded?(everything I can think of so far had at least one exception that would make the gameplay broken)
Edit: Used a point to plane equation but no matter what I do, the distance to floor is always different based on my proximity to the camera.
One possibility would be to compare it to the other foot.. if one is higher than the other, chances are they're standing on the other foot. If you're looking to detect jumps, you should be able to find a sudden change in the y position of both feet.
There's also the Floor Clipping Plane, but that involves some more complicated math from what I've seen. Check out the Kinect programming guide, which is super old but I think should still be relevant here. The section "Floor Determination" is what you're after.
Related
So i am making a simple Golf game, when trying to replicate the balls movement i have noticed that on slopes the ball functions very oddly, it either never stops or stops too quickly and when travelling down slopes will reach a very slow terminal velocity quickly (ie it stops accelerating down slopes). So it either doesnt deaccelerate enough going up a slope or accelerates too slowly going down a slope.
I have been messing about with angular and static Friction of both the ball and the surface to see if that changes it at all and i have also been changing the friction combine of the surface and the ball to see if that makes any difference and so far haven't had any luck.
Is this a common issue with Unity because i haven't been able to find any other questions about it on here. If anyone could give me some advice on how to have my ball not roll forever but still accelerate when going down a slope that would be great
EDIT: The ball has a rigidbody with continous collision, then the course uses a mesh collider. Both however have attached physics materials
The ball is currently just a basic sphere from unity using a sphere collider, i havent tried changing the rigidbody about much yet other than mass. When the ball is hit i addforce to it, the slopes are an asset i have purchased that are perfectly smooth.
Rolling object physics are indeed difficult in game engines.
As I mention in the comment for such questions it's necessary to know (a) what sort of collider and (b) what sort of object it is, since there are at least 4 major approaches to this problem.
But in general you usually have to manually add the "slowing down" function, in a sense representing air resistance.
For a moment set aside the collider choices, and imagine in the abstract you have a ball rolling along a flat plane. You've somehow started it moving at 2 m/s say.
There's really no reason at all it will stop rolling or slow down. Why would it? There's no air resistance in physX and what you "want" it to do in the game engine physics is keep rolling.
Thus what you do is add a script that, essentially, "slows it down a little" every frame. In pseudocode, something like
velocity = 0.99 * velocity
Note however that alternately, to "manually slow it down", you may have to simply add force to it.
The trick is you do that in the opposite direction to movement
yourBalls.addForce( v.normalized * -1 * some small force )
(It's easy to think of that as basically "air resistance")
You usually also, simply, just add a top speed. In this way on downslopes it won't just get "infinitely fast"
if (v.magnitude > 3.0) v = v.normalized * 3.0
That's basically how you make objects roll around on hilly surfaces.
Note that you basically should not fool with the friction settings in anyway, it's really not relevant in most cases.
Unfortunately there is a vast amount of detail but, I feel your question is more asking for the "basic principles" - and there they are!
Tip: it could be this question is more suited to the gameDev site, where "techniques" of game physics are QA'd.
I am trying to measure distance between multiple positions but I do not want the rotation to affect the distance. In concept, I want to track the starting transform and upon each update track the distance traveled without regard to the change in rotation. I am using an HTC Vive controller and people tend to rotate their hands and I want to control for this.
I've tried resetting the Eular Angles, but this doesn't seem to work.
Adding an Analogy that will certainly help.
Think of it like trying to draw and measure a line with a pencil, the position is in the eraser, and I can hold the pencil in any number of ways and in fact change the position in the middle of drawing the line, but my line will remain straight and the measurement will remain accurate.
Any help is appreciated.
I believe your problem lies around the position you are tracking. It sounds like you are tracking the transform.position of one of the child elements of the Vive controller model, leading to the situation that you're describing with the pencil eraser analogy.
Depending on where your script is attached, you could either move this to the top level element of the Vive controller, or alter your script to instead track transform.parent.position, which shouldn't be affected by the rotations of someone's hand.
everyone
I am just starting with a new project in VR and have some problems.
I want to simulate a simple 3D-Ball like the real one in real world.
I am using OptiTrack to register my camera( 3d glasses) and Middle VR(free edition) to realize the 3D effect in 3D room. And also Unity for 3D models and programming with C#.
My Problem:
I have a real plastic ball and use it to compare with that 3D-Ball. If i go to the real ball in (real world) it will be bigger and if i go away from it, it will be smaller visually.
The 3d ball has the same diameter as the real one and stand at the same position. But if i go to ihm with 3d glasses it will be (quicker) bigger than the one in real world and if i go away from it, it will quick smaller than the real one...
Can anyone explain to me, how to solve the problem, what should i do. I need your help.
Thank you and have a nice day.
Carvin.
Get the size right inside unity. 1 unit in unity is 1 meter in real life.
Also play with the field of view of your maincamera in unity to get the desired result
I want to make this phone app that can measure distance. I want to know how far away something is from the phone. So let's say I want to know how far away a wall is...I'd like my phone to tell me.
So how might this work? Well, I can shine an ordinary red laser pointer against the wall (in the dark) and have the phone's camera "see" the dot.
The further away the phone is from the dot, the smaller the dot will be. The picture below shows the dot from 1 foot, 5 feet, 10 feet, 20 feet, and 25 feet away. I think the app could then measure the size of the dot and figure out how far away the dot actually is from the phone. And then it could use a simple ratio or formula to determine distance for other sizes.
So my question is: Would this likely work for measuring distance?
As long as you can clearly identify the laser dot I would say:Yes. I'm seeing the problem in doing the identifying.
The distance measuring is just some maths and physics stuff (I'm not sure what to use but I think there is maybe some useful optics stuff... intercept theorem?) or you can create an "algorithm" by testing(but then accuracy could be a problem ;))
So, I think the dual laser pointer idea is superior to the single laser pointer idea.
But, because the camera is moving further and further away from the wall, I believe angling the laser pointers is a non-solution.
Instead, I think keeping the laser pointers in parallel is the solution. This way, the further back you go, the beams will look closer and closer together in the photo, but they will still remain the same distance apart. Then you can easily come up with some formula to measure the distance based on how far apart the dots are in the photo.
I'm working on an iPhone app for motorcyclist that will detect a crash after it has occurred. Currently we're in the data acquisition process and plotting graphs and looking at data. What i need to log is the forward user acceleration and tilt angle of the bike relative to bike standing upright on the road. I can get the user acceleration vector, i.e. the forward direction the rider is heading by sqrt of the x,y and z accelerometer values squared. But for the tilt angle i need a reference that is constant, so i thought lets use the gravity vector. Now, i realize that deviceMotion API has gravity and user acceleration values, where do these values come from and what do they mean? If i take the sqrt of the x,y and z squared components of the gravity will that always give me my up direct? How can i use that to find the tilt angle of the bike relative to an upright bike on the road? Thanks.
Setting aside "whiy" do this...
You need a very low-pass filter. So once the phone is put wherever-it-rides on the bike, you'll have various accelerations from maneuvers and the accel from gravity ever present in the background. That gives you an on-going vector for "down", and you can then interpret the accel data in that context... Fwd accel would tip the bike opposite of braking, so I think you could sort out fwd direction in real time too.
Very interesting idea.
Assuming that it's not a "joke question" you will need a reference point to compare with i.e. the position taken when the user clicks "starting". Then you can use cos(currentGravity.z / |referenceGravity|) with |referenceGravity| == 1 because Core Motion measures accelerations in g.
But to be honest there are a couple of problems for instance:
The device has to be in a fixed position when taking the reference frame, if you put it in a pocket and it's just moving a little bit inside, your measurement is rubbish
Hmm, the driver is dead but device is alive? Chances are good that the iPhone won't survive as well
If an app goes to the background Core Motion falls asleep and stops delivering values
It has to be an inhouse app because forget about getting approval for the app store
Or did we misunderstand you and it's just a game?
Since this is not a joke.
I would like to address the point of mount issue. How to interpret the data depends largely on how the iPhone is positioned. Some issues might not be apparent to those that don't actually ride motorcycles.
Particularly when it comes to going around curves/corners. In low speed turns the motorcycle leans but the rider does not or just leans slightly. In higher speed turns both the rider and the motorcycle lean. This could present an issue if not addressed. I won't cover all scenarios but..
For example, most modern textile motorcycle jackets have a cell phone pocket just inside on the left. If the user were to put there phone in this pocket, you could expect to see only 'accelerating' & 'braking'(~z) acceleration. In this scenario you would expect to almost never see significant amounts of side to side (~x) acceleration because the rider leans proportionally into the g-force of the turn. So while going around a curve one would expect to see an increase in (y)down from it's general 1g state. So essentially the riders torso is indexed to gravity as far as (x) measurements go.
If the device were mounted to the bike you would have to adjust for what you would expect to see given that mounting point.
As far as the heuristics of the algorithm to detect a crash go, that is very hard to define. Some crashes are like you see on television, bike flips ripping into a million pieces, that crash should be extremely easy to detect, Huh 3gs measured up... Crash! But what about simple downs?(bike lays on it's side, oops, rider gets up, picks up bike rides away) They might occur without any particularly remarkable g-forces.(with the exception of about 1g left or right on the x axis)
A couple more suggestions:
Sensitivity adjustment, maybe even with some sort of learn mode (where the user puts the device in this mode and rides, the device then records/learns average riding for that user)
An "I've stopped" or similar button; maybe the rider didn't crash, maybe he/she just broke down, it does happen and since you have some sort of ad-hoc network setup it should be easy to spread the news.