#53 Revamp 3d backends?
Hello,
I'm very fond of the clean appearance of Asymptote-generated (2d) output and I'd like it to produce similarly clean 3d output as well, preferably imitating the style of technical drawings or high-quality toon shaders. A NPR backend with vectorized output would probably be very difficult to implement, but it should be reasonably simple to implement OpenGL-based (rasterized, unfortunately) NPR techniques like this one: https://developer.mozilla.org/de/demos/detail/cross-hatching-glsl-shader
I had a go with the Asymptote source code yesterday and it was surprisingly easy to add a fragment shader attribute to the material system and use that fragment shader during OpenGL rendering. However, I noticed that my compiler emitted lots of deprecation warnings concerning various glut functions (I'm on Mac OS X 10.10). Also, I had to set the GLUT_3_2_CORE_PROFILE to use fragment shaders, which only worked in -batchView mode, and it seems like a bad idea to add further functionality like texture samplers or custom vertex attributes to an OpenGL backend that clearly shows its age.
Since I have little experience with OpenGL and practically none with the Asymptote codebase, I assume that this is where I should ask the Asymptote maintainers for adult supervision.
From my rather uninformed point of view, it would be reasonable to replace the hard-coded OpenGL/PRC distinction by a more general 3d backend interface that could then either emit PRC, render via OpenGL, or possibly pass on the data to a vectorizing NPR renderer once available. It might then also be possible to export Asymptote scenes to Blender so we can piggyback on their excellent FreeStyle NPR module, or one could export WebGL scenes for interactive use in browser-based notebook interfaces like ipython or LightTable.
I think it should not be too difficult to generalize the current material system, based on colors and "ambient"/"diffuse"/"emissive"/"specular" attributes, to arbitrary vertex attributes and uniform shader inputs without sacrificing backwards compatibility.
I guess it may be much more difficult to do away with the freeglut dependence, since this is apparently needed for its NURBS functionality (?); maybe it's not even necessary or a good idea to get rid of it, I don't know.
I'd be willing to work on this in my spare time, but not without a clear concept. Please let me know your thoughts on this.
best,
Sebastian
