Niles,

Great!  However, we need to get together on this.  I'm slowly working 
towards solving some of these problems.  Unfortunately, I get a couple of 
hours a week to work on this until May/June, then things will open up a 
bit.  See trac 12299, where I have updated Jmol to produce static images by 
default.  I have a partially written package that works a lot like the 
Tachyon_RT package as well, but I haven't made it available because it is 
unfinished.

The other issue is that the way we package information for Jmol needs to be 
redone, so that interactive 3-D animations can also be produced.  Jmol is 
capable of displaying animations that you can zoom and manipulate while the 
animation proceeds, but the information needs to be passed to it properly.

Anyway, contact me off-list at gu...@uwosh.edu and we should get organized.

Jonathan

On Monday, April 9, 2012 4:02:45 PM UTC-5, Niles Johnson wrote:
>
> 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

Reply via email to