Re: [Jmol-developers] Initial .cube file isosurface support

[<rka...@ri...>]

Oops,

Sorry, I got distracted by my own sentence.
What I was going for is that I can imagine that having a lot of=20
isosurfaces loaded for a particular structure may require too much=20
memory resources, in which case it would be nice to selectively remove=20=

them from memory too.
On the other hand, one could consider just zapping the whole thing and=20=

read all over, but that takes more time if you want to keep some.

Something I was wondering about. Is it possible or even preferable to=20
be able to keep the volume data in memory (i.e., the voxel data) and be=20=

able to tell Jmol to use the set voxel data to create a different=20
isosurface without having to reload the cubefile? Often for molecular=20
orbitals one wants to see two isosurfaces anyway. Maybe that takes even=20=

more memory resource....

Ren=E9

On Jul 17, 2005, at 8:22 AM, Ren=E9 Kanters wrote:

> The reason one may want to consider deleting a surface may be if it=20
> turns out that having, lets say 10 molecular orbitals with 2=20
> polarities for each orbital (i.e., 20 isosurfaces) on one atomset,=20
> which one would like to be able to turn on/off base on a=20
> javascript....