Unity 5 introduced changes to the physics system which requires the physics materials to be tweaked in some cases.Ī Mecanim player model is definitely on the list. These changes should help with the flickering/jittering issue.Īs for ladders not working, you might need to check that the friction value/combine mode of the physics material on the ladder is set to a lower value. If you find that the weapons occasionally are clipped by the near plane, you can decrease the Sway Amount value in the GunSway.cs component of the FPS Player object to 0.5, to reduce the weapon sway while rotating the main view. These values are still pretty low, but it's a tradeoff to allow the weapons to be closer to the camera and fit within the player capsule collider. 0.03 will become the default near clip plane value in the next version. Secondly, you can increase the camera near clip plane to. The borders of your level should extend to positive and negative amounts on each side, such as 500 to -500 units, to maximize use of the higher-precision area of the scene. The main things you can do to minimize flickering/jittering with the one camera setup, is to arrange your scene like in the terrain test demo, with the center of your terrain/level located at the scene origin (coordinates 0,0,0), since the floating point precision decreases further away from the origin. The 2 camera setup minimizes this issue, but the trade off is that there are no shadows from world geometry casted on the weapons and, so far, the new deadzone aiming system does not work correctly yet, due to the upscaled weapon models. Since the single camera setup uses a closer near-clip plane to allow the weapon models to be placed closer to the camera, this can cause some z-fighting in larger scenes. There's a limited amount of precision for the z-buffer, which is tied to the distance of the near and far clip planes of the camera. First of all, the flickering shadows and/or jittering models is due to the common computer graphics issue of z-fighting. Just wanted to cover some of the main questions that I've seen posted. Very sorry about this and thanks for your patience. There's currently a backlog of support requests that we're working to get caught up on. It's been a busy few months, but development has continued. Hope that might give you some ideas.Īpologies for my absence from the forums lately. You can view the NPC eye height positions by checking the Draw Debug Gizmos box at the bottom of the AI.cs component for visual tweaking of the eye heights. Some Character models have their origins near their feet, and if the Eye Height offset value is zero, they won't be able to see their targets consistently from ground level. First of all, are there any errors in the console window, or are the NPCs just not tracking the player as expected? Also, are either of you using the default NPCs, or new ones that you've created/duplicated? If you're using custom NPCs, one thing you might want to check is that the NPCs' Eye Height value of their AI.cs component is high enough so they are tracking the player from the height of their eyes. Is there a way to put a hard stop on this kind of behavior as I can't see a good reason for it.īTW, just using Navmesh in case that matters.Ĭlick to expand.Hi, sorry to hear you've encountered an issue with the NPCs.
Realistic fps prefab compatible code#
To make this even stranger it seems that it happens to 2 types of NPCs while another 2 with identical settings work fine under the same code scenarios.īesides this, there seems to be a possibility for any NPC to get into a game of leap from with other NPCs, such that they will keep moving past other NPCs over and over until they are on top of the player and pushing the player along. Rotation without moving the player does not work, the player has to actually move a
0 kommentar(er)
