Interface to Mitsuba 3 renderer

[vsnever]

Mitsuba 3 is a high-performance ray tracer that implements differentiable rendering, a technique ideal for inverse problems. It can ray-trace spectra and polarised light. It uses a JIT compiler with a CUDA backend and supports the Nvidia OptiX engine, making it orders of magnitude faster than Raysect.

Mitsuba 3 currently does not have off-the-shelf volumetric emitters, but does have a volumetric integrator and supports grid-based volumetric data sources. There is a PR, which adds volumetric emitters.

While building Cherab on top of Mitsuba instead of Raysect is as difficult as building a new package from scratch, I'm wondering if we should provide at least some interfaces to this renderer, given that it's starting to gain popularity in the fusion community and is already being used in Oak Ridge and MIT/CFS.

[jacklovell]

I would support this once volumetric emitters are implemented: it's come up a couple of times in discussions at ORNL and the performance benefits and polarisation support are compelling. It will be a big job and will require somebody to dedicate considerable time to developing and testing such an interface, but if that effort can be found this would be a very nice enhancement indeed.

Our documentation does state that multiple rendering engines should be possible:

Raysect is currently the only ray-tracing engine supported, but the framework has been designed such that this component is interchangeable. Support for other ray-tracers may be added in the future.

Guess it's time to put this into practice.

In terms of implementation, we would need to maintain compatibility with Raysect as well. Probably by introducing something like a cherab.renderer module to act as the interface layer between renderers and Cherab models/diagnostic observers.

[Mateasek]

Hi,

I agree with what Jack said.

Allowing users to use multiple ray tracing backends is in my opinion a good step forward.

It will be a lot of work to make this change, because a lot of Raysect functionality is wired into Cherab, but I think it is the only way forward. We don't have the means here to develop both Cherab and Raysect to keep it up with all the advances around. If Cherab doesn't keep up, it will start stalling.

When mitsuba3 supporst anisotropic volumetric radiation sources, I think we should have a look into how we could make this transition and what would it mean.

The valuable aspect of Cherab is the radiation physics included in the library and the good user experience we try to maintain. These are the two main reasons why I think it makes sense to try to keep this show going.

[Microno95]

Hi,

I just recently saw this as an extension of Cherab linking back to the PR I have opened with the Mitsuba 3 renderer. I agree that Cherab should include an interface to the Mitsuba 3 renderer, but as the PR brings many architectural changes to support volumetric emitters as first-class emitters which can be sampled as part of Next-Event Estimation, it is unlikely to be merged any time soon.

Nonetheless, I will shamelessly plug my own work on the topic that this branch is suitable for volumetric emission from plasmas and has been used in

• https://arxiv.org/abs/2408.07555
• https://indico.fusenet.eu/event/28/contributions/198/

I'll continue to advocate that the emissive volume implementation is merged into Mitsuba 3, but if you have any requests in the interim for the volumetric emission component, let me know, I'd be happy to look into the architectural changes required. Currently top of my list is implementing

1. Spatially varying spectral emission rendering with Next-Event Estimation, and
2. Combined discrete and continuous spectra rendering,

but I'll add more things to that list if there is demand.