A simple 3D animation created with Maxima.

One of the things which I find myself doing quite often is, to be undertaking some sort of task on the computer(s), that I know is possible, but, not knowing in advance what the correct syntax and semantics are, to perform this task. This tends to take me on some sort of search on the Web, and I’ll find that other people have undertaken similar tasks, but not, a task with the same combination of parameters, as my task.

Thus, Web pages can be found according to which 2D animations have been created using a free, open-source Computer Algebra System named “Maxima”. Other Web pages may explain how to create various types of (static) 3D plots. But there may just be lacking examples out there, on how to create the 3D plot, but to animate it.

Using Maxima, there may be more than one way, such as, to keep refreshing the 3D plot over a time interval. But I find that such solutions tend to be second-rate, because of their use of busy-wait loops, as well as the possibility that they may otherwise be wasteful of computing power. I think that the best way, perhaps, to get Maxima to generate an animated 3D plot, could be, in the form of an animated GIF File (of course, as long as there isn’t an excess of frames to this animation).

Thus, the recipe that seems to work is as such:



scenes: []$

for i thru 20 do (
    scenes: append(scenes,
                x, -1, 1, y, -1, 1))]

    delay = 10,
    file_name = "wavy",
    terminal = 'animated_gif,


The script outputs a file named ‘wavy.gif’ in the same folder, as whatever folder it was originally stored in. In some cases, the GIF File may appear in the user’s home directory, or even, in a temporary directory that’s difficult to find, unless the user also gives a full-path name for the file.

And, this is the GIF File that results:




My most recent posting had to do, with a version of Maxima that had been ported to Android. The example above will not work with that version of Maxima. In fact, I can really only be sure that this feature works under Linux, which is the O/S that Maxima was mainly designed to run on. Any directives to ‘plot()’ or ‘draw()’ open a separate GNU-Plot window, which behaves in the predictable way under Linux, including the user’s ability to rotate the 3D plots interactively. AFAIK, commands to change to a non-default ‘terminal’ (for drawing and/or plotting) will fail on other platforms.

But, There is also a Windows or Mac alternative to using this platform, which mainly presents itself in the application ‘wxMaxima’. Here, the functions ‘wxdraw2d()’ and ‘wxdraw3d()’ replace those that open a separate window, and both embed their results in the wxMaxima worksheet. In order to make this more versatile, wxMaxima also offers the functions ‘with_slider_draw()’, ‘with_slider_draw3d()’, ‘wxanimate_draw()’, and ‘wxanimate_draw3d()’.

Potential ‘wxMaxima’ users will find the documentation for how to script that Here.

(Updated 7/06/2020, 15h35… )

(As of 7/04/2020: )

One of the questions I recently asked myself was, ‘If I create such a wxMaxima worksheet, with embedded plots that are supposed to have a slider each, and, If I then tell this graphical front-end to export the same worksheet to HTML, what exactly will happen?’ What I already knew was, that this ability to Export to HTML depends on having LaTeX installed on the same computer, which wxMaxima just happens to find easily, on a Linux system.

The answer to this self-imposed question is not as mysterious as it might first seem. When compiling such slider-plots, wxMaxima already plots the graphics, that follow from a finite set of slider-positions. Moving the virtual slider simply selects one out of several graphics.

Well, this can be exported to HTML, without any need to implement sliders. And, in order to view the following worksheet, it’s entirely optional, whether the user enables JavaScript, From my site, and From MathJax.org. That JavaScript would allow typeset formulae to appear. But this worksheet actually has zero of those! ;-)



I should add, that the extra parameters I gave, which (were), ‘enhanced3d=true,surface_hide=true,colorbox=false‘, served to change the appearance of the surface, from a wireframe, to a colour-coded surface, and can also be applied in the first example above. When this is done, they need to be stated inside the ‘gr3d…’ object, and before the ‘explicit()’ entry. They cannot simply be added to a ‘draw()’ function-call, because by default, that would not be a 3D Drawing function. It’s inside the ‘gr3d()’ function-call, that the 3D extension of the plotting function is activated, and that these parameters can also be set.


(Update 7/06/2020, 15h35: )

I grew bored with the colour-coded surfaces that I had been using until today, and just wanted to demonstrate a recipe, to create a more interesting effect, of a uniformly grey surface with blue grid-lines.

A key to understanding this overlay is the fact that I first needed to draw the wireframe version of the plot, with ‘surface_hide=false‘, and then, to draw the second instance of the same scene-object, with ‘enhanced3d’ set, and with ‘wired_surface=true‘. This could also be interesting for readers to note, who already use some version of ‘Maxima’, but who may not know how to specify the colour of the ‘wired surface’ effect. The way it gets rendered is such, that the wired grid is open, as in, not rendered to, so that if its positions in the plot already contained a wire-frame, that will not be overwritten by the (‘enhanced3d’) surface.



Print Friendly, PDF & Email

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>