How interlinked are versions of Cycles and Blender? Would it be possible to download the source for e.g. Blender 4.x and Cycles 2.x and compile them together (if one wanted to use code from an older version of Cycles, but have access to UI/front-end features from a later version)? or would there be too many incompatibilities?
Also, I see that for Cycles on Windows with an Intel integrated GPU, you claim in the build instructions that precompiled libraries are necessary. What is this for–are the kernels not just regular OpenCL code? Does this put restrictions on how much the code of the kernels can be modified in a fork that is to run on such a GPU?
Very. Simply putting the code of two different versions into one build folder won’t work, especially not between Blender 2.x and 4.x.
OpenCL isn’t supported anymore since Blender 3.0. For Intel the oneAPI backend is used nowadays and these kernels are precompiled and shipped with Blender.
Then how easy is it to replace Cycles entirely with a custom-written renderer? Like for example to start from something simple like the “ray tracing in one weekend” renderer (https://raytracing.github.io/books/RayTracingInOneWeekend.html) and build up from there? Is the API that a renderer backend would need to implement well-defined? Is it possible even to build Blender without including Cycles–never mind writing something else to take its place?
So is this what the renderer add-ons for Blender use (e.g. LuxCore, Mitsuba etc.)? i.e. define a Python wrapper around their code and then use the bpy api to link them?