Fix entity rotation: handle yaw=0 + correct shortest-path math#478
Open
domdomegg wants to merge 1 commit into
Open
Fix entity rotation: handle yaw=0 + correct shortest-path math#478domdomegg wants to merge 1 commit into
domdomegg wants to merge 1 commit into
Conversation
The entity rotation update path had two latent bugs: 1. `if (entity.yaw)` skipped the update when yaw === 0 (a perfectly valid value meaning 'facing south'). The model retained whatever rotation it had from a previous frame. 2. The `((2 * da) % 2π) - da` shortest-path formula doesn't always pick the geodesic on the unit circle when `yaw - rotation` lands in certain quadrants, so models occasionally rotated the long way. Replace the truthy check with a `typeof === 'number' && isFinite` test and use the textbook 'wrap to (-π, π]' formula instead. Same change applied to the bot-self rotation path in lib/index.js.
Contributor
|
@sandexzx do you think we need to port this? |
@zardoy Yeah, makes sense to port. We have the exact same code on our side in minecraft-renderer (src/three/entities.ts, the entity rotation tween) — both issues reproduce: entities facing yaw === 0 That fix looks good — typeof === 'number' && isFinite is the right guard, and the ((d % TAU + TAU) % TAU) then wrap-to-(-π, π] is the standard correct formula for the shortest signed angular |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The entity rotation update path had two latent bugs that caused player models to snap to wrong orientations:
if (entity.yaw)skips yaw=0 —0is a perfectly valid yaw (facing south in MC convention), but the truthy check treats it as falsy and skips the rotation update entirely, leaving the model at whatever rotation it had from a previous frame.Shortest-path math regression —
((2 * da) % 2π) - dadoesn't always pick the geodesic on the unit circle whenentity.yaw - e.rotation.ylands in certain quadrants, so models occasionally rotate the long way (≈2π−ε in the opposite direction).Fix
The new formula is the textbook "wrap to (-π, π]" shortest-rotation calculation. The same change is applied to the bot's own model in
lib/index.js.Note
The most user-visible "models snap on jump" symptom of this code path was actually rooted in a mineflayer bug (PrismarineJS/mineflayer#3896 —
sync_entity_positionnot converting notchian yaw → radians). With that mineflayer fix in place, these viewer issues are still observable but more subtly: models facing exactly north (yaw=0) keep stale rotation, and occasional long-way-round spins on large yaw deltas. Worth fixing here too.