Repository navigation
Improve debug rendering for trigger volumes - #114
ccp-zoetrope wants to merge 2 commits into
Conversation
There was a problem hiding this comment.
Copilot review overview
🟢 Approval recommended
The focused debug-rendering changes are consistent across all volume shapes and no correctness issues were identified.
Review effort: Balanced
Findings: None
What changed in this PR
Adds clearer debug visualization for trigger volumes through translucent fills, visible occluded outlines, and state labels.
Changes:
- Adds shared debug color and inside-face rendering helpers.
- Adds translucent two-sided fills to box, sphere, and ellipsoid volumes.
- Displays trigger name, state, and intensity.
| File | Description |
|---|---|
trinity/Eve/Volume/IEveVolume.h |
Adds shared debug-rendering helpers. |
trinity/Eve/Volume/EveSphereVolume.cpp |
Adds sphere fill and occluded outlines. |
trinity/Eve/Volume/EveEllipsoidVolume.cpp |
Adds ellipsoid fill and occluded outlines. |
trinity/Eve/Volume/EveBoxVolume.cpp |
Adds box fill and occluded outlines. |
trinity/Eve/EveTriggerVolume.cpp |
Adds the trigger state label. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Wireframe-only outlines are hard to read from inside a volume. Add a translucent fill to all three volume shapes (box, sphere, ellipsoid) and a text label showing the trigger's name, state, and intensity. Both pick up the volume's existing debug color, which turns green once the tracked position enters the trigger. The debug renderer culls back faces, so each shape draws its fill twice, the second time through a mirrored transform that flips the winding to render the inner faces. Shared via helpers in IEveVolume.h so all three shapes behave the same way.
59981b8 to
3ab6110
Compare
|
Looks good, but we need to run it past artists: these volumes are also used for other things, for example, to define post-processing volumes. I wonder if solid fills would get in the way of artists tweaking visuals. |
|
@filipppavlov I didn't consider that this is also used by post-processing volumes :/ In Graphite, this already uses a gizmo that handles being selected and showing correctly (https://github.com/ccpgames/platformtools/pull/3497). This particular PR was meant only for using and debugging in the client. But in this case that would make it so that it would turn the volume green if your ship was inside it for post-process volumes as well, which I assume would not be ideal for artists. I think I may have to take this to the python side instead and do some custom code there instead for trigger volumes specifically in that case |
Summary
Wireframe-only outlines are hard to read from inside a volume. This PR adds a translucent fill to all three volume shapes (box, sphere, ellipsoid) and a text label showing the trigger's name, state, and intensity. Both pick up the volume's existing debug color, which turns green once the tracked position enters the trigger.
The debug renderer culls back faces, so each shape draws its fill twice, the second time through a mirrored transform that flips the winding to render the inner faces. Shared via helpers in IEveVolume.h so all three shapes behave the same way.
Linked issue (optional)
EF-19776
Testing
I added a box shaped trigger volume to a dungeon and it was much easier to tell if I was entering it or not. It was also much easier to tell what space it filled up. Before this, the wireframe only rendering made it very hard to actually see what area of space a trigger volume actually took up.
AI assistance
Most of the code was generated by Claude Fable 5.1