[FEATURE REQUEST] Output mesh rendering

[ES-Alexander]

Is your feature request related to a problem? Please describe. Following on from #25, it has been raised that it would be useful if we could create renders of our generated meshes. It's currently possible to visualise the meshes using Plotly, but those visualisations lack realistic materials and lighting, which can be important aspects in the research space and for images to put in publications.

Describe the solution you'd like At minimum:

• An example of how to take an exported mesh from FullControl, and render it with freely available software

Ideally:

1. Photo-realistic image rendering
2. Customisable materials and lighting
   • Transparent materials could be important for some applications
3. Customisable camera positioning, with automatically determined reasonable defaults
4. Generable from within a FullControl workflow
   • e.g. being able to set up a render with a Python function, rather than needing to manually configure it in some other software
   • Simple interface by default, with customising available but optional
5. Renderer package-able with FullControl (e.g. installable automatically using pip, as an optional project dependency)
6. Option to generate animated renders
   • Predominantly for cycling through multiple views
   • In future possibly displaying motion about joints, or even flexing under stress
     • advanced use-cases could include things like bi-stable mechanisms
   • .avif format is efficient, and supported by most modern browsers
     • Safari specifically on iOS devices is an exception (but safari on macOS is ok)
   • .gif format is likely supported by most image viewing devices at this point, but suffers from colour banding (due to a limited palette) and uses excessive memory (due to poor compression)

Describe alternatives you've considered The first place my brain goes to for rendering is Blender, which is likely an excellent option for advanced render generation (particularly within custom scenes), but is likely too heavy to be ideal for an average FullControl user. That said, it does have Python support (see this relevant example), and is capable of all the rendering-specific "ideal" features, so is definitely worth considering if we can't find something readily package-able with FullControl, or even just as a more advanced option for users who run into limitations of whatever alternative we can find.

Additional context Direct rendering from within FullControl may be outside the scope of the project (especially if it's complex to do). It would be cool and valuable though, so is at least worth looking into.

• STL mesh exporting was added in #25
• Meshes that are ideal for rendering may be better suited to a different format (that allows specifying colours / material properties)
  • Perhaps one of the alternatives discussed in #20

[fullcontrol-xyz]

I would love this to be super simple for users. Automatic generation of blender python scripts from FullControl at the same time as the STL export seems relatively simple as long as someone with the know-how can create a template for those scripts. I suggest these to be created by FullControl rather than being static scripts because I assume there may be some part-specific information required in the script. That may not be the case if the scripts automatically identify part size and sensible camera positions (or allow users to rotate in blender). What could be cool is if there was a FullControl object where you could specify camera position and shading effects, and maybe other controls, and feed them into the fc.transform functions as a RenderControls object like PlotControls. This would mean users need to understand the FullControl options but not blender at all. It also makes things easy to translate to other renderers since the rendering intentions are recorded in a non-software-specific format. Very much in line with overarching FullControl principles. I think it would be great if the user could use blender with literally zero knowledge of it by running our auto-generated python script. E.g. Like this

Another option that seems super easy for the end user is to consider linking in with js and something like threejs. I've done that in some testing work previously, I think using a magic js cell in js. This worked in colab too if I remember correctly, which would be beyond the requirements for convenience. But it would be super easy for anyone to do then. And would work in offline jupyterlab of course. There is also pythreejs, but I for some reason preferred pure threejs to that.