The joy of computer graphics programming

Mathématiques - Informatique
Eurographics 2017
Bruno Lévy
ALICE Géométrie & Lumière
CENTRE INRIA Nancy Grand-Est
The Joy of
Computer Graphics Programming
Bruno Lévy, Inria researcher

Introducing myself…
First name: Bruno
Familly name: Lévy
Age: approaching 45
Occupation: Inria ALICE team lead (since 2004)
ALICE = Geometry processing + Fabrication (S. Lefebvre)
Research: navigating between graphics, math. and physics
Code: open-source (geogram),commercial (GOCAD, Vorpaline)

Introducing myself…
First name: Bruno
Familly name: Lévy
Age: approaching 45 (born in 1972 = 4004+1)
Occupation: Inria ALICE team lead (since 2004)
ALICE = Geometry processing + Fabrication (S. Lefebvre)
Research: navigating between graphics, math. and physics
Code: open-source (geogram),commercial (GOCAD, Vorpaline)

OVERVIEW
1. Introduction, let s talk about programming
2. Graphics: eye candy with GLUP
3. Numerics: cranking the number cruncher
4. Geometry: predicates without the agonizing pain
What s next ? Physics+Mathematics+Computing=?

Part. 1 On Software Design
War stories on the design and implementation
of geogram, graphite and vorpaline

Documented open-source* implementations of reference algos.
+ the most important results from my group (2000 to 2017)
Algorithms from >20 research articles
and two ERC projects (GOODSHAPE and VORPALINE)
*Geogram (BSD) and Graphite (GLP), Vorpaline is proprietary

Documented open-source* implementations of reference algos.,
+ the most important results from my group (2000 to 2017)
Algorithms from >20 research articles
and two ERC projects (GOODSHAPE and VORPALINE)
•Mesh parameterization (LSCM, ABF++, PGP)
•Spectral mesh processing (Manifold Harmonics)
•Newton Centroidal Voronoi Tesselation (surfaces and volumes)
•Remeshing, reconstruction, Optimal Transport
•Low-level algorithms (Delaunay, Voronoi, predicates) …
*Geogram (BSD) and Graphite (GLP), Vorpaline is proprietary

From my attic: my first computer !

1979 Apple ][
6502 processor, 1MHz
64Kb RAM
Approx. 10 FLOPs

1979 Apple ][
64Kb RAM
Approx. 10 FLOPs
2017 PC
Core i7 gen3, 3 GHz
16Gb RAM
Approx. 100 GFLOPs

1979 Apple ][
64Kb RAM
Approx. 10 FLOPs
2017 PC
Core i7 gen3, 3 GHz
16Gb RAM
Approx. 100 GFLOPs
X 1 million !!!!
38 years

Boots in 20 seconds Boots in 3 minutes

Where did the 1 million acceleration factor go ?

What can you do in 20 seconds ?
3 GHz, 4 cores = 240 billions instructions !!

If you cannot do the job in less than 20 seconds
on a modern PC, then there is probably a
problem somewhere
What can you do in 20 seconds ?
3 GHz, 4 cores = 240 billions instructions !!

Where did the 1 million acceleration factor go ?
- Lost in abstraction -

Abstraction in Programming:
+ Separates concepts
+ Separates specification from Implementation

Abstraction in Programming:
+ Separates concepts
+ Separates specification from Implementation
- Sometimes separates things
that should be considered together !!

Background on Futuristic Programming
Paul Haeberli - 1994
www.graficaobscura.com/future/index.html

Background on Futuristic Programming

Futuristic Programming Priorities
1. It is something that has NEVER BEEN DONE BEFORE.
2. The USER LIKES to use the program.
3. The program is as FAST as it can be.
4. The program is as SMALL as it can be.
5. The program is BUG-FREE.
6. The program needs NO USER MAINTENANCE.
7. The program requires NO USER DOCUMENTATION.
8. The program requires NO SYSTEM ADMINISTRATOR

Geogram/Graphite Programming Priorities
1. Make it as simple as possible (but not simpler)

2. Make it as easy to use as possible

3. Make it as easy to compile as possible

4. Maximize speed

4. Maximize speed
5. Minimize memory consumption

4. Maximize speed
6. Minimize number of lines of code

4. Maximize speed
7. Minimize number of C++ classes

4. Maximize speed
Simplicity is the
ultimate sophistication

4. Maximize speed
8. Systematically document all classes, all functions, [+Biblio.]
9. Systematically document the implementation of all algorithms
10. Assertion checks everywhere
11. Zero warnings with all compilers / platforms
12. Perform systematic non-regression testing and mem. check.

Futuristic programming
Usefullness (and coolness) are primary !

• Jonathan Shewchuk s Triangle and exact predicates
• Tetgen, MGTetra, MMG3d
• Omar Cornut s ImGUI library
• David Mount s ANN library
• The LUA prog. language
Futuristic programming
Examples of Futuristic codes
Usefullness (and coolness) are primary !

Case study: mesh data structures
From several Computer Graphics / Mesh Processing 101 courses
- including (earlier versions of) mine -

Halfedges Design Principles
1. Individual combinatorial elements
can be created/destroyed at any time
in constant time
2. Basic operations (collapse, split, )
3. Higher-level operations on top of them
Halfedges and edgeuses, harmful or useful ?

+ Benefit of abstraction: layered design
in constant time

- Separates things that should have been considered together
in constant time

- Separates things that should have been considered together
Not the optimal level of granularity
in constant time

Indexed Mesh data structure (no data structure)

Objection ! (?) Deletion of one individual element is O(n) instead of constant
In fact: deleting 1 element = wrong granularity level !

Deleting a bunch of elements

Deleting a bunch of elements – operates also in O(n) – right granularity

Deleting a bunch of elements – operates also in O(n) – right granularity
Needs array permutation (not in the STL unfortunately,
but easy to implement, see GEOGRAM::permutation).

Summary:
•An array of vertices coordinates
•An array of triangle vertices indices

•An array of vertices coordinates
•An array of triangle vertices indices
•An array of triangle adjacencies (optional)
•An array of facet first indices (optional)
Summary:

Benefits of such a
non-datastructure, non-object, non-oriented, (non-)programming
1. Simpler code

Benefits of such a
1. Simpler code
2. Less memory;

Benefits of such a
1. Simpler code
2. Less memory;
3. Parallelization #pragma omp parallel for

Benefits of such a
1. Simpler code
2. Less memory;
4. Easy copy: memcpy()

Benefits of such a
1. Simpler code
2. Less memory;
5. Easy I/O: fread()/fwrite()

Benefits of such a
1. Simpler code
2. Less memory;
6. Properties/attributes are simply additional arrays

Benefits of such a
1. Simpler code
2. Less memory;
6. Properties/attributes are simply additional arrays
7. Directly understood by OpenGL: VertexBufferObject

A mesh = a bunch of arrays (std::vectors)

How do you iterate on a vector ?

Pre-2011:
for(std::vector<Thing>::iterator it = V.begin(); it!=V.end(); ++it) {
do something with *it
}

Pre-2011:
}
It s a pain to type
Clutters the source-code (less legible)

Pre-2011:
}
2011:
for(auto it = V.begin(); it!=V.end(); ++it) {
}

Pre-2011:
}
2011:
}
now:
for(auto&& i : V) {
do something with i
}

Warning: flying tomatoes alert ahead,
(modern C++ lovers might throw tomatoes at me)!

Pre-2011:
}
2011:
}
now:
for(auto&& i : V) {
do something with I
}

How I iterate on a vector:
for(uint i=0; i<V.size(); ++i) {
do something with V[i];
}

}
+ Easy to understand, even by C-only and Fortran programmers
+ Compatible with all compilers
+ #pragma omp parallel-for friendly* (and also better vectorization)
- 15 additional keystrokes as compared to modern C++ range-for
*But use ints instead of uints, omp does not like uints

}
+ Easy to understand, even by C-only programmers
+ #pragma omp parallel-for friendly
The following code has been approved for
APPROPRIATE AUDIENCES
PG-13

}
+ Easy to understand, even by C-only programmers
+ #pragma omp parallel-for friendly
#define FOR(i,N) for(uint i=0; i<(N); ++i)
FOR(i,V.size()) {
}
+ Easy to understand, legible
+ Trivial iterations easy to spot
- Macros are evil
[Nicolas Ray]

Objection:
It is bad because it is not flexible,
what if you want to adapt your algorithm to another container ?

Objection:
Answer:
I m not going to use something else than a vector, because it is the best
choice for the mesh data structure. Why keeping a tuning knob on the
dash board if it is always on the same position ?
modern/generic != futuristic

Objection:
Answer:
I m not going to use something else than a vector, because it is the best
choice for the mesh data structure. Why keeping a tuning knob on the
dash board if it is always on the same position ? (think of the I-Phone)
The Nokia N95, a
modern/generic phone.
The I-phone,
a futuristic phone.

It is good because it has
everything that you need
The Nokia N95, a
The I-phone,
a futuristic phone.

It is even better because it has
nothing else than what you need
The Nokia N95, a
The I-phone,
a futuristic phone.

It is even better because it has
nothing else than what you need
Work is finished when you have
nothing to add and nothing to remove !
The Nokia N95, a
The I-phone,
a futuristic phone.

Why keeping a tuning knob on the dash board if it is always
on the same position ? (think of the I-Phone)
A parameter that always has the same value is not a parameter and should be
removed from the API.
A template that is instanced only once should not be a template.

Objection: but we loose genericity if we do that ???

Objection: but we loose genericity if we do that ???
Answer to objection: but we gain a lot, it declutters the
code, makes it more legible, reduces compilation times,
makes C++ compilation error messages more legible.

Rule of thumb:
Make it a parameter not before you need it with at least two different values.
Make it a template not before you need at least two different instanciations.
*regarding compilation time, legibiity of error messages and run-time flex.

Rule of thumb:
Make it a parameter not before you need it with at least two different values.
Make it a template not before you need at least two different instanciations.
About templates, consider less annoying* alternatives, such as
(1) object oriented programming / virtual functions
(2) or simply a parameter and if() statements
*regarding compilation time, legibility of error messages and run-time flex.

Graphics
2
Fast and Easy eye-candy with GLUP

Part. 2 Graphics – endangered species
The Windows start menu The I-Phone jack
glBegin(GL_TRIANGLES)
glVertex(… )
glEnd()
OpenGL immediate mode
glPush/Pop/MultMatrix()
glLight()
OpenGL fixed functionality pipeline

Part. 2 Graphics – endangered species
glBegin(GL_TRIANGLES)
glVertex(… )
glEnd()
OpenGL immediate mode
glPush/Pop/MultMatrix()
glLight()
OpenGL fixed functionality pipeline
Difficulties for an undergraduate who starts:
(1) Assemble vertex buffer objects
(2) Design vertex and fragment shaders
(3) (+ the Professor, I see nothing syndrom, nothing new here)
R.I.P. R.I.P.

Part. 2 Graphics – GLUP
Immediate mode + fixed functionality pipeline implemented
in modern OpenGL (4.x) (nearly source-compatible)
glupBegin(), glupEnd(), glupVertex(), glupPushMatrix()…

normals not needed (per-fragment shading)

new volumetric primitives:
GLUP_TETRAHEDRA, GLUP_HEXAHEDRA,
GLUP_PRISMS, GLUP_PYRAMIDS, GLUP_SPHERES

new clipping modes (on-GPU marching cells algorithm)

new clipping modes (on-GPU marching cells algorithm)
glupEnable(GLUP_DRAW_MESH)

glupDrawArrays(), glupDrawElements(), VBOs
VanillaGL (1.x)
OpenGL ES,
WebGL
GLSL 1.5 (GL3.3)
GLSL 4.4 (GL4.4)
POINTS LINES TRGLS QUADS SPHERES T ETS PRISMS HEXES PYRAMIDS
glupDrawArrays()/glupDrawElements()/VBOs and immediate mode
Immediate mode only

glupDrawElements(GLUP_TETRAHEDRA)
1 single draw call with VBOs, everything occurs on GPU
glupSetClippingMode(GLUP_CLIP_SLICE)

glupDrawElements(GLUP_SPHERES)
1 single draw call with VBOs, everything occurs on GPU
(GLUP + screen-space ambient occlusion in Graphite)

glupDrawElements(GLUP_HEXAHEDRA)
2 draw calls with VBOs, everything occurs on GPU
Hexahedral-dominant mesh [Ray, Sokolov, Unterreiner, L 2016]

glupDrawElements(GLUP_HEXAHEDRA)
2 draw calls with VBOs, everything occurs on GPU
Cross-section computed with on-GPU marching cells with interpolated attrib.

Numerics
3
Cranking the number cruncher

Part. 3. Numerics
Numerical problems: neighborhoods
F = sum of terms, attached to neighborhoods
Discrete fairing
[Kobbelt98, Mallet95]
Parameterization
[Desbrun02]
Deformations
[CohenOr], [Sorkine]
Curv. Estimation
[Cohen-Steiner 03]
Texture mapping
[L01]
Discrete fairing
[Desbrun], ...
Parameterization
[Haker00]
[L02]
[Eck]

Part. 3. Numerics
Numerical problems: mesh parameterization
i
j1
j2
j…
Ui = ai,jUj
j  Ni
 i,j ai,j > 0
ai,i = -  ai,j
The border is mapped to
a convex polygon
[Tutte], [Floater]

Part. 3. Numerics
Numerical problems: mesh fairing
i
j1
j2
j…
F(p)=  pi - ai,jpj
2
j  Nii
[Mallet], [Kobbelt], [Sorkine]

Part. 3. Numerics

Part. 3. Numerics
F(x) =
2A x - b

Part. 3. Numerics
F(xf) =
xf
xl
[ Af Al] - b
2
F(x) =
2A x - b

Part. 3. Numerics
Numerical problems: least squares
F(xf) = A.x - d = Al.xl + Af.xf - d
2 2

Part. 3. Numerics
2 2
F(xf) minimum Af
t.Af.xf = Af
t.d - Af
tAl.xl
M.x = b
}
}

Part. 3. Numerics
2 2
F(xf) minimum Af
t.Af.xf = Af
t.d - Af
tAl.xl
M.x = b
}
}
The problem:
(1) construct the linear system (assembly)
(2) solve a linear system

Part. 3. Numerics – the OpenNL library.
The problem:

The problem:
Similarity between a mesh and a sparse matrix:

The problem:
nlBegin(NL_ROW)
nlAddCoefficient(I,j,val)
nlRightHandSide(val)
nlEnd(NL_ROW)
Similarity between a mesh and a sparse matrix:
OpenNL: API inspired by OpenGL immediate mode.
(+ automatic construction of AtA for least-squares)

The problem:
NLSparseMatrix: dynamic data structure (can grow)
OpenNL internals
…
…
…
…
…

The problem:
NLSparseMatrix NLCRSMatrix
OpenNL internals
nlCompress()

The problem:
NLSparseMatrix NLCRSMatrix NLCusparseMatrix
OpenNL internals GPU
nlCompress() (optionnal)

Part. 3. Numerics – the OpenNL library
The problem:
nlSolve() Iterative solvers
CG
GMRes
BiCGStab
CPU/GPU
Abstraction layer
OpenMP
multicore
CUDA
CuBLAS
CuSparse

The problem:
nlSolve() Iterative solvers
Direct solvers
CG
GMRes
BiCGStab
SuperLU
CHOLDMOD
CPU/GPU
Abstraction layer
OpenMP
multicore
CUDA
CuBLAS
CuSparse

The problem:
nlSolve()
Iterative solvers
Direct solvers
CG
GMRes
BiCGStab
SuperLU
CHOLDMOD
CPU/GPU
Abstraction layer
OpenMP
multicore
CUDA
CuBLAS
CuSparse
Eigen solver ARPACK

OpenNL as a pluggable software module
Following futuristic programming principles:
* OpenNL also available as a single .c,.h pair, portable
to all architectures, easy to compile.
* Object-Oriented abstract matrix interface in C (achieves
run-time CPU/GPU flexibility)
* Dynamically loads CUDA CuBLAS and CuSparse
on demand (as well as CHOLMOD, SUPERLU,ARPACK)
* Double precision (and no single precision).

OpenNL at work Everything available in geogram
GUI in graphite

OpenNL at work
LSCM,
Spectral parameterization.
(600 lines of code for both)
ABF++ (800 lines of code)
PGP, QuadCover, MIP.
(700 lines of code)
Manifold Harmonics, HKS, ADF. (400 lines of code)
Everything available in geogram
GUI in graphite

GUI in graphite
Baby groot © Marvel (this version by Byambaa on Thingyverse)

GUI in graphite
Automatic decimation and normal
map generation.
Baby groot © Marvel (this version by Byambaa on Thingyverse)

Geometry
4
Predicates without the agonizing pain*
*Section title is a tribute to Jonathan Shewchuk.

The joy of computer graphics programming

4. Geometry - Motivations
[Martinez, Dumas, Lefebvre]

4.Geometry Motivations
René Descartes
Wonder
Shapes
Structures
Symmetry

Part. 4. Geometry
Computing (restricted) Voronoi diagrams

Part. 4 Geometry
Pointset X Simplicial complex S
either triangulated surface
or tetrahedralized solid
The input

Part. 4 Geometry
Vor(X)|S (Intersection between Vor(X) and S)
The output

Part 4. Geometry – a difficult dataset
Lots of degeneracies:
Voronoi diagram with degree 4 vertices.
Voronoi cell faces match exactly facets of the initial surface.

Part. 4 Geometry
Voronoi cells as iterative convex clipping
Half-space clipping
xi
x1
x2
x3
x4
x5
x6
x7
x8
x9
x10
x11

Part. 4 Difficulties – predicates
xi
xj
Elementary operation: cut a polygon
(or polyhedron) with a bisector

xi
xj
Classify the vertices of the polygon

xi
xj
Sign( d(p,xj) – d(p,xi)) > 0

xi
xj
Sign( d(p,xj) – d(p,xi)) < 0

xi
xj
Compute the intersections

xi
xj
Compute the intersections - discard

xi
xj
xk Now clipping with the bisector of (xi, xk)

xi
xj
We need to classify all the points, including
these ones !

xi
xj
these ones !
(they are intersections between a
segment and a bisector)

xi
xj
these ones !
(they are intersections between a
segment and a bisector)
This generates a new intersection
(between a facet and two bisector)

Three configurations
1) Side(xi,xj,q) where q is a vertex of S

1) Side1(xi,xj,q)

1) Side1(xi,xj,q)
2) Side(xi,xj,q) where q = π(i,k) ∩ [p1,p2]

1) Side1(xi,xj,q)
2) Side2(xi,xj,xk,p1,p2)

1) Side1(xi,xj,q)
3) Side(xi,xj,q) where
q = π(i,k) ∩ π(i,l) ∩ [p1,p2,p3]

1) Side1(xi,xj,q)
3) Side3(xi,xj,xk, xl,p1,p2,p3)

1) Side1(xi,xj,q)
Implementations of exact predicates:
- J. Shewchuk s code
- CGAL (Pion, Meyer)

1) Side1(xi,xj,q)
Implementations of exact predicates:
- J. Shewchuk s code
- CGAL (Pion, Meyer)
They do not have Side1(), Side2(), Side3() ( exotic predicates )

1) Side1(xi,xj,q)
How to implement Side1(), Side2(), Side3() ?
We need an exact number type with +,-,*,Sign()

Part. 4 Exact Arithmetics
Wish list:
• Easy to use
(no Guru needed for each new predicate)
• Reasonably efficient
• Easy to compile/integrate ( Futuristic programming )
(multi_precision.h, multi_precision.cpp and that s all)

Idea #1: (dense) multi-precision (GMP)
a0a1a2a3
x 20
x 21*32x 22*32x 23*32
…
Each number is an array of (32 bits) integers:
Implement +,-,* (reasonably easy)
Sign: look at the leading non-zero component

a limitation :
c = a10 * 210*32 + b0

a limitation :
b000a10
x 20x 210*32
c = a10 * 210*32 + b0
…

Idea #2: (sparse) multi-precision
b0 | 0a10 | 10
c = a10 * 210*32 + b0
Store the exponents of the components

b0 | 0a10 | 10
c = a10 * 210*32 + b0
Exp. Exp.

b0 | 0a10 | 10
c = a10 * 210*32 + b0
Exp. Exp.mantissa mantissa

b0 | 0a10 | 10
c = a10 * 210*32 + b0
Exp. Exp.mantissa mantissa
These are floating point numbers !!!

Idea #3: expansions (Shewchuk)
x3 x2 x1
…
Each number is represented by the sum of an array of components

x3 x2 x1
…
They are sorted in decreasing exponents

x3 x2 x1
…
They are non-overlapping

x3 x2 x1
…
They are non-overlapping
The sign is determined by the first component (highest exponent)

x2 x1Two_sum(double a, double b)

+
Length:
l+m
Length l Length m

+
*
Length:
l+m
Length:
2*l
A double
Length l

* …
Length: 2*l*m
Expansion * Expansion product implemented by a recursive function
( distillation )
Length l Length m

* …
( distillation )
Performance ? 10 to 40 times slower than standard doubles
Length: 2*l*mLength l Length m

* …
( distillation )
Use arithmetic filters
Adaptive precision [Shewchuk] ? Too complicated to get right

* …
( distillation )
Use arithmetic filters
Adaptive precision [Shewchuk] ? Too complicated to get right
Quasi-static filters [Meyer and Pion] – FPG generator (easy to use)

PCK (Predicate Construction Kit)
multi_precision.h / multi_precision.cpp
A low-level expansion class (allocates expansions on stack)
A high-level C++ number type (+,-,*,Sign overloads)
a compiler that generates the filter with FPG [Meyer and Pion] and the
exact precision version with expansions

(why not templates / metaprogramming ?
would be possible, but specialized language is much better here).

So we are done ?

Part. 4 Symbolic Perturbation
xi
xj
Not yet !!

[Voronoi]
[Edelsbrunner et.al]
[Devillers et.al]

[Voronoi]
[Devillers et.al]
Each point pi is replaced
by a trajectory pi(ε)
xi(ε) = xi + ε3i
yi(ε) = yi + ε3i+1
zi(ε) = zi + ε3i+2
For instance:

[Voronoi]
[Devillers et.al]
Each point pi is replaced
by a trajectory pi(ε)
Take the limit when
ε tends to 0

xi
xj
π(i,j) = {p | d2(p,xi) = d2(p,xj)}
[Voronoi]
[Devillers et.al]
In our case, perturb the
weights of a power diagram.

xi
xj
πw(i,j) = {p | d2(p,xi) - wi = d2(p,xj) - wj}
[Voronoi]
[Devillers et.al]
In our case, perturb the
weights of a power diagram.

xi
xj
[Voronoi]
[Devillers et.al]
The Voronoi diagram is replaced with a power diagram

xi
xj
[Voronoi]
[Devillers et.al]
Symbolic perturbation – Simulation of Simplicity:
Define the weight as a function of ε: wi = εi

xi
xj
[Voronoi]
[Devillers et.al]
Symbolic perturbation – Simulation of Simplicity:
Define the weight as a function of ε: wi = εi
The combinatorics is determined by the limit ε →0

How to write side1(), side2(), side3(), side4() ?
d2(q,pj)-wj – d2(q,pi) + wi where:
q = πw(i,k1) ∩ …πw(i,kd) ∩ [p1,p2,p3…pd]

Solve for q in:
q Є πw(i,k1)
…
q Є πw(i,kd)
q Є [p1,p2,p3…pd]
{

q = (1/d) Q
Keep numerator and denom.
separate (remember, we are
not allowed to divide)
Solve for q in:
q Є πw(i,k1)
…
q Є πw(i,kd)
{

q = (1/d) Q
Inject q=(1/d) Q in side1() and mutliply by d to remove the division
Solve for q in:
q Є πw(i,k1)
…
q Є πw(i,kd)
{

q = (1/d) Q
Order the terms in wi = εi
Solve for q in:
q Є πw(i,k1)
…
q Є πw(i,kd)
{

q = (1/d) Q
Order the terms in wi = εi the constant one is non-perturbed predicate
if zero, the first non-zero one determines the sign
Solve for q in:
q Є πw(i,k1)
…
q Є πw(i,kd)
{

Part. 4 Symbolic Perturbation – side1
#include "kernel.pckh"
Sign predicate(side1)(
point(p0), point(p1), point(q0) DIM
) {
scalar r = sq_dist(p0,p1) ;
r -= 2*dot_at(p1,q0,p0) ;
generic_predicate_result(sign(r)) ;
begin_sos2(p0,p1)
sos(p0,POSITIVE)
sos(p1,NEGATIVE)
end_sos
}
Source PCK

point(p0), point(p1), point(q0) DIM
) {
scalar r = sq_dist(p0,p1) ;
r -= 2*dot_at(p1,q0,p0) ;
generic_predicate_result(sign(r)) ;
begin_sos2(p0,p1)
sos(p0,POSITIVE)
sos(p1,NEGATIVE)
end_sos
}
Source PCK
(p1-p0).(q0-p0)

#include "kernel.pckh“
Sign predicate(side2)( point(p0), point(p1), point(p2), point(q0), point(q1) DIM) {
scalar l1 = 1*sq_dist(p1,p0) ;
scalar a10 = 2*dot_at(p1,q0,p0);
scalar Delta = a11 - a10 ;
scalar DeltaLambda0 = a11 - l1 ;
scalar DeltaLambda1 = l1 - a10 ;
scalar r = Delta*l2 - a20*DeltaLambda0 - a21*DeltaLambda1 ;
Sign Delta_sign = sign(Delta) ;
Sign r_sign = sign(r) ;
generic_predicate_result(Delta_sign*r_sign) ;
begin_sos3(p0,p1,p2)
sos(p0, Sign(Delta_sign*sign(Delta-a21+a20)))
sos(p1, Sign(Delta_sign*sign(a21-a20)))
sos(p2, NEGATIVE)
end_sos
} Source PCK

sos(p2, NEGATIVE)
end_sos
} Source PCK
Denominator

sos(p2, NEGATIVE)
end_sos
} Source PCK
Barycentric
coords. of q

sos(p2, NEGATIVE)
end_sos
} Source PCK
Barycentric
coords. of q
Solely depend
on dot products
between input
points

sos(p2, NEGATIVE)
end_sos
} Source PCK
Result when in
generic position

sos(p2, NEGATIVE)
end_sos
} Source PCK
Symbolic
perturbation

Sign side2_exact_SOS(
const double* p0, const double* p1, const double* p2,
const double* q0, const double* q1,
coord_index_t dim
) {
const expansion& l1 = expansion_sq_dist(p1, p0, dim);
const expansion& l2 = expansion_sq_dist(p2, p0, dim);
const expansion& a10 = expansion_dot_at(p1, q0, p0, dim).scale_fast(2.0);
const expansion& Delta = expansion_diff(a11, a10);
Sign Delta_sign = Delta.sign();
vor_assert(Delta_sign != ZERO);
const expansion& DeltaLambda0 = expansion_diff(a11, l1);
const expansion& DeltaLambda1 = expansion_diff(l1, a10);
const expansion& r0 = expansion_product(Delta, l2);
const expansion& r1 = expansion_product(a20, DeltaLambda0).negate();
const expansion& r2 = expansion_product(a21, DeltaLambda1).negate();
const expansion& r = expansion_sum3(r0, r1, r2);
Sign r_sign = r.sign();
………..
Exact version with expansions

if(r_sign == ZERO) {
const double* p_sort[3];
p_sort[0] = p0;
p_sort[1] = p1;
p_sort[2] = p2;
std::sort(p_sort, p_sort + 3);
for(index_t i = 0; i < 3; ++i) {
if(p_sort[i] == p0) {
const expansion& z1 = expansion_diff(Delta, a21);
const expansion& z = expansion_sum(z1, a20);
Sign z_sign = z.sign();
len_side2_SOS = vor_max(len_side2_SOS, z.length());
if(z_sign != ZERO) {
return Sign(Delta_sign * z_sign);
}
}
const expansion& z = expansion_diff(a21, a20);
Sign z_sign = z.sign();
len_side2_SOS = vor_max(len_side2_SOS, z.length());
if(z_sign != ZERO) {
return Sign(Delta_sign * z_sign);
}
}
return NEGATIVE;
}
}
vor_assert_not_reached;
}
return Sign(Delta_sign * r_sign);
} Exact version with expansions

point(p0), point(p1), point(p2), point(p3),
point(q0), point(q1), point(q2) DIM
) {
scalar l1 = 1*sq_dist(p1,p0);
scalar b00 = a11*a22-a12*a21;
scalar b01 = a21-a22;
scalar b10 = a12*a20-a10*a22;
scalar b20 = a10*a21-a11*a20;
scalar Delta = b00+b10+b20;
scalar DeltaLambda0 =
b01*l1+b02*l2+b00 ;
b11*l1+b12*l2+b10 ;
b21*l1+b22*l2+b20 ;
scalar r = Delta*l3 - (
a30 * DeltaLambda0 +
a31 * DeltaLambda1 +
a32 * DeltaLambda2
) ;
generic_predicate_result(
Delta_sign*r_sign
) ;
begin_sos4(p0,p1,p2,p3)
sos(p0, Sign(Delta_sign*sign(
Delta-((b01+b02)*a30+
(b11+b12)*a31+
(b21+b22)*a32)
)))
sos(p1, Sign(Delta_sign*
sign((a30*b01)+
(a31*b11)+
(a32*b21))))
sos(p2, Sign(Delta_sign*sign(
(a30*b02)+
(a31*b12)+
(a32*b22))))
sos(p3, NEGATIVE)
end_sos
}
Source PCK

……….
scalar b00= det3x3(a11,a12,a13,a21,a22,a23,a31,a32,a33);
scalar b01=-det_111_2x3(a21,a22,a23,a31,a32,a33);
scalar b02= det_111_2x3(a11,a12,a13,a31,a32,a33);
scalar b10=-det3x3(a10,a12,a13,a20,a22,a23,a30,a32,a33);
scalar b20= det3x3(a10,a11,a13,a20,a21,a23,a30,a31,a33);
scalar b30=-det3x3(a10,a11,a12,a20,a21,a22,a30,a31,a32);
scalar Delta=b00+b10+b20+b30;
scalar DeltaLambda0 = b01*l1+b02*l2+b03*l3+b00;
……….
scalar r = Delta*l4 - (
a40*DeltaLambda0+
a41*DeltaLambda1+
a42*DeltaLambda2+
a43*DeltaLambda3
);
Sign Delta_sign = sign(Delta);
generic_predicate_result(Delta_sign*sign(r)) ;
begin_sos5(p0,p1,p2,p3,p4)
sos(p0, Sign( Delta_sign*sign(Delta - (
(b01+b02+b03)*a30 +
(b11+b12+b13)*a31 +
(b21+b22+b23)*a32 +
(b31+b32+b33)*a33
)))
)
sos(p1, Sign( Delta_sign*sign(a30*b01+a31*b11+a32*b21+a33*b31)))
sos(p4, NEGATIVE)
end_sos
}
q is the intersection of three bisectors and a tetrahedron embedded in nD
Note: There is a special case in 3d (no need for the tetrahedron) = insphere3d()
The code of the general
nD version (excerpt) :
Source PCK

Part 4. Geometry – Crash test 1/2

Part 4. Geometry – Crash test 2/2

Part 4. Geometry - RVD
If we eliminate the zero components during computations, the length of the
expansions remain reasonable (see observation in Shewchuk’s paper)

Part 4. Clipped Voronoi diagram

Part 4. Clipped Voronoi diagram
Polyhedral elements for
Finite Elements Analysis
>vorpaline/vorpalite profile=poly fusee.meshb

Part 4. Geometry – 3D Anisotropic VD

The PCK (Predicate Construction Kit)
Features:
• Expansion number type – low level API (allocation on stack, efficient)
• High level API with operators (easy to use, less efficient)
• Script to generate FPG filter and exact version with SOS
• Standard predicates (orient2d, 3d, insphere3d, orient4d)
• More exotic predicates for RVD (side1, side2, side3, side 4 in dim 3,4,6,7)
• 3D Delaunay triangulation
• 3D weighted Delaunay triangulation
• Only 6 source files
• multi_precision.(h,cpp)
• predicates.(h,cpp)
• delaunay3d.(h,cpp)
• Fully documented
• No dependency (compiles and runs everywhere*, I got a version on my phone :-)
BSD license (do what you want with it, including business)
*In the IEEE754 world

What s next
5
Physics + Mathematics + Computing = ?

?
T
ρ1 ρ2
Minimize C(T) =
∫Ω
|| x – T(x) ||2 dx
Subject to: T is measure-preserving
ρ1(x)
Optimal Transport

A map T is a transport map between μ and ν if
μ(T-1(B)) = ν(B) for any Borel subset B
B
(X;μ) (Y;ν)
Optimal Transport

A map T is a transport map between μ and ν if
μ(T-1(B)) = ν(B) for any Borel subset B
B
T-1(B)
(X;μ) (Y;ν)
Optimal Transport

Continuous
(X;μ) (Y;ν)
Optimal Transport : probability measures

Continuous
Semi-discrete
Discrete
(X;μ) (Y;ν)
Optimal Transport : probability measures

Optimal Transport – semi-discrete
∫X ψc (x)dμ + ∫Y ψ(y)dν
Sup
ψ Є ψc
(DMK)
∑j ∫Lagψ(yj) || x – yj ||2 - ψ(yj) dμ
∫X inf yj ЄY [ || x – yj ||2 - ψ(yj) ] dμ
∑j ψ(yj) vj

Voronoi diagram: Vor(xi) = { x | d2(x,xi) < d2(x,xj) }
Power Diagrams

Power diagram: Pow(xi) = { x | d2(x,xi) – ψi < d2(x,xj) – ψj }
Voronoi diagram: Vor(xi) = { x | d2(x,xi) < d2(x,xj) }
Power Diagrams

Shape Fitting
TopOpt2FEA
<<<<
<<

Periodic Global Parameterization
Scan2FEA

Subd surface fitted using Optimal Transport
Scan2FEA

Finite Element Analysis (vibration modes)
Scan2FEA

Think Big: Simulating the entire universe

The millenium simulation project, Max Planck Institute fur Astrophysik
pc/h : parsec (= 3.2 années lumières)Large-Scale structure

Optimal Transport
Early Universe Reconstruction
The Data

Optimal Transport
Invert Newton Einstein Eqn to go back 14 milliards years in time
The millenium simulation project,
Max Planck Institute fur Astrophysik
pc/h : parsec (= 3.2 light years)

Optimal Transport
pc/h : parsec (= 3.2 années lumières)
In 2002, 5 hours of computation
with a supercomputer / 5000 points

Optimal Transport
Can we do it with 1 000 000 points ?

Optimal Transport
Yes, if we wait 4500 years

Optimal Transport

Optimal Transport
We need a new algorithm.

Towards Early Universe Reconstruction
Numerical Experiment: Performances
2002: several hours of supercomputer time were needed
for computing OT with a few thousand Dirac masses, with a combinatorial
algorithm in O(n2log(n))

2015:
3D version of [Mérigot] (multilevel + BFGS) + several tricks [L 2015]

2015:
2016: Damped Newton [Mérigot, Thibert] + several tricks for 3D:
1 million Dirac masses in 240 seconds

2015:
10 million Dirac masses in 90 minutes

2015:
10 million Dirac masses in 90 minutes
2017: 10 million Dirac masses in 2 minutes (for specific configurations)
Semi-discrete OT is now scalable ! (new tool in Num. Ana. Toolbox)

Take-home message
Programming is a great source of fun

Take-home message
Futuristic programming principles
(make it fun for your users as well)

Take-home message
Program speed
Low memory consumption
Lines of code
Classes
Templates

Take-home message
Program speed
Lines of code
Classes
Templates
Gains Costs

Take-home message
Program speed
Lines of code
Classes
Templates
Gains Costs
Measure it !
(profiler, continuous integration)

Take-home message: Usefulness is primary
.h, .cpp
.h, .cpp
.h, .cpp
.h, .cpp
.h, .cpp
.h, .cpp
.h, .cpp
Object-oriented design
Generic design

Futuristic design
.cpp
.h
void the_functionality(Data& )

Futuristic design
.cpp
.h
void the_functionality(Data& )
* Make it easy to compile
* Do not bother the user
with internal details (even if
you are proud of them)

.cpp
GLUP.h – C API
glupBegin(), glupEnd(), glupVertex()
GLUP state
variablesVanillaGL
OpenGL ES /
WebGL
GLSL 1.5
GLSL 4.4
matrix stacks
buffers
Shaders
OpenNL.h – C API
nlBegin(), nlEnd(), nlCoeff(), nlSolve()
.c
CG
GMRes
BiCGStab
SuperLU
CHOLDM
OD
CPU/GPU
Abstraction layer
OpenMP
multicore
CUDA
CuBLAS
CuSparse
ARPACK
nlCompress()

.cpp
GLUP.h – C API
GLUP state
variablesVanillaGL
OpenGL ES /
WebGL
GLSL 1.5
GLSL 4.4
matrix stacks
buffers
Shaders
OpenNL.h – C API
.cpp
CG
GMRes
BiCGStab
SuperLU
CHOLDM
OD
CPU/GPU
Abstraction layer
OpenMP
multicore
CUDA
CuBLAS
CuSparse
ARPACK
nlCompress()
Algorithms and Data Structures
Mostly arrays (std::vector) and for() loops
Object oriented / virtual functions
Run-time selection of algorithm
Generic programming
For dimension-independent code (RVD)
If() statements
Predicates

Futuristic programming – the product
GLUP.h – C API
OpenNL.h – C API
Geogram – C++ API
Mesh class, Delaunay, Voronoi,
Remesh, param., repair, reconstruct.
Predicate Construction Kit
Compiler for arbitrary precision
Geometric predicates (C/C++ API)
Graphite: Qt GUI + LUA scripting
Download from gforge.inria.fr, see also links on my webpage

Acknowledgements
Eurographics Association
European Research Council
GOODSHAPE ERC-StG-205693
VORPALINE ERC-PoC-334829
ANR MORPHO (Vision), ANR BECASIM (Physics)
ANR MAGA (P.I.: Q. Merigot),
ANR ROOT (P.I.: N. Bonneel) Optimal Transport stuff.
Inria EXPLORAGRAM
Key contributors to Geogram/Graphite:
N. Ray, W.-C. Li, B. Vallet, D. Sokolov, N. Bonneel, R. Zayer, A. Sheffer
MOKA team (Monge-Ampere-Kantorovich)

The joy of computer graphics programming

The joy of computer graphics programming

Recommandé

Contenu connexe

Tendances

Tendances(20)

Similaire à The joy of computer graphics programming

Similaire à The joy of computer graphics programming(20)

Plus de Bruno Levy

Plus de Bruno Levy(11)

Dernier

Dernier(20)

The joy of computer graphics programming