uniform api for 3d graphics renderers

[nilesjohnson]

Refactor 3d plotting classes to create a uniform interface for rendering with various frontends. Will make it easier to maintain current and implement new rendering frontends. This will also make it possible to implement a new renderer outside of the Sage library, e.g. for prototyping.

Similar in strategy to rich representation as in #17234.

Note: we use 'render' in the most liberal sense. E.g. x3d "renders" to a particular format. Better term is welcome.

Idea: Instead of a repr method for each renderer on each 3d graphics class, put all rendering commands for a given renderer in a single class. Renderers are registered in a global dict, etc.

To do: Figure out precisely how this should interact with the rich_repr framework.

CC: @ohanar @vbraun @haraldschilly @novoselt

Component: graphics

Keywords: graphics3d, rich_repr

Branch/Commit: public/3drenderers @ c590694

Issue created by migration from https://trac.sagemath.org/ticket/18510

[nilesjohnson]

New commits:

48c7028	some stupid broken api code
3ab3f3e	some progress, but still mostly broken
f6442fa	more non-working stubs
df462f4	add FaceSequence and VertexSequence helper classes
31e7fb5	progress on jmol renderer
485bdf2	more progress on jmol renderer

[nilesjohnson]

Commit: 485bdf2

[nilesjohnson]

Changed branch from public/3drenders to public/3drenderers

[sagetrac-git]

Changed commit from 485bdf2 to dd6cdf9

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

dd6cdf9

some fixes, some progress

[vbraun]

comment:3

+1 to the idea

Its a variant of the translator pattern, so maybe name things JmolTranslator etc?

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

8305657	skeleton files for other renderers
1f756f1	more progress
6444541	renderers now work correctly for Graphics3dGroup and TransformGroup

[sagetrac-git]

Changed commit from dd6cdf9 to 6444541

[sagetrac-git]

Changed commit from 6444541 to 4e6a7dc

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

4e6a7dc

sphere for tachyon

[sagetrac-git]

Changed commit from 4e6a7dc to ae8ccb5

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

ae8ccb5

initial idea for rich_repr

[sagetrac-git]

Changed commit from ae8ccb5 to c7def5f

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

9f6d8cf	move some jmol stuff
c7def5f	Merge branch 'public/3drenderers' of git://trac.sagemath.org/sage into public/3drenderers

[sagetrac-git]

Changed commit from c7def5f to 98873c0

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

98873c0

fix compilation

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

7c3ac01	start adding graphics3d preference
5cc7f56	register name instead of __name__

[sagetrac-git]

Changed commit from 98873c0 to 5cc7f56

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

b6e0cc1	cylinder for tachyon; probably broken
c496e19	Merge branch 'public/3drenderers' of git://trac.sagemath.org/sage into public/3drenderers
372c662	changes

[sagetrac-git]

Changed commit from 5cc7f56 to 372c662

[sagetrac-git]

Changed commit from 372c662 to 0aeaca6

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

0aeaca6

fix rich output hopefully

[vbraun]

comment:12

The idea behind the rich output is that the backend knows best which implementation to pick. The graphics preferences is just to express some overall preference, but it shouldn't be used to micromanage the implementation. E.g. for 2-d graphics there is a choice between raster and vector graphics, but which raster graphics format (png/jpg/gif/...) is intentionally not specified: Which one of those is best depends on the backend capababilities, e.g. the IPython notebook can't display gif. This is also easier for the user since he doesn't have to know the difference between different implementations nor their support in different backends.

For 3-d graphics there is a logical choice between rendered (2-d bitmap) vs live 3d, but shouldn't offer further controls on the particular implementation. More is just confusing to non-experts (what is jmol and why is it not working [if I don't have java installed]?). Let the backend decide what produces good quality and what doesn't.

[ohanar]

comment:13

Right now the preferences that you can set aren't really publicized, so at the moment, non-experts will never really see the preferences. Moreover, I think that you should support experts who might care about the format that they get (e.g. they always want jpg over png) and that they should be able to set their preferences as such.

Additionally, with the binary choice, I wouldn't be able to implement a renderer outside of the sage library and use it as the default in my own backend, since all of the renderers within the sage library would be preferred over my own.

For instance, SMC does not currently use a backend, but rather monkey patches things because it uses its own threejs based renderer. While this stuff will likely eventually make its way into the sage library, you shouldn't be forced to implement these things in the library itself. If the backend can specify its own preferred renderers, then it is possible implement such things outside of the sage library.

[sagetrac-git]

Changed commit from 0aeaca6 to fb1292f

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

fb1292f

todays progress

[sagetrac-git]

Changed commit from fb1292f to b5c7cac

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

8582fd9	set graphics3d preferences for various backends and fix doctests
b5c7cac	clear out stubs and move docstrings/tests into apropriate files

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

80067fe

make python stop complaining about indentation

[sagetrac-git]

Changed commit from b5c7cac to 80067fe

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

85f083e	make renderers singleton classes
c590694	make register stuff work

[sagetrac-git]

Changed commit from 80067fe to c590694

[vbraun]

comment:19

No, the preferences are what you access through %display, so they are in fact the easiest and intended way to interact with the display manager. Thats why its user hostile if you name settings after obscure package names, and confusing to boot since not every 3d implementation makes sense for every UI.

If you want to micromanage the format then there is already foo.plot(viewer='jmol') and friends. The keyword name might/should be changed but at least its hidden away so that no ordinary user has to deal with it. An alternative would be foo.save('output.obj').show() and use the file extension to guess the type.

You can't realistically have pluggable arbitrary rich output, the author of the Sage object needs to know what the possibilities are in order to decide on the suitable rich output. Now for the the very special case of just 3d graphics that might make sense, but then you can easily do that by

def _rich_repr_:
    ... try sane defaults first ...
    # if none of the defaults work try the rest 
    for output_type in display_manager.supported_output():
        try:
            return renderer(self, output_type) 
        except:
            pass

and then declare a particular output type as the only supported one from your backend.

[vbraun]

comment:20

PS: "render" has a rather narrow meaning in the 3d graphics context http://en.wikipedia.org/wiki/3D_rendering, IMHO it would be clearer if you chose a different one