Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Interface to Mitsuba 3 renderer #445

Open
vsnever opened this issue Jul 3, 2024 · 2 comments
Open

Interface to Mitsuba 3 renderer #445

vsnever opened this issue Jul 3, 2024 · 2 comments
Labels

Comments

@vsnever
Copy link
Member

vsnever commented Jul 3, 2024

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
Copy link
Member

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants