There seems to be an issue when i am using VR. The movement I make is not scaled correctly with the movement in the VR. I have to move much further in reality to go where I need to in VR. I am working on the reach with the OVRgrabbable script after finding something online that may help. I am having an issue with getting the X,Y axis to be recognized as objects. Everything else about the code seems to be ok as nothing else is underlined in red.
This image is the notif. i am getting. I am just referencing the x and y axis i think it should operate just fine
I have one suggestion, on the OVRCustomHand.prefab check the configurations on the script OVRCustomSkeleton.cs:
Make sure to check the checkboxes for Update Root Pose (only if your OVRHandPrefab is not parented to OVRCameraRig), Update Root Scale (makes the hand model size is scaled either up or down based on the user’s actual hand size), Apply Bone Translation.
This will make sure the Hand's position is referenced to your scene's global space instead of real tracking space.
Hope it works!
Related
My script is running fine and had been showing the game up in play mode (but not in scene view) up until I finished the script and now it has disappeared and I can't seem to find it in either.
I made sure I was in orthographic view, tried messing with the near and far values of the clipping planes in the main camera and made sure all assets in the scene including the gameobject housing the script were positioned at 0 on all axis. I can't find it at all anymore, aside from when pressing pause in play mode but then I can't test the interactions.
This is what I see when I enter play mode
This is what I see when I hit pause
it's supposed to be shuffled at the beginning so that part seems right as it is a different order every time I try this
Move the camera back 10 units on the z. Cameras have a view frustum, where elements outside it won't render. This is what is happening here. With the near plane set to 0.3, you need to move the camera away from an object by 0.3 units. The default z value is -10 on the camera.
https://docs.unity3d.com/ScriptReference/Camera-nearClipPlane.html
I've create a movement script that moves a character (ship) in a topdown view.
Gravity is disabled, but the rest of the settings i left mostly alone.
I'm applying a constant force in the forward or backward direction (local, so relative to the character NOT the world). This however causes some movement in other directions if the character is rotated for some reason.
Debug.Log(nameof(force) + force);
rigidBody2D.AddRelativeForce(force);
Lets me explain with pictures.
Starting point:
Moving forward somewhat (works okay):
Back to starting point (stopping game, starting anew)
And then i manually change the rotation to -90 in the inspector.
I then move forward somewhat.
As we can see since the rotation is -90, moving forward in relative to the character (AddRelativeForce(..)) causes it to move to the right on the screen.
The X position increments accordingly.
However, also the Y component changes, the character gets velocity in this direction, even though i apply no force in that direction - which we can see in the output.
How can I move my character with force without this issue?
Edit:
Here are the project files. Runs under the latest unity 2020.1.14f1. The logic mentioned here is located in MoveExecuteSystem. I use a small ECS framework: https://github.com/Leopotam/ecs
https://wetransfer.com/downloads/b86dfb27b4388b85ac4fef285d87b39520201124193329/00af66
Take into account that AddRealtiveForce adds the force in the local coords system. If the force vector has got always the same value, the outcome is going to be different depending on the rotational position of the entity.
To solve this, you need to apply the force such as: Vector3 force = myShip.forward * forceValue where force value can be an int or a float.
It can be myShip.up or myShip.right depending on what you want. My point is that with the .forward, .up or .right you always will apply the force according to the instant local coordinate system rotational position.
EDIT:
This question seems deeper than I thought, I made the trial in a project myself, and actually there are variations in the position when you apply force only when the object is rotated. Had a quick look and don't know why this is. Seem to be a precisión thinh regarding the rotations of the physics the rigidbody uses under the hood.
I tried to remove the friction which I thought might be also cause of the problem but seems not possible. +1 to this question and lookig forward to know the answer.
EDIT2:
Bounciness and friction can be set to 0 if a new physics material 2d is created, but the issue persists.
You can freeze position in determined axis as a solution, but this does not explain the position variation problem.
I have made a smoke particle effect that I instantiate everytime the player shoots, its working but can not be seen with the background. If I delete the background it's visible, I've tried changing the ordering layer, creating a new layer and putting it above the default, but no matter what it's still below the background. Any ideas?
Assuming you are developping a 2D game, you can use the z axis to set the distance of the elements to the camera (what will be the equivalent to the order of render)
Usually in a 2D game you will have the main camera at -10 in the z axis. So moving in the inspector the backgroun to, lets say z=5 or z=10, and keeping in you particle system in z=0 should solve your problem.
Try this easy trick and let me know if you are still facing problems.
You can check the second half of this video for a better understanding
Also, if you are making a 3D game you can go to the material of the particles and make sure that render face is set to both. I just had that problem and it was annoying me. but that fixed it.
I'm using an Oculus Rift with Unity, and am attempting to allow the user to zero-out the orientation of their device when they push a key. The idea is that the camera is frozen looking in a particular direction, and when the user begins the game, whatever direction they're looking in is bound to that camera orientation. I found this forum post, but it only says to use SetOrientationOffset, but doesn't provide code.
I've tried both of the following, independent and together:
OVRDevice.ResetOrientation ();
cameraController.SetOrientationOffset (Quaternion.identity);
However, neither seems to have an effect. I've even tried passing other quaternions into SetOrientationOffset, but that seemed to have no effect.
Does anyone have a working code example?
If different quaternions make no difference then you probably have a game object set in the FollowOrientation variable. If you clear that then passing in different quaternions should have an effect. Alternatively you can rotate the thing you've set in FollowOrientation. Then you need to find the correct orientation to start in. Probably the rotation of the frozen camera is what you need.
I am writting a collision detection engine for my game and I have some problems.
Indeed, since I have several fixed rectangle and one moving (the player), I need to know which side of the fixed one was collided at first by the player, to replace him correctly.
The fixed rectangle are NOT in a grid so they can be placed anywhere on the map and they can have diffents size. They are not rotated.
The player class stores it's direction vector.
Any idea?
KiTe
In a nutshell:
You'll compare the Y and X components of the bounding rectangles to eachother to check for a collision. If the top(Y) of the player is less than the bottom of an enemy then you don't need to check anymore because it's not possible that they're colliding. If the right(X) side of the player is less than the left side of the enemy then they can't be colliding. It would help to define top, right, bottom, left of each object you intend to check inside the class. This will allow you to know which side is hit also. This should be enough to get you thinking and experimenting.
Have fun!
The name is "Axis-Aligned Bounding Box" collision detection.
Now you know the name, you can Google for the rest.
thanks to both of you for your help.
I've heard about AABB, but at first sight it didnt seem to fit to my needs (since I didn't understand it well).
But after writing down everything on papper, the solution I found appeared to be exactly the same as AABB !