New renderer in Rust using the nsi crate
Opened this issue · 3 comments
Hello, sorry if my question is trivial, but what are the steps to use this crate correctly when writing a new renderer instead of using 3dlight ?
Sorry, I completely missed this.
You need to expose the C API. I.e. what is in the nsi.h header. The API is copy. I.e. anything passed-in is copied immediately. This is the safest way to do this in C.
The main issue is that you need to actually also replicate the functionality of NSI. I would be interested in helping writing this middle layer crate. That crate would keep the node graph representation and offer hooks to convert data to whatever internal representation the renderer requires.
Then there is the biggest challenge: Open Shading Language support. For shading NSI relies on OSL.
An alternative is to use pre-defined material/texture nodes that a renderer implements. And then combine them into a shading network via NSI, just as one would with OSL nodes.
Probably MaterialX would be a good, minimal, starting point. Of course, if you have OSL, you can just use the MaterialX reference implementation. Without OSL you need to translate the MaterialX nodes to your renderer.
As a reward you renderer is immediately available in Maya, Houdini and Cinema4D via the resp. OSS plugins on GitLab.
Once you have the C-API exposed, you can then compile your renderer to a dylib and load that instead of lib3delight.
When that happens I will gladly add code that lets a user select the rendering backend both at build time as well as dynamically, at compile time. I.e. there would probably be Context:new_with_backend() method that allows selecting the rendering backend for each context it creates.
Furthermore, once the middle layer exists, we could create a Rust-only version of the NSI API that offers move and borrow semantics for the data passed into a Context.
The C-FFI wrapper around that would just call the move version with a copy of the data passed in.