[P3][RENDER] Evaluate hardware ray tracing and path-traced lighting strategy

Open
  • Is something wrong?
#165 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
48/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
rust
Domain
computer-graphics

Research direction

Start by reading src/render/gi.rs and src/render/ssr.rs to understand the existing raster baseline, then inspect src/render/gpu3d.rs and the current wgpu backend capabilities. Identify one measured GI/SSR quality failure and a feasible backend path before building an isolated comparison. Done for the first slice means evidence on quality and GPU cost, with existing fallbacks preserved.

Written by the indexing model from the issue text.

Description

area: rendering help wanted priority: P3 type: research

Problem and goal

Competing with modern rendering stacks eventually raises RT/advanced GI questions, but this is not a near-term rewrite priority.

Implementation scope

  • Map available backend capabilities and constraints in current wgpu versions.
  • Measure GI/SSR quality failures that a ray-traced technique could address.
  • Develop a small isolated prototype and compare GPU cost, memory, and visual benefit.
  • Define fallback to existing GI and SSR.

Acceptance criteria

  • Decision document covering supported backends and quality/performance.
  • No dependency on a large visual editor.
  • No promise of production integration without demonstrable practicality.

Relevant code

  • src/render/gi.rs
  • src/render/ssr.rs
  • src/render/gpu3d.rs

Dependencies and notes

Do only after architecture, correctness, performance and streaming work.

Compatibility: preserve existing public Rust and C/C++ APIs unless an independently approved design explicitly requires a breaking change. Collect correctness results and before/after measurements for performance-oriented changes.

Source audit and first contribution (2026-11-09)

Reviewed against source baseline df5c1d4 and merged implementation PRs through #167. The full issue acceptance criteria are still open; this audit does not mark the task complete. Existing priority is unchanged.

Starting point: Existing GI/SSR provide a concrete raster baseline; hardware ray tracing/path tracing remains exploratory.

First slice: Identify a measured quality failure and feasible backend path before building an isolated comparison.

Dependencies and coordination: Retain P3; follow architecture, correctness, performance and streaming foundations. Keep existing fallbacks.

Focused Rust-only PRs are welcome; a contributor need not complete this entire issue in one PR or also implement C/C++ bindings and guide chapters. Maintainers coordinate scoped documentation/native follow-ups. Preserve existing compatibility and supply tests/evidence relevant to the slice.

Dominant language
Rust
Stars
4
Forks
0
Avg merge
45m
Merged PRs (30d)
199

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 ponkoengine/ponko

All issues in ponkoengine/ponko

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.