We are making a 2d game and I stumbled upon some strange behavior.
When I made some particle systems in Unity3d itself, everything was looking right. When I made an application and started it on maximum settings, particles were behaving themselves like crazy. When I started at low settings and they were good.
I found out that it depends on vsync setting (and FPS, as result). Now, without vsync FPS is 1100 (with vsync: 60). Maybe even the whole physics is changing, I haven't spotted that yet.
So the question is: how can I fix this? I can't just turn off the very possibility to turn vsync on, because as I understand, when a game will become more complicated, FPS will drop, and then what? Redo all particle systems? And tearing may appear, why do so?
On the other hand I can't force VSYNC for the following reasons:
intense difficulties with working in Unity IDE itself (it runs game "preview" without vsync, also, in "scene" mode particles appear as they are without vsync on.)
The game will be playable at 30-50 FPS, how it will behave with forced vsync? It will turn it off and particles will start to behave weird again? (UPDATE: the correct answer it will sync to 30 FPS, obviously)
(No scripts were used in the particle systems' gameobjects, just empty GameObject with system attached).
This is a known bug in Unity and has been reported previously in their issue tracker. See http://issuetracker.unity3d.com/issues/shuriken-particle-system-module-limit-velocity-over-lifetime-is-fps-dependent
Related
I have several shaders that use the Time node to animate certain UI elements for my mobile game.
In certain cases (which I am unable to reproduce), the shaders will be stuck on a specific time and not animate.
For example, a shine shader might be stuck mid-shine.
Some important things to note:
Time.timeScale is 1 - all my tweens using scaled delta time are working correctly
When this happens all shaders using the time node in the active scene will "freeze in time"
This only reproduces on actual Android devices (iOS untested)
All parameters affecting time in said shaders are positive, valid numbers
There are no errors or warnings
When I transition from my main menu scene to the game scene, time based shaders will work correctly - when I come back to the main scene, it will reproduce again (obviously it's something specifically there)
Running on Unity 2019.4.11f1 with URP & Shader Graph 7.5.1, but it did reproduce in older versions of Unity/URP as well
Sample shader - The preview actually looks exactly like the issue as it will appear in game when frozen:
For any lost souls who stumble upon this issue (although I doubt it's by design as it seems like a bug).
The problem is that time isn't updated in shaders in scenes without a camera.
The camera doesn't have to render anything; it just needs to exist.
My main menu is pure UI elements and had no camera; adding a camera to the scene fixed the issue.
It is important to note that this behavior only happens once you build to an Android device; not sure if it reproduces on other platforms.
Firstly, I've built for the Quest and checked the Unity profiler - everything seems good.
The weird thing is, when I move my head from side to side I don't see any framerate drops in the profiler but I see a noticeable stutter/lag in the headset. When my head is still or even just rotating, everything looks great, there's no stutter at all.
This stutter only occurs when I'm close to my UI and moving my head. When my head is static or rotating, it's all good. If I move back from the UI, there's no stutter either.
I don't think that it's an issue with too complex geometry or materials, as surely this would show up as a framerate drop in the profiler. I'm guessing that the camera movement is causing some kind of frame mismatch which (for some weird reason) isn't showing up in the profiler.
Does anybody have any ideas as to what might be causing this?
Well, I found the issue after narrowing the issue down to a specific set of GameObjects. It seems that the issue was being caused by a custom 'Dissolve' shader I was using. After setting the shaders back to 'standard' the problem went away! Weird...
This happens if your game FPS is lower than the device refresh rate.
For example if the headset is displaying 90 frames per second and your game is only able to render 70 frames per second, the headset needs to reuse a rendered frame every few frames.
When the game doesn't provide a rendered frame in time the device will just take the last rendered "image" and adjust it to the changed headset position and rotation. If it's a rotation change only, you will not notice, because the headset can easily just rotate the last image. But if it's also movement, the device can't simulate the difference of movement of close objects versus far objects on the image, so if you are moving an object close to a camera (e.g. your hand), it will stay at the same position for two frames (every few frames), which will make it look like it's stuttering.
I'm currently just trying to learn to use the animator within Unity, I'm very in-exp at animation and don't understand it even in the editor as I focus on programming/scripting.
I have an animation and the states for the animations as-well as the conditions all working perfectly however the animation check for the next state is way to slow. I've tried changing the speed of the actual state but it speeds the animation up and makes it look like my character is walking insanely fast.
I've tried messing around with the frames, making them over a longer time period and making the speed of the state faster however it seems to counter act each other, when I make it longer frames the pace of the animation is slow and then when I make the speed of the state go quicker it just makes the frames tick faster making the animation faster.
What I believe is happening is that the check for the next state of animation is happening once the full animation has been played. However what I need is the check to be happening constantly (as if frame by frame of the unity game not the animation).
Any advice would be great, I've tried using youtube to solve this before coming here however most people are creating a platformer game where as I'm trying to aim for a top down 2d, all directional character movement instead of the linear x axis character movement., and outside libraries.
I deeply apologise for my inability to find a suitable source. I have literally just came across an article online that came across a simple solution.
here:https://answers.unity.com/questions/221601/slow-animation-response.html
basically if you can't be bothered to click the link and you are having the same problem,
find exit-time by clicking the transition and then in the inspector and untick it.
Sorry.
This is posted here since this is Xbox specific, but I am also posting this onto the Unity forums.
When testing my Unity game on Xbox One I am getting a very large amount of visual "jitter" from the ball. This is a skeeball game where you control the movement of the ball. Essentially the core of the movement is similar to the Rollerball tutorials. On PC this works fine and there are no perceptible jitters. However, on Xbox, I am seeing this a lot more. The object is travelling large distances with the camera following smoothly behind. None of the other objects or scenery are affected, I actually think the camera itself is moving perfectly. But, the ball itself seems to glitch.
Changing my camera movement to LateUpdate seemed to minimize it the most on the PC, but that doesn't make sense to me since I am still not convinced the camera is the problem.
Any help would be greatly appreciated. Perhaps a quality setting isn't placing nice with the Xbox?
Thanks!
Nick
Keep in mind the clock speed of the CPU on the Xbox is likely much slower than your PC (although there are more cores).
Unity is primarily single threaded, so that could explain the performance difference. Here are some things you can try:
* Make sure you are running the "Master" build on Xbox. The default is "Debug" which is significantly slower.
* It's possible it's something with the physics.
Once you've checked to make sure you aren't running Debug, the next step would be to use the Unity profiler to see where your frame time is being spent, then depending on what the cause is optimize that part.
Here is more information on the system resources:
https://learn.microsoft.com/en-us/windows/uwp/xbox-apps/system-resource-allocation
There is also a great post about the graphics debugger here:
https://tarhik.wordpress.com/2017/09/04/antimatter-instance-dev-log-entry-2-using-microsofts-graphic-debugger/
It looks like switching the RigidBody to use "Extrapolate" instead of "Interpolate" fixed the issue I was seeing. I am not sure if this works for every situation, but for the scale of the levels and the player physics of my game this seemed to do the trick.
I have my "player" gameObject standing atop a platform. He press a combination of keys, I verify that he's standing on the right kind of platform, and I run this code:
Physics2D.IgnoreLayerCollision(playerLayer, plataformLayer);
The intention being that he'd drop down from the platform. Instead, nothing happen immediately. The player is still atop the platform and can move around - only if he gets out of it and tries to get back to it, only at that point will he fall down from it.
So I made a temporary ugly workaround:
Physics2D.IgnoreLayerCollision(playerLayer, plataformLayer);
rigidbody2D.AddForce(transform.up * jump / 1.5f);
This will force the player to jump, making Unity "recalculate" the collisions and the player will, as I want to, pass through the platform. The even weirder part is: if the jump isn't high enough (100 force at 1 mass with 0.5 gravity scale seems to be the minimum), the player will still land on the platform, even though Unity is supposed to be ignoring those collisions.
I also tried pushing the player downwards, both with force and direct velocity, but no luck - he still collides with the platform, he only stops colliding with it after being away from it once.
Also, my player Rigidbody2D Detection Mode is set to Continuous, and I tried setting the platform up in many different ways, with and without a Rigidbody2D.
Any ideas on how to make the player instantly fall down from the platform as soon as collisions start being ignored? Thanks in advance.
I had been having the exact same issue. I have an alternative solution that you may find to your liking.
Rather than disabling or moving the terrain to be ignored, temporarily set the rigidbody2D of your player gameObject to kinematic. This will not cause you to 'drop' through the platform as you would like - but it will allow you to create the illusion that you are, by briefly using transform.Translate (or Vector3.Lerp, if you like) to move your character down via code.
This will disable Rigidbody2D.AddForce, but will still allow for set movement via rigibdody2D.velocity, if that is preferable to manipulating the transform directly.
Ensure the downward velocity lasts only as long as you are Kinematic, and try to let it match the gravity of your game, and it looks pretty seamless.
If you turn the rigidbody back on too quickly, it can (even with ignoreLayers :/ ) still jump back up to the platform - but if you leave it on too long, you can drop through more than one intended one-way platform, or even :O through the bottom of the stage!
This is easily avoided if you can be careful - personally I used both MonoBehaviour.Invoke to set a very short time limit on how long the player would remain Kinematic (about 0.5 seconds), AND I disabled Kinematic as soon as they moved 0.5 units from the point where the 'hopDown' was initiated.
If your gravity / platforms / character scale are vastly different than my own, you may have to experiment with some different numbers.
This has been my first attempt at an answer on stackoverflow, so I hope it has been helpful!
One easy way to do this is after calling
Physics2D.IgnoreLayerCollision(playerLayer, plataformLayer);
You reset the player's layer:
player.gameObject.layer = playerLayer;
It's sounds like you have covered a ton of possible solutions to this problem before coming here so, good job there. I listed a few alternative ideas below. I hope they help. Good luck!
Remove the collision object from the platform itself.
Offset the collision object to be in some remote location so it will not interact with the player. Offsetting the object may cause the collision to have a similar reaction to the jump you mentioned.