Path tracing can produce remarkably realistic lighting, reflections, and shadows, but that visual quality comes with a fundamental responsiveness problem. When an artist moves an object, changes a material, or adjusts a light, the renderer may effectively restart the entire image—even when only certain areas are meaningfully affected. For creators working in look development, virtual production, level design, or architectural visualization, that delay can interrupt the iterative process.

Hierarchical Progressive Rendering, or HiPR, approaches the problem as one of scheduling. Developed by University of Utah researcher Rafael Padilla alongside Andrew Tate, Dhruv Ram, and Cem Yuksel, the technique identifies where an edit is directly visible and follows its influence through reflections, shadows, indirect illumination, and other light-transport paths. It then updates the most important image regions first while the remaining pixels progressively catch up, ultimately producing the same unbiased path-traced result.

You can read more about the work in the full research paper.

We spoke with Padilla, whose background includes production work at Walt Disney Animation Studios and DreamWorks Animation, about connecting a scene’s logical state more closely to its renderer. He discussed how HiPR constructs its hierarchy of affected regions, determines perceptual priorities, handles temporarily outdated pixels, and could eventually help path-traced creative tools, games, and XR experiences spend their rendering budgets where they matter most.

First, can you please tell me a bit about you, your research, and your background as an introduction?

Rafael Padilla: I’m currently a master’s student in Computer Science at the University of Utah, focusing on computer graphics and rendering/simulation. Before starting the program, I worked in the animation industry at Walt Disney Animation Studios and, most recently, at DreamWorks Animation, where I worked on graphics problems from a very practical, production-focused perspective. That experience made me especially interested in the gap between what rendering technology can do and how responsive it actually feels to artists and users.

That led me to interactive path tracing. Path tracing can produce incredibly high-quality images, but when you make a small change to a scene, the renderer often has to effectively start over. I became interested in whether we could make the renderer smarter about where it spends its time.

That is what led to HiPR, or Hierarchical Progressive Rendering, which I developed with my collaborators Andrew Tate, Dhruv Ram, and Cem Yuksel. The core idea is to treat interactive rendering as a scheduling problem. Instead of giving every pixel equal priority after an edit, we use light transport to figure out where that change is likely to have an effect and update those areas first.

More broadly, my research focuses on interactive rendering and graphics systems, and on how we can make physically based rendering feel much more responsive and useful in real creative workflows or real-time applications like games and VR.

What led you to focus on render scheduling specifically as the solution to interactive path tracing?

Rafael Padilla: One way I think about modern 3D applications is that they really have two levels. There is a simulation or logical world, which describes what exists, how objects behave, where they are, and what has changed. Then there is rendering, which turns that state into an image that we can actually see.

Historically, those two levels have been fairly loosely connected. The application knows that an artist moved a chair, changed a material, or turned on a light, but the renderer often sees that simply as, “The scene changed, so I need to render the new scene.” It does not necessarily understand the meaning of that change or how it propagates through the image.

I think that disconnect becomes increasingly important as rendering techniques get more sophisticated. With path tracing, for example, a tiny change in the logical world can have a highly nonlocal effect on the rendered world. Moving one object might change a reflection across the room, a shadow on the floor, and indirect illumination on a wall. Yet the rendering system can still treat the whole frame as equally important.

That led us to a simple question: what if the renderer could better understand what happened in the logical world?

Instead of assuming every pixel needs to be recomputed with equal priority, HiPR uses the change itself as information. We identify where the edit is visible, track how its effect propagates through light transport, and then schedule rendering work based on where that information is most likely to matter.

So the core idea is less about making a path tracer fundamentally faster and more about connecting these two worlds more intelligently. We are changing the order in which information reaches the screen, rather than changing the underlying path-tracing algorithm or the final result. The goal is to make the renderer respond to the *meaning* of an edit, not just the fact that a frame has changed.

When an artist moves an object, adjusts a material, or changes a light, how does HiPR determine which pixels are affected—particularly when the change influences reflections, indirect illumination, shadows, or caustics elsewhere in the image?

Rafael Padilla: The key idea is that a change in a 3D world can have consequences far less (or far beyond) the thing you actually changed. Move an object/player, change a material, or adjust a light, and the effect can travel through reflections, shadows, and indirect light to completely different parts of the scene.

We think of that almost like ripples in water. The edit is the splash, and light transport determines where those ripples go.

A conventional renderer often has to play it safe and update the whole image. HiPR instead tries to follow those ripples. We start with where the change is directly visible, then trace how its influence propagates through the scene. As we discover other visible areas that may be affected, we prioritize those areas for rendering.

This is useful across film, games, VR, and other interactive 3D applications because the important question is often not “How fast can I render everything?” but “How fast can I see the consequence of what I just did?”

So at a high level, HiPR asks the renderer: “Where does this change matter?” Once we know that, we can spend our limited rendering time there first, giving people useful visual feedback much sooner.

Could you explain how the hierarchy of light-path dependencies is constructed and how the system decides which parts of the image will provide the most perceptually important feedback to the artist?

Rafael Padilla: The hierarchy starts with the directly affected region and then expands through the light paths discovered while rendering that region. This means that, using some heuristic, you must first select your "most important subjects," such as the object in editing, a game's player, or another criterion.

We represent the image as a set of tiles. When we trace paths from the initially affected tiles, every visible secondary interaction can effectively vote for another tile. The contribution of that interaction is weighted using the accumulated path throughput, the bounce depth, the type of scattering event, and the class of light path.

So a tile that receives many strong transport contributions from paths originating at the changed element will accumulate a larger weight than a tile that is only weakly or distantly connected.

We then sort the discovered tiles according to those weights and render them in descending order. The weighting also gives us a way to express perceptual priorities. For example, specular or direct responses can be prioritized differently from diffuse or deeply indirect transport. In a glass-heavy scene, we may want transmission and caustic effects to appear earlier; in a mirror-heavy scene, reflected changes may be more important.

That is why we call this a hierarchy: there is a natural progression from the directly changed region outward through increasingly indirect consequences of the edit. The interesting thing is that the hierarchy is not simply based on image-space distance. It is based on how the edit actually travels through the scene’s light transport.

HiPR keeps some existing pixels on screen while progressively updating others. How do you prevent the intermediate image from becoming misleading?

Rafael Padilla: There is a tradeoff here between image freshness and rendering effort. HiPR is deliberately designed to prioritize useful feedback, rather than insisting that every pixel become up to date immediately.

When we render a region, we are still using the same unbiased path-tracing process. We are changing the order in which work is done, not the underlying rendering algorithm. That means the image can temporarily contain a mixture of newly updated pixels and information from before the edit, but as rendering continues, the rest of the image catches up, and the final result remains a fully converged path-traced image.

What counts as an acceptable intermediate image is also very context-dependent. An artist working on a film shot may want the character, its reflections, and the nearby environment to update immediately, while a distant background can afford to lag behind. In a game or VR application, we could make that even more explicit: prioritize the player and the most important light-transport dependencies around them, such as reflections on the floor, walls, or nearby objects, while updating a large distant environment less frequently.

That suggests a broader direction for the future. Rather than treating every frame and every pixel equally, the renderer could adapt its update rate to perception and context. Some parts of the world might need to update every frame, while others could be refreshed every few frames or even less often without anyone noticing.

HiPR is a first step toward that idea. We show that rendering can use knowledge of scene changes and light transport to decide what deserves attention first. Future work could go further by accounting for the size of an edit, using motion and simulation data to guide rendering, and automatically learning which light-transport effects are perceptually important. Ultimately, the goal is to make the renderer more aware of what changed, where it matters, and how quickly that information actually needs to reach the screen and, most importantly, the retina.

What kinds of edits and scenes currently benefit most from HiPR, and where does the approach struggle?

Rafael Padilla: HiPR’s sweet spot is situations where someone is actively shaping a 3D world and needs to see the consequences quickly. That makes it especially promising for look development, games, virtual production, level editing, architectural visualization, and XR. Change a material, move an object, or adjust a light, and HiPR can prioritize the parts of the image that matter most instead of restarting everything equally.

For games/VR in particular, the renderer could prioritize the player, nearby objects, and important reflections, shadows, and indirect lighting, while allowing a distant environment to update less frequently. The broader idea is that not every part of a world needs the same amount of rendering effort at every moment.

There are limitations. HiPR is most effective for localized changes. Large lighting or environmental changes (e.g., changes in sunlight) can affect much of the image, leaving less work to prioritize. Camera motion is also challenging in the current system, since some objects may change dramatically while others barely move perceptually due to parallax, one of our directions of future work.

There is also room to make the system more perceptually aware. Future versions could consider the magnitude of an edit, motion, and simulation data, or even where the viewer is actually looking (foveation).

So I think the larger idea is simple: the renderer should spend its effort where it matters most, rather than treating every pixel as equally important.

How difficult would it be to integrate HiPR into established production renderers or game-engine path tracers? Where do you see the greatest immediate value: look development, virtual production, level editing, architectural visualization, or eventually path-traced gameplay?

Rafael Padilla: One of the things we are most excited about is that HiPR can be relatively easy to integrate into an existing ray or path tracer. The core idea is a scheduling layer that helps decide what rendering work should happen next, rather than requiring developers to replace their renderer.

The SIGGRAPH paper explains the algorithm through three simple stages, which was important to us. We wanted the core idea to be understandable and practical, rather than buried inside a complicated rendering system.

What we showed at Real-Time Live! was a Vulkan reference implementation, which we plan to release soon. We are also working on a follow-up paper for SIGGRAPH 2027 that takes the approach much further, and the results we have seen so far have been incredibly encouraging.

As part of that 2027 work, we also want to make HiPR much easier to adopt. The goal is a very lightweight API that could essentially be pulled into an existing ray or path tracing project as a Git submodule or a small header-only library, with minimal changes to the renderer. So instead of treating HiPR as a large rendering framework, the idea is that it should feel more like adding a useful building block to an existing system.

In terms of applications, I think the immediate value spans content creation and interactive 3D: look development, virtual production, level editing, architectural visualization, games, and XR. Games are especially exciting because the engine already knows so much about context. It knows where the player is, what is moving, and what matters to the experience. That information could be combined with light transport to continuously decide where rendering effort matters most.

That leads to the bigger idea behind all of this. As ray tracing becomes more common, the challenge is not only to make it faster. It is to make the renderer smarter about where, when, and why it spends its computation.

Rafael Padilla, Researcher and  University of Utah Computer Science Master's Student

You can read more about the work in the full research paper or watch the SIGGRAPH presentation here.