Re: [PyMOL] Ambient occlusion on isosurface

2018-06-09 Thread Thomas Holder
Hi Gianluca,

> is it possible to set ambient occlusion for isosurfaces?

Unfortunately no, it's only implemented for molecular surfaces.

Cheers,
  Thomas

--
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

Re: [PyMOL] Collada export with instances?

2018-06-09 Thread Thomas Holder
Hi Jared,

Only writing one sphere geometry per color makes a lot of sense, yes let's talk 
about that offline! I also see some dispensable elements like  with 
identity matrix, which we could safely remove to reduce file size further.

Cheers,
  Thomas

> On Jun 6, 2018, at 10:49 PM, Jared Sampson  wrote:
> 
> Hi Gary and Thomas - 
> 
> As Thomas mentioned, the sphere/cylinder/etc. primitives described in the 
> COLLADA 1.5 spec as  ("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  elements.  However, 
> as Gary has noticed, it defines a separate  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  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 
>  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 
>  and  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  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  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
> 
> 

--
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