#5249: [with patch, needs work] implicit_plot3d functionality (isosurfaces, 3d
contour plots, etc.)
-------------------------+--------------------------------------------------
Reporter: jason | Owner: was
Type: enhancement | Status: new
Priority: major | Milestone: sage-4.0
Component: graphics | Keywords:
-------------------------+--------------------------------------------------
Comment(by wcauchois):
Here's a status update:
I posted to the jmol-users mailing list and Robert Hanson, who wrote most
of the isosurface code in Jmol, helped me find the problem with our JVXL
files. Apparently the JVXL specification is wrong. Where the spec says
{{{
for (int x = voxelCountX; --x >= 0;) {
for (int y = voxelCountY; --y >= 0;) {
for (int z = voxelCountZ; --z >= 0;) {
}}}
to demonstrate the order for visiting voxels (on page 7), it should be
{{{
for (int x = 0; x < voxelCountX; x++) {
for (int y = 0; y < voxelCountY; y++) {
for (int z = 0; z < voxelCountZ; z++) {
}}}
-- that is to say, the order is reversed. A quick fix for this is to
reverse the order of the edge data stored in self.bitmap in
MarchingCubesJVXL. I tried it and it worked.
Anyhow, I also wrote a backend based on IndexFaceSet, and that works fine,
and I've attached the patch. I think the IndexFaceSet backend should be
the default for both Jmol and Tachyon, since it offers a number of
features -- including mesh=True, transparency, and methods to manipulate
the mesh programmatically. As long as MarchingCubesJVXL is working, shall
we keep support for JVXL as a feature?
There is one outstanding issue with the IndexFaceSet backend, which is
that the scale for the Jmol plots is incorrect. If you try to graph
something, you can see that the figure will be larger than its bounding
box by a factor of about 3. I believe the bounding box is correct, so the
problem must be with the transformation matrix we are given through
render_params or the way we apply that transformation. On line 317 of
plot3d/base.pyx, in _prepare_for_jmol, I noticed that it applies some
scaling factor "s" (=3). Do we have to account for that somehow? Does
anyone have any insight into this issue?
So basically the major things left to do are to fix that bug, and add
doctests for everything. I will continue to work on this.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/5249#comment:23>
Sage <http://sagemath.org/>
Sage - Open Source Mathematical Software: Building the Car Instead of
Reinventing the Wheel
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en
-~----------~----~----~----~------~----~------~--~---
