1. Complex Geometry Visualization TOol
COGEVITO
Complex Geometry Visualization TOol

2. Definitions-Introduction
COGEVITO -> (COmplex GEometry VIsualization TOol)
JSON (JavaScript Object Notation)
is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999.
Three.js
In the last couple of years, browsers have become more powerful and are capable platforms to deliver complex applications and graphics. Most of these, though, are standard 2D graphics.
Most modern browsers have adopted WebGL, which allows you to create beautiful and good performing 3D applications using the capabilities of the GPU.
Programming WebGL directly, however, is very complex
Three.js provides a very easy interface to use JavaScript API around the features of WebGL, so you can create beautiful 3D graphics without having to learn WebGL in detail.
Three.js provides a large number of features and APIs that you can use to create 3D scenes directly in your browser
ROOT
(GEOM Package) – triangularization

3. Motivation Sharing graphics related to HEP on the web
New detector design
Monte Carlo simulations
Online Data Monitoring
Offline Data Analysis
Interactive web sites
New services: Consider information about time
and
display particles inside the detector
Just by using a web browser

4. Using ThreeJS Advantages Disadvantages
A PUBLIC DOMAIN SOFTWARE using WebGl for 3D graphics on the web
Advantages
Disadvantages
Powerful, with a lot of functionalities ready to use.
A lot of existing examples
Open Source
Flexible
Using JavaScript
Free
Being developed and new releases are published by deprecating old functionalities
Poor documentation in a few but important functions

5. ThreeJS and detector visualization
As a first step, we want to display a Geometry defined in ROOT (GEOM Package)
We export the Geometry in JSON format that can be then imported to ThreeJS.
Each volume is defined as a set of triangles that define its surface
During the implementation of this technic we understood the limitations and also eventual solutions to be tested in the future.

6. EXPORT from GEOM to JSON
It is possible to export the full information that is needed for visualization purposes from GEOM to JSON (ThreeJS format)
This is done by:
Exporting each of the logical volumes (Geometries).
They are defined in linear structure one after the other.
They can be a set of triangles or a volume defined using the primitives in ThreeJS
Exporting all materials that are used with their properties for visualization (actually we use color, transparency and saturation)
Exporting the full tree structure of physical volumes together with their rotation and translation matrix.
Each volume is positioned according to its local coordinates inside its mother volume.
This tree structure is kept in memory
Each volume is displayed when added in the scene
The tool we have developed is designed to function for any GEOM defined Structure.
There are some limitations on the type of volumes that are accepted. So far we cannot treat Composite shapes but we have a solution to the problem.
It is possible to use parameters like the max depth level or the name of the node defining the sub-tree we want to visualize.

7. Visualizing an exported geometry in JSON format ThreeJS
It is possible to write a tailored visualization tool and add all needed functionality (from scratch or by modifying existing editors)
There exist a beta version of an editor tool that may be used for testing purposes and this is the one we have chosen at this stage
The Geometry can be imported to the Editor which can assembly different Geometry JSON files if the positioning of the Top volume is absolute

8. Some trials
First we have tried some examples to understand the functionality and also the format in JSON for ThreeJS
Then we defined all logical volumes to see the file size (ALICE 2Gb, 64Mb Geometries and the remaining logical volumes)
In this case we excluded Assembly volumes
As expected … it runs out of memory
Our solution is defining only the first copy of a volume that is positioned and optionally all of them in order to have a visualization for comparison at a later stage
It is also possible to export up to a certain level of depth in the defined tree structure and there is also the possibility to select the branch of three to export
When a level is selected, then we do not count the assembly volumes but only the real level of a volume.
We are obliged to define also empty volumes when we encounter an assembly volume because they are positioned more times in the structure

9. Going Live (by examples)

10. Atlas (11.8 Mb  10.4 Gb Max level) depth level 4, all volumes defined

11. Atlas (4.5 Mb  6.9 Mb Max level) depth level 4, only first copy of volumes defined

12. Alice(14.7 Mb) Max depth level, only first copy of volumes defined

13. Alice “Dipole” (157 Kb) Max depth level, all volumes defined (selective view)

14. Rootgeom.C(165 Kb) Max depth level, all volumes defined

15. Rootgeom.C(28 Kb) Max depth level, only first copy of volumes defined

16. tank.C(436 Kb) Max depth level, all volumes defined

17. robot.C(2.1 Mb) Max depth level, all volumes defined