#168 spheres/balls not exported to vrml

[James Green]

PyMOL 1.7.4.0
OS X 10.9

I'm trying to export a 3D model with stick_ball or stick + sphere.

The balls and spheres export correctly to collada, but not vrml.

• load file.cif
• as stick
• show sphere
• set stick_radius,0.1
• set sphere_scale,0.2
• save file.wrl

Expected:

Observed:

[James Green]

Sorry I set the wrong milestone/version. I'm not sure how to change that now...

[Jared Sampson]

Hi James - I noticed this for Wavefront (.obj) format when I was writing the COLLADA exporter (the atom centers are exported as vertices, rather than the surfaces), but actually, the VRML output does include spheres. It may be that the application you're using to view the .wrl file doesn't support them. For example, Blender doesn't use the VRML spheres directly, but rather converts them to polygon meshes. (See attached screenshot of ala.wrl imported into Blender after using the same settings you used to generate your figure.) Hope that helps.

[James Green]

Hi Jared,

Thanks a lot for the response. That makes sense.

0) My goal here is real-time rendering in WebGL ( on Sketchfab ). For that, I need optimized meshes/materials for good javascript performance. I know JSmol and PV are the standards here, but I find the viewer experience much better:
(pymol) https://sketchfab.com/models/192e5b5ca4f24275b786741463dfcc1c
(vmd) https://sketchfab.com/models/bc1045c7c7ac42f4918f44bf48066e4e

1) Unfortunately (at least in my brief experience) the VRML and COLLADA files exported from pymol are horribly inefficient in the way they export geometry instances. Most of my local software reports corrupt collada, and the vrml tend to have 1000s of separate geometries. My solution so far has been to use meshlab[server] to immediately convert .wrl to .obj with vertex colors. Apparently, meshlab does not convert the spheres to meshes. I'd love to use blender, but it hangs when trying to open big vrml files.

2) I was not aware pymol could natively export .obj. I just tried it, and although the vertex/face encoding looks good at first glance, opening them results in an empty scene (Be it meshlab, blender, rhino, sketchfab...). Strangely, the vertex/face counts are non-zero, but the scene is empty.

Any insight?

Ultimately, it would be great to implement a 'Publish to Sketchfab' function directly in pymol.

[Jared Sampson]

For what it's worth, the 1000s of geometries is based on PyMOL's internal representation of the geometry. Every triangle mesh, sphere, cylinder, or cone is its own geometric element, and the easiest way to export this into another graphics format is 1:1.

I'm sorry to hear you're having trouble with the Collada export. When I was writing the exporter, I consistently tested output files to make sure hey adhered to the 1.4.1 spec using xmllint (xmllint --noout --schema collada_schema_1_4_1.xsd myfile.dae, schema available here). While it's entirely possible there's a problem with the output, it may also be that your local software doesn't support the entire spec. E.g. Blender only imports <polylist> geometries and completely ignores anything written using <triangles>, <tristrips>, etc. I seem to recall Meshlab had similar issues, but I don't remember exactly what the problem was. Could you try exporting with collada_geometry_mode set to 1 (Blender-compatible mode) and see if that helps? If it doesn't, could you attach one of the corrupted files to this thread? If it is in fact a problem with the Collada file, I'd like to try to fix it.

As for optimization, yes, it's true the geometries aren't particularly well optimized. For example, there are cases (e.g. cones and cylinder endcaps) where I would have liked to use trifans with Collada, but I haven't found a program that supports them, even for the v1.4.1 spec, which is now almost 10 years old. Also, remember that—for better or worse—COLLADA is by design a bulky, verbose format, meant more for graphics interchange between programs, rather than optimized use on a specific platform.

Furthermore, support for COLLADA 1.5 is essentially non-existent, which is unfortunate. It introduces <brep> elements that can define standard geometric objects (e.g. spheres, cylinders, cones) in terms of center/endpoints and radii, rather than requiring them to be approximated with triangle meshes, and would substantially cut down on file size.

If you're looking for a smaller file size for better loading in the browser, you can do so by reducing the values of the surface/sphere_quality settings before exporting from PyMOL.

As for .obj export, yes, the problem with the spheres is that it doesn't output a full mesh for the spheres, only 3 vertices, which would normally generate a single triangle, but since they are for some reason all given identical coordinates, it ends up rendering as a single point (see layer1/Ray.cpp:2394-2409). Other than this errant attempt at spheres, only triangle meshes (e.g. molecular surfaces) are currently implemented for .obj export. I'm currently working on a patch to fix the .obj sphere issue. Maybe if I get a chance I'll add cylinders and cones as well, but I wouldn't hold my breath. :)