Behind what you can touch
Two faces. One bill. One selection.
The tree has 2,400 selectable bills. Drawing both artwork sides does not create another 2,400 chances.
One shared shape, many placements
The current Three.js tree uses instanced rendering: many papers share geometry and artwork, while each bill keeps its own placement matrix. A server-provided layout seed reproduces the branching arrangement. The visual seed is not a disclosed winning-bill ID.
Normal bill artwork is drawn in a front batch and a visual-only back batch. That bill presentation uses two draw calls when both batches are rendered; this is not a two-draw-call claim for the entire tree, garden, shadows or result animation. Shared resources reduce repeated object setup without removing selectable slots.
What a click actually identifies
The pointer raycast supplies an instance index. The active front layer checks hits from both physical sides of the paper, so seeing the back does not make a different bill. The visible back layer itself does not handle selection.
Accepted clicks change the bill’s selection highlight and the counter. Clicking that bill again removes it from the set before submission. A camera drag is not intended to become a selection. If two bills overlap on screen, a slight orbit or closer zoom gives you a less ambiguous target.
Why the scenery cannot win
Grass, leaves, rocks and water are decoration, not selectable bills. A garden lantern does not carry a hidden game ID. The tree’s appearance and day/night lighting do not answer whether a bill wins; that information stays on the server until the final batch is checked.
For a practical example, mark one bill from Reset, then inspect the same selection from Top. The counter stays at one even though the camera and visible face change. Do this only during a round you intend to use, because the 120-second timer continues.
Screenshots show the game interface and may change as the game is updated.