Define a smaller supported scope
I would begin with a narrow scene model and explicit supported workflows instead of accumulating renderer features before the foundations were validated.
An early C++ renderer-integration project built to learn scene architecture and artist-facing tooling around Radeon ProRender. It is preserved as a record of what I learned, not presented as a production-ready engine.
I used Horus Vision to understand how a renderer SDK, scene data and an interactive tools layer fit together. The work focused on integration and interface architecture rather than developing a new light-transport algorithm.
I would begin with a narrow scene model and explicit supported workflows instead of accumulating renderer features before the foundations were validated.
I would place a clearer boundary between artist-facing scene data and Radeon ProRender-specific objects so the application is easier to test and change.
I would add repeatable reference scenes, image comparisons, supported-platform checks and measured timings before making quality or performance claims.
I would stabilise scene ownership, serialization and error reporting before expanding experimental interface features.
This portfolio entry describes the public alpha releases, from version 1.0 in October 2023 to version 1.3 in February 2024. It does not make claims about production readiness, commercial support, rendering performance or future features.
I learned that renderer features are useful only when scene state and feedback remain understandable. Integrating a third-party SDK made ownership and abstraction boundaries more important than feature count. Today I would validate a smaller core before extending the UI.