This is great, thanks! I created a dae file with some geometry instances
before I saw this email, but I think you guys are well beyond that point
already. And yes -- one sphere per color seems like the best that can be
done simply with Collada 1.4, and it would already be a huge improvement in
size and speed.
I also agree Collada 1.5 is DOA, too bad. If you're interested in the
future, glTF is probably the way to go, though it doesn't have breps
either. It's quite easy to write; I've written an exporter for it (not from
pymol) in python which I'm happy to share.
On Wed, Jun 6, 2018 at 4:49 PM Jared Sampson <jared.samp...@columbia.edu>
wrote:
> Hi Gary and Thomas -
>
> As Thomas mentioned, the sphere/cylinder/etc. primitives described in the
> COLLADA 1.5 spec as <brep> ("boundary representation") elements would be
> the best option for spheres and basically all other PyMOL representations
> except for molecular surfaces. Unfortunately COLLADA 1.5 is not well
> supported by other graphics applications. However, there is still room to
> optimize the storage within the constraints of COLLADA 1.4.
>
> After looking through a couple test .dae files to refresh my memory, I see
> that the output from PyMOL does use <instance_geometry> elements. However,
> as Gary has noticed, it defines a separate <geometry> element for each
> sphere in the scene. This adds up quickly for scenes with many atoms
> represented as spheres. FWIW, the reasoning behind this when I originally
> wrote the COLLADA exporter was that color information is included in the
> <geometry> definition, and it was easier to write a separate geometry for
> each sphere than to collect information about all the different colors of
> spheres.
>
> Of course, it is possible to do this more efficiently. Probably the
> simplest way to cut down the file size would be to write only a single
> sphere <geometry> element *per color* of sphere present in the scene, and
> then use instances of those to represent all spheres that share the same
> color. The attached files each have two geometries (output by PyMOL with
> pseudoatom spheres at position=[0, 0, 0] and [1, 0, 0], in grey90 and red,
> respectively). The first file, "test.dae", was output directly by PyMOL
> and has one instance of each sphere, for a total file size of 21545 bytes.
> Manually adding a second instance of each sphere (translated by +/- 4Å
> along the X axis) in "test-added.dae" adds only 1147 bytes to the file
> (look for <node id="node-geom0-added"> and <node id="node-geom1-added"> in
> your favorite text editor), compared to adding 18174 bytes if the two
> additional spheres are exported from PyMOL with their additional geometries
> by adding additional pseudoatoms (that file not attached). That's an
> almost 94% reduction per added sphere; for scenes with many spheres, the
> storage savings would be substantial.
>
> On the other hand, if there is a way for color to be specified separately
> from the <geometry> element (which I imagine must be possible, but I
> haven't found a clear example of how to do this), that would be the most
> preferred option, as it would allow us to use a single sphere <geometry>
> element per output file.
>
> Thanks to Gary for bringing this up. Thomas, perhaps we can talk offline
> about what might be the best way to implement this?
>
> Cheers,
> Jared
>
>
> On June 6, 2018 at 2:24:08 PM, Thomas Holder (
> thomas.hol...@schrodinger.com) wrote:
>
> Hi Gary,
>
> Do you know an application which can actually read COLLADA files with
> sphere primitives? We've faced the problem that most tools only handle
> COLLADA 1.4, so if PyMOL would use COLLADA 1.5 features, the programs we
> know wouldn't read the exported files. See
> https://pymolwiki.org/index.php/COLLADA#Limitations
>
> I fully agree that sphere primitives and other COLLADA 1.5 features would
> be better (smaller files, precise sphere representation, etc.).
>
> Thomas
>
> > On Jun 6, 2018, at 1:19 PM, Gary Oberbrunner <ga...@darkstarsystems.com>
> wrote:
> >
> > The collada file exported by pymol would be smaller and export/import
> faster, I think, if it used geometry_instance for spheres rather than
> giving each sphere its own geometry/mesh/accessors/etc.. Has that been
> discussed before?
> >
> > --
> > Gary Oberbrunner
>
> --
> Thomas Holder
> PyMOL Principal Developer
> Schrödinger, Inc.
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> PyMOL-users mailing list (PyMOL-users@lists.sourceforge.net)
> Info Page: https://lists.sourceforge.net/lists/listinfo/pymol-users
> Archives: http://www.mail-archive.com/pymol-users@lists.sourceforge.net
>
>
--
Gary Oberbrunner -- CEO -- Dark Star Systems, Inc.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
PyMOL-users mailing list (PyMOL-users@lists.sourceforge.net)
Info Page: https://lists.sourceforge.net/lists/listinfo/pymol-users
Archives: http://www.mail-archive.com/pymol-users@lists.sourceforge.net
