Study of Commodity VR for Computational Material Sciences

Recent advancements in virtual reality (VR) devices and software environments make it possible to easily incorporate this technology for many applications, including computational materials science. For studying three-dimensional (3D) structure models and related chemical information, we focused on using a commodity VR device (VIVE) and an authoring tool (Unity). To visualize 3D chemical structures, disturbances like judder due to dropped frames should be eliminated from the VR experience to improve simulations. We propose a simple evaluation method that is straightforward for the nonexpert or novice VR user. We examine the major visualization representations including ball, ball and stick, and isosurface systems. For systematic benchmark measurements, a pendulum from the VR device was used to generate periodic oscillatory motion during measurements of a time series in frames per second (fps). For VIVE with a refresh rate of 90 Hz, judder occurred when less than 90 fps. We demonstrated the system size limitations for the results of molecular dynamics simulations of phase separation of ABA block copolymers and experimental observations of filler morphologies in rubber.


INTRODUCTION
Until recently, immersive virtual reality (VR) equipment (e.g., cave automatic virtual environment (CAVE)) was very expensive. 1,2 The advent of VR devices for various forms of entertainment 3 has decreased cost and led to advancements employed in molecular sciences. 4−15 Such devices are now widespread and affordable (e.g., ∼500 USD for HTC VIVE 16 or Oculus Rift 17 ). VR devices such as head-mounted displays (HMDs) provide stereoscopic images that follow the movement of the head in real time. Compared to conventional stereoscopic displays, VR provides immersive experiences with walk-through. That is, VR provides a fantastic three-dimensional (3D) voyage in nanoscale space with data from computer simulations and electron microscopies. Furthermore, software environments have been improved by the use of integrated tools such as Unity 18 and Unreal Engine. 19 These developments in VR can be utilized for training, presentations, and advanced research and development (R&D). In particular, the use of VR in computational materials science (CMS) makes it easy to recognize complicated charge distributions, atomic positions, and Fermi surfaces. 20 Recently, the Novel Materials Discovery (NOMAD) Laboratory, funded by the European Union Horizon 2020 Framework Programme for Research and Innovation, reported the importance of VR in CMS. 21,22 Accordingly, it is clear that immersive VR can be used by both academic researchers and industry developers to evaluate computational results.
As a technology, development of VR for CMS has received much attention that has been strongly focused on interactive molecular dynamics (MD) technology (e.g., molecular manipulation). Very recently, several inspiring and innovative reports have been published. 8−15 Notably, for the interested reader, O'Connor et al. 8 and Goddard et al. 9 published excellent reviews of VR for MD simulations. Interactive MD technology is an intriguing technology for utilization in drug discovery as it has been examined by VMD 23 with stereoscopic vision on a display using NVIDIA 3D Vision. Currently, interactive MD technologies are at the developmental stage of technical verification through proposing new frameworks and/or program codes. Unfortunately, this means that the average chemical researcher does not use interactive MD as a part of daily research activities.
Tasks required for VR in CMS are not limited to manipulation of molecules. For example, there is a strong interest in the observation of 3D morphology related to the structure− property relationship of polymer nanocomposites (PNCs). By utilizing VR as a tool, the time required to recognize a complicated 3D structure should be shortened considerably, benefiting both academia and the industry (e.g., R&D of materials). For aggregated materials such as PNCs, it is desirable to simply change the viewpoint and cross-section position using VR rather than through molecular or instrumental manipulations. Use of VR is therefore expected to surpass current techniques in use for simulation.
Although current research on VR technology focuses on functional implementation (e.g., molecular manipulation and demonstrations using small molecular systems), there are no recent reports on commodity VR for research on PNCs. In PNC systems, a large number of molecules form multiscale structures owing to self-organization and filler aggregation, with large-scale visualization targets. For VR of PNCs, difficulties related to practical system size range are currently being tackled in order to extract useful information. Furthermore, although chemical researchers would like to use VR to visualize objects to produce sleek images in publications using biomolecular software programs such as VMD, 23 Pymol, 24 or Chimera, 25 there are no corresponding reports available to guide the novice. The focus of VR publications is on the implementation of VR visualization using new codes and algorithms; thus, information on general-purpose tools widely available to the general chemical researcher, who is not a VR specialist, is largely inaccessible. Although VR has become more accessible through commodity VR, a VR divide nevertheless has occurred; although chemists can easily use VR with modern desktop PCs, they tend not to do so because appropriate information regarding VR is lacking. Solving the VR divide is therefore of great importance for material chemistry research, including CMS.
In this study, we focus on simplified use of commodity VR using a VR model generated by VMD. 23 Historically, VR is a research subject requiring advanced computer programming skills. Although users no longer need programming knowledge to use VR, they still need to have programming skills to display very large systems with moving objects. At a minimum, system size limitations are important to consider for use by VR nonexperts or novices. In the present study, we investigate the dependence of system size on VR performance of CMS simulation data. For researchers of chemistry and material sciences in particular, a simple evaluation method with less effort is desirable. Herein, we propose a simple performance evaluation method and present its effectiveness.
In the present paper, we employed commodity VR for CMS data using HTC VIVE, Unity, and VMD, followed by a simplified performance evaluation method to clarify the limits of system size for each type of visualization of CMS data. We also present results of performance benchmarks using recent middleclass graphics processing unit (GPU) cards. GPUs are frequently released with new products, and GPU performance continually improves. To know the relative performance of recent GPUs, the established 3DMark 26 is a very useful benchmark. Since individual performance depends on visualization targets, we decided to focus on visualization of CMS data and evaluation of the performance of VR.
This article focuses on a simplified performance evaluation method that the average chemical researcher can perform at a reasonable cost. We show that the proposed evaluation method functions as a benchmark indicator by evaluating the performance based on system size dependence for several VR presentations. We present herein a simplified performance evaluation method accessible to the average chemical researcher who is not a VR expert and will not optimize the code of a VR program.

BACKGROUND ON PERFORMANCE PROBLEMS IN VR
As VR systems for large capacity processing are being developed, much research on rendering algorithms, data transfer, and realtime processing have been conducted. 23,24 Parameters related to performance can be classified as "system size", "rendering method" (software), and "VR hardware". In the past, even with small systems, some problems occurred due to insufficient performance of VR hardware. For example, VR hardware problems consisted of "motion tracking" and "communication to distributed parallel-rendering computers," even for high-end devices such as CAVE, though these problems have now been solved. Today, fortunately, algorithms are adopted and commodified when using HTC-VIVE, 16 Oculus Rift, 17 and other devices with software such as Unity 18 and Unreal Engine. 19 The development of fast and efficient rendering techniques is still quite important, requiring system size to be addressed when considering VR for CMS used by nonexperts or novices. The problem of "data transfer" from the central processing unit (CPU) to the GPU is regarded here as a problem within the system size parameter. The historical technical development of VR has been reviewed in detail in the literature. 27,28 Here, to contextualize this article, we provide a brief overview as follows. Processing resolution, image effect quality, CPU performance, and GPU performance are important considerations in VR development that have improved over time. For instance, in early versions of CAVE systems (e.g., those installed at Osaka University, the National Institute for Fusion Science, and the Earth Simulator in Japan), motion tracking and communication problems to dispersed rendering computers were often encountered prior to high-quality rendering. 29 Within the past decade, such system problems have largely been resolved due to improvements in computing performance.
VR expressions originally used very light wire frames for rendering, which were then replaced with more realistic polygons. With each passing year, the limit of the number of objects that can be rendered has increased. This is due to improvements in both software and computer performance, though limitations were considered to originate from the rendering procedure. A general approach to render objects using a computer graphics library (e.g., OpenGL) relies on the CPU to generate object data consisting of vertices, faces, and textures and then transfers this object data with rendering instructions to the GPU. The GPU can then execute a rendering pipeline to draw objects on the display. When the transfer limit is exceeded, the transfer excess from each object slows the rendering speed. This rendering cost can be reduced by packing all operations into a single data transfer. To accelerate rendering operations on a GPU, a programmable shader (e.g., GLSL) enables handling of parallel processing through advances in general-purpose GPUs. Thus, a large number of polygons can be drawn instantaneously. Furthermore, the culling technique, in which polygons that disappear from sight are ignored, is effective at reducing rendering costs. According to the Unity document "Optimisation for VR in Unity," 30 a feature such as occlusion culling, which omits rendering of polygons hidden behind the foreground, is an effective performance optimization method for VR. This technique is advantageous for construction of objects in 3D games (e.g., hidden polygons are almost the same even if a player moves a shoulder width). On the other hand, for condensed ballstick systems (e.g., PNCs), the balls (spheres) and sticks

ACS Omega
Article (cylinders) cover less area behind objects, and thus polygons change drastically when moved very little. Therefore, VR walkthrough of condensed ball-stick systems suffers from problems associated with depth more than from details related to drawing polygons.
When the size of a system increases, problems result when drawing beyond the limits of data transfer. This is especially challenging for very large systems with moving objects, in which rendering processes become slower due to poor data-loading performance. As a result, frames are dropped, and dropped frames cause judder; 31,32 high-level programming skills for highperformance data loading are required to address the issue. Even in the absence of object motion, judder can occur when the system size increases. It is important to prevent judder in presentations and other educational uses because it can cause motion sickness symptoms (e.g., eyestrain, headache, nausea, or vomiting).
In modern VR setups such as HTC VIVE and Unity, we expected that the factor causing judder would originate from polygon depth processing, as mentioned above. To improve rendering performance related to avoiding judder, much useful information can be found on the Unity website. 18,30 However, this information may be too technical for the average chemical researcher. For nonexperts or novices of VR, system size of the VR model can be recognized as the primary index to control performance and to avoid judder. Therefore, it is beneficial to know system size limits quantitatively (i.e., number of polygons and vertices) in typical system configurations for each type of VR presentation. Moreover, for quantitative evaluation, it is desirable to have a performance evaluation method that can be easily implemented as a standard.

RESULTS AND DISCUSSION
We generated VR data with VMD 23 and displayed it using VR on VIVE by using Unity. 18 The possibility of using other VR devices (Oculus Rift and PSVR) is described in Supporting Information A. For the present benchmark measurements, we generated two types of data: ball-stick and isosurface. The present study examines the data size limits of various VR presentations. For the systematic benchmark measurements, we use the VR device as a pendulum (see details in Section 5.3) to generate periodic oscillatory motion during measurements of a time series in frames per second (fps).
3.1. VR Data Generated by VMD. 3.1.1. Visualization of Ball-Stick Data. In VMD, 23 ball-stick systems can be drawn by using PDB, xyz format files, and LAMMPS 33 trajectory files. In addition, the "Nanotube Builder" extension in VMD is useful for making atomic positions and bonds of multilayer graphene without positions required for the input data.
To investigate ball systems without sticks, we used the LAMMPS trajectory of a phase-separated system of ABA block copolymers with bead-spring simulations 34 of the Kremer− Grest model. 35 Details of the methods used for this simulation can be found in the literature. 34 Here, we built a chain of eight Asegments, 48 B-segments, and another eight A-segments. The spherical aggregations of the A-segments were nearly identical in size because the same simulation parameters were used. We prepared four systems: (i) 256 chains of 64 atoms, (ii) 512 chains of 64 atoms, (iii) 768 chains of 64 atoms, and (iv) 1024 chains of 64 atoms. Snapshots of the system are shown in Figure  1. VDW style was used as the drawing method in the graphical representation. Here, we set the sphere scale to 0.4.
3.1.2. Visualization of General Isosurfaces. VMD 23 can plot isosurfaces from field data in the AVS Field format as well as the Gaussian cube format. For the AVS Field format, however, VMD supports only uniform field types. In the AVS Field module in VMD, the order of description of the FLD file is restricted (refer to the sample file given in the Supporting Information). Here, we used 3D volume data of filler morphologies in rubber collected by using focused ion beam scanning electron microscopy (FIB-SEM). 36 Details concerning the measurements are provided in the literature. 36 We prepared three systems: (1) 192 × 192 × 192, (2) 256 × 256 × 256, and (3) 320 × 320 × 320 grids. Snapshots of these systems are shown in

ACS Omega
Article Figure 3. Isosurface style was used as the drawing method, with the isovalue set to 92.0.
3.1.3. Specifications of the Produced VR Data. We produced the VR data using VMD 23 as listed in Table 1. The table also presents the specifications of the VR data. We directly counted the number of polygons and vertices in the ".obj" file because this information is absent. Since the polygons and vertices depend on the degree of sphere and bond division, we

ACS Omega
Article used the default parameters: sphere resolution and bond resolution are 12 for the CPK or VDW style, and the step value is 1 for the isosurface style.

Evaluation of Data Size Limits of Various VR Presentations
. We compared the system performances of two GPU cards: NVIDIA GeForce GTX 1060 and GTX 1070. Both GPUs have 6 GB memory. The GTX 1060 has 1280 CUDA cores and the GTX 1070 has 1920 CUDA cores. In the performance tests, one of each of these GPUs was installed in a personal computer with an Intel Core i5 (6600K processor, 3.50 GHz) and 32 GB memory, running Windows 10 Professional as the OS. We placed the center of mass of the displayed objects at a height of 150 cm from the origin. The area with z < 0 was cut by using the "Cross Section Shader" for comparison with dynamic cutting of displayed objects in the next subsection. Figure 4 shows the measured time series of frame rates for various systems when using the GeForce GTX 1060 and GTX 1070. From Figure 4a, it is clear that the frame rate decreases as the number of atoms increases. For the case with 16 384 atoms, since the rate was near 90 fps, the influence of judder was considered negligible. In general, rendering lower than the refresh rate of the hardware used results in judder. 31,32 The refresh rate of HTC-VIVE is 90 Hz. For the case with 32 768 atoms, since the rate was around 75 fps, the influence of judder was not negligible. For cases with 49 152 and 65 536 atoms, since the frame rate was around 45 fps, the influence of judder was clearly observed. To avoid judder, we enabled the "Interleaved reprojection" function of SteamVR, which drops the frame rate to 45 fps by reprojecting every other frame. We found that the frame rates oscillated at a cycle of ∼2.1 s. A smaller number of objects located in front of the HMD showed higher frame rates. Consistent with the ratio of 1.33 associated with the benchmark 3DMark, 26 we confirmed that the frame rates of GeForce GTX 1070 were better than those of GeForce GTX 1060 (Figure 4d). Here, the average frame rates were compared between GeForce GTX 1060 and GeForce GTX 1070, and the ratio of fps from GTX 1070/GTX 1060 was calculated. For the case of 32 768 particles, the GeForce GTX 1060 rate was 70.86 fps and GeForce GTX 1070 rate was 89.58 fps, with a ratio of 1.26. When increasing the number of particles to 49 152, the GTX 1060 rate was 46.66 fps, whereas the GTX 1070 rate was 70.58 fps, with a ratio of 1.51. The latest GPUs, such as GeForce RTX 2080 and 2080 Ti, can achieve ratios relative to 3DMark 26 for GeForce GTX 1060 of 2.1 and 2.33, respectively. We expect the threshold for the number of particles to increase when using the latest GPUs. Verification using more recent GPUs is outside the scope of this study, but it is a future task that we intend to pursue.
From Figure 4b,e, it is clear that the performance of multilayer graphene is better than that of dense balls, although the numbers of polygons and vertices of the multilayer graphene were slightly larger than those of the dense balls. We expected the load from drawing dense objects to be larger than that from drawing sparsely distributed objects. To verify this, we tested cases with 2048 and 4096 chains of 64 atoms and generated VR data for Asegments only. Here, the A-segments numbered 32 768 and 65 536 atoms for 2048 and 4096 chains, respectively. Figure 5 shows the frame rates of densely and sparsely distributed balls of 32 768 and 65 536 atoms when using the NVIDIA GeForce GTX 1060. We concluded that the frame rate was smaller for denser objects.
From Figure 4c,f, it is clear that the frame rates from the isosurface of the filler morphologies observed by FIB-SEM 36 were better than those from multilayer graphene for similar numbers of polygons because the filler morphologies contained fewer vertices.
3.3. Performance for Dynamic Cutting of Displayed Objects. We examined the performance from dynamic cutting of displayed objects by using the Unity asset Cross Section Shader. Dynamic and intuitive control of cross sections enables researchers to better understand computational results. Figure 6 shows the results of dynamic cross-section cutting of the examined VR data. Snapshots are presented in Figure 6a−c. The frame rates of these objects when using NVIDIA GeForce GTX 1060 and GTX 1070 are given in Figure 6d−i. We found that the ball-stick systems with dynamic cutting performed worse than those with static cutting (examined in the previous subsection). On the other hand, the isosurface systems with dynamic cutting performed better than those with static cutting. We believe that this difference is due to the substantially increased number of displayed polygons visible in the cross section. In general, performance depends on the rendering algorithm and shaders used. Although our results cannot directly extend to different shaders due to the complexity of shader implementation (including deferred rendering 37 ), analyses and considerations for the shader "OnePlaneBSP" used in the present study may provide a useful guideline. Studies to estimate the performance of different shaders and improve performance are currently in progress.
After cutting the displayed objects, part of the polygon mesh disappears from the display area. Although we expected that this decrease in polygons would result in an increase in the frame rate, the performance of cut objects was worse than that of the complete objects. To use Cross Section Shader, the shader program OnePlaneBSP should be applied to the objects (see Supporting Information D3).
A general rendering process mainly contains four operations: (1) transformation of vertex positions in the polygon mesh, (2) tessellation from those vertices, (3) rasterization of the generated triangles, and (4) computation of color and other attributes of each pixel. The surface shader in OnePlaneBSP automatically generates programmable shader codes for those operations. The shader checks whether each pixel lies in front of the cutting plane, (p − a) n > 0, where p is the coordination of the pixel, a is the center of the plane, and n is the normal vector of the cutting plane. 27 When the pixel lies in front of the cutting plane, the pixel makes up the undisplayed objects as the attribute of the pixel in the operation (4). The calculation cost for pixel attributes increases with the number of polygons since each

ACS Omega
Article polygon is divided into pixels in proportion to the display area. To render cut objects, the surface shader in the shader program code OnePlaneBSP in Cross Section Shader (see Supporting Information D3) was used.
Here, the surface shader executed rendering processes (i.e., operations 1−4, above), with the calculation cost for pixel attributes depending on the number of polygons, as color and other attributes of each polygon are assigned to pixels. Although the surface shader program halted operations for pixels in parts of the cut object polygons, cost reduction was ultimately negligible. The reason for this is that the shader program performed shader operations on the pixels of all the polygons even though some of the polygons were hidden from view. Therefore, the rendering load does not decrease when cutting objects. Additionally, the interior of the objects observed in the cross-section view became filled-in white in the shader, as shown in Figure 6a−c. The reverse side of each polygon is generally ignored in the rendering process, and consequently, objects when viewed from the cross section seem to contain holes. This extra rendering cost causes a decrease in the frame rate when cutting objects.

SUMMARY
We demonstrated VR for CMS simulations using commodity VR devices. VR is an effective method not only for CMS simulations but also for chemical information and modeling in order to understand complicated 3D structures. In the present study, VR data were generated using VMD 23 and displayed on the VIVE 16 VR device via Unity. 18 For CMS, we assessed the drawing performance of ball systems, ball-stick systems, and isosurface systems. The ball system data were prepared from bead-spring simulations of ABA block copolymer phase separations. 34 The ball-stick systems were generated as multilayered graphene by using the Nanotube Builder function of VMD. The isosurface systems were graphical representations of 3D volume data of filler morphologies in rubber observed by FIB-SEM. 36 We systematically measured the frame rate for these systems while moving either the VR device or a handheld device as a pendulum.
We measured time series of frame rates for various systems using NVIDIA GeForce GTX 1060 and GTX 1070. For each condition, the frame rates of GeForce GTX 1070 were better than those of GeForce GTX 1060, reflecting the difference in the number of processing cores. The frame rate increased with the Figure 6. Results of dynamic cross-section cutting of the examined VR data. Snapshots of (a) phase-separated ABA block copolymers, (b) bilayer graphene, and (c) filler morphologies in rubber. Frame rates of various systems displayed with NVIDIA GeForce GTX 1060 (d−f) and 1070 (g−i).

ACS Omega
Article number of polygons in each system. We found that the spatial density of objects also influenced the frame rates by comparing ball systems and ball-stick systems. In the ball systems, the performances of sparsely populated systems were better than those of densely populated ones with the same numbers of polygons. On the other hand, the isosurface system showed much better performance when containing the same number of polygons due to fewer isosurface vertices than other systems. For practical use, we measured the performance of dynamic crosssection cutting. The frame rates decreased because, in the rendering program, hidden polygons from cutting undisplayed objects were not discarded until the last rendering process. The frame rates also decreased as the polygons visible in the cross section increased. We concluded that for drawing objects without judder using GeForce GTX 1070, fewer than 10 million polygons and 30 million vertices should be used, except in dense ball systems. For systems filled with dense ball objects, fewer than 4 million polygons and 13 million vertices (corresponding to 32 768 particles) are sufficient for drawing objects without judder. Regarding the latest GPUs such as GeForce RTX 2080 Ti, the 3DMark 26 performance was 2.33 times that of GeForce GTX 1060, which is the minimum requirement for operating HTC-VIVE. Because the performance ratio between GeForce GTX 1070 and GTX 1060 in this study agrees with that of the 3DMark 26 benchmark, the threshold is expected to improve with newer GPUs. Incidentally, along with the performance improvement of the GPU, the number of pixels of HMD increased. Recently, HTC VIVE Pro was released with 2880 × 1600 pixels, which is 1.78 times that of HTC VIVE (2160 × 1200). We expect that fps performance of HTC VIVE Pro with GeForce RTX 2080 Ti is comparable to that of HTC VIVE with GeForce GTX 1060. Investigation of the performance of these systems in detail is a future task.
Finally, we concluded that the commodity VR equipment was useful for VR observations of the isosurface of filler morphologies with 320 3 grid and dense particle systems with 32 768 particles. This shows that VR can be utilized for various research subjects of CMS, including PNCs.

METHOD
5.1. Preparation of VR Data by VMD. For practical use of VR for CMS, the method to make a VR model is similar to that used for 3D printing, which can also be regarded as a type of VR that produces a physical object in the process. Figure 7 illustrates the composition of software and hardware for practical application of VR to CMS. As shown, the VR-authoring tool directly controls the VR device, and VR-authoring tools generally require 3D VR data. Here, Wavefront OBJ, VRML, STL, and PLY are commonly used formats of VR data. The VR data are modeled using a VR modeler such as VMD 23 or AVS/ Express, which can handle CMS simulators such as VASP, 38 TOMBO, 39 LAMMPS, 33 and Gaussian. 40 The VR formats and VR-authoring tools can also be used for 3D printers. VMD 23 is a molecular visualization program developed and maintained with NIH support by the Theoretical and Computational Biophysics group at the Beckman Institute, University of Illinois at Urbana-Champaign. VMD is mainly designed for modeling, visualization, and analysis of biological macromolecules such as proteins. It is also useful for modeling CMS simulation data, as shown in Figure 8. Note that VMD can read POSCAR, CHGCAR, XML (VASP 5), and Gaussian cube formats. In VASP, atomic positions and charge densities are recorded by POSCAR and CHGCAR, respectively. In VASP 5 and higher, they are recorded in one XML format file, whereas in Gaussian, they are recorded in one file in the Gaussian cube format. An explanation of visualizing VASP data and Gaussian data is given in the Supporting Information. Besides atomic positions and charge densities, CMS studies are interested in the properties of Fermi surfaces. Here, to visualize Fermi surfaces by using VMD, BXSF format data must be converted into field data that is supported by VMD, such as the Gaussian cube format. Here, the BXSF format for XCrySDen 41 is widely used to present Fermi surfaces in density functional theory simulations. Similar approaches are described in the NOMAD documents. 21,22 Using VR, atomic positions can be presented as ball-stick systems, whereas charge densities and Fermi surfaces can be represented as isosurface systems. VR data of CMS simulations such as VASP and Gaussian can be expressed as combinations of balls and sticks and isosurfaces. Other CMS simulations, such as classical MD simulations and mesoscale simulations, can also use balls, sticks, and isosurfaces. Examples of ball-stick data are presented in Figure 8c,e,f, whereas examples of isosurface data are presented in Figure 8d. Since we want to determine the limitations of the drawing process of large systems, we decided that it is important to know the drawing characteristics of ballstick and isosurface systems. Therefore, in the present benchmark measurements, we separately evaluated the performances of these systems.
5.2. Control with VR-Authoring Tool by Unity. Unity 18 is a VR-authoring tool developed by Unity Technologies. Unity is widely used as a cross-platform game engine for 3D video games and simulations. In the present work, we used Unity version 2017.3. Note that Unity Technologies offers free educational licenses for academic institutions. Supporting Information B describes the setup for Unity version 2017. Supporting Information C is a step-by-step description of the use of Unity version 2017 for VR of CMS simulation data. Supporting Information D describes the setup of a function for cutting VR objects using Unity, whereas Supporting Information E describes the setup for measuring frame rates (in fps) in Unity. Note that a brief explanation of how the Unity asset Cross Section Shader works is given in Section 3.3.

Measurement Conditions.
For practical use, we want to understand the behavior of the frame rates for various object sizes during walk-through VR observations using cross sections

ACS Omega
Article from a handheld device. Since the motions during actual walkthrough VR observations are not reproducible, it is necessary to evaluate a reproducible motion. Furthermore, it is desirable to separate the movements of the VR device and the handheld device. To estimate the frame rate systematically, we required certain devices on a standard scale.
As a device for moving the head-mounted display (HMD) periodically, we first considered mounting the HMD on a rail frame with a motor. However, the production cost of such a device is much more than the cost of HTC VIVE, so it is not realistic in terms of commodity VR. As a device that periodically moves the HMD at low cost, we relied on the principles of nature and created a pendulum of the VR device and of the handheld device as shown in Figure 9. For the handheld device, we placed the VR device on the table at z = −40 cm. We swung the pendulum of the handheld device along the z-direction at its natural frequency. For a length of 125 cm, the natural period is ∼2.24 s. Here, the swing width of the pendulum was approximately from −50 to +50 cm. We manually maintained a constant swing width and direction. We recorded the number of frames drawn per second, with the first several seconds discarded and the following 50 s used. Here, we measured the frame rate in the Play mode of Unity to monitor several values by replacing the given models and measurements for simplicity (with the novice user in mind), although built binaries generally show slightly better performance than the Play mode.

* S Supporting Information
The Supporting Information is available free of charge on the ACS Publications website at DOI: 10.1021/acsomega.8b03483.
Availability of other VR devices, setup of Unity 2017 for VR, step-by-step use of Unity 2017, setup of VR object cutting function, measurement of frame rate, supporting note (PDF) Sample data; ball-stick systems drawn using PDB, xyz format files, and LAMMPS trajectory files, and isosurface system (ZIP)