Scaling when exporting

[Tristan Croll]

The following bug report has been submitted:
Platform:        Linux-3.10.0-1127.19.1.el7.x86_64-x86_64-with-centos-7.8.2003-Core
ChimeraX Version: 1.1 (2020-09-09 22:22:27 UTC)
Description
Would it be possible to add a scale argument when exporting to other 3D formats like X3D? When importing a ChimeraX-generated X3D into Blender, the scale comes out as 1 Angstrom = 1 metre. While rescaling after import is trivial for a single object, it becomes a real hassle for complex scenes where you might be exporting a few dozen individual components from the one model. Would be great to be able to just say something like "save xxx.x3d scale 0.01" to get 1A = 1cm, for example.

OpenGL version: 3.3.0 NVIDIA 455.32.00
OpenGL renderer: TITAN Xp/PCIe/SSE2
OpenGL vendor: NVIDIA Corporation
Manufacturer: Dell Inc.
Model: Precision T5600
OS: CentOS Linux 7 Core
Architecture: 64bit ELF
CPU: 32 Intel(R) Xeon(R) CPU E5-2687W 0 @ 3.10GHz
Cache Size: 20480 KB
Memory:
	              total        used        free      shared  buff/cache   available
	Mem:            62G        4.1G         47G        273M         11G         57G
	Swap:          4.9G          0B        4.9G

Graphics:
	03:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP102 [TITAN Xp] [10de:1b02] (rev a1)	
	Subsystem: NVIDIA Corporation Device [10de:11df]	
	Kernel driver in use: nvidia
PyQt version: 5.12.3
Compiled Qt version: 5.12.4
Runtime Qt version: 5.12.9
Installed Packages:
    alabaster: 0.7.12
    appdirs: 1.4.4
    Babel: 2.8.0
    backcall: 0.2.0
    blockdiag: 2.0.1
    certifi: 2020.6.20
    chardet: 3.0.4
    ChimeraX-AddH: 2.1.1
    ChimeraX-AlignmentAlgorithms: 2.0
    ChimeraX-AlignmentHdrs: 3.2
    ChimeraX-AlignmentMatrices: 2.0
    ChimeraX-Alignments: 2.1
    ChimeraX-Arrays: 1.0
    ChimeraX-Async: 0.1
    ChimeraX-Atomic: 1.6.1
    ChimeraX-AtomSearch: 2.0
    ChimeraX-AxesPlanes: 2.0
    ChimeraX-BasicActions: 1.1
    ChimeraX-BILD: 1.0
    ChimeraX-BlastProtein: 1.0.1
    ChimeraX-BondRot: 2.0
    ChimeraX-BugReporter: 1.0
    ChimeraX-BuildStructure: 2.0
    ChimeraX-Bumps: 1.0
    ChimeraX-BundleBuilder: 1.0
    ChimeraX-ButtonPanel: 1.0
    ChimeraX-CageBuilder: 1.0
    ChimeraX-CellPack: 1.0
    ChimeraX-Centroids: 1.1
    ChimeraX-ChemGroup: 2.0
    ChimeraX-Clashes: 2.0
    ChimeraX-Clipper: 0.15.0
    ChimeraX-ColorActions: 1.0
    ChimeraX-ColorGlobe: 1.0
    ChimeraX-CommandLine: 1.1.3
    ChimeraX-ConnectStructure: 2.0
    ChimeraX-Contacts: 1.0
    ChimeraX-Core: 1.1
    ChimeraX-CoreFormats: 1.0
    ChimeraX-coulombic: 1.0.1
    ChimeraX-Crosslinks: 1.0
    ChimeraX-Crystal: 1.0
    ChimeraX-DataFormats: 1.0
    ChimeraX-Dicom: 1.0
    ChimeraX-DistMonitor: 1.1
    ChimeraX-DistUI: 1.0
    ChimeraX-Dssp: 2.0
    ChimeraX-EMDB-SFF: 1.0
    ChimeraX-ExperimentalCommands: 1.0
    ChimeraX-FileHistory: 1.0
    ChimeraX-FunctionKey: 1.0
    ChimeraX-Geometry: 1.1
    ChimeraX-gltf: 1.0
    ChimeraX-Graphics: 1.0
    ChimeraX-Hbonds: 2.0
    ChimeraX-Help: 1.0
    ChimeraX-HKCage: 1.3
    ChimeraX-IHM: 1.0
    ChimeraX-ImageFormats: 1.0
    ChimeraX-IMOD: 1.0
    ChimeraX-IO: 1.0
    ChimeraX-ISOLDE: 1.1.0
    ChimeraX-Label: 1.0
    ChimeraX-LinuxSupport: 1.0
    ChimeraX-ListInfo: 1.0
    ChimeraX-Log: 1.1.1
    ChimeraX-LookingGlass: 1.1
    ChimeraX-Map: 1.0.1
    ChimeraX-MapData: 2.0
    ChimeraX-MapEraser: 1.0
    ChimeraX-MapFilter: 2.0
    ChimeraX-MapFit: 2.0
    ChimeraX-MapSeries: 2.0
    ChimeraX-Markers: 1.0
    ChimeraX-Mask: 1.0
    ChimeraX-MatchMaker: 1.1
    ChimeraX-MDcrds: 2.0
    ChimeraX-MedicalToolbar: 1.0.1
    ChimeraX-Meeting: 1.0
    ChimeraX-MLP: 1.0
    ChimeraX-mmCIF: 2.2
    ChimeraX-MMTF: 2.0
    ChimeraX-Modeller: 1.0
    ChimeraX-ModelPanel: 1.0
    ChimeraX-ModelSeries: 1.0
    ChimeraX-Mol2: 2.0
    ChimeraX-Morph: 1.0
    ChimeraX-MouseModes: 1.0
    ChimeraX-Movie: 1.0
    ChimeraX-Neuron: 1.0
    ChimeraX-Nucleotides: 2.0
    ChimeraX-OpenCommand: 1.2.1
    ChimeraX-PDB: 2.1
    ChimeraX-PDBBio: 1.0
    ChimeraX-Phenix: 0.1
    ChimeraX-PickBlobs: 1.0
    ChimeraX-Positions: 1.0
    ChimeraX-PresetMgr: 1.0
    ChimeraX-PubChem: 2.0
    ChimeraX-Read-Pbonds: 1.0
    ChimeraX-Registration: 1.1
    ChimeraX-RemoteControl: 1.0
    ChimeraX-ResidueFit: 1.0
    ChimeraX-RestServer: 1.0
    ChimeraX-RNALayout: 1.0
    ChimeraX-RotamerLibMgr: 2.0
    ChimeraX-RotamerLibsDunbrack: 2.0
    ChimeraX-RotamerLibsDynameomics: 2.0
    ChimeraX-RotamerLibsRichardson: 2.0
    ChimeraX-SaveCommand: 1.2
    ChimeraX-SchemeMgr: 1.0
    ChimeraX-SDF: 2.0
    ChimeraX-Segger: 1.0
    ChimeraX-Segment: 1.0
    ChimeraX-SeqView: 2.2
    ChimeraX-Shape: 1.0.1
    ChimeraX-Shell: 1.0
    ChimeraX-Shortcuts: 1.0
    ChimeraX-ShowAttr: 1.0
    ChimeraX-ShowSequences: 1.0
    ChimeraX-SideView: 1.0
    ChimeraX-Smiles: 2.0
    ChimeraX-SmoothLines: 1.0
    ChimeraX-SpaceNavigator: 1.0
    ChimeraX-StdCommands: 1.0.4
    ChimeraX-STL: 1.0
    ChimeraX-Storm: 1.0
    ChimeraX-Struts: 1.0
    ChimeraX-Surface: 1.0
    ChimeraX-SwapAA: 2.0
    ChimeraX-SwapRes: 2.0
    ChimeraX-TapeMeasure: 1.0
    ChimeraX-Test: 1.0
    ChimeraX-Toolbar: 1.0
    ChimeraX-ToolshedUtils: 1.0
    ChimeraX-Tug: 1.0
    ChimeraX-UI: 1.2.3
    ChimeraX-uniprot: 2.0
    ChimeraX-ViewDockX: 1.0
    ChimeraX-Vive: 1.1
    ChimeraX-VolumeMenu: 1.0
    ChimeraX-VTK: 1.0
    ChimeraX-WavefrontOBJ: 1.0
    ChimeraX-WebCam: 1.0
    ChimeraX-WebServices: 1.0
    ChimeraX-Zone: 1.0
    colorama: 0.4.3
    comtypes: 1.1.7
    cxservices: 1.0
    cycler: 0.10.0
    Cython: 0.29.20
    decorator: 4.4.2
    distlib: 0.3.1
    distro: 1.5.0
    docutils: 0.16
    filelock: 3.0.12
    funcparserlib: 0.3.6
    grako: 3.16.5
    graphviz: 0.14.1
    h5py: 2.10.0
    html2text: 2020.1.16
    idna: 2.10
    ihm: 0.16
    imagecodecs: 2020.5.30
    imagecodecs-lite: 2020.1.31
    imagesize: 1.2.0
    ipykernel: 5.3.0
    ipython: 7.15.0
    ipython-genutils: 0.2.0
    jedi: 0.17.2
    Jinja2: 2.11.2
    jupyter-client: 6.1.3
    jupyter-core: 4.6.3
    kiwisolver: 1.2.0
    line-profiler: 2.1.2
    lxml: 4.5.1
    MarkupSafe: 1.1.1
    matplotlib: 3.2.1
    msgpack: 1.0.0
    netifaces: 0.10.9
    networkx: 2.4
    numexpr: 2.7.1
    numpy: 1.18.5
    numpydoc: 1.0.0
    objgraph: 3.4.1
    openvr: 1.12.501
    packaging: 20.4
    ParmEd: 3.2.0
    parso: 0.7.1
    pexpect: 4.8.0
    pickleshare: 0.7.5
    Pillow: 7.1.2
    pip: 20.2.2
    pkginfo: 1.5.0.1
    prompt-toolkit: 3.0.7
    psutil: 5.7.0
    ptyprocess: 0.6.0
    pycollada: 0.7.1
    pydicom: 2.0.0
    Pygments: 2.6.1
    PyOpenGL: 3.1.5
    PyOpenGL-accelerate: 3.1.5
    pyparsing: 2.4.7
    PyQt5-commercial: 5.12.3
    PyQt5-sip: 4.19.19
    PyQtWebEngine-commercial: 5.12.1
    python-dateutil: 2.8.1
    pytz: 2020.1
    pyzmq: 19.0.2
    qtconsole: 4.7.4
    QtPy: 1.9.0
    RandomWords: 0.3.0
    requests: 2.24.0
    scipy: 1.4.1
    Send2Trash: 1.5.0
    SEQCROW: 0.20
    setuptools: 49.4.0
    sfftk-rw: 0.6.6.dev0
    six: 1.15.0
    snowballstemmer: 2.0.0
    sortedcontainers: 2.2.2
    Sphinx: 3.1.1
    sphinxcontrib-applehelp: 1.0.2
    sphinxcontrib-blockdiag: 2.0.0
    sphinxcontrib-devhelp: 1.0.2
    sphinxcontrib-htmlhelp: 1.0.3
    sphinxcontrib-jsmath: 1.0.1
    sphinxcontrib-qthelp: 1.0.3
    sphinxcontrib-serializinghtml: 1.1.4
    suds-jurko: 0.6
    tables: 3.6.1
    tifffile: 2020.6.3
    tinyarray: 1.2.2
    tornado: 6.0.4
    traitlets: 5.0.4
    urllib3: 1.25.10
    versioneer: 0.18
    wcwidth: 0.2.5
    webcolors: 1.11.1
    wheel: 0.34.2

[Tom Goddard]

A scale option would be possible but is a good bit of work. There are several scene export formats, x3d, gltf, stl, obj, vtk, that often assemble coordinates in many routines many levels deep in the code. Possibly some formats (x3d, gltf) could set a top level scale matrix but there is no telling whether a Blender file reader would ignore that.

Could you explain what it is the problem in Blender working with a scene 10,000 meters wide? Also could you explain why it is hard to scale in Blender if you have 10 separate models -- wouldn't you simply import them all and apply a global scale factor?

[Tristan Croll]

Oh, it's all do-able - it just gets a bit fiddly if you're trying to do intermediate renders while composing the scene (i.e. before you have everything imported). Possibly only because I'm still a bit of a Blender neophyte, of course. Why it becomes a problem is that everything in Blender is modelled on real-world principles: light outputs are in watts, camera is defined with sensor and aperture in mm, etc... So if you use the default scaling coming from ChimeraX your light sources will be in the megawatts, and (more importantly) at a standard 30-50mm focal length your camera ends up sitting a kilometre or so from the scene (and damn near impossible to find other than via the object menu).

If it's going to be a lot of work, then I suppose I wouldn't bother.

[Tom Goddard]

What export format do you want to scale? X3D? Adding it to one format is of course easier than adding it to 5. The X3D has custom_x3d() methods that models can use to output geometry -- Structure uses that. That method would need the scale factor.

I guess you can import each of your 10 models one at a time, scale it, then export it in Blender. Then work with suitably scaled models. Tedious, and a I agree it would be nice to do the scaling as the model is export from ChimeraX. But I am not sure the rare use of this puts its priority above many other things we need to work on.

[Tristan Croll]

As far as I've gathered so far, X3D seems to be the most convenient for Blender import - apart from the scale, the only real stumbling block was learning how to join all the individual spheres and cylinders from an atom/bond scene into a single object (trivial once you know how).

By the way, I don't know if it counts as a bug or not but hidden surfaces (the result of doing surf sel  and then ~surf​) are still exported.

[Tom Goddard]

Yep, only displayed parts of models should be included in exported X3D. Report that as a separate bug if you would like it fixed.

I am reassigning this request for X3D scale factor to Greg who wrote the X3D code.

[Greg Couch]

Would putting everything inside a Transform node, ​https://www.web3d.org/documents/specifications/19775-1/V3.2/Part01/components/group.html#Transform, that scales everything be sufficient? It's easy to try by hand. Using the XML encoding, it would be:

<Transform scale="0.1 0.1 0.1">
 ....
</Transform>

If you bracketed the first Group node (which goes to almost the end of the file) with the above Transform node, then it should scale everything to be 0.1X smaller.

For completeness, but not in this case, another part of the X3D file that can affect scaling is the line:

<unit category='length' name='ångström' conversionFactor='1e-10'/>

Depending on the X3D importer, it might or might not apply the unit scaling factor. The unit scaling is supposed to be used to keep the relative sizes of multiple input files consistent and allow each file's coordinates to be given in "native" values. (Graphics hardware does not like objects that greatly in scale. Programs, that can display things at multiple scales, are very careful to adjust the coordinates to have the log of the graphics coordinates near zero).

[Tristan Croll]

Yep - the Transform node does the trick. In the ChimeraX-generated X3D file I tested it on the Transform node was already there:

<Transform rotation="0 0 1 0" translation="0 0 0">​

Adding scale="0.01 0.01 0.01"​ brought it down to a nice sensible size in Blender.
________________________________
From: ChimeraX <ChimeraX-bugs-admin@cgl.ucsf.edu>
Sent: 02 February 2021 06:21
Cc: goddard@cgl.ucsf.edu <goddard@cgl.ucsf.edu>; gregc@cgl.ucsf.edu <gregc@cgl.ucsf.edu>; Tristan Croll <tic20@cam.ac.uk>
Subject: Re: [ChimeraX] #4194: Scaling when exporting

#4194: Scaling when exporting
------------------------------------+------------------------
          Reporter:  Tristan Croll  |      Owner:  Greg Couch
              Type:  enhancement    |     Status:  feedback
          Priority:  normal         |  Milestone:
         Component:  Input/Output   |    Version:
        Resolution:                 |   Keywords:
        Blocked By:                 |   Blocking:
Notify when closed:                 |   Platform:  all
           Project:  ChimeraX       |
------------------------------------+------------------------
Changes (by Greg Couch):

 * status:  assigned => feedback


Comment:

 Would putting everything inside a Transform node,
 https://www.web3d.org/documents/specifications/19775-1/V3.2/Part01/components/group.html#Transform,
 that scales everything be sufficient?  It's easy to try by hand.  Using
 the XML encoding, it would be:
 {{{
 <Transform scale="0.1 0.1 0.1">
  ....
 </Transform>
 }}}
 If you bracketed the first Group node (which goes to almost the end of the
 file) with the above Transform node, then it should scale everything to be
 0.1X smaller.

 For completeness, but not in this case, another part of the X3D file that
 can affect scaling is the line:
 {{{
 <unit category='length' name='ångström' conversionFactor='1e-10'/>
 }}}
 Depending on the X3D importer, it might or might not apply the unit
 scaling factor.  The unit scaling is supposed to be used to keep the
 relative sizes of multiple input files consistent and allow each file's
 coordinates to be given in "native" values.  (Graphics hardware does not
 like objects that greatly in scale.  Programs, that can display things at
 multiple scales, are very careful to adjust the coordinates to limit the
 dynamic range.)

--
Ticket URL: <https://plato.cgl.ucsf.edu/trac/ChimeraX/ticket/4194#comment:7>
ChimeraX <http://www.rbvi.ucsf.edu/chimerax/>
ChimeraX Issue Tracker