Seven Identical BVH Bugs and an Uncited Slide

Evidence to gather (in order, before speaking to students):

1. The public source. Watch the YouTube series and check whether the 1e-4 epsilon, the tie-breaking rule, and the names mnx/mxx appear in it. If they do, a common tutorial is the parsimonious explanation for seven students, and the case shifts from collusion to uncited transcription.
2. The starter code. Rule out that the constructs came from what the instructor provided.
3. Process artefacts. Commit history, file timestamps, and editor metadata, if the submission method captured them. If it did not, say so plainly rather than inferring from absence.
4. Structural comparison. Diff the ray-tracer core: identical comments, dead code, unusual refactors, and the same non-obvious bug are far stronger evidence than shared idioms; near-identical unused code is very hard to explain independently.

Then interview individually, with the same scripted question set, asking each student to explain why 1e-4 works, what happens at 1e-3 and 1e-5, and how the tie-break affects tree quality. A student who wrote the code can reason about it; a copier often cannot, but eloquence is not proof either way.

What the evidence cannot settle. It cannot distinguish "watched the same tutorial and transcribed it" from "copied each other" without the tutorial check, and it cannot establish intent. Because the syllabus is genuinely ambiguous about tutorials, the defensible finding may be "policy was unclear" rather than misconduct. The roommate pair is the one case where pairwise similarity metrics beyond the shared source are worth computing. File the required report inside the five-day window with the ambiguity stated, and ensure the accommodated student's process uses the oral format their plan allows, without treating the accommodation as suspicion.

Separate the two matters procedurally and connect them pedagogically.

Procedurally, the slide is a professional-practice issue, not a student-discipline issue, and must not be traded against it - neither "I'll drop the student case if you drop the slide" nor "the students copied because I did". Handle it on its own track: verify the source, check whether the textbook's licence permits reproduction or only citation (many require permission for figures, so replacing it with an original diagram may be the only compliant route), then correct the slide with a full credit line, or redraw it, before the next delivery. Disclose the correction to the class briefly and without drama, and tell the chair if departmental practice requires it. Check the rest of the deck for the same problem, since one instance rarely travels alone.

Pedagogically, the lapse is an asset if handled openly. Students who watched the instructor correct an attribution error learn the norm more effectively than from a policy paragraph. Use it to introduce the citation format you will require for tutorials, code, textures, and AI tools, and to explain the difference between learning from a source and presenting a source's work as your own - the exact distinction at stake in their own case.

What must not happen is using the lapse as an excuse to drop the student inquiry, or using the student inquiry to minimise the slide. Both are handled on the merits, documented, and resolved within their own timelines.

Policy text. Replace "discuss ideas freely" with a short, concrete contract: what may be shared (verbal discussion of algorithms, debugging help on your own machine, the provided starter code), what must not be shared (source files, in any form, including screenshots and chat pastes), and how to cite tutorials, forum answers, generated images, and AI assistance, with an example of an acceptable citation. State that following a tutorial is permitted if cited and if the student can explain and modify the result.

Assignment design.

• Individual variation: require each student to justify one design choice against a measured alternative (e.g. SAH versus median split at a given scene), so submitted text and numbers differ even when the skeleton is shared.
• Process artefacts: require a commit history or short design log, and grade the log as evidence of iteration, not as surveillance.
• Oral defence: a 10-minute code review where the student opens a random function and explains it, weighted lightly (e.g. 10% of the assignment) so it can be graded fairly and accommodated.
• Staged milestones (ray-primitive intersection, BVH build, traversal, shading) so copying is visible as a discontinuity and feedback arrives before the deadline.

Resubmission path. For unclear-policy cases, permit a capped resubmission (e.g. maximum 70%) with correct citations plus a short written explanation of what was reused; reserve the full penalty for cases where evidence shows deliberate concealment after the new policy is in force.

Grading under the new scheme. Score correctness and performance against a fixed test suite (render time on a supplied scene, image similarity to a reference), score design justification and code review separately, and publish the rubric with weights before the assignment opens. Run the similarity check as a screening tool, never as a verdict; any flag goes to the same evidence-and-interview process used here.