You might want to have a look at vpython:
It originated at Carnegie Mellon as a program to teach undergraduate
physics such that with very little code (and critically, no 3d
programming or OpenGL knowledge), one could
create a physics problem with
> components such as ramps, blocks, balls, pulleys, and springs, and
> processes such as motion (translational or rotational), collisions
> (elastic, inelastic, completely inelastic), and forces (friction,
> gravity, normal forces, driving forces, etc).
:)
Even if it doesn't fit precisely your needs, it's probably good
inspiration and has been around for ~ 9 years. I've used it (the old
version) for small demos and it's really nice.
Cheers,
f
Thanks for pointing that out. So far, I've noticed Kevin is very
good at taking existing things and plugging them together.
Maybe he could provide an AJAX-style web-based interface to some
vpython functionality?
William
Since we also already have momentum for incorporating mayavi, we should
also point out the mayavi tvtk "visual" module, whose api is modeled
after vpython:
https://svn.enthought.com/enthought/wiki/TVTKIntroduction#visual
I've used vpython too, and I thought it was really nice and simple.
Jason
--
Jason Grout
You might also consider integrating pydy in:
it uses sympy to generate the equations of motion for a rigid body and
scipy to solve them.
Ondrej
Prabhu may comment with more information, but in the meantime, it's
worth keeping in mind that 'tvisual' has significantly lower
performance than visual, and in this case I'm not sure it can be
fixed. The issue is that the traits event handling machinery proves
to be too much overhead when you're trying to render a 3d scene at
interactive framerates, and the geometry is already being computed by
a python loop. Since tvtk is based on traits, all the traits machinery
is still active and in this case may be a bit too much.
If memory serves me right, Prabhu wasn't super optimistic about being
able to match vpython performance with tvisual, but I could (and would
love to) be misremembering, or perhaps it's just a matter of putting
manpower into it and not a fundamental limitation.
I just mention it so you are aware that out of the box, tvisual's
performance is just not enough to be usable like vpython is (and I
only tested it on fairly simple examples).
In case you'd like to run a simple comparison (and perhaps things have
improved), I'm attaching a simple example of parabolic motion written
both for vpython (old version) and tvtk/visual. Caveat: I haven't run
this code in years, so I'm not sure it runs with today's vpython or
tvtk.
Cheers,
f
Thanks Fernando. The speed issue is still true but I wouldn't blame
traits since that isn't the source of the bottleneck. I think there are
a little too many events and too many renders. I have not had the time
to profile it carefully.
> If memory serves me right, Prabhu wasn't super optimistic about being
> able to match vpython performance with tvisual, but I could (and would
> love to) be misremembering, or perhaps it's just a matter of putting
> manpower into it and not a fundamental limitation.
I am not sure at all, since I haven't had the chance to look closely
enough but it is possible that there are too many events flying around
calling too much Python code.
> In case you'd like to run a simple comparison (and perhaps things have
> improved), I'm attaching a simple example of parabolic motion written
> both for vpython (old version) and tvtk/visual. Caveat: I haven't run
> this code in years, so I'm not sure it runs with today's vpython or
> tvtk.
It does and visually there is no difference but there is an order of
magnitude speed difference between the two in terms of CPU time.
prabhu
In Januari I made a very, very experimental spkg for vpython.
See:
http://sage.math.washington.edu/home/jsp/SPKGS/VPython/
Screenshots:
http://picasaweb.google.nl/j.spies88/Vpython?authkey=CFT7gXmyzAA#
Jaap
Thanks for the clarifications, Prabhu. I remembered the performance
drop, but wasn't sure what all of the reasons were under the hood and
I was worried I could misrepresent the issue.
It would really be great to have vpython-like performance with the
clean tvtk api! Here's to hoping it's possible :)
Cheers,
f
There are some links at
It may be best to start with an existing package. How about GeoGebra
? Moreover, the best solution may involve both Java (e.g., for
rendering, interaction) and JavaScript (e.g., for control,
communication, updates). I think Jmol and GeoGebra are both JS-able.
Yes. Although Sage, for now, does not make extensive use of either
project's JS API, we could use them, e.g., to update the applets
dynamically, with results computed on the notebook server.
Jmol
http://jmol.sourceforge.net/jslibrary/
GeoGebra
http://www.geogebra.org/en/wiki/index.php/GeoGebra_JavaScript_Methods