To visualize any new entity, a visualization should be designed and programmed. Investigating approaches for programming new scientific visualizations, we come to the following idea: utilize CinemaScience format to describe 3D scenes. CinemaScience is developed for storing and visualizing supercomputer and physical modelling results, and difers with simplicity both for human and machine. It has a set of interesting features, for example it allows to specify dynamics in views dependent on parameters. However its current known applications are of 2D graphics, and in this paper we extend it for 3D. It's main idea is to treat Cinema artifacts as visual objects of explicit type. We successfully used the suggested approach in various visualization tasks, examples are presented in the paper. We developed the open-source web application that implements the suggested approach.
Scientific visualization is a valuable part of modeling pipeline, allowing researchers to perceive computation results. Sometimes existing visualization methods are not enough, especially if a novel research is performed. In that case, a new visualization should be created.
To construct a new visualization, a developer has to perform various steps [
The designing of a visualization is a very creative process. But its implementation is a very time-consuming process, and that is a problem. Visualization systems suggest a solution for that problem in the form of visual languages, e.g. GUI, for implementing visualizations. In addition, such systems ofer scripting and/or API for the same purpose. Also, specialized languages are developed.
As an example of using GUI for visualization implementation we point out Kepler.gl. This is a specialized geospatial visualization system. It provides visual language that allows importing data, constructing a view as a combination of basic views, and connecting structural parts of imported data with the view’s inputs.
Another example, a set of systems like ParaView, Visit, 3dMax, and Blender, provide both visual language (in the form of GUI with menus, buttons, and other graphical elements) and scripting. Besides, platforms like Unity, Unreal, Roblox, Xclu.dev, and Viewzavr (which is based on ideas of our team), belong to this group.
There are systems that use special models for visualization programming. For example
KNIME platform (uses data flow diagrams for defining scientific visualization pipelines) and
SciVi platform (uses ontologies for declaring visual objects and semantic filters of data, see [
Moreover, there exist specialized programming languages as Vega, A-Frame, and frameworks like Plotly, which allow creating visualizations primarily by scripting.
Finally, various 3D graphical formats like OBJ, STL, VRML, GLTF, so on have been developed with application for describing static scenes or scenes with limited dynamics.
Our contribution. We suggest a method of constructing 3D visualizations of some class. It allows to easily describe a set of 3D visual objects and configure a kind of scene dynamics and user interaction. The approach uses the CinemaScience format with extra semantics. As a result, with relatively small eforts an interactive 3D visualizations might be achieved.
CinemaScience is a modern format developed to store massive data sets. In this format, data
is stored in a directory called the Cinema database. This directory should contain an index
information file named data.csv in the CSV text format. This file contains a table with columns
for parameters and columns for data artifacts. Artifacts can be images, grids, CSV files; i.e., any
type of data that can be written to disk. Thus this table defines a mapping between parameters
and artifacts. The interpretation of these mapping is free and determined by the scope of an
application which uses the format [
Here is an example of a data.csv file (spaces between values are not necessary): alfa, beta, FILE_image 0, 0, i1.png 0, 1, i2.png 1, 0, i3.png
This file describes a dataset which consist of two parameters, alfa and beta, and a one image artifact. The semantics of this definition may be diferent; for example, the application may allow users to select ranges of parameters and show images that correspond to the selected subset.
Other examples are provided at the project website https://cinemascience.github.io.
We specialize CinemaScience for programming 3D visualizations by the following.
Artifacts may be 3D visual objects. Thus a list of artifacts in a data.csv file specifies a list of visual objects. All these objects are displayed in a common 3D space. The type of particular visual object is determined by artifact name, in second underscores-surrounded word. For example, "FILE_points_atoms" artifact name specifies “points” object type.
The list of supported types is considered extensible. Our practice required us to implement points, lines (segments), triangles, spheres, vrml (for VRML files), obj (for OBJ files), vtkpoints (for VTK files). Currently, the type strictly determines not only the visual object look and behavior, but also the data format of its input files.
In figure 1, images for the influenza virus hemagglutinin are presented. These are generated
by 3D scene computed by our team [
The visualization program for this scene is the following "code" placed in a data.csv file:
Here, one parameter (T) and two artifacts (FILE_points_atoms, FILE_lines_connections) are defined. The parameter T represents the time. However, it is indiferent on the CinemaScience level because it operates parameter names just as identifiers. But the interpretation of artifact names is diferent.
For the first artifact, FILE_points_atoms, the points type is specified (by its name); that means loading and visualizing 3D points, coordinates, and colors for which are specified in artifact file. In the current scene it is used to depict atoms. For the second artifact, the lines type is specified; it is used in the scene to depict connections between atoms.
The following logic is used: for each parameter column, a graphical control is generated (slider for numeric parameter and combobox for string parameter). A user manipulates these controls and thus specifies the combination of parameter values. This determines the current set of input ifles corresponding to visual objects.
In the scene above, there is the parameter T. A user is able to select a value of T using GUI and observe visual change in the scene. For example, by selecting T=1 the file w-coords-t1.csv is displayed, whereas for T=2 the file w-coords-t2.csv is displayed, both together with w-lines.csv.
Imagine there is a requirement to paint point cloud, e.g. a set of points in 3D space. Additionally, let this point cloud changes according to some parameter theta (it may have the meaning of time or any other meaning). Let the following dynamics in a scene be required: when a user selects theta value, a point cloud corresponding to that value should be displayed.
The solution using the suggested approach is as follows: 1. Put coordinates of points in a series of files, each file corresponding to some particular theta value. An example list of such files is shown in the Table 1a. 2. Each file should contain points coordinates in CSV format. An example content of such ifle is shown in the Table 1b. Each data line in it represents some point of the point cloud. 3. Create a Cinema database file data.csv with following content (Table 1c): 1. A list of data files, each containing coordinates of some point cloud instance (in pts_*.csv ifles). Each one is allowed to have its own amount of points. 2. A list of visual objects in a scene (artifact FILE_points_p) and their types (points). 3. A list of parameters in a scene (theta). 4. A relation between parameter values and input files for visual objects.
This information is enough for painting the required. Currently, our approach has a builtin algorithm that implements the required dynamics of a scene, as described in section 2.3. Parameter theta will be shown as graphical element. When a user will change value of that parameter, a related file with point cloud will be loaded by visual object and presented on a screen.
In this study, the spreading of a highly viscous incompressible fluid was considered. The
Navier-Stokes flow equation was considered in the form [
(∇ + (∇) ))︁ = −∇ − where , , , , is a volumetric mass density, velocity vector, dynamic viscosity, pressure and gravitational acceleration respectively. The viscosity here is not a constant but is a function () = * + (0) where (0) is an initial viscosity (constant for all fluids); is the lifetime of a particle after leaving the volcano; is the constant responsible for the rate of change in viscosity. This form of viscosity allows an approximate description of the processes of change in viscosity associated with the formation of crystals in lava.
Numerical calculations were carried out using Smoothed particle hydrodynamics (SPH)
methods. More details can be found, for example, in [
Figure 3 shows the dynamics of spreading of a viscous fluid under various conditions of viscosity change.
(a) = 0 (b) = 200 (c) = 1000 (d) = 2000
This visualization was achieved using Cinema database data.csv file of the following content: T, 4, 5, 4, 5, 4, 252, 3,
ViscoStep, FILE_vtkpoints_lava, 0, 0/ParticleData_4.vtk, 0, 0/ParticleData_5.vtk,
. . . 1, 200/ParticleData_4.vtk, vulk.obj, 1, 200/ParticleData_5.vtk, vulk.obj,
. . . 2, 1000/ParticleData_4.vtk, vulk.obj,
. . .
2000/ParticleData_252.vtk, vulk.obj, Let’s denote interesting parts in contrast to the example presented in previous section: 1. There are two parameters defined, T and ViscoStep. While the first one is a time, the second one is the computational parameter representing viscosity changes. Graphical controls will be displayed in GUI for both parameters. Their values, selected by a user, FILE_obj_vulkan, FILE_obj_emmiter vulk.obj, emit.obj vulk.obj, emit.obj emit.obj emit.obj emit.obj emit.obj will determine current input files for visual objects. Thus a user might move his focus among T or among ViscoStep. This gives a researcher the opportunity to view results of numerical simulation with diferent parameters at the same modeling time. 2. There are three visual objects defined, FILE_vtkpoints_lava, FILE_obj_vulkan and
FILE_obj_emitter. The first one have type "vtkpoints", and the latter two have type "obj". 3. The vtkpoints type corresponds to VTK file format whereas the loader of that type was implemented especially for the visualization task being described and now made publicly available. The obj type corresponds to the OBJ file format. It was implemented earlier in another project.
The total size of data files (e.g. all vtk and obj files) of the scene presented in Figure 3 is about 4.3 Gb. Because it is only files corresponding to current parameters values are required at any given moment, we successfully performed visualization of this and similar scenes on a typical laptop.
In N. N. Krasovskii Institute of Mathematics and Mechanics, V. S. Patsko’s working group
performs long-term research on Dubins car model [
The approach suggested in this paper (of using CinemaScience for 3D scenes) was practically born in response to visualization required by that research. An example resulting image is presented in Figure 4.
For this figure, a scene data.csv file has the following typical content:
Here are one parameter T which denotes time instant and three visual objects. The first one represents the reachable set surface; it is of type vrml which corresponds to VRML file format. The latter two of type treki, and this type was created especially for the current task.
It was necessary to show a set of points which denotes some extreme motions, e.g., tracks, interesting to a mathematician. Additionally, it was necessary to filter them, e.g. to show only particular tracks. For that purpose, we used points data type implementation and extended it to load additional column named N from input CSV file. A custom GUI control, which allows specifying values of interesting N, was added, and data filtering was implemented as a built-in ability of treki type. Thus the stated necessity was achieved.
We see that the presented approach of using CinemaScience for 3D scenes is just a way to program; it is a programming language with semantics built for the description of relations between entities in a dynamic visual scene.
This semantics reflects the following. A Cinema database defines a list of parameters and separately their associated values, a list of artifacts, and a relation between parameters values and artifacts. The specified relation is further interpreted by some algorithm built into visualization software. In our approach, as stated in section 2.3, it is about choosing vector of artifact values.
There might be other algorithms. For example, CinemaScience authors use, among with the
presented one, an algorithm based on multiple artifact values specified by parameter range
restrictions using parallel coordinates [
Also, as demonstrated in [
In [
One of the questions of our interest is how far the suggested approach is able to move towards expressiveness according to that statement. In the current case, the primitive expressions are artifacts (and probably their relations with parameters). Then, they might be combined by listing them in a Cinema database. And finally, a Cinema database, theoretically, might be used itself as an artifact in other Cinema databases, which resembles some form of abstraction. E.g. one may use them by denoting in a common-like FILE_somecinemadb_item. This is the subject for future research.
The modern development of high-performance computing opens up a number of new
possibilities for solving mathematical modeling problems, including large-scale parametric researching
and solving optimization analysis problems [
If it is proposed to use visual lfitering (filtering alternatives based on their visual images) in
[
Unlike work [
Thus, we have defined the task of abstracting parameters for the solution of which we have applied the extension of the CinemaScience format.
We suppose that it is beneficial to turn the development of a new specialized visualization
system from a complex project (that includes many routine technical tasks) into a process of
adaptation, usage and expansion of the capabilities of the visualization systems constructor. It
is done for example in [
In the development of specialized visualization systems, we continue to move from theory
to practice. The theoretical research of visualization was also performed in the computer
visualization laboratory of V. L. Averbukh, see [
Visual analytics solutions provide technology that combines the strengths of human and
electronic data processing. Visualization becomes the medium of a semi-automated analytical
process, where humans and machines cooperate using their respective distinct capabilities for
the most efective results. The goal of visual analytics is to make our way of processing data
and information transparent for an analytic discourse [
Let us answer the question, what can be given in practical terms by reasoning about abstracting parameters. Advantages of using parameters in the development of specialized visualization systems are: 1. It might be used for steering of high-performance computing in-situ visualization (e.g.
for on-line visualization) through passing and control of parameters.
2. The CinemaScience format structure is suitable for out-of-core algorithms implementation,
such as using k-tree for multi-view visualization.
3. A continuous map (e.g. visualization) might be defined through a small parameters change
(operational semantics) [
We emphasize once again that dynamic visualization is not a set of words (signs) but is a phrase. We can consider it as any change of a visual image, but we must give a strict definition in terms of information theory.
For example, if the information does not change, a person achieves the sleep efect. It means that a person loses "trust" not only to the information being perceived but also to the information source.
Therefore, the rate of change of information should be considered, or mutual information should be considered. The change of information is a process; thus, we must consider data ifltering, like any other visualization, as a process. Two options are possible: a human-computer interactive process and an animation.
The strong sides of the suggested approach for 3D scenes construction are the following. First, the CinemaScience format is extra simple to write. This allows a developer not to be overwhelmed by details like in other 3D formats. Second, this format is extra simple to read. That is, a format reader and a player algorithm may be easily implemented both as a standalone application or as a plugin to existing scientific visualization software.
Our preliminary results show that the approach is robust and relatively versatile. It is suitable for some class of scientific visualization tasks, especially related to visualization of results of computational modeling.
However, there is a nuance. The approach allows to define a set of visual objects and simple dynamics of a scene. Additional view settings like windows, clippings, transfer functions, and advanced a user interaction are out of the scope of the approach.
It is supposed that a user configures these aspects using the graphical interface of a visualization software. It then may be saved as project settings and reused in scenes of the same kind.
We develop software that implements the described approach as a web application using WebGL and WebXR technologies. It is available at https://github.com/viewzavr/vr-cinema page.
We would like to thank reviewers of the paper for their constructive feedback.