Good Morning,
I’ve been thinking about a project for awhile that would bring the rendering capabilities of OVITO to Julia (an OVITO.jl package). In the Julia ecosystem most of the molecular simulation packages share an interface that defines the System. This shared interface could allow me to write a single generic package to visualize/render the code from all of these various packages. The thing I’m stuck on is how I can make use of OVITO to do this. The existing tools in Julia to visualize are limited and it would be nice if you could render your scene without need for opening the OVITO GUI.
I’m fairly certain I can build OVITO as a shared library and call OVITO functions from Julia, but OVITO was not designed to do this nor is there documentation about the source code. The second option would be to rely solely on running python code like this.
I would much prefer the first approach; however, I was hoping someone more familiar with the source code could comment on the feasibility of this project. For success I would at a minimum need a way to build and save a scene to a PNG or MP4 (access the OpenGL renderer somehow). A bonus would be if I could actually get some kind of Qt or OpenGL object that represents the scene in OVITO and render it out to VSCode (similar to how you can render a plot or webpage).
Thanks,
Ethan
In general, I very much support your idea to make OVITO functions accessible from Julia. However, that would also be a very large undertaking. I speak from my own experience. A lot of development work has gone into the Python bindings of OVITO and we continue to invest a lot of time in maintaining and documenting this public API as it is used intensively by users.
Unfortunately, we cannot invest as much time in documenting the underlying C++ code and its interfaces, as we simply lack the necessary resources and funding for this type of work. The C++ interfaces are also not well documented because they are continuously changing. Moreover, not all features are included in the public C++ code base. Important extensions, for example the rendering backends Tachyon and OSPRay of OVITO Pro are part of our proprietary code base. So it would simply not be possible for you to develop Julia bindings for these functions yourself.
In my eyes it would actually make the most sense at the moment to build the Julia interface on top of the best maintained, most stable and public interface of OVITO, namely the OVITO Python interface. I am wondering, is it possible from Julia to directly talk to a Python interpreter and access Python objects and functions? I’m thinking for example of interop layers such as PyCall.jl. What do you think of this idea? I should say that I personally have no experience with Julia and its ecosystem.
1 Like
Completely forgot about the Python interface. That interface definitely provides an easier entry point and PyCall is the right library to do that. I don’t think there’s an automated way to re-create all the OVITO python functions in Julia, but that’s not my primary goal. With this approach I should be able to define a render function in Julia that internally deals with calling the OVITO library and reformatting the data.
It’s been over a year since I’ve used the Python part of OVITO. The Python interface has access to all the pro features, but if you do not have Pro then the python code just won’t execute? Also there’s no limitations by not using the ovitos interpreter correct (although you should be able to use this from Julia)?
Also, there’s no licensing issues etc. here right? Like, can I call my package OVITO.jl?
The OVITO Python package is available separately and independently from OVITO Pro. One doesn’t need a paid license to use it or incorporate it into other software (it’s made available under MIT license). The package provides almost the full functionality of OVITO Pro available so far (except the GUI, of course). You can install it in a regular Python interpreter (no ovitos needed).
I would suggest you choose a name other than simply “OVITO.jl” for your package. For two reasons: To avoid misunderstandings, it should be obvious to users of your package that it is not a product developed and maintained by the original software vendor. We (OVITO GmbH) cannot currently provide technical support for it or take any responsibility for it. Secondly, I would like to keep open the possibility that we might develop a native interface to Julia ourselves in the future.
So ideally the package name should make it clear that this is a wrapper for OVITO’s Python API developed by a third party. Of course, the term “OVITO” may still be part of the package name.
1 Like
Sounds good, I’ll choose my own name.
Thanks for the advice!
@stukowski I’ve been looking through the source code trying to find the Qt object that is contained within the viewport. I thought there would be a QGraphicsView somewhere but could not find it let alone how to get access to it. Could you point me to where I can find that?
I am also wondering if the scene in OVITO is stored purely as 2D that is re-rendered when the camera pans or is it actually 3D data? I’m trying to figure out if I can get a way to save an OVITO scene as an STL or similar 3D file format.
In terms of the Julia library I’ve been able to wrap the entire Python interface and get most of the extra functionality I was after from Julia. Just working on some extra/crazy ideas to see what I can get working.
Thanks,
Ethan
The scene rendering framework of OVITO consists of several layers and is relatively complex - to explain it completely would go far beyond the scope here. The second to last layer is where drawing calls take place, operating with primitive 3D and 2D object types (e.g. sets of spheres, ellipsoids, cylinders, lines, meshes, textured quads, etc.).
At the lowest level, there are several rendering backends that implement these drawing operations and perform the rasterization (OpenGL, Vulkan, Tachyon, OSPRay). The default OpenGL backend is part of the public OVITO source code and is used for the interactive viewports. It renders spheres, cylinders, etc. using GPU-based shader programs and raycasting techniques to ensure best performance and quality. So these drawing primitives are never converted to triangular meshes, which would be necessary for export to mesh-based data formats like STL. If every sphere and cylinder of a molecular model were converted into triangles by OVITO, the resulting data would very quickly exceed the available memory.
If you’re looking for a Qt widget: at the lowest level, it’s a QOpenGLWidget. You can find it here. That particular kind of widget can be created from Python, see Viewport.create_qt_widget().
Full-scene export from OVITO is currently available via export_file() function and the “povray” output format. We have plans to add support for the standard USD file format in the future. This would enable data exchange with 3d visualization software such as Blender.
1 Like
VMD does this somehow by the way, maybe they just make an outer surface and mesh that. I have not spent much time playing with it. Either way, I’m excited for this feature.