OpenCL Acceleration for V-HACD

January 21, 2015, 10:56 pm

≫ Next: Unreal Engine 4 switches to V-HACD

≪ Previous: [V-HACD] Adaptive Convex-Hulls Sub-sampling

$

0

0

Since I don’t expect to have time in the near future to work on V-HACD , I am writing this post to keep track of the performance improvements obtained after the latest optimizations I added. The source code is available here.

Experimental Evaluation
Table 1 compares the computation times (cf. Section "Machine description") of V-HACD 2.0 and V-HACD 2.2 obtained by using the configuration described below (cf. Table 2). These results show that V-HACD 2.2 is an order of magnitude faster than V-HACD 2.0. The gains are mainly obtained thanks to the convex-hull approximation (cf. Section "Updates"). The OpenCL acceleration provides 30-50% lower computation times when compared to the CPU-only version of V-HACD 2.2. 

The code is still not fully optimized and more improvements could be expected!

	V-HACD 2.0 (CPU only)	V-HACD 2.2 (CPU+GPU)
army_man	650s	65s
block	220s	26s
Bunny	317s	30s
Camel	388s	34s
Casting	744s	79s
Chair	408s	42s
Cow1	314s	30s
Cow2	349s	32s
deer_bound	411s	34s

Table 1: Computation times: V-HACD 2.0 vs V-HACD 2.2 

Parameter	Config. 1
resolution	8000000
max. depth	20
max. concavity	0.001
plane down-sampling	4
convex-hull down-sampling	4
alpha	0.05
beta	0.05
gamma	0.0005
delta	0.05
pca	0
mode	0
max. vertices per convex-hull	64
min. volume to add vertices to convex-hulls	0.0001
convex-hull approximation	1

Table 2: Tested configuration 

Updates

V-HACD 2.2 include the following updates:

1. OpenCL acceleration to compute the clipped volumes on the GPU
2. Convex-hull approximation to accelerate concavity calculations
3. Added local concavity measure to clipping cost calculation
4. Changed command line parameters

To do
When I'll find time (probably not soon), I need to do the following:

• Test the code and build executables for different platforms (i.e., Linux, Mac OS), and 
• Update the Blender add-on to make it work with the new command line parameters.

Machine description

• OS: Windows 8.1 Pro 64-bit
• CPU: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz (8 CPUs), ~3.4GHz
• GPU: NVIDIA GeForce GTX 550 Ti
• Memory: 10240MB RAM

---

Unreal Engine 4 switches to V-HACD

April 2, 2015, 6:24 pm

≫ Next: Using V-HACD for 2D Approximate Convex Decomposition

≪ Previous: OpenCL Acceleration for V-HACD

$

0

0

Using V-HACD for 2D Approximate Convex Decomposition

April 10, 2015, 3:07 pm

≫ Next: A Simple C++ Class for 3D Mesh Decimation

≪ Previous: Unreal Engine 4 switches to V-HACD

$

0

0

A Simple C++ Class for 3D Mesh Decimation

June 26, 2015, 8:45 pm

≫ Next: Latest V-HACD source code

≪ Previous: Using V-HACD for 2D Approximate Convex Decomposition

$

0

0

Some time ago I wrote a simple C++ class to simplify a 3D mesh. It is based on Michael Garland's article "Surface Simplification Using Quadric Error Metrics"

The code is available under a BSD license.

A win64 executable is also available for quick testing.

The code produces good quality results. However, it is relatively slow!

Usage:
MeshSimplification fileNameIn.obj targetNTrianglesDecimatedMesh targetNVerticesDecimatedMesh maxDecimationError fileNameOut.obj

For instance, to generate a decimated mesh with 1000 triangles use the following command line:
MeshSimplification input.obj 1000 0 1.0 decimated.obj

To generate a decimated mesh with 1000 vertices:
MeshSimplification input.obj 0 1000 1.0 decimated.obj

To generate a decimated mesh with an error of 1%:
MeshSimplification input.obj 0 0 0.01 decimated.obj

To use the mesh decimation class in your code, proceed as follows:

// input mesh    
Vec3<Float>* points;
Vec3<int>* triangles;

// Fill points and triangles with input mesh
// ...

// decimate mesh
MeshDecimator myMDecimator;
myMDecimator.Initialize(nPoints, nTriangles, points, triangles);
myMDecimator.Decimate(targetNVerticesDecimatedMesh, targetNTrianglesDecimatedMesh, maxDecimationError);

// allocate memory for decimated mesh
size_t nVerticesDecimatedMesh = myMDecimator.GetNVertices();
size_t nTrianglesDecimatedMesh = myMDecimator.GetNVertices();
Vec3<Float>* decimatedMeshPoints =new Vec3<Float>[nVerticesDecimatedMesh];
Vec3<int>* decimatedMeshTriangles =new Vec3<int>[nTrianglesDecimatedMesh];

// retrieve decimated mesh
myMDecimator.GetMeshData(decimatedMeshPoints, decimatedMeshTriangles);

Latest V-HACD source code

January 24, 2016, 2:00 pm

≫ Next: Who is using Open3DGC?

≪ Previous: A Simple C++ Class for 3D Mesh Decimation

$

0

0

The latest version of the V-HACD code is available here https://github.com/kmammou/v-hacd

Who is using Open3DGC?

June 2, 2016, 7:20 pm

≫ Next: Open3DGC vs. Draco

≪ Previous: Latest V-HACD source code

$

0

0

Please, let me know if you are using open3dgc in your products/projects/articles

• Khronous glTF
• SEA3D Studio
• Cesium
• BLAST

Open3DGC vs. Draco

March 6, 2017, 1:20 am

≫ Next: HACD optimization

≪ Previous: Who is using Open3DGC?

$

0

0

I have recently read a blog comparing the Draco library released by google to the Open3DGC library I published in 2013. I'll try in this blog to reproduce the same results and provide a more complete experimental evaluation of both libraries.

Compression Efficiency

Reproducing results 

In the blog, the author used 11 bits for coordinates quantization and 10 bits for normals quantization. The test dataset used is composed of smooth and dense 3D meshes. I was able to reproduce comparable results (see table below). In a nutshell, Draco offers better compression results for 4 models out of 6.

	Draco	Open3DGC
bun_zipper.obj	118K	94K
armadillo.obj	561K	504K
dragon_vrip.obj	1.6M	1.4M
happy_vrip.obj	1.7M	2.0M
xyzrgb_dragon.obj	9M	11M
xyzrgb_statuette.obj	14M	17M

More results: higher quantization parameter 

However, as pointed out here (see the remark at bottom), using 11-bit quantization is not usually considered enough to preserve a good visual quality. Below I report the results obtained with 14-bit quantization for coordinates and 10 bits for normals. Here, Open3DGC offers better compression results than Draco for 5 models out of 6. For happy_vrip.obj, the two codecs provide comparable results.

	Draco	Open3DGC
bun_zipper.obj	153K	121K
Armadillo.obj	720K	593K
dragon_vrip.obj	1.8M	1.7M
happy_vrip.obj	2.2M	2.2M
xyzrgb_dragon.obj	10M	8.5M
xyzrgb_statuette.obj	18M	17M

More results: Bigger datasets

TBD

Encoding speed

According to the results reported in here, the Draco encoder is 2-5 times faster than the Open3DGC encoder. These results are expected since the Open3DGC encoder was not optimized for speed. In practice, encoding is usually an offline process and the network transmission is supposed to be the main bottleneck.

Decoding speed

According to the results reported in here, the Draco decoder is 0.5-3 times faster than the Open3DGC decoder. Except for bun_zipper.obj, Draco decoding is faster and the Open3DGC decoder.

HACD optimization

October 5, 2011, 6:56 am

≪ Previous: Open3DGC vs. Draco

$

0

0

Today, I have updated the HACD library in order to reduce both memory usage and computation complexity (cf. http://sourceforge.net/projects/hacd/). 

The new version:

• uses John's Micro Allocator to avoid intensive dynamic memory allocation (thanks John for the great work),
• exploits a simplified version of  an axis-aligned-bounding-volume AABB tree to accelerate dual graph generation (the code is inspired by John's post on this subject, thanks again John :) )
• has an integrated mesh simplification pre-processing step, which makes it possible to handle dense meshes.

In this post, I'll give more details about this last feature.

To enable mesh decimation, the user specifies the target number of triangles that should be produced before running the convex decomposition. HACD will handle automatically the simplification and the decomposition processes. For the details of the mesh decimation algorithm, have a look at Michael Garland's  webpage http://mgarland.org/research/thesis.html. To turn this feature off just set the parameter targetNTrianglesDecimatedMesh=0.

I have tested the updated HACD algorithm on the 3D model "Bunny", which has 70K triangles. The HACD's parameters were set as follows:

• minNClusters = 12
• maxConcavity = 1000
• addExtraDistPoints = 1
• addFacesPoints = 1
• ConnectedComponentsDist = 30
• targetNTrianglesDecimatedMesh = 500, 1000, 2000, 4000, 8000 and 16000.

The snapshots of the produced convex decompositions are reported below. The computation times on my machine (Mac Intel Core 2 Duo, 4 GB RAM DDR3) ranged between 3 sec. for 500 triangles and 200 sec. for 16000 triangles (cf. Table 1 for the details).

----------------------------------------

# triangles Time (sec.)

----------------------------------------

5002.8

10004.6

200010

400021

800070

16000192

----------------------------------------

Table 1. Computation times for targetNTrianglesDecimatedMesh= 500, 1000, 2000, 4000, 8000 and 16000 

# triangles after simplification - 500

# triangles after simplification - 1000

# triangles after simplification - 2000

# triangles after simplification - 4000

# triangles after simplification - 8000

# triangles after simplification - 16000

---