Hello everyone,
I'm thinking about making a small update to the Animation class so that it
can handle animating 3D graphics too. (Details below.) Since this is a
frequently-requested feature, I wouldn't be surprised if people have
already done some work on it, or at least have strong feelings about how it
should be done. But I haven't found a Trac ticket for it -- could someone
point it out to me if it doesn't exist?
Likewise, please let me know if the following analysis seems flawed:
Identifying the problem:
The Animation object type-checks its input with
isinstance(x,Graphics)
Since 3d graphics are (strangely!) not a subclass of Graphics, the test
fails and 3d objects cannot be animated. Nor can Tachyon objects, nor
GraphicsArrays, for that matter.
Ideas for solution:
1. remove the type-checking all together, and use some kind of try/except
duck typing instead
2. rearrange the graphics classes so that *all* graphical objects are a
subclass of some one class, and objects which cannot be saved to image
files are not subclasses of that class
3. implement a more robust type-checking function
Further analysis:
Solution 3 is relatively easy to implement, but relies on type-checking.
This will be problematic if some future Sage graphical class (e.g.
Graphics4d) is developed but the type-checking function is not updated to
work with this new type of object. Or [Insert other standard arguments
against type-checking here].
Solution 2 would require a major overhaul, and I'm not interested in such
an undertaking.
Solution 1 sounds great, but is problematic upon further reflection:
Nearly every Sage object has a "save()" method, but only some of these can
produce an image. If you try (x^2 - x + 1).save('tmp_filename.png'), for
example, your expression will be nicely saved as tmp_filename.png.sobj.
When you later try to animate the saved images, they will be missing. But
animating a sequence of images is done by os.system('convert ...'), using
the ImageMagick convert tool (or ffmpeg instead). As a consequence, error
handling is unreliable (How do I know if the thrown error is a result of
convert not being installed, rather than the png file not being found?).
So I'm planning to do something like Solution 3, and to make Animation more
robust by also developing a better fallback method in case the
type-checking fails. I suppose a hybrid of Solutions 1 and 2 might be to
instead add something like an is_graphic() method to each of the major
graphics base classes, and then use the existence of that method for duck
typing. But there is already a function named is_Graphics(), which checks
whether its input is a Graphics instance, and Solution 3 seems to be the
approach which is most consistent with that function (for better or for
worse).
Please feel free to give me a better idea, or let me know where else I
should be looking for solutions.
best,
Niles
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
