Remote Interactive Visualization of Complex Virtual Environments using Networks and Machines of Variable Performances
Jean-Eudes Marvie INSA of Rennes
IRISA – SIAMES / INRIA – Région Bretagne
Objective • Real time navigation and visualization • Client-server architecture • Applied to complex virtual worlds Server
Client 1
Client 2
Client 3
Database 1 Database 2 Database 3
Virtual World 1
Virtual World 2
Virtual World 2
Network – Ethernet, WiFi, GPRS, etc.
12/16/2004
IRISA - SIAMES / INRIA - Region Bretagne / INSA
2
Why ? What kind of applications ? • Tourism & geo positioning
• Urbanism & architecture
12/16/2004
IRISA - SIAMES / INRIA - Region Bretagne / INSA
3
Why ? What kind of applications ? • Virtual reality & cooperative worlds Grenoble
Rennes
Server: only one shared copy of the model in Grenoble, Rennes or somewhere else. - Easier to maintain - Implicit synchronization 12/16/2004
IRISA - SIAMES / INRIA - Region Bretagne / INSA
4
What do we need ? • The user must not wait - Short download time at connection - Transparent downloading during visualization (i.e. streaming)
• Visualization must be interactive - We focus on fast rendering - Say 25 frames per second (at least)
12/16/2004
IRISA - SIAMES / INRIA - Region Bretagne / INSA
5
Complex environments • Geometric complexity - Millions of polygons or points - Per vertex normal - Object hierarchies
• Photometric complexity - Large set of texture maps - Per vertex texture coordinates
⇒ Very large data sets 12/16/2004
IRISA - SIAMES / INRIA - Region Bretagne / INSA
6
Hardware constraints • Network - Low and variable bandwidth - High and variable latency
• Client machines - Variable graphics hardware capabilities - Variable CPU capabilities - Variable RAM capacities
⇒ Algorithms must be adaptive 12/16/2004
IRISA - SIAMES / INRIA - Region Bretagne / INSA
7
Some of our solutions • Global optimizations - Complex sceneries streaming [Web3D 2004] • Scene is downloaded by parts at need • Pre-fetching and client’s memory adaptation
• Local optimizations - Progressive texture maps [VIIP 2003] • Progressive transmission of partial mipmap levels • Adaptation to networks and client’ graphics hardware
- Procedural geometry [PG 2003] • Transmission of the construction manual • Geometry is reconstructed on the client side • Manuals are encoded using FL-System [TVC,submitted]. FL-system was developed by Julien Perret (SIAMES). 12/16/2004
IRISA - SIAMES / INRIA - Region Bretagne / INSA
8
Outline I.
Magellan 1. 2. 3.
II.
Framework architecture The generic application Enhancing the generic application
Global optimizations 1. 2.
Visibility streaming Automatic pre-processing
III. Local optimizations 1. 2.
Texture maps streaming Procedural geometry
IV. Conclusion 12/16/2004
IRISA - SIAMES / INRIA - Region Bretagne / INSA
9
Part I : Magellan A development framework for distributed applications
12/16/2004
IRISA - SIAMES / INRIA - Region Bretagne / INSA
10
I.0. Motivation •
Many existing solutions: -
•
But ! -
•
[Chang97], [Schneider99], [Hesina98], [Vrml97], etc. Architectures and solutions are always specific States and algorithms distribution is always static Applications are hard to enhance
Objective -
Provide a tool to develop all these solutions easily •
-
Allow the use of all the solutions • •
12/16/2004
And also any new solutions Within a given virtual environment Each part is optimized using the best solution IRISA - SIAMES / INRIA - Region Bretagne / INSA
11
Outline I.
Magellan 1. 2. 3.
II.
Framework architecture The generic application Enhancing the generic application
Global optimizations 1. 2.
Visibility streaming Automatic pre-processing
III. Local optimizations 1. 2.
Texture maps streaming Procedural geometry
IV. Conclusion 12/16/2004
IRISA - SIAMES / INRIA - Region Bretagne / INSA
12
I.1. Framework architecture 1. System layer -
Provides C++ encapsulation of system calls • •
Sockets, Threads, Time, etc Compatible with Linux, WIN32, SunOS.
2. Application layer -
Provides modular elements •
-
Proposes a generic distributed application •
-
Allows the implementation of many solutions
Proposes an API for new components • •
12/16/2004
To produce any kind of client-server architectures
Used to enhance the generic application A component can be a node or a module IRISA - SIAMES / INRIA - Region Bretagne / INSA
13
I.1. Framework architecture 2. Application layer (continued) -
A node is an object that allows •
The downloading & manipulation of specific data -
-
A module is an object that allows •
-
PM, QSplat, Video, VRML, any …
The application of algorithms on sets of nodes
To sum up • •
A node is a part of the Magellan meta scene-graph A module works on parts of the meta scene-graph We will discuss the meta scene-graph later…
12/16/2004
IRISA - SIAMES / INRIA - Region Bretagne / INSA
14
I.1. Framework architecture 3. Components layer -
All the developer’s components lies in this layer It also provides two generic components: • •
•
A simulation module + an API for nodes A rendering module + an API for nodes
Development facilities (two ways) -
Producing new applications •
-
Enhancing the generic application •
12/16/2004
With specific architectures Using new nodes and modules
IRISA - SIAMES / INRIA - Region Bretagne / INSA
15
Outline I.
Magellan 1. 2. 3.
II.
Framework architecture The generic application Enhancing the generic application
Global optimizations 1. 2.
Visibility streaming Automatic pre-processing
III. Local optimizations 1. 2.
Texture maps streaming Procedural geometry
IV. Conclusion 12/16/2004
IRISA - SIAMES / INRIA - Region Bretagne / INSA
16
I.2. The generic application •
Distributed architecture
12/16/2004
IRISA - SIAMES / INRIA - Region Bretagne / INSA
17
I.2. The generic application •
Meta scene-graph and node creation
12/16/2004
IRISA - SIAMES / INRIA - Region Bretagne / INSA
18
I.2. The generic application •
Meta scene-graph access & manipulation
12/16/2004
IRISA - SIAMES / INRIA - Region Bretagne / INSA
19
I.2. The generic application •
The plug-in system
12/16/2004
IRISA - SIAMES / INRIA - Region Bretagne / INSA
20
I.2. The generic application •
Monitoring -
Provides on-line statistics Pre-defined monitors: • • •
-
Can be used by nodes and modules •
-
And share them with other components
Provides automatic statistics recording •
12/16/2004
To adapt to variable hardware performances
Developer can add it’s own monitors •
-
Network and downloading bandwidth Memory occupation on the client side Rendering frequency
Useful when prototyping new solutions IRISA - SIAMES / INRIA - Region Bretagne / INSA
21
Outline I.
Magellan 1. 2. 3.
II.
Framework architecture The generic application Enhancing the generic application
Global optimizations 1. 2.
Visibility streaming Automatic pre-processing
III. Local optimizations 1. 2.
Texture maps streaming Procedural geometry
IV. Conclusion 12/16/2004
IRISA - SIAMES / INRIA - Region Bretagne / INSA
22
I.3. Enhancing the application •
Distributing states & algorithms -
Objective • •
-
Solution • • •
-
A generic algorithm for network transmissions Marshalling-unmarshalling performed by the nodes Network communications also
Practically, very simple • •
12/16/2004
Distribute the node’ states on server & client Distribute the node’ algorithms on server & client
Only three abstract classes Providing only four virtual methods IRISA - SIAMES / INRIA - Region Bretagne / INSA
23
I.3. Enhancing the application •
Distributing states & algorithms -
12/16/2004
Executed by client managing & loading processes Piloted by the nodes themselves
IRISA - SIAMES / INRIA - Region Bretagne / INSA
24
I.3. Enhancing the application •
Distributing states & algorithms -
12/16/2004
The root node
IRISA - SIAMES / INRIA - Region Bretagne / INSA
25
I.3. Enhancing the application •
Distributing states & algorithms -
12/16/2004
The exclusive extern nodes (see VRML Inline)
IRISA - SIAMES / INRIA - Region Bretagne / INSA
26
I.3. Enhancing the application •
Distributing states & algorithms -
12/16/2004
The shared extern nodes
IRISA - SIAMES / INRIA - Region Bretagne / INSA
27
I.3. Enhancing the application •
Distributing states & algorithms -
12/16/2004
The distributed nodes (progressive)
IRISA - SIAMES / INRIA - Region Bretagne / INSA
28
I.3. Enhancing the application •
Simulation-rendering modular pipeline -
Objective •
-
Easy construction of the simulation-rendering loop
Solution • •
The loop is modeled with a succession of modules Pipeline description (order of execution) -
-
Practically, very simple •
12/16/2004
Hard coded Or described in a configuration file
Only two abstract classes providing two virtual methods
IRISA - SIAMES / INRIA - Region Bretagne / INSA
29
I.3. Enhancing the application •
Simulation-rendering modular pipeline -
12/16/2004
Executed by the main thread Piloted by the GUI
IRISA - SIAMES / INRIA - Region Bretagne / INSA
30
I.3. Enhancing the application •
Simulation-rendering modular pipeline -
General architecture
-
Example of construction
12/16/2004
IRISA - SIAMES / INRIA - Region Bretagne / INSA
31
I.3. Enhancing the application •
Generic rendering -
Objective •
Perform traversal of hybrid scene graphs -
•
Perform hybrid rendering -
-
A generic algorithm for traversal and rendering Traversal and rendering are performed by the nodes
Practically, very simple •
12/16/2004
Each node type can use it’s own rendering technique: Polygon based, point based, image based, etc.
Solution • •
-
Nodes are of different types
Two abstract classes providing two virtual methods IRISA - SIAMES / INRIA - Region Bretagne / INSA
32
I.3. Enhancing the application •
Generic rendering -
12/16/2004
Operates on the client side
IRISA - SIAMES / INRIA - Region Bretagne / INSA
33
I.3. Enhancing the application •
Adaptive rendering -
Objective •
Share polygon, points and GRAM budgets -
• •
To match a target frame rate To optimize GRAM occupation -
-
Optimizing transfers through the AGP bus
Solution • •
GRAM benchmark during client setup On-line frame rate analysis to predict -
•
Points and polygon budgets for next frame construction
Two greedy algorithms -
12/16/2004
Between adaptive nodes (geometry & texture maps)
To share budgets between adaptive nodes
IRISA - SIAMES / INRIA - Region Bretagne / INSA
34
I.3. Enhancing the application •
Adaptive rendering -
Practically 1. Adaptive nodes registers themselves during traversal -
Specifying their contribution to the final image Contribution is expressed as a percentage Allow the use of several kind of metrics Greedy algorithms are thus generic Nodes contributions are normalized during traversal
2. Normalized percentages are then used -
To share the budgets between adaptive nodes
3. Allocated budgets can be used during rendering 12/16/2004
To update texture maps into GRAM To select mesh or point cloud resolutions To activate downloading if refinements are needed IRISA - SIAMES / INRIA - Region Bretagne / INSA
35
I.3. Enhancing the application •
Adaptive rendering -
Possibilities •
Performs automatic budget allocation on -
•
Many kind of selection metrics can be used -
•
12/16/2004
Hybrid scene graph (PM, QSplat, etc.) Developer don’t have to be aware of other node types Distance from viewpoint Surface of projection Perception dependent (focus on bright areas, etc.) Metrics can be merged thanks to normalization step
Developer focuses on its node & Magellan does the rest
IRISA - SIAMES / INRIA - Region Bretagne / INSA
36
I.3. Enhancing the application •
Summary -
•
Distributed meta scene graph Generic protocol to distribute & synchronize nodes Modular simulation-rendering loop Generic & adaptive rendering Enhancement facilities through plug-ins
Important ! -
12/16/2004
Open architecture Easy to enhance
IRISA - SIAMES / INRIA - Region Bretagne / INSA
37
Our utilization of Magellan Part II – Global optimizations Part III – Local optimizations
12/16/2004
IRISA - SIAMES / INRIA - Region Bretagne / INSA
38
Part II - Global optimizations Optimizing the structure of the whole scene to perform streaming and fast rendering
12/16/2004
IRISA - SIAMES / INRIA - Region Bretagne / INSA
39
Outline I.
Magellan 1. 2. 3.
II.
Framework architecture The generic application Enhancing the generic application
Global optimizations 1. 2.
Visibility streaming Automatic pre-processing
III. Local optimizations 1. 2.
Texture maps streaming Procedural geometry
IV. Conclusion 12/16/2004
IRISA - SIAMES / INRIA - Region Bretagne / INSA
40
II.1. Visibility streaming •
Occlusion in sceneries reduces complexity
[Airey90],[Funkhouser96],… • But for a local purpose • And always specific • indoor or outdoor 12/16/2004
IRISA - SIAMES / INRIA - Region Bretagne / INSA
41
II.1. Visibility streaming •
A VRML97 extension for data streaming -
Unifies and extend existing solutions •
-
To perform streaming over networks
1-N cell or object description per VRML file Each cell node contains references to •
Adjacent cells -
•
I.e. a part of the whole adjacency graph
Potentially visible cells and/or objects -
I.e. a part of the whole visibility graph
Partial graphs + separated files allows streaming
12/16/2004
IRISA - SIAMES / INRIA - Region Bretagne / INSA
42
II.1. Visibility streaming •
Introducing new VRML nodes and concepts -
The cell node • •
-
The linked viewpoint •
-
Used to track the current cell
The extended URL •
12/16/2004
Used to describe cell’s convex hull As well as associated partial graphs
Used to refer to cells or objects described in separated files
IRISA - SIAMES / INRIA - Region Bretagne / INSA
43
II.1. Visibility streaming •
The navigation space -
12/16/2004
Can be rooms of an indoor scenery Can be streets of an urban scenery (see below)
IRISA - SIAMES / INRIA - Region Bretagne / INSA
44
II.1. Visibility streaming •
Visibility relationships -
Extension allows three kinds of relationships
Cell-to-objects outdoor 12/16/2004
Cell-to-cells indoor
IRISA - SIAMES / INRIA - Region Bretagne / INSA
Hybrid optimizes both 45
II.1. Visibility streaming •
On-line processing (client side) -
Fetching and pre-fetching • •
Example with cell-to-objects (street-to-buildings) Step 1: fetch the current cell and its OPVS
1 Current cell
1
1 1
12/16/2004
1
IRISA - SIAMES / INRIA - Region Bretagne / INSA
46
II.1. Visibility streaming •
On-line processing (client side) -
Fetching and pre-fetching •
Step 2: pre-fetch the adjacent cells and their OPVS
1 Current cell
1 2
1
Adjacent 1
12/16/2004
1
IRISA - SIAMES / INRIA - Region Bretagne / INSA
47
II.1. Visibility streaming •
On-line processing (client side) -
Fetching and pre-fetching •
Step 3: pre-fetch the cells adjacent to the ray-cast cell and their OPVS
3
1 Current cell
1 2
1
Adjacent 1
12/16/2004
Adjacent 2 1
IRISA - SIAMES / INRIA - Region Bretagne / INSA
48
II.1. Visibility streaming •
On-line processing (client side) -
Adaptive memory management •
Uses partial adjacency graph to perform topological replacements 2- Not enough memory
1- Current cell changes
Current cell
12/16/2004
IRISA - SIAMES / INRIA - Region Bretagne / INSA
49
II.1. Visibility streaming •
On-line processing (client side) -
Adaptive memory management •
Uses partial adjacency graph to perform topological replacements 3- Ok, enough memory
Current cell
12/16/2004
IRISA - SIAMES / INRIA - Region Bretagne / INSA
50
II.1. Visibility streaming •
Video -
Performed at 2Mbits/s (Medium ADSL speed) Kerlan Polygons 375 962 TGA maps 11.2MB Buffering 17s Pre-fetching enabled Kerlan Idem Pre-fetching disabled
12/16/2004
Greek temple Polygons 45 683 TGA maps 40MB Buffering 30s Pre-fetching enabled Basilica Aemilia Polygons 750 000 TGA maps 27.3MB Buffering 25s Pre-fetching enabled
IRISA - SIAMES / INRIA - Region Bretagne / INSA
51
Outline I.
Magellan 1. 2. 3.
II.
Framework architecture The generic application Enhancing the generic application
Global optimizations 1. 2.
Visibility streaming Automatic pre-processing
III. Local optimizations 1. 2.
Texture maps streaming Procedural geometry
IV. Conclusion 12/16/2004
IRISA - SIAMES / INRIA - Region Bretagne / INSA
52
II.2. Automatic pre-processing •
Problem - Sceneries are complex ⇒ cannot build the database structure by hand
•
We propose automatic solutions to produce -
12/16/2004
the navigation space the visibility relationships an average importance metric
IRISA - SIAMES / INRIA - Region Bretagne / INSA
53
II.2. Automatic pre-processing •
Navigation space construction -
Either generated with the model (easy) Or extracted from an existing model • • •
12/16/2004
2D solutions [Teller92],[Meneveaux97],[Lamarche04],… 3D solution [Haumont03] limited to small models We propose a robust constrained 3D BSP
IRISA - SIAMES / INRIA - Region Bretagne / INSA
54
II.2. Automatic pre-processing •
Navigation space construction -
Opacity planes extraction possibilities
center
front
back
merged
12/16/2004
IRISA - SIAMES / INRIA - Region Bretagne / INSA
55
II.2. Automatic pre-processing •
Computing visibility relationships -
Widely addressed problem • •
-
We propose a simple OpenGL shooting •
12/16/2004
[Teller92], [Durand00], [Wonka00], [Schaufler00],… But solution are either complex or specific Not conservative but fast and general
IRISA - SIAMES / INRIA - Region Bretagne / INSA
56
II.2. Automatic pre-processing •
Computing visibility relationships -
Shot frames example •
12/16/2004
each color is a memory pointer to a node (cell or object)
IRISA - SIAMES / INRIA - Region Bretagne / INSA
57
II.2. Automatic pre-processing •
Computing average coverage hints (ACH) -
Pre-computes an average visual importance •
-
for each potentially visible cell or object of each cell
Performed during visibility shooting (low cost) ACH are used on-line for adaptive rendering
For all the frames shot for a cell: 1. 2. 3. 4.
12/16/2004
Pixel count for each color (node) Normalize value using total pixel number Get a percentage of coverage for each node Store the result into the database
IRISA - SIAMES / INRIA - Region Bretagne / INSA
58
II.2. Automatic pre-processing •
Utilizing average coverage hints • •
ACH of visible nodes are renormalized Result is used for adaptive rendering (Magellan) Current cell
0.5
0.66
PVCell
0.25
0.33
PVCell
0.25 12/16/2004
0.0 IRISA - SIAMES / INRIA - Region Bretagne / INSA
59
II.2. Automatic pre-processing •
Utilizing average coverage hints •
12/16/2004
Example of renormalized ACH
IRISA - SIAMES / INRIA - Region Bretagne / INSA
60
Part III - Local optimizations Optimizing the structure of each object or texture map
12/16/2004
IRISA - SIAMES / INRIA - Region Bretagne / INSA
61
Outline I.
Magellan 1. 2. 3.
II.
Framework architecture The generic application Enhancing the generic application
Global optimizations 1. 2.
Visibility streaming Automatic pre-processing
III. Local optimizations 1. 2.
Texture maps streaming Procedural geometry
IV. Conclusion 12/16/2004
IRISA - SIAMES / INRIA - Region Bretagne / INSA
62
III.1. Texture maps streaming • Motivation - Texture maps volume can be huge. • May saturate the network • May saturate graphics hardware memory and AGP
• Solution - Use progressive texture maps • Texture maps are particular images • We introduced a lossless progressive format (PTM)
- Refine texture maps according to • Visual importance • Available GRAM and network bandwidth
- Uses Magellan adaptive rendering + ACH 12/16/2004
IRISA - SIAMES / INRIA - Region Bretagne / INSA
63
III.1. Texture maps streaming • Progressive Texture Maps (PTM) - Mipmap levels are transmitted one by one • On demand, starting from lowest resolution
- Only ¾ of each level is transmitted - The other ¼ is computed on client side
N0 +
• Using partial level (3/4) plus previous level
N1’
- Uses integer arithmetic • Low CPU cost for reconstruction • But ! Require error transmission - Increase original size of only 6% - Instead of 30% using JPEG
- Each level can be compressed • With lossless method (RLE,LZW,ZLIB) 12/16/2004
IRISA - SIAMES / INRIA - Region Bretagne / INSA
+ Error = N1 64
III.1. Texture maps streaming • Adaptive algorithm -
M = GRAM budget allocated to the texture (by Magellan) L = highest mipmap level into graphics hardware Lh = highest mipmap level already downloaded Lmax = highest mipmap level available S(L) = memory size of mipmap pyramid for level L Not downloading S(L+1) ≤ M L+1 ≠ Lmax L+1 > Lh
no S(L+1) ≤ M L+1 ≤ Lmax L+1 > Lh
yes
12/16/2004
no
S(L) > M yes
Add L+1 to hardware
Remove L from hardware
yes Download L+1 from server if download time is ≤ allowed time
IRISA - SIAMES / INRIA - Region Bretagne / INSA
65
III.1. Texture maps streaming • Video - Cell-to-cell relationships • Museum scenery (17 000 polygons) • 90MB of progressive texture maps
- Navigation space • Extracted using constrained BSP
- Bandwidth • Test performed at several bandwidths • 128Kbits/s 500Kbits/s • 1Mbits/s LAN
12/16/2004
IRISA - SIAMES / INRIA - Region Bretagne / INSA
66
Outline I.
Magellan 1. 2. 3.
II.
Framework architecture The generic application Enhancing the generic application
Global optimizations 1. 2.
Visibility streaming Automatic pre-processing
III. Local optimizations 1. 2.
Texture maps streaming Procedural geometry
IV. Conclusion 12/16/2004
IRISA - SIAMES / INRIA - Region Bretagne / INSA
67
III.2. Procedural geometry • Motivation - We focus on city models - Potentially visible geometry can be huge - Progressive geometry is not well suited
• Solution - We extend L-system to model buildings - Many buildings follow the same style • We produce an FL-system grammar for each style • FL-system are functional L-systems developed by Julien Perret
- FL-system grammars are amplifiers • A small grammar can produce a very large model
- Each building is reconstructed on the client side • Using one procedural model (one style) • Using a set of input parameters (footprints, nb of floors)
12/16/2004
IRISA - SIAMES / INRIA - Region Bretagne / INSA
68
III.2. Procedural geometry • Network approach & styles redundancy - Using one grammar Server
Client
Grammar
Parameter 0
Rewriting
T C P
Model 1
Parameter 1 Parameter 2
Parameter n
12/16/2004
Model 0
I P
Model 2
Model n
IRISA - SIAMES / INRIA - Region Bretagne / INSA
69
III.2. Procedural geometry • Levels of detail generation Transmitted 1 time Script : 25KB
Rewriting
One parameter file per building #VRML V2.0 utf8 # Extern PROTO invocation i.e. building model EXTERNPROTO Build01 [ field MFVec3f footprint field SFInt32 floors field MFInt32 adjacentHeights ] "Library/build01.wrl " # model instanciation Build01{ footprint [12.2065,0,246.818, 32.1485,0,248.112, 37.0815,0,228.059, 9.39851,0,229.303 ] floors 4 adjacentHeights [ 0, 0, 3, 3 ] }
12/16/2004
IRISA - SIAMES / INRIA - Region Bretagne / INSA
70
III.2. Procedural geometry • Adaptive rendering - New AutoLOD VMRL node - Uses polygon and vertex budgets • To choose the nearest compatible level
- Budgets are provided by Magellan • Computed by the adaptive rendering algorithm
- Shared using visual importance of buildings • Relies on ACH provided by the visibility extension
12/16/2004
IRISA - SIAMES / INRIA - Region Bretagne / INSA
71
III.2. Procedural geometry • Video - Cell-to-objects relationships • City scenery using procedural geometry - 1 million polygons - encoded using 512KB instead of 1GB
- Navigation space • Generated as well as the street network
- Bandwidth • Test performed at 56Kbits/s
12/16/2004
IRISA - SIAMES / INRIA - Region Bretagne / INSA
72
Part IV - Conclusion Hybrid - Progressive - Adaptive Magellan
12/16/2004
IRISA - SIAMES / INRIA - Region Bretagne / INSA
73
Conclusion • Hybrid - Each problem requires specific optimal data structures and algorithms.
• Progressive - Of prime necessity to optimize downloading and rendering. Allows the use of adaptive algorithms.
• Adaptive - Large scale content distribution requires adaptation to the different hardware bottlenecks.
• Magellan - Allows fast development and integration of all these kinds of solution. 12/16/2004
IRISA - SIAMES / INRIA - Region Bretagne / INSA
74
Future work & open issues • Integrate new local and global optimizations - In order to further validate our approach - And also to extend the framework
• Add event routing to VRML - In order to work on dynamic scenes - And also to be a possible scene graph for OpenMask
• Port the framework on PocketPCs - Still validate our adaptive solutions on low CPU - Explore possibilities of adaptation to energy consumption 12/16/2004
IRISA - SIAMES / INRIA - Region Bretagne / INSA
75
Questions ? • Find materials at: http://www.irisa.fr/siames/Jean-Eudes.Marvie
12/16/2004
IRISA - SIAMES / INRIA - Region Bretagne / INSA
76
Thanks • Members of the jury • INRIA, Region Bretagne and IRISA • Members of the SIAMES team - And all the IRISA staff
• Participants of the V2NET project • MRSH of Caen for the roman 3D models • Family and friends for their support Have a drink in Sein 12/16/2004
IRISA - SIAMES / INRIA - Region Bretagne / INSA
77
