Hi,
I’m really pleased that Ovito now supports the .glb format. However, I found that even using a resolution of 1 to create the files, it’s still difficult to operate them in Blender or PowerPoint. They can be successfully imported but the operation is sluggish. The .glb file I exported via UCSF ChimeraX was very smooth, even though the file size was twice as from Ovito. I think this may be related to the mesh settings, as ChimeraX allows for free setting of triangles.
Is there a way to further adjust the mesh settings? I have attached the files exported from Ovito and ChimeraX respectively.
https://drive.google.com/drive/folders/12XxXu7mezUwd8g5g7QxVWCv4vaoolasl?usp=sharing
Interestingly, the response of the model can be quickly improved by merging mesh and deleting duplicates as below.
Import the .glb file exported by Ovito in Blender. There will be 20K different meshes as follows.
Simply by merging mesh, the exported new blend1.glb can already respond normally in Blender and powerpoint.
Further, I found that some mesh has no impact on the final visual presentation. For example, if I only keep the last node, it will have no impact on the result. And the exported blend2.glb is really smoth.
Relative to the amount of data, the structure of data seems have a great impact on fluency. If you open the exported .glb of ChimeraX, you will find that it is only include two mesh. I have attached all .glb files on the link above.
Thank you for this suggestion. OVITO’s glTF export function currently aims to minimize the resulting file size by writing the sphere and cylinder meshes just once and then reusing them for all atoms and bonds. But apparently this leads to poor rendering performance in many applications, because it means that each atom or bonds needs to be an individual scene object.
I have extended the glTF exporter of OVITO now to also support a different export mode, where the spheres or cylinders get merged into a single large mesh. This increases the file size but rendering speed is typically much better in many applications (e.g. in PowerPoint or the Babylon.js viewer)
With the new method, per-atom color information must be stored as mesh vertex attributes instead of object materials. Apparently, Blender is one of the applications that cannot import vertex colors correctly. I saw in the ChimeraX docs that they use a workaround for this (texture-based coloring). This is something I would like to look into more. Could you please export your model from ChimeraX again using this option? I would like to inspect the resulting file structure.
In the meantime you can try the extended export function of OVITO if you like. We have a dev build of OVITO Pro and the OVITO Python module (pip wheel) here:
[Removed]
1 Like
Thanks for your update. I don’t have a pro license, and pip installation always encounters issues. I will test it after version 3.10.4 is released. I have an additional question: why are the particles I exported are semi-transparent, but the bonds are opaque? Additionally, I have attached the colorTexture results from ChimeraX.
https://drive.google.com/drive/folders/12XxXu7mezUwd8g5g7QxVWCv4vaoolasl
Thanks. Next time we can provide a dev build of the conda package too.
The transparency of particles and bonds is controlled separately in OVITO. Did you set just the particle transparency property perhaps? You may have to do the same for bonds.
Thank you, Alex. I didn’t actively set the transparency. And I found that the transparency of the particles is caused by creating bonds, as shown below:
pipeline = import_file('2110687_0_1_0.cif')
pipeline.add_to_scene()
export_file(None, "crystal.glb", "gltf", mesh_resolution = 1)
cb = CreateBondsModifier(mode=CreateBondsModifier.Mode.Pairwise)
cb.set_pairwise_cutoff('C','C',1.5)
cb.set_pairwise_cutoff('C','N',1.5)
cb.set_pairwise_cutoff('C','O',1.3)
cb.set_pairwise_cutoff('H','N',1.5)
cb.set_pairwise_cutoff('H','O',1.05)
pipeline.modifiers.append(cb)
export_file(None, "crystal2.glb", "gltf", mesh_resolution = 1)
Both the CIF and GLB files can be found in the link:
https://drive.google.com/drive/folders/12XxXu7mezUwd8g5g7QxVWCv4vaoolasl
It can’t be fixed, even I set transparency after creating bonds.
Interestingly, if I set transparency to 1, the atoms still could be hidden.
And switch to other creating bond mode did not help also.
cb = CreateBondsModifier(mode=CreateBondsModifier.Mode.VdWRadius)
This is not a transparency problem. It’s a back-face culling problem, which means you are seeing only the back sides of the atomic spheres but not their front sides. That’s why the bond cylinders inside of the atomic spheres are visible in the second picture. It’s supposed to be the other way round: The material’s backface culling option is turned on to prevent rendering of the backsides of the spheres and cylinders. Note that the problem is also present in the atoms-only model, but here it’s more difficult to notice. In the first picture spheres slightly penetrate into neighboring spheres but the intersections are visually wrong because of the wrong backface culling.
In the glTF file format materials can be either “double-sided” or “one-sided”. The latter is a synonym for the back-face culling materials option, which activates a rendering technique where only the front side of a surface gets rendered. What the front side of the surface is depends on the winding order of the triangles the mesh is made of. And that’s where compatibility issues between different applications may arise if they define the roles of back and front side differently.
I’m not sure how this could happen in this case. At least I couldn’t reproduce the issue with any of the current OVITO versions. When I load your CIF file and export it to a GLB file, the backface culling turns out always correct: I see the front sides of the spheres, not their backsides, in PowerPoint and Babylon.js viewer. But when I load your two files, crystal.glb and crystal2.glb, I observe the issue in the viewer application. I assume you did not, but please let me know in case you’ve any changes to these files outside of OVITO, i.e., if they are not the original ones written by the export_file() function.
I understand your point. I didn’t make any changes to the files; they were directly exported. The previous test ran on Ubuntu 18.04.6. I retested on MacOS 14.2.1 and found that this issue does not occur. I’m not sure what happened. Maybe it has something to do with my Ubuntu version that is too old.
OVITO 3.10.4 is now available as a conda package. Please give it a try.
If the back-face culling issue shows up again, let me know. The new OVITO version marks the glTF materials of particles and bonds as “double-sided”, which should effectively disable back-face culling under all circumstances.
Furthermore, I did not take any further steps regarding the texture-based coloring of objects after I realized that Blender does not display vertex-based coloring in the real-time viewport. The vertex colors are visible at rendering time though. Therefore, I guess, Blender has learned to import vertex colors from glTF files and there no longer is a need to work around the limitation mentioned in the ChimeraX documentation.
When exporting a glTF file from OVITO using the export_file() function, the new optimitize_size parameter lets you switch between the new and the old behavior (small file size vs. better rendering performance).
Thank you for your updated response. Sorry for the delay, I only got around to testing today.
The additional optimitize_size are effective, and the .glb are no longer sluggish in Powerpoint. However, there’s still an back-face culling issue with exporting on Linux as shown in the following image:
Could you please upload the .glb file to your Google folder? From the image alone it’s difficult for me to identify the issue (if any). At least I don’t see something that looks like a back-face culling problem. Thanks.
Yes! In fact, it has been fixed. It is the rendering of powerpoint that makes it look transparent. Apologize for my carelessness.
