[💬] 캐릭터 컨트롤 문제.. 도와줄래...?

[Nameles..(221.161)]

내가 어디서 잘못하고 있는지 좀 봐줘

셀레스트처럼 최대높이에서 일정시간동안은 천천히 떨어지게 하는걸 만들고 있음

그런데 내가 원하는 총 점프 시간과 높이를 정해주고 싶다 이거야.

점프거리는 점프시간에 딸려오는거니까 여기선 논외로 함ㅇㅇ

[Tooltip("최대 점프 높이")]

public float JumpHeight = 6f;

[Tooltip("점프 상승시간")]

public float JumpTime = 0.3f;

[Tooltip("점프 최고높이 유지 시간")]

public float JumpPeakTime = 0.15f;

[Tooltip("Peak로 판정할 플레이어의 종단속도 최대치")]

public float PeakThreshold = 0f;

[Tooltip("Fall로 판정할 플레이어의 종단속도 최대치")]

public float FallThreshold = -10f;

[Header("중력")]

public float Grvt;

[Tooltip("Peak시 적용할 중력배율")]

public float PeakGrvt;

[Tooltip("Fall시 적용할 중력배율")]

public float FallGrvt;

void Start() {

Grvt = (2 * JumpHeight) / Mathf.Pow (JumpTime, 2);

JumpPow = Grvt * JumpTime;

PeakGrvt = (-1 * FallThreshold / JumpPeakTime) / Grvt;

FallGrvt = ((2 * JumpHeight

- PeakGrvt * Grvt * Mathf.Pow (JumpPeakTime, 2)

+ 2 * FallThreshold * (JumpTime - JumpPeakTime))

/ Mathf.Pow (JumpTime - JumpPeakTime, 2)) / Grvt;

}

Grvt는 매프레임 캐릭터 종단속도에서 빼 주고 있어서 +값으로 계산했음

졸업후 수십년만에 연습장에다가 수식도 끄적여보고 엑셀로 시뮬레이션도 돌려보고 했지만

중력이나 JumpPow계산은 잘못되지 않은것.. 같아

그럼 점프시간은 총 0.6초고 최대 높이도 6이 나와야 할텐데 말이야,

디버그로 찍어보면

점프시간은 주로 0.64에서 0.66, 최대 0.62에서 0.70초 정도를 왔다갔다 하고

최대높이는 6.3에서 7정도를 왔다갔다 함.. 최대 6.0이랑 7.2 까지도 찍히더라

문제 1.

FPS에 따라서 정상보다 점프가 한프레인 빠르게 혹은 느리게 끝날 수 있다.

-> 그러면 적어도 0.6초 언저리에서 왔다 갔다 해야하는거 아닐가..

또 인게임 FPS를 찍어보면 약 25ms정도가 찍히는걸 보면

점프가 한프레임 앞뒤로 빠르거나 늦게 끝난다고 쳐도 최대 50ms정도 차이만 나야하는데

어째서 80ms까지도 차이가 나는가 ㅠ

문제 2.

Velocity.y에 점프를 하는 첫 프레임에 JumpPow를 적용하고 그 다음 프레임부터 Grvt * deltaTime을 빼주는데

첫 프레임부터 중력을 적용해 줄여줘야 한다 즉 JumpPow가 40인데 첫 프레임에 40이 아니라 더 작은 수치가 들어가는 셈

-> 이렇게 바꾸면 점프 시간은 훨씬 안정적으로 0.58~0.62 사이로 찍힘. 0.6초 ± 25ms로 정상 범위

그러나 점프 높이가 보통 5.5~5.7 정도로 의도한 바 보다 낮게 나옴 (최소 4.x이나 6.x까지도 찍힘..)

또한 점프의 오차범위도 하드코어 플래포머 입장에서 나와선 안되는 수준의 오차..

문제 3.

Focus모드는 FPS가 너무 낮아서 생기는 문제다! 빌드하거나 Max모드로 돌리면 FPS가 높아져서 오차가 줄어들것!

이라고 생각하고 max로 돌려서 60fps가 되었지만 시간이나 높이 오차는 딱히 줄어들지 않았음.

정확히 수백번 시행해서 통계를 내본건 아니지만 디버그에 찍히는 최대 최소로 수치는 거기서 거기임

그래서..

점프 시간이나 높이에 일관성을 기하는 노하우가 있을까?

아니면 내가 아예 잘못 접근한게 있을까?

아님 Float을 다 Double로 바꾸면 좀 더 정확한 계산이 나올까?

[해당 댓글은 삭제되었습니다.]

해당 댓글은 삭제되었습니다.

[Nameless(221.161)]

당연히 그리하고 있습니다.. 부족한 저의 킹리적 갓심으로는 매 프레임마다 달라지는 deltatime의 오차가 쌓여.... 도 오차가 적게 나오라고 deltatime 곱하는 건데 나는 웨않된데 ㅠㅠ

[Nameless(221.161)]

Drag = 0 Inertia = 0 Fraction = 0 .... ㅠㅠ

[정공개발자(firetruck4545)]

문제점은 업데이트를 봐야 알것같은데, 이동관련 코드블록의 deltatime을 빼고 update 대신 FixedUpdate로 바꿔보셈

[Nameless(221.161)]

FixedUpdate로 바꿔도 deltatime은 어차피 같은 값을 호출할테니까 안빼도 되지않아? 그거 빼면 다른 수치를 온통 다 건드려야되는데...

[정공개발자(firetruck4545)]

Update는 매 프레임마다 호출하고 FixedUpdate는 일정한 아주 작은 시간마다 호출되도록 되어있음 근데 여기서 쓰이는 deltatime은 저번 프레임 이번 프레임의 사이의 시간을 의미함 ,FPS가 일정하다고 하더라도 절대 같은 값이 나온다고 보장 할수 없음. 따라서 프레임마다 호출되는게 아닌 일정한 시간마다 호출하는 FixedUpdate에서 deltatime을 쓸 이유도 없고 써선 안됨, 게다가 일정한 시간마다 호출되는 FixedUpdate에 물리 관련 코드를 작성하는게 오차도 줄이고 코드를 쓰는것도 편함

[Anonymous(58.124)]

나도 여기 정공아저씨 말대로 픽스드쪽이 의심간다. delta도 fixed용 잇으니 그거쓰구.

[Anonymous(58.124)]

저기 너가만지는 velocity가 rigidbody의 것이라면 더더욱 fixedupdate에서 만져야한다

[익명(116.127)]

fixedupdate상에서의 deltatime 은 fixeddeltatime과 같음. 어차피 갱신주기가 일정하기 떄문임

[익명(112.168)]

update에서도 Time.fixedDeltaTime 쓰면됨.

[익명(112.168)]

Update() 함수에 Time.fixedDeltaTime이랑 FixedUpdate에 Time.deltaTime 이 동일합니다. 물리 처리할땐 이거쓰는게 마즘

[익명(116.127)]

fixeddeltatime은 그냥 상수값인데 갱신 타이밍이 들쑥날쑥인 update에서 물리 움직임 제어용으로는 쓸 수가 없지 글고 fixedupdate상에서의 deltatime은 어차피 갱신 주기가 일정하다보니 fixeddeltatime과 같은 거고.. 갱신 주기가 일정하니 상수값인 fixeddeltatime이 의미가 있는거임

[익명(112.168)]

그러넴, 나도 fixedUpdate에 넣어놨었구나. 착각했다

[Nameless(221.161)]

FixedUpdate에서 돌리니까 오차가 훨씬 줄어들었어 내가 웨~ 이걸 생각 못했을까... 예전에 Fixed로 리팩토링 한번 했다가 안되겠다 하고 다시 엎은적도 있었는데 이번엔 로직을 잘 짜서 그런지 원하는대로 잘 작동함! 고마워 칭구들~