From: Bob Hanson <hansonr@st...> - 2007-04-18 16:02:32
OK, I need advice.
What I plan to do later this week is to integrate the Jvxl class code
into Jmol. I want to do it right, and I'm not sure where it should go.
Here's the idea:
Currently we have:
QM calculation stuff
Mopac calculation stuff
MEP calculation stuff
Isosurface (a MeshCollection)
IsosurfaceMesh (a Mesh)
The problem is that Isosurface is just packed with way too much stuff.
I'd like to make it a front end for a SurfaceGenerator Jvxl class that
will do all the calculation business based on being sent a set of
jvxl/readers/Parameters and jvxl/data/volumeData structures.
What I'm thinking is making isosurface implement the
jvxl/calc/MarchingReader interface and tying a jvxl/data/meshData
structure to IsosurfaceMesh. That interface just lets the Marching Cubes
and Marching Squares algorithms report back a set of verticies and
triangles on the fly.
I'm thinking Isosurface can mostly just pass on any setProperty() calls
to an instance of SurfaceGenerator, but I'm not sure exactly how to do
Q: Where's the proper place for what is now org/openscience/jvxl?
Q: How do you make it so that both the stand-alone Jvxl program and Jmol
can use all the classes currently under org/openscience/jvxl?
Q: Is it acceptable to leave the various data elements in JvxlData and
VolumeData public, or do I have to write accessors for each and every
one? Can I avoid "public"? Does it matter?
Q: Ultimately Isosurface has to pass vertex and triangle information on
to IsosurfaceMesh. Should it just hold onto a copy of volumeData until
the very end and then just pass it on to IsosurfaceMesh? Is that the