I'm colliding with a normal perspective behavior.
In my 2.5D scenes where I use a background image in a 3D space I have to lift up and rotate the camera to give the right perspective to the 3D character.
Unfortunately, this kind of perspective causes the inclination of the character when it is on the sides of the screen.
In the many forums I visited I could not find anything about it.
Do you think that there are no solutions other than to work in an orthogonal projection and to attach a script to the character to resize it?
if your character should be visible like an 2D game element just change the Camera from Perspective to Orthogonal :) (the view height can than be adjusted with the size slider)
Related
I am working in Unity2D and have a character who can shoot in all directions. The game has mobile controls and the player will choose his shooting direction with a joystick on the right side.After testing I found it rather difficult to correctly determin where the shot is going to land at. To convey this to the player I wanted to add a sort of "shooting line of sight" to the player. It is moving around the player according to the joysticks position. (As seen in the picture)
Because I want the line to be pixelated (to match the design theme of the game) I cant use the standard LineRenderer component as it doesn't support such pixelated lines. So I started looking for solutions to this problem and stumbled upon Bresenham's line algorithm. After implementing it into the game I knew which x, y coordinates I had to fill with a pixel. Currently every single white pixel in this line is a GameObject with its own SpriteRenderer and a single white pixel as a sprite. In my test scenario up to 400 pixels where rendered at once. I am already using an object pooling system to minimize the performance drag. Moving this line around drops me from around 1100 Fps down to like 200 Fps in the editor. I know it will be slightly better in the build game but I am sure it will take a toll on older mobile devices when enemys, animations etc. are present in the level.
So my question is: Is there a better or more efficient way to render the sprites? Or (preferably) do you have a better idea on how to render this line at all without creating ~300+ GameObjects. (e.g. Shaders (Zero experience), drawing on a texture)
I am grateful for any ideas that lead me into the right direction.
I have a project that deals with AR, so I use ARFoundation in Unity. Everything works fine until I want to position my 3D object on the left of the screen. I tried many solutions but none of them work.
I try taking the width and height of the screen and alter them then set the position of my object to them but it didn't work.
What should I be doing?
Understanding the space you are working in is crucial.
Screen positions are a different dimension compared to the normal 3D you have in your scene. In order to exchange positions you need to use https://docs.unity3d.com/ScriptReference/Camera.WorldToScreenPoint.html and https://docs.unity3d.com/ScriptReference/Camera.ScreenToWorldPoint.html.
For example you can have a box that has its transform at 0.0.0 but depending on where you are looking at it and at what angle, it's transform stays the same but its *screen-position changes.
Using WorldToScreenPoint can tell you where the object from the scene is at your screen (2D), and ScreenToWorldPoint does the opposite (you give it 2D from you screen and it gives you that position in the 3D).
I'm trying to animate a hierarchy of 2D sprites (essentially body parts) by explicitly setting sprite positions at various key frames throughout a given animation clip. Unfortunately, Unity is implicitly changing all of the sprite positions using interpolation between key frames. This causes the sprites to look like they're sliding around rather than immediately transitioning into their correct positions.
So far I've come up with 2 rather poor solutions:
I could potentially create separate animation clips for each combination of sprite positions and transition
between them using mecanim parameters or in
code, but this seems tedious at best and inefficient at worst.
I could add more keyframes (either in the animator tab or in the
curves screen) that maintain each sprite position until just before
they need to be updated. This is a slightly better option but also
extremely tedious.
Is there any way to tell Unity to disable animation interpolation at least as far as positions are concerned? Thanks.
In the current version of Unity (2019.3), go to curves view, right click a keyframe node and select Left Tangent -> Constant. You may want to use Right Tangent depending on the use case. That should give you the instant change you're looking for.
Have you checked Brackeys video of animating 2D in Unity? Maybe it can help you :)
The following link is his video on how to animate 2D sprites.
https://www.youtube.com/watch?v=whzomFgjT50
Alright, I've come to the unfortunate conclusion that Unity forces you to use curves when dealing with animation keyframes and that you need to add an extra set of keyframes for abrupt shifts in animation.
I'm completely new to Unity and I'm starting to work on a little game for my class. The scenario says that the main character should be placed in my home town.
Since I'm not capable of modeling my town, I tried making skybox from google street view images using free plugin I found. It looks ok, so I tried adding an avatar, and that's where I'm having troubles.
When adding an avatar, he falls trough the floor, I suppose because its only image underneath him. Then I tried adding box below his feet, and now he levitates in squat position abowe it.
Has anyone any suggestions or ideas on how to fix this? Or maybe some suggestions on different vay of doing this would also be apprechiated.
Here is a photo of what it looks like now:
https://postimg.org/image/ehklr8sg5/
The reason your character falls is because there is no "floor" yet. The skybox is nothing but a special cube that wraps infinitely around your scene. With the street view images it may appear like the character is standing on solid ground based on the optical illusion of the skybox, but they're actually floating in space. When you press play, the physics engine starts, gravity takes hold, and your character falls.
There are a number of ways to prevent them from falling.
Disable Gravity on Character
This is only a good idea if you're not planning to use physics in your game.
Select your character's root node in the Hierarchy
In the inspector, find the RigidBody component
Uncheck Use Gravity
Add Floors
Add something with a collider on it that doesn't have a RigidBody. The collider will prevent the character from passing through it and the lack of RigidBody will ensure it doesn't also get affected by physics or gravity.
Create > Plane
Set its transform position to 0, 0, 0 so it's centered in the world
Scale it up big enough for your character to land on
Uncheck the Mesh Renderer in the inspector to make the plane invisible
In current Unity,
For use in Unity.UI as conventional UI ..
for any "Sprite (2D and UI)", in fact it always defaults to having "Generate Mip Maps" turned ON. Every time you drop an image in, you have to turn that "off" and apply.
As noted in the comments, these days you can actually use world space UI canvasses, and indeed advanced users may indeed have (say) "buttons that float over the head of Zelda and they are in the far distance". However if you're a everyday Unity user adding a button, just turn it off :)
In Unity, "sprites" can still be positioned in 3D space. For example, on a world space canvas. Furthermore, mipmaps are used when the sprite is scaled. This is because the mipmap sampling is determined by the texel size rather than the distance.
If a sprite is flat and perfectly scaled then there is no reason to use mipmaps. This would likely apply to your icon example.
I suspect that it is enabled by default for 2D games where sprites will often not be perfectly scaled. To clarify, a sprite does not need to be on a canvas. Sprites can exist as their own GameObject with a Sprite Renderer (not on a canvas.) When this is the case, scaling the camera view will change the sprite's size on the screen resulting in mipmapping due to the texel size changing. This results in making the sprite always perfectly scaled challenging without a canvas.