When I was missing around with Unity once, I encountered a problem where the main player's position start losing precision, wobbling and
movement smoothness turns into jitter.
It turns out I was going too far off the origin point which is too much for unity's vector3 floating point to handle.
In graphic. You can easily overcome this issue by just looping through a certain range. Ignoring that will result in an issue similar to this:
Source: https://youtu.be/wGhBjMcY2YQ
Which makes me really wounder, how do developers over come finite variables to create infinite worlds. I personally haven't dipped my toes in making infinite world but I have encountered the graphic floating point error.
If developers relay on the fact that players will never reach the point where that error start to occur then technically, it's not an infinite world.
I would love to hear from the experts.
Related
I have a sphere with bounciness set to 1
The ball has no drag and uses gravity
It hits a platform, which has bounciness set to 1 and no friction
Yet, the ball bounces higher on every bounce, going to infinity. How is such a thing possible, when I have not given it any extra momentum?
The issue comes from the fact that physics in games happens in discrete frames, and that a moving object will be "inside" another at the frame where there is a collision. The physics engine then has to separate the objects before the next frame, and figure out how much energy to "bounce" with.
One of the steps to do this involves figuring out how much the objects overlap, and that's where this phantom extra energy is comin from. Less error in the overlap equals less error in the energy.
Don't fiddle with the bounciness; those are naive solutions, not to mention they sidestep the issue rather than solving it.
What you should do is to fix what's wrong with your collisions. That can be done a number of ways, the most appropriate/performant of which depends on each specific game:
Increase your physics frame rate (decrease fixed delta time). This reduces overlaps and makes physics frames "smoother". It doesn't really solve phantom energy though; only makes it's causes and effects smaller (maybe so small they become unnoticeable, which is all you need).
Set your sphere's collision detection method to Continuous Dynamic,
and set your ground to static. If you need the sphere to collide with
other stuff, those other stuff present similar issues, and those need
to be non-static, set their rigidbodies' collision detection method
to Continuous. (This is the method I most often find to be the best, but I've had projects where others were better for various reasons)
Increase your Default Solver Velocity Iterations
Change your solver type to Temporal Gauss Seidel
I have had a similar issue with javascript/html/css canvas animations. I have no explanation for this. Use a number like 0.99999 or 0.969399 and that should do the trick. I do get what you mean though it's weird. Just get close to 1. That's all I can say. I hope this helps anyway.
I am making an FPS game and I need for the forward facing vector to hit exactly where the crosshair is aiming.
This is my current blueprint.
It takes all references from the camera position where the players head should be. (as it usually is in FPS games).
When "shooting" the vector it is slightly offset though. (pink dot near crosshair)
Things I have tried:
Increasing distance of vector makes the problem go away but it then becomes inconsistent, which means it's a bad solution to the problem :(
Manually changing axis values, but that was also very inconsistent.
Changing between 3 different nodes of taking rotation from the camera, they all (didn't) work the same way :/
Maybe there is an issue of the values that I am taking, although the starting position of the camera seems to be correct.
Thank you for any insight you may have!
Suggested by user Ruzihm the issue was that the crosshair was off-center. My blueprints were actually okay.
So for anyone looking see if your crosshair is in the center.
I'm trying to implement my own version of a dice roller.
So far I've reached a decent result, my solution is not very flexible yet but I like the realism of the physics.
I have an issue, though: sometimes a dice lands on it's edge and it keeps that unnatural position for the rest of the time.
How can I avoid it?
I tried to tweak the physics materials, the rigid body simulation, the scale of the dice and the system gravity with no success.
Maybe I did not find the right mix or maybe I'm missing something.
I will appreciate any suggestions thanks
you can iterate thorugh your dice, find ones that are sleeping (Rigidbody.IsSleeping) and for those that are check the angles are not wierd (i.e. one of the angles should be close to multiplies of 90), and apply some random torque for those that are likely to stand on edge
Update:
Shadows! It looks like the biggest problem I had was with shadows. I had absolutely every mesh giving and receiving shadows. Turning off shadows seems to reduce my issues by 99%. Not sure what the remaining 1% is, but this is way better! So on that note, my question still remains, how the heck could I have known it was shadows? Surely the graph below should have somehow told me this, yes?
Original Question:
The main question is how can I troubleshoot this further? I know there's a profiler thing but I'm not sure what to do with it. Is that what I want and need? Does this tell anyone anything? It should be representative of when the jitter is occurring.
More Background: I use a Vive controller to move by pulling the trigger. I perform a transform based on Time.DeltaTime using the vector position of the controller minus the y axis to know which way to move and how fast. There are tons of enemies and tons of spherical trees. The game seems to run quite well except when I look towards a particular direction. In trying to isolate what it is in that direction, I started turning stuff off such as enemies and the trees. Oddly enough, it makes it WORSE. The only way I can imagine this to be possible is if something is eating up resources all the more now that it's no longer fighting for them with other objects. But it would have to be doing it outside the regular frame loop or else the movement wouldn't appear impaired at all, right? That, or it's something wrong with how I move which now has more processing power to make it worse? I'm so at a loss. Anything wrong with this strategy?
public override void OnTriggerPulled(float triggerPullPercent)
{
if (!mainHand && triggerPullPercent > 0.05)
{
Vector3 goForward = transform.forward;
goForward.y = 0;
transform.parent.transform.Translate(goForward * triggerPullPercent * Time.deltaTime * 5f);
}
}
Even worse, the issue is inconsistent. After removing all the trees and seeing zero signs of improvement, I removed a single object just cuz it was ugly and not ready for the game anyway. Suddenly, things seemed quite a bit better than the "Worse" state it was in but it was more akin to the original jittery state which had me doing this to begin with. I added the object back in and oddly enough, it did not revert back to its worse state. So clearly it must not have been the object that made it any better/worse. I added my trees back in and it was suddenly back to the horrendous state. Now suspecting the trees, I removed them again and found no difference. Still crappy. So... not the trees or the object? I removed the one object and it was suddenly much better again. I can do this forever very repeatably. What gives? It's neither and both simultaneously? Any ideas? What more can I do to troubleshoot this? My current method is severely lacking.
Thanks!
Here is what happens when I copy&paste a few thin boxes, and then vertex-snap them to the ground and each other:
Pressing "Play" leads to the stack toppling.
I tried reducing the BoxCollider y to 0.99 and 0.95. No luck still.
Does anyone have recommendations to easily get a stacked wall to just stay up (until a real force is applied)? Maybe there is some sort of "glue" component to prevent two faces separating until a force exceeds some threshold?
Try setting their positions manually so that they are right under each other.
You shouldn't expect to be able to make a stack of 20-30 box colliders stacked on their smaller faces because of physics simulation inaccuracies, floating point errors and so on. If that's your intention and/or the above doesn't work, try using Fixed Joints with a manually set Break Force and/or Break Torque.
You can also try increasing the Solver Iteration Count to something like 10 or 15 (which should do the trick in most cases), but it won't be good for performance in scenes with 1000s of objects.
Increasing the Sleep Threshold will also help in this specific case, but can cause problems like small objects sleeping when they have small (but not infinitesimal) velocities.
EDIT:
A similar thing happens with my own custom physics engine. Another workaround you can do is to align the bodies and set them to sleep in Start. That way they'll stay upright (not moving rather) and topple when something collides with them.