Announcement
Collapse
No announcement yet.
[Video] Physics Programmers  Help :(
Collapse
X

TheJamsh repliedOriginally posted by dev100000 View Postnot sure if you already consider it, but the dot product can not distinguish between eg 170deg to 180deg and 190deg to 170deg. Both give the same dot product. So by default the dot product is only good up to 180deg. At higher angles say 190deg you get a disambiguity.
If you pass the 180deg mark with your vehicle, then you have to create a 'if pass 180, then make 360deg minus the dot product result' logic to actually achieve for example 190degs.
Leave a comment:

dev100000 repliednot sure if you already consider it, but the dot product can not distinguish between eg 170deg to 180deg and 190deg to 170deg. Both give the same dot product. So by default the dot product is only good up to 180deg. At higher angles say 190deg you get a disambiguity.
If you pass the 180deg mark with your vehicle, then you have to create a 'if pass 180, then make 360deg minus the dot product result' logic to actually achieve for example 190degs.Last edited by dev100000; 01082015, 04:35 PM.
Leave a comment:

TheJamsh repliedI DID IT. You have no idea how happy I am. I hope this post helps anybody meeting this issue in future!
A few problems with my old method, was that I was trying to generate my normal axes from three cross products, but actually i only need two, one for the 'Uprightness', and then another to force the orthogonality (Direction). Using a 'Make Rot From ZY', this enabled me to get the rotation in worldspace of the normal impact, and then rotate it locally according to the Vehicles rotation, thusly:
So using this, I can forcibly set the worldrotation of my object, and add local rotation on the ZAxis. The object will then align itself correctly to the surface and it can rotate around the arbitrary Zaxis. This would be fine if I was using Rotators directly to 'set' the rotation, but naturally I had to push the boat out and use physics to drive it, by setting angular velocity directly (as opposed to torque).
Following the psuedocode example above, I can work out the required 'strength' AND direction of the force properly, doing this. The key stage is the 'Unrotate Vector', that prevents it from being worldrotation dependant and again allows it to rotate around an arbitrary axis. As a massive bonus, it makes sure that the craft can't ever settle when it's upsidedown, and will forcibly stay upright! 'Nrm' is the same surface normal, and 'Rot' is the rotation I generated above!
Now... to C++!
Leave a comment:

TheJamsh repliedEDIT: Nope  Still have the ZRotation problem :@
Some Success! And thus the power and magic of blueprints was praised on that day...
Broke down the problem a little more on paper, and basically the problem I have is that the upvector of the normal alone isn't enough information to get the difference. The way to correctly get the difference in LOCAL space, is to compute the Right and Forward vectors of the normal (using crossproducts), and rotate them so that they align with the Zrotation of the object, in world space.
The result is arrows that follow the surface around, and you can then use those as a point of reference to calculate a difference from. In my case, I'm using a Dot product with the UpVector of the normal, to calculate just how much different there is between the craft and the up vector. The Dot Product can then be a simple multiplier for my selfrighting force.
Visualizing it with arrow components definitely helped, and the best part is that I'm still steering clear of rotators, so I avoid any gimballock errors at the same time, and flipping it upside down also causes a selfrighting behaviour too. Magic!
Test Blueprint (object rotates around it's own Z axis)
21825
The Math...
21826Last edited by TheJamsh; 01072015, 01:45 PM.
Leave a comment:

TheJamsh repliedOriginally posted by PenguinTD View Postinstead of one trace and calculate how much you should rotate and balance, how about doing 4 trace at each corner and apply force to them so they try to keep away from surface at specific distance?
It would be a simpler calculation and more robust for different terrain situations.
The singleline trace is based on a force atm similarly to how you said, but using a simple springphysics calculation.
Leave a comment:

PenguinTD repliedinstead of one trace and calculate how much you should rotate and balance, how about doing 4 trace at each corner and apply force to them so they try to keep away from surface at specific distance?
It would be a simpler calculation and more robust for different terrain situations.
Leave a comment:

Kashaar repliedOriginally posted by TheJamsh View PostThanks Sinoth for looking,
The XYZ of the model is okay, it's the root component of the actor and there aren't any other components inside the version you're seeing in the video (it's just a static mesh), so it doesn't seem to be a modelrelated issue. When converting Angular Velocity to local space (and then back again at the very end of the function when it's set on the mesh), I've tried both 'RotateVector' (using the meshes world rotation), and the 'Inverse Vector Transform Location / Direction' in code, neither of which seem to fix the problem.
I think it might be something more to do with the maths of the way it's done. I'm using the DotProduct of the Surface Normal and the Vehicles Forward/Right vectors to work out the strength of the force, but at some point I think those vectors might flip in relation to something... not sure. I might have to switch to using a series of cross products or something. *Logically* it should work, I think.
Another thought, have you tried using a "Make Rot from ZX" (that's what it's called in BP) from the terrain normal and vehicle forward vector? That'll give you a rotation (which you can then convert to a vector) perpendicular to the detected terrain normal, pointing where the forward vector of the vehicle *should* go. Would that help at all?
Leave a comment:

TheJamsh repliedThanks Sinoth for looking,
The XYZ of the model is okay, it's the root component of the actor and there aren't any other components inside the version you're seeing in the video (it's just a static mesh), so it doesn't seem to be a modelrelated issue. When converting Angular Velocity to local space (and then back again at the very end of the function when it's set on the mesh), I've tried both 'RotateVector' (using the meshes world rotation), and the 'Inverse Vector Transform Location / Direction' in code, neither of which seem to fix the problem.
I think it might be something more to do with the maths of the way it's done. I'm using the DotProduct of the Surface Normal and the Vehicles Forward/Right vectors to work out the strength of the force, but at some point I think those vectors might flip in relation to something... not sure. I might have to switch to using a series of cross products or something. *Logically* it should work, I think.
Leave a comment:

sinoth repliedSorry I can't delve into it more deeply at the moment but it seems to me like one of your vectors is either in local where it should be world (or vise versa) or you have a vector somewhere that is rotated strange, like 90 degrees on Y axis or something. Have you tried adding an Arrow component to things to make sure your assumptions match reality? I would also make 100% sure the XYZ axis of the model matches what you think it is, as well as any components of the model you are applying forces to. Make sure there are no weird relative rotations.
Leave a comment:

Xenome repliedHard to say without handson experience, but I notice you're not doing any damping on alpha.y  is that intentional, or maybe the source of the problem?
Leave a comment:
Leave a comment: