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.
Related
I'm new on that thing of analisys profile of Unity. I decided to see if my player is dropping too much FPS and the I found this. Will that be a problem for my game? I don't know how that system works, but I guess 8.35 is a high number...
Not its not.
The editor loop is how long the unity editor took.
The player loop is (roughly) the performance of your game. And the big green part looks like the WaitForTargetFPS call to me. Though to tell for sure you'd have to expand the player loop and see.
If you want to measure the actual performance of your game accurately you have to make a development build and profile that one (you can select the debugging options for this in the build dialog).
Further reading: profiler documentation
so I've been trying to see if I can make use of Wheel Colliders for the past several months now. As much as I've managed to figure out more and more things about how to set them up properly, there's some things I've been noticing that seem impossible to avoid:
Even if your friction sideways stiffness is lower, there's a chance that your car will continue to "spin" or "rotate" in the direction you were steering if you JUST hold down your input long enough to get the car beyond just rotating. I've noticed this will happen, whether for example the "SteerHelper" or "TractionControl" functions are doing their work or not. This will put a dent in ensuring smooth turn movement. Now, I don't know if maybe this is just due to realistic car physics (I mean, I can picture the car skidding in scenarios where they lost grip of the road for sure), but it just feels kinda glitchy. Sometimes, even when I'm not turning, the car will start to turn a little to the left or right and then gradually seem to "lean" that way in terms of applied torque to the rigidbody. I've seen many suggestions for trying to stop the rigidbody from doing this. Here is one way I'm trying to work against this:
rb.AddTorque(-rb.angularVelocity * 2);
However, it seems that the car will still "spin" more than intended. What would be ideal is to be able to MAYBE allow the car to turn a little extra after the left or right steer buttons were released (maybe more or less depending on the vehicle), and no more than that to ensure there is maximum control to give the engaged and maybe arcadey game play I've been going for for a long while.
It's been difficult to adapt an ideal friction curve value that would give the most ideal feel of a drift turn, especially a more arcadey one. I'm not trying to go for wide turns that slow you down, I'm trying to go for tight (yet controllable) turns that allow you to preserve most of your speed. I find that especially at higher values of stiffness, as I know many people have observed in other posts, that again, the car will turn back an extremely high amount sometimes (you drift left enough, a force is turning your vehicle way to the right). It's sad, because I've wanted to be able to say I've "mastered this beast" and used it for my purposes, but I don't know if that's really a good practical expectation for anyone. I even worked my own alternate friction curve values that would be used in the controller:
But I guess as some people say, you can't polish something that's broken? Moving to the third point...
I've read so many posts that show how to adjust a vehicle's center of mass, or to add more colliders in different spots to correct it, using scripting to add an offset to the center of mass, etc. So many tips that say, "lower the center of mass, you'll find it" and I give that a try. When the center of mass is too low, my car can get pretty shaky on the terrain (not that it hasn't in the past, but it's often been things I could correct, like the weird initialization of the attachedRigidBody of the wheel colliders themselves in the beginning, etc). High enough, and of course, (even when it's lower sometimes???) the car will just start spinning in the air on either multiple axes or specifically the forward z, when you drive off a ledge or bump into something with a high enough speed. It just seems inevitable.
I've been trying to give my benefits of a doubt. I like to think there's a correct way to use this thing, and that I'm just not familiar enough with Unity3D physics concepts. However, it just seems more and more that I'm investing too much time in a broken component - or, maybe I just never got the best grip of physics.
I was about ready to try just convex mesh colliders around my tires, and just abandon the idea of gripping physics altogether, but I'd love to hear suggestions to either address anything I've mentioned above, or just a more ideal package to move onto. I've glanced at packages like Vehicle Physics Pro, but I do want to be sure I'm getting something that makes sense.
Full disclosure: I'm in the middle of trying to make a game that feels incredibly similar to F-Zero, but with wheels.
Thanks in advance for any thoughts or suggestions you can provide.
(Maybe not an answer per se, but hopefully helpful.)
Note Unity also suggests to possibly give the car a constant downward force via script. It might be telling that such workarounds are officially given, one would think proper physics would, well, properly work without them.
There's some assets you might want to give a try generally:
One is the Unity Asset Store asset called Arcade Car Physics, and it's free. I've tried it and it works (but not sure if it works for your needs). It's using Unity's native Wheel Collider plus extra scripts.
Another is the Arcade Car Physics github project. It has nice plane stabilization and more, and works well. It's not using the native Wheel Collider.
Then there's this asset called Vehicle Physics. Instead of native Wheel Colliders, they've create a fully custom wheel system so that it would be more physically workable. The asset is not free, but they offer a free demo executable where you can drive around different vehicles, and that works quite well. (I haven't yet bought this asset myself.) As a downside, some reviews mention there's some complexity in setting this up (and I suppose future support for this custom Wheel Collider hinges on the company continuing to exist).
Good luck!
I'm using Unity3D 5.3 version. I'm working on a 2D "Endless running" game. It's working normally on PC. But when I compile it to my phone, all of my gameobjects are shaking when they are moving. Gameobjects are in a respawn loop. I'm increasing my Camera's transform position x. So when my camera is in action, all of the other objects look like they are shaking a lot and my game is working slowly on my phone as a result. I tried to play my game at Samsung, on discovery phones. It's working normally on some of them. But even on some Samsung devices it's still shaking. So i don't understand what the problem is. Can you help me with this?
One thing you can do is start optimising, if you have a game that is either finished or close to it. If you open the profiler, click "Deep Profile" and then run it in the editor on your PC, you'll get a very detailed breakdown of what is using the most resources within your game. Generally it's something like draw calls or the physics engine doing unnecessary work.
Another thing that might help is to use Time.deltaTime, if you aren't already. If the script that increases the transform doesn't multiply the increase by Time.deltaTime, then you're moving your camera by an amount per frame rather than per second, which means that if you have any framerate drops for any reason, the camera will move a smaller distance and that could be throwing out some of your other calculations. Using Time.deltaTime won't improve your framerate, but it will make your game framerate independant, which is very important.
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
Something must wrong here either with me or my monitor or GPU. Others also suffer from this phenomena see the links.
Now I would like to emphasize this problem is exist, being optimist I think there is some solution. Maybe it is only noticeable in special circumstances, and definitely not a performance (or GC) problem. If it would noticeable in all circumstances Unity3D would be useless...
My goal to use this wider forum to specify this problem is my hope the wider community may have wider scope to search the root of the problem. I think it is not algorithm or Time class usage related. Maybe the Time.deltaTime itself has bugs or mislead in some circumstances.
Just a feedback if anyone can reproduce the vibrating effect or not may have diagnostic value. (it seems to be oscillating in horizontal, the left and right edges are very blurry.)
Marrt created a web demo for Unity to demonstrate the effect:
http://marrt.elementfx.com/SmoothMovementTest.html
Whatever I do this demo is so vibrating + choppy. NOTE: All my self created simple scroll projects running in editor or standalone desktop are also exhibits the same, so it is not about 'how to use Time.deltaTime'
I thought the problem is in my hardware until today I saw this WebGL demo (use Chrome):
http://webglsamples.googlecode.com/hg/aquarium/aquarium.html
It is so smooth (any fish movement, also the rotating also the light fades) I mean smoooth. Why I can not produce (no one produce) this with Unity (at least in my machine)?
If anyone interested there is an exact proble description here, but no all answers solve the problem.
The problem in details:
http://answers.unity3d.com/questions/275016/updatefixedupdate-motion-stutter-not-another-novic.html
I tried all the things including the programming variations + quality setting (VSync etc)
My very simple self created projects are running 1000 - 2000 fps and still vibrating + choppy.
I spent 2 days to get the rid of this poor visual experience. Did all the programming thing what mentioned in the linked threads + tried to configure my video card (btw Radeon 6770 with 1Gigs)
Any thoughts?