Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Derive the vertex marker depth bias from screen space

Open
  • Is something wrong?
#135 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
20/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
rust
Domain
computer-graphics

Research direction

Start by locating VERTEX_MARKER_DEPTH_TOLERANCE and the vertex/edge draw and pick paths; the issue names no files, so trace from viewport task T7 and follow-up #29. Implement the screen-space bias in view space and make picking read the same value, leaving FACE_CENTER_DEPTH_TOLERANCE unchanged. Done when readbacks across viewport sizes, fovs and distances pass, thin-plate occlusion has a documented thickness, and tests pin draw/pick agreement; update the known-issues entry.

Written by the indexing model from the issue text.

Description

area/selection area/viewport effort/m impact/many priority/p2 severity/low triaged type/bug urgency/this-quarter

Follow-up from #29 (Vertex and Edge selection), viewport task T7.

Problem

Vertex markers and the selected-edge strip are drawn with a constant depth bias toward the eye, VERTEX_MARKER_DEPTH_TOLERANCE, which is also the occlusion slack for vertex and edge picking so drawing and picking agree. It is a relative fraction of the linear view distance, currently a flat 6e-3.

The constant is chosen empirically and the margin is thin:

  • Readbacks on an Apple M1 Pro (Metal), 1024 px viewport, 45 degree fov, side-2 cube, near 0.01, far 10000, at the default distance and at distance 120: 6e-3 to 8e-3 draws every visible corner marker fully (25 of 25 pixels) and hides every hidden corner.
  • 5e-3 leaves one visible corner at 20 of 25 pixels.
  • 2e-2 lets a hidden corner draw at distance 120.
  • Only this adapter was measured; CI's software Vulkan job runs the GPU tests but did not bracket the value.

The failures are slope-limited, not depth-resolution-limited: a screen-aligned marker is flat while the faces around a corner are tilted, so part of the marker falls behind the adjacent surface. A world-relative constant cannot track that, which is why it trades see-through (plates thinner than about 0.05 units at the default distance 8 can show or pick a vertex behind them) against clipped markers. An earlier attempt to scale the tolerance with Depth32Float resolution was removed because no readback needed it and it widened see-through at distance.

Proposal

Derive the bias per marker from screen space: roughly (marker size in pixels / viewport height) * tan(fov / 2) * a slope allowance, applied in view space, with picking using the same value so draw and pick stay consistent. Keep FACE_CENTER_DEPTH_TOLERANCE unchanged unless face-centre markers show the same problem.

Acceptance

  • Readbacks at several viewport sizes, fovs and distances (including small and far objects) draw every visible corner marker fully and hide every hidden corner, without per-case tuning.
  • A thin plate in front of a vertex hides it and blocks picking down to a documented thickness that improves on the current about 0.05 units at distance 8.
  • Draw and pick read the same bias; tests pin that.
  • known-issues entry updated with the adapters measured.
Dominant language
Rust
Stars
4
Forks
2
Avg merge
3h 46m
Merged PRs (30d)
115

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from cristim/AztecCraft

All issues in cristim/AztecCraft

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.