Getting the axis pointing up in a rotation (Unity) - unity3d

I have an object in unity which has a rotation described as the following:
x, y, z, where they are both rotations ranging from 0 to 360 around their respective axis.
Now I'm trying to find out which of the vectors point up the most. Essentially I have a 6-sided dice, on which I use physics to emulate a dice-throw. I now want to find out which of the 6 faces of the die points upwards. I can imagine some rather advanced if sentences, revolving around checking the rotations individually, but I'd like to know if there is a good way to do this?

You can get the face directions with:
transform.up
-transform.up
transform.right
-transform.right
transform.forward
-transform.forward
You need to associate each direction with the appropriate face value. The side facing up will be the one with the greatest Dot Product vs Vector3.up (the world "up" direction). A dot product of 1 means a face is pointing directly up. Note that this only works because all the directions are unit vectors.
Vector3.Dot(Vector3.up, transform.up);
Given that it's only 6 (or 3 if you are clever) if statements to find the max that's probably the best way. If you are considering the general case, i.e. to support any die shape and number of faces, you could store a list of structs with a lambda expression denoting the face direction + the face value then use Linq Max().

You could, as you say, check the rotations directly manually.
Here's an alternative collider-based approach: put invisible children game objects with individual trigger colliders on each face of the die, then whenever one of them collides with the table surface, record the number of the opposite side of the face.

Related

Precision in onCollisionStart in flame with flutter

I'm attempting to write a bouncing ball game using flame in flutter. To detect collisions the onCollision and onCollisionStart methods are provided. What I had hoped is that onCollisionStart would give a precise location when two objects first hit each other. However, instead it gives a list of positions indicating where the two objects overlap after the first game-tick when this happens (i.e. onCollisionStart is called at the same time as onCollision, but is not called a second time if the same two objects are still colliding on the next tick).
This is illustrated in the attached picture. The collision points are marked with red dots. If the ball were moving downwards, then the ball would have hit the top of the rectangle and so should bounce upwards. However, if the ball were moving horizontally, then its first point of contact would have been the top left corner of the box, and the ball would bounce upwards and to the left.
If I want to work out correct angle that the ball should fly off, then I would need to do some clever calculations to work out the point that the ball first started hitting the other object (those calculations would depend on the precise shape of the other object). Is there some way to work out the point at which the two objects first started colliding? Thanks
What you usually need for this is the normal of the collision, but unfortunately we don't have that for the collision detection system yet.
We do have it in the raytracing system though, so what you could do is send out a ray and see how it will bounce and then just bounce the ball in the same way.
If you don't want to use raytracing I suggest that you calculate the direction of the ball, which you might already have, but if you don't you can just store the last position and subtract it from the current position.
After that you need to find the normals of the edges where the intersection points are.
Let's say the ball direction vector is v, and the two normal vectors are n1 and n2.
Calculate the dot product (this is build in to the vector_math library) of the ball direction vector and each of the normal vectors:
dot1 = v.dot(n1)
dot2 = v.dot(n2)
Compare the results of the dot products:
If dot1 > 0, n1 is facing the ball.
If dot2 > 0, n2 is facing the ball.
After that you can use v.reflect(nx) to get the direction where your ball should be going (where nx is the normal facing the ball).
Hopefully we'll have this built-in to Flame soon!

What is a "Break Rotator" and "Make Rotator" in Unreal Engine 4?

So, I am beginner in Unreal Engine 4. I am having trouble understanding "Make Rotator" and "Break Rotator" on Movement Input of the character blueprint class. The original definition UE4 documentation has made me even more confused. Can anyone explain this in a simple way?
A FRotator (or just Rotator in BP) is Unreal's way of storing rotations.
Usually, there are two main ways rotations are represented in programs:
As three separate rotation values per-axis, which is called Euler rotation: one for how much you rotate on X, one for Y, one for Z. This is the "older" approach, and has its issues, mainly gimbal lock. Also, there's no standard, and different programs apply them in different orders (some programs do ZXY: Z first, X second, Y third, but other do XYZ etc).
To solve the issues with Euler rotations, another option is used, with four separate values: three values denote the axis of rotation, and another one denotes the angle. This axis-and-angle value is called a quaternion (beacuse it has four values, quat is four in latin). Since any unique rotation mathematically can be expressed as an axis and angle, quaternion rotations are free of gimbal lock, and aren't dependent on any order.
Unreal internally uses quaternions (FQuat), but they're a bit harder to explain and understand, than just three X Y Z rotations. Because of that, FQuat is only for C++, and on the Blueprint level the editor simply shows the rotation as three axis. That's what the Rotator is for.
When you break a rotator, you just separate out the three float values for the XYZ rotations. When you make a rotator out of three float values, it makes the rotation that would result from them.
These break and make nodes exist for many other types, like FVector (shown in BP as just Vector), FLinearColor (Linear Color), to easily make a more complicated thing, like a color or rotation, out of simple float values.
Having said this, since the Rotator really represents an axis and angle, it's better not to use the make Rotator node, but the rotator from axis and angle node.
Rotators are quite convenient, because there are many functions in Unreal to work with them, such as Lerp (Rotator) and others.
Break Rotator : allows access to the elements of the rotator.
Make Rotator : Make a rotator with three values.

(UNITY) Plane not rotating to normal vector of three points?

I am trying to get a stretched out cube (which we can call a plane for the sake of discussion) to orient itself to the normal vector of a plane described by three points. I wrote a script to find the normal of three points, and then used transform.LookAt to have the planes align. However, I am finding that this script is not working at all how it is intended to and despite my best efforts I can not figure out why.
drastic movements of the individual points hardly effect the planes rotation.
the rotation of the object when using the existing points in the script should be 0,0,0 in the inspector. However, it is always off by a few degrees and as i said does not align itself when I move the points around.
This is the script. I can also post photos showing the behavior or share a small unity package
First of all Transform.LookAt takes a position as parameter, not a direction!
And then it
Rotates the transform so the forward vector points at worldPosition.
Doesn't sound like what you are trying to achieve.
If you want your object to look with its forward vector in the given normal direction (assuming you are calculating the normal correctly) then you could rather use Quaternion.LookRotation
transform.rotation = Quaternion.LookRotation(doNormal(cpit, cmit, ctht);
alternatively to this you can also simply assign the according vector directly like e.g.
transform.forward = doNormal(cpit, cmit, ctht);
or
transform.up = doNormal(cpit, cmit, ctht);
depending on your needs

Explanation of how to calculate transforms in Unity

I am getting started with Unity and am just trying to get my head around the units. What are these units? It seems they are their own 'quantity' and to treat 2 units as 2 times the value of 1 unit.
Anyway - I am trying to workout how to optimally calculate transforms to objects sit exactly where I want them to.
In my scene I have a terrain and a cylinder as so:
As you can see my cylinder is floating. I want the cylinder to sit perfectly on top of the terrain.
My terrain is at the following transform: 0,0,0 and scale 0,0,0 (not sure how to tell it's dimensions yet).
My cylinder is part of a new object, as so:
My FirstPersonPlayer is at transform: 85.9,2.165,51.8 and scale 1,1,1. My Cylinder is at 'localposition' 0,0,0 and local scale 1.2,1.8,1.2
Now - the transform of FirstPersonPlayer on the y axis appears to be what I need to correct.
Currently it is set to 2.165 and is floating a bit above the terrain.
Through manually shifting it, around 1.85 looks about right - but I want to know how to calculate that, rather than doing a finger in the air 'that looks about right'.
Can anyone help me? (Before you suggest using gravity etc , I actually am, but don't want the player falling as soon as they start, however slight that may look or feel.
Many thanks,
As per #Nikola Dimitroff the answer is:
You don't have to compute anything, hold Shift + Control and drag the object. Every game engine ever made calls this "Snap to Ground"
I appreciate and agree with the other comments.

Move 3d model forwards based on rotation

I have a 3d model in Xcode using SceneKit, that can rotate around itself, and i would like for it to move forwards based on rotation, for example if it is rotated 236 degrees in the z axis, it wouldn't go straight in x or y, but a bit of both so it would move forwards. Is it possible? Do i have to get any plugins?
No plugins required.
You can do this two main ways:
Move the object's position relative to its rotation by changing its "transform" over time.
Applying force (and/or impulses) over time (or instantly) in the direction you'd like your entity to travel.
Within these two approaches are a LOT of other considerations regarding scene size, resistance, speed, immediacy, etc.