Allow the player to toggle a waypoint that directs them towards the world origin

[patowen]

The button on the keyboard to toggle this is "Home".

The waypoint marker will be stopped by the boundaries of the viewport, allowing it to always be visible regardless of which direction the player is looking.

[patowen]

Keeping as a draft for now. There's a bug where toggling the waypoint on and off causes the UI to flicker. I think this may be a bug in yakui itself, as there doesn't seem a good way to prevent this bug.

I seem to be able to avoid this bug by always rendering a mesh. It doesn't have to be the same mesh, but it does at least need either the same number of vertices or the same number of indices, or both (I'm not exactly sure what the requirement is).

It may be okay to merge this while the bug is still active. It looks silly, but it's not game-breaking.

[Ralith]

Are the validation layers clean? Anything funny in the number of vertices/draws/whatever yakui generates? Probably worth updating yakui to see if that helps, though I'm not sure how churny that will be.

[Ralith]

Very happy to have this feature, btw! This is an overwhelmingly important primitive to make the game playable. Follow-up work is probably to attach the marker to an entity and let the player move the entity around.

[patowen]

Very happy to have this feature, btw! This is an overwhelmingly important primitive to make the game playable. Follow-up work is probably to attach the marker to an entity and let the player move the entity around.

Just to make sure I understand, is the primitive you are calling important the path_between_nodes function or the ability to render a waypoint (or both)?

I made a mistake in this PR and accidentally included #532 unnecessarily.

[Ralith]

The part users will care about is obviously the UI, but finding a path is presumably an inextricable part of that.

[Ralith]

I guess not actually necessary when the waypoint is the origin, but it will be for the natural evolution of the feature.

[patowen]

Are the validation layers clean? Anything funny in the number of vertices/draws/whatever yakui generates? Probably worth updating yakui to see if that helps, though I'm not sure how churny that will be.

While the validation errors and synchronization hazards are clean, I do now think it's more likely to be a bug in Hypermine than a bug in Vulkan, as I was not easily able to reproduce the issue with similar code in yakui's Vulkan example. It could still go either way, but I would like to double-check Hypermine's logic.

One bug that my be related: It appears that the waypoint is slightly desynced with the rendering of the voxels. Interestingly, it seems to be one frame ahead instead of one frame behind.

[Ralith]

Yeah, sounds like some flavor of sync issue all right.

[patowen]

Yeah, sounds like some flavor of sync issue all right.

This might be a yakui issue after all. Since Yakui shares a single vertex buffer and a single index buffer between all draw calls, I think the issue might be that if I call YakuiVulkan::paint while the previous frame is still in flight, it will hijack the data being rendered from the previous frame, causing the previous frame to render with the new vertex/index data but the old draw calls.

My guess is that validation layers don't catch this because the memory is HOST_VISIBLE | HOST_COHERENT, which likely means that external synchronization requirements are relaxed.

The function in Yakui YakuiVulkan::build_draw_calls seems like all it does is populate a Vec<DrawCall>, but it also sneakily updates the shared index_buffer and vertex_buffer before returning. This has not changed between v0.3.0 and the current main branch as of 2026-09-23, and I was able to get similar flickering when testing yakui's master branch.

[patowen]

@Ralith, I'm not sure if the effort of fixing this bug and/or finding a workaround is worth blocking this PR. I'm going to go ahead and remove the "draft" status from this PR. If this gets merged, I can file an issue for the race condition.