Page 1

Versatile Design of Changing Mesh Topologies

for Surgery Simulation

Barbara Andr´ e and Herv´ e Delingette

INRIA Sophia Antipolis, Asclepios Research Project,

2004 route des Lucioles BP 93, 06902 Sophia Antipolis Cedex, France

{barbara.andre,herve.delingette}@sophia.inria.fr

http://www-sop.inria.fr/asclepios

Abstract. In the context of surgery simulation, this paper presents a

generic and efficient solution to handle topological changes on deformable

meshes under real-time constraints implemented in the SOFA [4] plat-

form. The proposed design is based on a simulation tree gathering soft-

ware components acting on a mesh. The mesh topology is described by

a topological component which also provides algorithms for performing

topological changes (cutting, refinement). An important aspect of the

design is that mesh related data is not centralized in the mesh data

structure but stored in each dedicated component. Furthermore, topo-

logical changes are handled in a transparent way for the user through

a mechanism of propagation of topological events from the topological

components toward other components. Finally, the previous concepts

have been extended to provide multiple topologies for the same degrees

of freedom. Examples of cataract surgery simulation based on this ver-

satile design are shown.

Key words: Mesh Topology, Topological Change,

Real-Time Simulation, User-defined Data Structure

1Introduction

While mesh geometry describes where mesh vertices are located in space, mesh

topology tells how vertices are connected to each other by edges, triangles or any

type of mesh element. Both information are required on a computational mesh

to perform mesh visualization, mechanical modeling, collision detection, haptic

rendering, scalar or vectorial field description.

Since topological changes are essential for surgery simulators, a common dif-

ficulty when designing those simulators is to ensure that the visual, mechanical,

haptic and collision behavior of all meshes stay valid and consistent upon any

topological change.

This paper proposes a framework to handle topological changes in a modular

and versatile way. Our approach is modular since each software component (colli-

sion detection, mechanical solver...) may be written with little knowledge about

the nature of other components. It is versatile because any type of topological

changes can be handled with the proposed design.

Page 2

2Versatile Design of Changing Mesh Topologies for Surgery Simulation

The proposed framework has been implemented in SOFA [4], which is an

Open source C++ platform for the real-time modeling of deformable structures,

particularly for medical simulation and planning. While there exists several other

simulation platforms, to the best of our knowledge most of them do not ex-

plicitely handle topological changes [3,2] or do so for only a limited type of

meshes or mechanical behaviors [5].

Our objective to keep a modular design implies that mesh related information

(such as mechanical or visual properties) is not centralized in the mesh data

structure (as done using the CGAL [1] library) but is stored in the software

components that are using this information. Furthermore, we manage an efficient

and direct storage of information into arrays despite the renumbering of elements

that occur during topological changes.

The SOFA framework is based on the integration of multiple simulation

components that are associated to one or several objects. These components

include Solvers, Degrees of Freedom (containing vertex positions), Mechanical

Force Fields, Mappings, Mass or Constraints. They are considered as the leaves

of a simulation tree, which describes the scene and whose internal nodes separate

hierarchical levels of modeling the scene objects (e.g. Behavior Model, Collision

Model, Visual Model). Fig. 1 shows one example of a simulation tree associated

to a SOFA scene with a cylinder mesh. Note that some components may interact

together and need to be synchronized. Information flow is carried on by visitors

that traverse the simulation tree to propagate spatial positions top down and

forces bottom up.

Fig.1. Simulation Tree associated to a SOFA scene with a cylinder mesh: the cylinder

is both modeled as a tetrahedral volume (2ndlevel) and as a triangular surface (3rd

level). The lower model corresponds to the visible part of the mesh. The Mechanical

Object component contains the mesh Degrees of Freedom. The dotted arrows indicates

dependencies for two types of Mapping components, the Topological Mapping will be

presented in Section 5.

Page 3

Versatile Design of Changing Mesh Topologies for Surgery Simulation3

2 Family of Topologies

We focus the topology description on meshes that are cellular complexes made of

k-simplices (triangulations, tetrahedralisation) or k-cubes (quad or hexahedron

meshes). These meshes are the most commonly used in real-time surgery sim-

ulation and can be hierarchically decomposed into k-cells, edges being 1-cells,

triangles and quads being 2-cells, tetrahedron and hexahedron being 3-cells. To

take advantage of this feature, the different mesh topologies are structured as

a family tree (see Fig. 2) where children topologies are made of their parent

topology. This hierarchy makes the design of simulation components very versa-

tile since a component working on a given mesh topology type will also work on

derived types. For instance a spring-mass mechanical component only requires

the knowledge of a list of edges (an Edge Set Topology as described in Fig. 2)

to be effective. With the proposed design, this component can be used with no

changes on triangulation or hexahedral meshes.

The proposed hierarchy makes also a distinction between conformal and man-

ifold meshes. While most common FEM components require a mesh to be confor-

mal (but not necessarily manifold), many high-level software components (such

as cutting, contact, haptic feedback algorithms) require the mesh to be a mani-

fold where a surface normal is well-defined at each vertex.

Fig.2. Family tree of topology objects. Dashed arrows indicate possible Topological

Mappings from a topology object to another (see Section 5).

Topology objects are composed of four functional members: Container, Mod-

ifier, Algorithms and Geometry. The Container member creates and updates

Page 4

4Versatile Design of Changing Mesh Topologies for Surgery Simulation

when needed two complementary arrays (see Fig. 3). The former describes the

l-cells included in a single k-cell, l < k, while the latter gives the k-cells ad-

jacent to a single l-cell. The Modifier member provides low-level methods that

implement elementary topological changes such as the removal or addition of an

element. The Algorithms member provides high-level topological modification

methods (cutting, refinement) which decompose complex tasks into low-level

ones (see Section 4). The Geometry member provides geometrical information

about the mesh (e.g. length, normal, curvature, ...) and requires the knowledge

of the vertex positions stored in the Degrees of Freedom component.

Fig.3. The two topological arrays stored in a Container correspond to the upper and

lower triangular entries of this table. The upper entries provide the k-cells adjacent to

a l-cell, l < k. The lower entries describe the l-cells included in a k-cell. Similar table

exists for quad and hexahedron elements.

3Component-Related Data Structure

A key feature of our design is that containers storing mesh information (material

stiffness, list of fixed vertices, nodal masses, ...) are stored in components and

spread out in the simulation tree. This modular approach is in sharp contrast

with a centralized storage of information in the mesh data structure through the

use of generic pointers or template classes.

Another choice is that most containers are simple arrays with contiguous

memory storage and a short direct access time. This is important for real-time

Page 5

Versatile Design of Changing Mesh Topologies for Surgery Simulation5

simulation, but bears some drawbacks when elements of these arrays are being

removed since it entails the renumbering of elements. For instance, when a single

element is removed, the last array element is renumbered such that the array

stays contiguous. Fortunately, all renumbering tasks that maintain consistent

arrays can be automated and hidden to the user when topological changes in the

mesh arise (see Section 4). Therefore, in our framework, mesh data structures are

stored in simple and efficient containers, the complexity of keeping the container

consistent with topological changes being automated.

There are as many containers as topological elements: vertices, edges, trian-

gles, ... . These containers are similar to the STL std::vector classes and allow

one to store any component-related data structure. A typical implementation

of spring-mass models would use an edge container that stores for each edge,

the spring stiffness and damping value, the ithelement of that container being

implicitly associated with the ithedge of the topology. Finally, two other types

of containers with similar characteristics have been defined. The former stores

a data structure for a subset of topological elements (for instance pressure on

surface triangles in a tetrahedralisation) while the latter stores only a subset of

element indices.

4Handling Topological Changes

Surgery simulation involves complex topological changes on meshes, for example

when cutting a surface along a line segment, or when locally refining a volume

before removing some tissue. However, one can always decompose these complex

changes into a sequence of elementary operations, such as adding an element,

removing an element, renumbering a list of elements or modifying a vertex po-

sition.

Our approach to handle topological changes makes the update of data struc-

tures transparent to the user, through a mechanism of propagation of topological

events. A topological event corresponds to the intent to add or to remove a list

of topological elements. But the removal of elements cannot be tackled in the

same way as the addition of elements. Indeed, the element removal event must

be first notified to the other components before the element is actually removed

by the Modifier. Conversely, element addition is first processed by the Modi-

fier and then element addition event is notified to other components. Besides,

the events notifying the creation of elements also include a list of ancestor ele-

ments. Therefore, when splitting one triangle into two sub-triangles (see Fig. 5),

each component-related information (e.g. its Young modulus or its mass density)

associated with a sub-triangle will be created knowing that the sub-triangle orig-

inates from a specific triangle. Such mechanism is important to deal with meshes

with non-homogeneous characteristics related to the presence of pathologies.

The mechanism to handle topological changes is illustrated by Fig. 4. The

notification step consists in accumulating the sequence of topological events in-

volved in a high-level topological change into a buffer stored in the Container.

Then the event list is propagated to all its neighbors and leaves beneath by us-