MS Report

Get Started. It's Free
or sign up with your email address
Rocket clouds
MS Report by Mind Map: MS Report

1. Getting started

1.1. Add a sibling idea by hitting ENTER

1.2. This is a sibling idea

1.3. Add a child idea by hitting TAB

1.3.1. This is a child idea

1.4. Choose icons and images to decorate your mind map

1.5. Connect topics with the arrow tool in the upper left corner of your screen

1.6. Add links, tasks or files to your topics, using the widgets in the sidebar

1.7. Change your map layout by opening the layout options in the upper left corner of your screen

1.8. Advanced

1.8.1. Open the Theme menu from the bottom of your map editor to change your map theme

1.8.2. Create a presentation of your mind map by clicking the presentation icon in the bottom left corner of your screen

1.8.2.1. Simply hold down COMMAND i.e. CTRL and Click & Drag to create a slide for one or multiple topics

1.8.2.2. Set transitions for your slides

1.8.2.3. Click "Start Slideshow" to view your presentation

1.8.3. Open the Sharing Settings from the bottom of your map editor to share the map with a friend or publish it to the web

1.8.3.1. You can share your map with anyone via email

1.8.3.2. You can publish your map and enable anyone with an internet access to find it

1.8.3.3. You can embed your map on a blog or website

2. By the way, this is a floating topic. To create a floating topic, simply drag it away from the map center.

3. Abstract

3.1. 3D scanners used in geological, environmental and preservation (archeological) work

3.2. Most of these data sets contain millions of points. Usage of software allows user to view the scan as a 3D object

3.3. With any data set, loading the data up there can be gaps or holes in the model. This can be caused by things like environmental factors or how the scanner was placed to capture the other sectors of the scan

3.4. There are other software that can load up point cloud (LiDAR) data onto personal computers such as potree

3.5. In this, I present a solution to sample the data and provide an appropriate splat size to cover any gaps

4. Introduction

4.1. Usage of 3D scanners are now more accessible to the public and data scientist. Where it can be used for geological, environmental and archaeological work

4.2. Users want to capture a scan that is as complete as possible.

4.3. Scan will usually have holes when rendered due to errors caused by the environment or user error

4.4. Finding the right splat size when rendering the data set can help to cover these gaps when you want to apply a mesh over the data afterwards or just render each point as a splat

4.5. We were given man point cloud data sets to visualize and with most of them, we would have to go with a trial and error approach to choosing the right splat size

5. Related Works

5.1. Potree Dissertation Paper Potree: Rendering Large Point Clouds in Web Browsers

5.1.1. Uses octree data structure to store and read the data

5.1.2. Uses Adaptive Points Sizes. It adjusts the level of detail to hide the differences of point density in different levels of details

5.1.3. Fixed Screen-Space Size: A fixed screen-space point size means that the same pixel size is used for all points. This mode is trivial to implement and sufficient in many cases. The main disadvantage of this mode is that it is prone to holes at close range and overdraw when the user zooms out.

5.1.4. Fixed World-Space Size: Instead of specifying a pixel size, the size is defined as the world-space radius in this mode. This leads to larger sizes at close range and reduced sizes for distant points.

5.2. Scanopy Dissertation Paper Interactions with Gigantic Point Clouds

5.2.1. Point size heuristic that can be used when rendering points stored in an MNO. It tries to adjust the screen sizes of the points such that a closed surface is mimicked for the rendered point cloud. It does so by increasing the point sizes in areas where the density of the rendered points would be otherwise too low for neighboring points to overlap.

5.3. Visually-Complete Aerial LiDAR Point Cloud Rendering

5.3.1. Due to the imaging process, vertical surface features such as building walls, and ground areas under tree canopies are totally or partially occluded, resulting in gaps and sparsely sampled areas. These gaps produce unwanted holes and uneven point distributions that often produce artifacts when visualized using point based rendering (PBR) techniques. We show how to extend PBR by inferring the physical nature of LiDAR points for visual realism and added comprehension

5.4. QSplat: A Multiresolution Point Rendering System for Large Meshes

5.4.1. The position and radius of each sphere is encoded relative to its parent in the bounding sphere hierarchy. In order to save space, these quantities are quantized to 13 values. That is, the radius of a sphere can range from 1=13 to 13=13 of the radius of its parent, and the offset of the center of a sphere relative to the center of its parent (in each of X, Y, and Z) is some multiple of 1=13 of the diameter of the parent sphere.

5.4.2. A hierarchy of bounding spheres [Rubin 80, Arvo 89] for visibility culling, level-of-detail control, and rendering. Each node of the tree contains the sphere center and radius, a normal, the width of a normal cone [Shirman 93], and optionally a color. One could generate such a bounding sphere hierarchy from polygons, voxels, or point clouds, though for our application we only needed an algorithm for generating the hierarchy from triangular meshes. The hierarchy is constructed as a preprocess, and is written to disk.

5.5. Instant Points

5.5.1. The error e in the original SPT (Sequential Point Trees) algorithm assumes that the points are actually splats (or surfels) with a splat size d and a normal vector n. Inner nodes have splat sizes that encompass the child nodes. This allows levels of detail where larger splats approximate flat surface areas, and smaller splats are used in curved areas.

5.5.2. The splat size used to render MOSPTs is determined in each outer octree node by the lowest level descendant (more specifically, the smallest projected bounding box of its associated MOSPT) that has all requested children loaded. This prevents gaps caused by missing nodes. The splat size of leaf nodes will coarsely depend on the sampling density using this construction. Alternatively, a fixed node size can be used for rendering leaf nodes.

6. Experiments

6.1. 9 data sets, 4 real 5 random

6.2. Implemented in Python, there were 7 different implementation used for testing when the benefit of more branch traversal doesn't help run time

6.3. Machine has Intel i7-4702HQ CPU @ 2.20GHz, 512GB SSD, 16GB DDR3 RAM running Windows 10 Pro

6.4. Finding Smallest Distance

6.4.1. Did a brute force implementation using SciPy and NumPy for 2 of the smaller data sets. Which numbered less than 50K data points

6.4.2. Over 50k, the brute force solution with pdist would use about 27GB of RAM.

6.4.2.1. Tested this on Dylan's Alienware

6.4.3. The brute force implementation would be unfair to the other data sets as the program would start to use my disk as RAM

6.4.4. pdist was used to calculate the distance between each point after reaching base case

6.4.5. Used an octree to put the points into the appropriate bin. Once I reach the user defined bin size, I would calculate the distance between each point for that bin and return the smallest distance

6.4.6. The test done was to traverse the most dense branch recursively then the 2 most braches and so forth. Stopped at 6 branches and the last implementation was build an entire octree structure with the distance of each bin stored in the leaf nodes

6.5. Finding Most Common Distance

6.5.1. Assumption that as the data is scanned the smallest distance should be the resolution that the scanner was set at is incorrect.

6.5.2. An idea was to find which distance was most commonly calculated

6.5.3. Minor modifications to the code and going with what was learned with the previous implementations, I only went down the most dense branch until I hit the bin threshold of 10000 or less

6.6. With both of these implementation, with the Waiopae data set at 30 million data points my machine would use about 12GB of RAM. Along with the normal RAM usage my machine uses, I got really close to using over my 16GB of RAM.

7. Results

7.1. Finding Smallest Distance

7.1.1. Chart of time and % error

7.1.2. There is no benefit to traversing extra branches. With the real data sets, all implementation was able to find the same answer.

7.1.3. The time that it took as we go through more branches seems to cause the program to run in exponential time.

7.1.4. Using the results from these tests, I used Ryan Theriot's Unity PointCloud Loader and loaded Waiopae and Tempel1

7.1.5. The result was that the coral data set appeared translucent and the asteroid points were spread apart in a way that the splat couldn't be seen without a black background

7.1.6. Tested this implementation on another data set, which wasn't part of the test runs. The French Frigate had the same translucent effect

7.2. Finding Most Common Distance

7.2.1. Using the most common distance yielded a better appearance

7.2.2. For tempel1, most of the empty space in the model were filled up and for the coral data sets, they looked completed without any major gaps

7.2.3. The same applied to another asteroid dataset called eros433

8. Conclusion

8.1. 3D scans done by scanners aren't truly uniform. There can be gaps caused by environment or humans.

8.2. There was no real benefit to choosing more branches to find the smallest distance between all of the points. A 1 branch traversal yielded the same splat size as the other 7 implementations.

8.3. The more branches that we recursively went down. The longer it took to get a results. The time it took seems to be exponential.

8.4. Finding the smallest distance didn't yield an appropriate splat size for the render to cover the space between the points.

8.5. Since the data isn't uniform to cover any gaps in the rendered model. Choosing an appropriate splat size helps to fix this.

8.6. Due to this fact, finding the smallest distance would be the same as finding the resolution that the scanner was set at

8.7. Finding the most commonly calculate distance yield a better result. The render model had most of its space between the points covered by the splat

8.8. This implementation was a better analogy of finding the scan resolution of the data set