PhD Eric Hajjar
email: eric.hajjar@dsf.unica.it

Amit Kumar

Paolo Ruggerone

Matteo Ceccarelli

Investigating reaction pathways in rare

Keywords: Reaction coordinate, free energy, accelerated molecular dynamics, antibiotics uptake, diffusion, bacterial porins, antibacterial design, ampicillin, moxifloxacine Reaction coordinate  Free energy  Accelerated molecular dynamics  Antibiotics uptake  Diffusion  Bacterial porins  Antibacterial design

come

Introduction

The permeability to antibioticsor uptake -is the very first line of defense of Gram-negative bacteria, that are protected by an outer-membrane [START_REF] Nikaido | Molecular basis of bacterial outer membrane permeability revisited[END_REF]. In the case of E.coli, the uptake of several classes of β-lactam antibiotics, a prominent group in our current antibacterial arsenal, is largely controlled by general diffusion protein channels such as Outer Membrane Protein F (OmpF) [START_REF] Nikaido | Molecular basis of bacterial outer membrane permeability revisited[END_REF]. Indeed, pathogenic strains of Gram-negative bacteria, that were found to be resistant against quinolones and β-lactams (two of the main classes of antibiotics) frequently have modulation of the structure or the expression of general diffusion porin OmpF [START_REF] Chevalier | Comparative aspects of the diffusion of norfloxacin, cefepime and spermine through the F porin channel of Enterobacter cloacae[END_REF].

A key feature in the structure of porins, as seen from the X-ray structure of OmpF [START_REF] Cowan | Crystal structures explain functional properties of two E. coli porins[END_REF], is the presence of the loop L3 that folds back into the channel to form a gate, also called constriction region (see Fig. 1A). In addition to such spatial constriction, the zone is also characterized by a strong transversal electric field, generated by negatively charged residues D113, E117 (L3 side) that faces a cluster of positively charged residues R42, R82, and R132 (anti-L3 side) (see Fig. 1).

While antibacterial research and development is on the decline, the resistance is on the rise, and we are thus facing an alarming situation where there is an emergency call for a new way to develop potent antibacterial agents and to bring them to the market faster and at reduced cost. An emerging strategy is to follow a bottom-up approach, from the knowledge of resistant mechanisms to a rational structure-based design and screening of antibiotics. Within this scheme, molecular simulations have the potential to provide an accurate microscopic explanation of what governs antibiotics diffusion (and thus bacterial resistance) and how to screen for better antibiotics. In principle, standard MD simulations would have the required microscopic accuracy to link the structure and dynamics (of the drug and porin) to the rate of permeation. However, standard simulations are limited to hundred of nanoseconds at most and they do not allow the study of the reactive pathway that antibiotics follow during passive diffusion, which is on the order of hundreds of microseconds [START_REF] Nestorovich | Designed to penetrate: time-resolved interaction of single antibiotic molecules with bacterial pores[END_REF].

To overcome this timescale problem, we propose to use accelerated MD simulation algorithms schemes, or metadynamics, while keeping an "all atom" description of the systems [START_REF] Ceccarelli | Microscopic mechanism of antibiotics translocation through a porin[END_REF][START_REF] Laio | Escaping free-energy minima[END_REF]. The metadynamics algorithm (to accelerate sampling) is based on the following principle: a time-dependent bias is added on a few chosen reaction coordinates (RC). It is important to note that a crucial point of such metadynamic approach is the choice of appropriate RC.

Unlike other popular techniques (such as steered molecular dynamics [START_REF] Robertson | Orientation and interactions of dipolar molecules during transport through OmpF porin[END_REF]), metadynamics allows more than one RC to be defined and this is important advantage as specifying a single reaction coordinate, can lead to a strong approximation of the sampled process.

Several studies addressed the challenge of such biased molecular dynamics methods to study the difficult problem of molecular diffusion through narrow channels. In their recent paper, Henin et al. [START_REF] Henin | Diffusion of glycerol through Escherichia coli aquaglyceroporin GlpF[END_REF], highlight the importance of using another reaction coordinates than the usually taken, Z (distance) coordinate that drives the process under study. Indeed it is believed that including an extra reaction coordinate would allow explicitly to account for reorientations and/or relaxation needed for reaching better accuracy in the sampling of the process studied.

In fact, our and others previous studies suggested that the flexibility and orientation of the antibiotic would play a role in its diffusion process through OmpF [START_REF] Ceccarelli | Microscopic mechanism of antibiotics translocation through a porin[END_REF][START_REF] Vidal | Beta-lactam screening by specific residues of the OmpF eyelet[END_REF]. However, the qualitative and quantitative consequences of the choice of RC are still poorly understood and there are very few studies illustrating this point. The first natural reaction coordinate that could be used in our metadynamics approach is the position of the antibiotic with respect to the axe of diffusion Z.

Here we go further and include more informative reaction coordinates, accounting not only for the directionality of the transport but also explicitly for: (i) the antibiotic orientation and (ii) specific interactions with the channel. Our approach will allow discussing the two choices of RC in the translocation with the study of two different antibiotics: the beta-lactam ampicillin and the quinolone moxifloxacine, for which experimental data and simulations are already available [START_REF] Mach | Facilitated permeation of antibiotics across membrane channels-interaction of the quinolone moxifloxacin with the OmpF channel[END_REF][START_REF] Danelon | Interaction of zwitterionic penicillins with the OmpF channel facilitates their translocation[END_REF].

Finally, we conclude by discussing the improved strategies, as highlighted by our study. Indeed, the in-depth analysis of these two model systems allows us to discuss for future improvements in the biased methods (importance of explicitly including the relative orientation and the specific interactions) to screen and design for antibiotics in particular, but also for investigating any other complex process of interest.

Materials and methods

Starting structures for molecular dynamic simulations

We followed the same protocol of simulations as described earlier [START_REF] Ceccarelli | Microscopic mechanism of antibiotics translocation through a porin[END_REF], starting from the crystal structure '2OMF' (pdb-code) and residues protonation state as in [START_REF] Im | Ions and counterions in a biological channel: a molecular dynamics simulation of OmpF porin from Escherichia coli in an explicit membrane with 1 M KCl aqueous salt solution[END_REF]. We added the required amount of Cl-and K+ counter ions to neutralize the protein charges. We embedded the system in a hydrophobic environment of detergent molecules (lauryl dimethyl amine oxide, LDAO) and solvated the system with ~8000 water molecules in an hexagonal box.

"Hexagonal periodic boundary conditions were used and the simulation box edges are 68.4Å, 68.4Å, 78.1Å. Electrostatic interactions at long distance were evaluated using the soft particle mesh Ewald scheme while a cutoff of 10 Å was used for the Lennard-Jones and short electrostatic energy terms. Multiple Time Step Algorithm (MTS Respa) was used with the SHAKE algorithm to keep bond lengths involving hydrogens fixed. The simulations were done at 300 K with Nose thermostat to control temperature. We used the Amber potential and TIP3P for water [13]. The parameters of antibiotics were developed following the Amber protocol [START_REF] Wang | Development and testing of a general amber force field[END_REF]: (i) the three dimensional chemical structure of the antibiotic was drawn, using the software package HyperChem; (ii) geometry optimization was performed using the Hartree-Fock (HF) basis set HF-6-31G* with the Gaussian03 package [START_REF] Frisch | Gaussian 03, Revision C02[END_REF]; (iii) the molecular electrostatic potential was generated at HF/6-31G* level; (iv) the atomic charges were fitted to molecular electrostatic potential with aid of a module RESP in Amber8 program package, adding the restraint for equivalent atoms [START_REF] Wang | Development and testing of a general amber force field[END_REF]. The structure obtained after full optimization is considered the starting geometry of the molecule onto which we assign all the force-field parameters. The atom types and parameters were derived using either the program antechamber (Amber-module), when possible, or were assigned manually on the basis of our optimized geometry. We used the program ORAC and the Amber force field [13] for system setup and simulation [16]. All simulated systems were validated for convergence and stabilization of energy, temperature and root mean square deviation with respect to the starting structure.

Metadynamics algorithm

The metadynamics algorithm employs a bias to accelerate the evolution of some collective variables, defined as the relevant reaction coordinates for the process under investigation. The bias consists of a history dependent potential, which is constructed as a sum of repulsive potential centered along the trajectory of the collective variables. These additional energy terms avoid revisiting the same conformations or at least add a penalty term to the previously visited conformations. In the present simulations, a Gaussian potential is added every 4ps with a height is of 1.0 kJ mol -1 . The Gaussian width is set to 0.2 Å, 5.0 degrees and 0.5, respectively for the distance Z, the angle  and the number of hydrogen bonds. These parameters were chosen to allow a better resolution in the sampling of the free energy and a low error (around 2k B T).

The most important point in the metadynamics is to select the proper reaction coordinates.

These must be variables that are of interest but difficult to sample with a standard scheme, since the local minima in the space spanned by these variables are separated by barriers that cannot be overcome in the simulation time available. We also wanted to compare the effect of choosing different collective variables in this case, and thus we chose the three different collective variables:

(i) Distance (Z) , defined as: Z=Z GEO (ant)-Z GEO (solute), where Z GEO is calculated as the average of Z coordinates of all the heavy atoms of the system, respectively antibiotics and (porin+detergent) (ii) Angle (), defined as:

  . Z ant Cos e v  
, with e Z being the eigenvector of inertia tensor (calculated on the porin C) that is closest to the axe of diffusion of the porin, ant v being the vector of the long axis of the antibiotic, the closest to the highest component of the dipole moment.

(iii) Number of hydrogen bonds, defined as a continuous function from the list of all defined donors and acceptors of the system:

6 0 12 1 0 1 ( / ) 1 ( / ) nHB i HB i i r r N r r      ,
where nHB is the total number of possible hydrogen bonds calculated at time t; r 0 is the reference distance between the two heavy atoms of the bonds taken as 2.5Å.

The metadynamics algorithm enables the reconstruction of the free energy in the subspace of the collective variables by integrating the history dependent terms [START_REF] Laio | Escaping free-energy minima[END_REF]. Due to the complexity of the process studied, we calculated the free energy after obtaining the first translocation path, which is considered to be the most probable path because it passes through the lowest saddle point, as done before for the unthreading of a molecule [START_REF] Laio | Assessing the accuracy of metadynamics[END_REF]. In fact, once the antibiotic crosses the constriction region, we expected a diffusive regime, with no significant affinity sites. The error bars associated with the energy calculations were assessed as previously done [START_REF] Laio | Assessing the accuracy of metadynamics[END_REF] and are of 1kcal mol -1 at most.

Microscopic analysis methodology

To decipher the molecular details of the translocation mechanism additional equilibrium MD simulations (1 ns length) were started from each visited minima along the diffusion path. In depth analysis using VMD and in-house scripts, was performed to characterize the following key structural features:

(i) The atomic root mean square fluctuations (rmsf) were calculated for each heavy atoms of the backbone of the antibiotic with respect to its average position during the MD simulations;

(ii) Existence of hydrogen bonds (Hb) and hydrophobic contacts (Hc) between atoms of the antibiotics and of OmpF. Hbs are counted using VMD scripts according to the following threshold parameters: a distance of at most 3Å and donor-hydrogen-acceptor angle of at least 130 degrees. Hcs are counted when non-polar atoms are separated by at most 3 Å.

Further, we report the molecular properties in terms of the amount of hydrophilic/hydrophobic surface, as calculated from the PLATINIUM server [START_REF] Pyrkov | PLATINUM: a web tool for analysis of hydrophobic/hydrophilic organization of biomolecular complexes[END_REF] .

Results and discussion

Metadynamics simulations allow studying the translocation process

Both ampicillin and moxifloxacine have a permanent dipole, being its larger component along their long axe (Fig. 1 B-C). As during permeation, antibiotics have to penetrate the constriction region that is rich of charged amino acids, it is important to accurately define the way of entry and the interactions with the channel. To do so, we included explicitly these degrees of freedom as reaction coordinate along the metadynamics runs.

The Fig. 2 displays the free energy surfaces (FES) of the translocation of the ampicillin betalactam antibiotic (Amp) through the OmpF channel for two different choices of the reaction coordinates: (A) with the combination of the distance Z and the number of hydrogen bonds Hb; and (B) with the combination of the distance Z and the angle . Interestingly, the free energy barrier required for ampicillin to translocates is of the same order in the two simulations: 11 kcal mol -1 and 9 kcal mol -1 for the simulation A and B respectively (the values correspond to the energy barrier needed to translocates starting from the deepest minima above). In both cases, deep energy minima are visited, which can be related to well defined affinity sites of ampicillin inside the channel. In particular, we observe the location of a deep energy minimum exactly at the constriction region (Mini-CR at Z~0, see Fig. 2). To address the similarity (reproducibility) of the process sampled with different RC, we further calculated the missing RC of each simulation and plot it in the corresponding FES. Thus, the Hb coordination number, as calculated in the course of the simulation B, were superimposed as blue points in Fig. 2A; similarly, the  angle, as calculated in the course of the simulation A, were superimposed as blue points in Fig. 2B. Interestingly, the number of hydrogen bonds needed (about 10 Hbs) to cross the constriction region and translocate is similar in both simulations that were "constrained" (A) or "free" (B) of this RC. Similarly, both simulations sample the same populations of states of the angle  (the value of  when ampicillin crosses the constriction region and translocates is around 150 degrees in both simulations A and B) defining the deep minima at the constriction region. The fact that both the angle and the hydrogen bond coordinate are reproducing a very similar path, with a deep energy minimum located centrally at the CR, comforts us in the choice of these RC. For the study of ampicillin's translocation, both RC are appropriate.

Equilibrium MD simulations allow studying the structural and dynamics properties

In order to characterize the structural and dynamics properties that govern the antibiotics diffusion process we then performed equilibrium MD simulations (of 1ns length) starting from the relevant, preferential minima identified by the FES. We focus only on the minima where the antibiotics are bound at the constriction region of the channel (Mini-CR) as if such interaction was the rate-limiting step of the process. In the case of ampicillin, we find that very similar structures are sampled along the two Mini-CR from both simulations with the Hb and  RC, we will further only describe the Mini-CR of the simulation B (with the  RC). As seen from the snapshot in Fig. 4A, to enter the affinity site at the constriction region (Mini-CR) and further translocates, ampicillin is oriented with its polar carboxyl group pointing down and makes favorable interactions with the residues of the porin constriction zone. We present in Fig. 4B the lifetime of the hydrogen bonds and hydrophobic contact (Hc) interactions between ampicillin and OmpF atoms sampled along Mini-CR (as explained in the Method section). We observe that ampicillin is able to make a large number of durable polar Hbs, in particular both the one between its N-terminal positive group (N1) and D113 and the one between its C-terminal carboxylic group (O2) and R132 exceed 70% of the equilibrium simulation time. Instead, only one significant Hc (~20% of the simulation time) is made between the CT2 carbon of ampicillin and M114 (Fig. 4B).

A similar detailed structural analysis was performed when moxifloxacine is bound in Mini-CR, in the simulation B (with the  RC), and we find that in this case, the antibiotic is oriented with its polar carboxyl group pointing up (Fig. 5A). Instead, it is with its hydrophobic group that moxifloxacine is seen to penetrate the constriction region (Fig. 5A).

The interaction network analysis indeed reveals a predominance of Hcontacts between the antibiotic and the many hydrophobic residues on the porin side such as F118, L20, M114, P116 (Fig. 5B). The only significant Hb identified involves Y124, E117 and to a lesser extend R82.

Differences in the structural, dynamical or physico-chemical properties of the two antibiotics could explain the differences observed in our study -that is, the translocation of ampicillin is described equivalently by both the Hb and the  RC while the translocation process of moxifloxacine differs if choosing the Hb or the  RC. Table 1 reports diverse physicochemical properties of the two antibiotics, such as the flexibility and solvation pattern, obtained from the optimized 3D structures or from simulations where they are placed in a box of water. We observe that, although both antibiotics have the same molecular surface size, ampicillin is found to be much more polar while moxifloxacine is much more hydrophobic (see computed surface properties in Table 1). This is in agreement with the antibiotics nature of interactions with of the antibiotics with OmpF, as . Furthermore, based on RMSF Interestingly, we also find that the ampicillin structure is twice more flexible than the one of moxifloxacine (see calculated rmsf in Table 1).

Conclusions

Here we used all-atom metadynamics simulations with different choice of the RC and followed the translocation through OmpF of two commonly used antibiotics. The high resolution in time and space that metadynamics simulations provide has the potential to be used to characterize the molecular basis of translocation of antibiotics, and further, such strategy might be used to help select/design antibiotics with better permeation properties and thus combat bacterial resistance. To improve the accuracy and efficiency of future simulations efforts, we must keep on developing the algorithms at hands. Here we address the consequences of chosen different RC, which is the crucial point of the metadynamics techniques. Due to the cylindrical shape of OmpF, a tentative choice of RC is the position of the antibiotic along the main axe of diffusion. Our results on moxifloxacin and ampicillin support our hypothesis that the  angle defines an optimal RC, as it is an internal variable not subject to change as OmpF diffuses during simulation.

Altogether, from our simulations, we observe that the bottleneck for the antibiotics translocation is to overcome the constriction region, where the antibiotic has to optimally interact with the channel, its dipole has to match the strong transversal electrostatic field and its surface has and adapt to fit to a given size.

In the simulation where the Hb was taken as a RC, we found that ampicillin can make and break Hb easily and it reaches up to 10 Hb but in the case of moxifloxacine this number is constant and as low as 4, thus we believe that overcoming the constriction is more difficult in the case of a less polar or more hydrophobic antibiotic. The molecular details of the simulations allow assessing how the choice of the RC affects the FES and the molecular mechanism for antibiotic translocation.

In the case of ampicillin, although metadynamics is applied with different RC, we find a similar antibiotic translocation pathway. In both cases, a unique energy minimum is found for ampicillin at the constriction region, which is well defined with a strong interaction network.

In this preferential minimum, the (two charged groups) dipole of the antibiotic matches perfectly with the one of the porin, known as the transversal electric field, with negative residues clustered on the L3 side and positive residues lining on the anti-L3 side (see Fig. 1).

Interestingly, a different molecular path is found by moxifloxacine with respect to ampicillin:

it translocates with its hydrophobic group pointing down and we note a predominance of Hcontacts interactions that play an important contribution as a driving force. Such possible contribution from hydrophobicity was already raised in the pioneer work of Nikaido [START_REF] Yoshimura | Diffusion of beta-lactam antibiotics through the porin channels of Escherichia coli K-12[END_REF].

Indeed, the newer generations of antibiotics that are more hydrophilic have enhanced antibacterial activity, indicating that hydrophilicity would enhance their affinity to OmpF.

Thus, in such cases, we suggest to include directly the hydrophobic interactions number as a RC in the course of metadynamics simulations. Further analysis allowed extracting important structural and dynamical properties of the antibiotics, such as solvation and flexibility, and the same could be done with the porin target.

It is noteworthy that the two different sets of reaction coordinates used in this manuscript reproduce well the previously obtained experimental observations [START_REF] Mach | Facilitated permeation of antibiotics across membrane channels-interaction of the quinolone moxifloxacin with the OmpF channel[END_REF][START_REF] Danelon | Interaction of zwitterionic penicillins with the OmpF channel facilitates their translocation[END_REF]. Indeed, both resulting simulations reveal the same "macroscopic event" that is the passage/diffusion of the antibiotic and both find a preferential affinity site for the antibiotic inside the channel.

However, using different reaction coordinates leads to different simulation time and efficiency. In this particular manuscript we aim at improving the efficiency of the molecular simulations and we show how the "right choice of coordinate" could be primordial for doing so. The importance of having an efficient and reliable computational model for antibiotic translocation is also highlighted by our recent findings that pointed out the limitations, in time and space resolutions, of kinetic experiments [START_REF] Hajjar | Bridging Timescales and Length Scales: From Macroscopic Flux to the Molecular Mechanism of Antibiotic Diffusion through Porins[END_REF].

To conclude we believe that to gain in efficiency and accuracy, the antibiotic translocation could be simulated with many RC coupled together: allowing to account explicitly for solvation, flexibility and different possible specific interactions/properties of importance in the system of study. This could be done by using a scheme such as the "bias exchange metadynamics" recently proposed [START_REF] Piana | A bias-exchange approach to protein folding[END_REF].

Tables

Figure captions

Fig. 5

Molecular details (A) and interaction map (B) of moxifloxacine at the preferential minimum, Mini-CR (see legends in Fig. 4)

Fig. 1 A)

 1 Fig. 1 A) Structural details of OmpF. The backbone of OmpF is displayed in cyan cartoons to highlight its secondary structure. The charged residues at the constriction region (D113, E117, D121 on the L3 side and R42, R82, R132 on the anti-L3 side) are colored by residue type (positively charged in blue, negatively charged in red). The loop L3 is colored in orange. 3D structures of the optimized geometry of ampicillin (B) and (C) moxifloxacin. The molecules are colored by atom types: blue for nitrogen, red for oxygen, cyan for carbon.

Fig. 2

 2 Fig. 2Complete free energy surfaces for ampicillin translocating through OmpF, associated with the reaction pathway along the subspace of the two variables: taken as (i) the distance Z (Z = 0 corresponds to the center of the constriction zone, also indicated by the grey shading) and the number of Hb (A); and taken as (B) the distance Z and the angle . Each isoline correspond to a different color gradient and to 1 kcal mol -1 . The blue points superimposed on the FES correspond to the superimposed values of the RC calculated from the other simulation.

Fig. 3 2 ). 4 A)

 324 Fig. 3Complete free energy surfaces for moxifloxacine translocating through OmpF (see legends in Fig.2)

  Figure 1 Click here to download high resolution image

Table 1

 1 Structural details of the antibiotic obtained from the equilibrium MD simulations.

	(see Materials and Methods)
	System Analysis	Averaged	Surface Properties [18]
	(in box of waters)	Atomic	Hydrophillic	Hydrophobic
		Fluctuations
		(rmsf in Å)
	AMP	0.99	221.45	83.92
	MOX	0.48	156.52	175.63

Acknowledgments

We thank Attilio Vargiu and Enrico Spiga for fruitful discussions. This study was supported by EU-grant MRTN-CT-2005-019335 (Translocation) and by the computer center and consortiums: Cybersar, CASPUR and CINECA through CPU-hours.

Next, we performed metadynamics simulations using the same two sets of RC for the quinolone antibiotic: moxifloxacine. As seen in the FES displayed in Fig. 3, there are some important differences between the two sets of simulations for the translocation of moxiflocacine. First, the free energy barrier required for moxiflocacine to translocate is much larger in the simulation A, 21 kcal mol -1 , compared to the simulation B, 16 kcal mol -1 . The localization of the energy minima, defining the affinity sites of the antibiotic inside the channel, is also very different. In the simulation A we note the absence of a deep energy minimum at the constriction region, instead it is localized slightly above, at Z ~ 4Å (Mini-Above, Fig. 3A). In the case of the simulation B we find two energy minima localized above but also in particular one energy minimum centrally localized, at the constriction region, at Z~ 0Å (Mini-CR, Fig. 3B).

The important differences between these simulations using different RC are seen from the superimposition in the FES obtained from the simulation with a RC of the calculated values of the missing RC. As seen in the blue points superimposed in Fig. 3A, the hydrogen bonds calculated from the simulation B do not follow the same path as the Hb sampled from simulation A. Instead, the number of Hb calculated from the simulation B is both more constant and lower than the number of Hb sampled along simulation A (~4 Hb from simulation B while there are 8 Hb when the antibiotic crosses the constriction region in simulation A). Similarly, as seen in the Fig. 3B, the superimposed  angles calculated from simulation A do not really follow the path of the  angles sampled in simulation B. Instead, the  angles calculated from simulation A reveal a much more stretched and limited exploration path (the  angles only take values from 40 to 120 degrees in the case of the simulation A, whereas they can cover fully the range from 0 to 180 in the case of simulation B), as a consequence some local minima (above the constriction region) are not sampled in the path followed by the simulation A (Fig. 3).

To elucidate the microscopic details of the different translocation path and conclude on the importance of the choice of the RC we further performed in-depth analysis based on equilibrium simulations.

Another possibility is to use a bias-free method [START_REF] Branduardi | From A to B in free energy space[END_REF], but then a way must be found to sample the trajectory corresponding to the studied process (for example, by using temperature as a bias as in TAMD simulations [START_REF] Weinan | Transition-Path Theory and Path-Finding Algorithms for the Study of Rare Events[END_REF]). Such explorative strategies would in fact reveal which RC is relevant for the process and system studied. Better-tuned simulation methodology will be also useful to investigate many diverse complex biological processes, such as folding or protein-protein interactions.


Olivier Leroy

Prospects for CP violation in B 0 s → J/ψφ from first LHCb data

The determination of the CP-violating phase in B 0 s → J/ψφ decays is one of the key goals of the LHCb experiment. Its value is predicted to be very small in the Standard Model but can be significantly enhanced in many models of New Physics. The steps towards a precise determination of this phase with a flavourtagged, time-dependent angular analysis of the decay B 0 s → J/ψφ are reviewed and first studies performed with data collected in 2010 at LHC in pp collisions at 7 TeV center-of-mass energy are presented for the first time. In particular, we report the first LHCb measurements of lifetime in the channels B + → J/ψK + , B 0 → J/ψK * 0 , B 0 → J/ψK 0 S , B 0 s → J/ψφ, Λ b → J/ψΛ; the polarization amplitudes in B 0 → J/ψK * 0 and B 0 s → J/ψφ; the width and mass differences of the B 0 s mass eigenstates, ∆Γs and ∆ms. The data sample used corresponds to an integrated luminosity of 36 pb -1 .

-Introduction

The interference between B 0 s decays to J/ψφ either directly or via B 0 s -B 0 s oscillation gives rise to a CP violating phase φ J/ψφ s . In the Standard Model, this phase is predicted to be -2β s , where β s = arg (-V ts V * tb /V cs V * cb ). The indirect determination via global fits to experimental data gives 2β s = (0.0363 ± 0.0017) rad [1], within the Standard Model. The direct measurement of this phase is one of the key goals of the LHCb experiment. Indeed, φ J/ψφ s is one of the CP observables with the smallest theoretical uncertainty in the Standard Model, and New Physics could significantly modify this prediction, if new particles contribute with a new phase to the B 0 s -B 0 s box diagram. Both CDF and DØ have reported constraints on φ J/ψφ s with large uncertainties [2,[START_REF]The D0 Collaboration, D0 Conference note 6098-CONF[END_REF]. In this document, we present the steps towards a measurement of φ J/ψφ s at LHCb and give the first preliminary results obtained with the 2010 data. The CP-violationg phase will be extracted from a tagged time-dependent angular analysis of B 0 s → J/ψφ decays. Therefore, the following steps are required:

( * ) on behalf of the LHCb Collaboration c Società Italiana di Fisica 1

• in Section 2, we present the selection and lifetime of B 0 s → J/ψ(µµ)φ(KK) channel, together with other b→ J/ψ(µµ)X control channels;

• in Section 3, we report on the untagged angular analysis of B 0 s → J/ψφ, together with the control channel B 0 → J/ψK * 0 ;

• the tagging of the B 0 s flavour at production is discussed in Section 4, together with the measurement of ∆m d and ∆m s ;

• other channels can be used to measure the mixing-induced CP violation in B 0 sdecays amongst which the B 0 s → J/ψf 0 channel. The first observation of this decay is reported in Section 5.

-Selections and lifetime measurement

The trigger and selection of B 0 s → J/ψ(µµ)φ(KK) and control channels are described in [START_REF]b-hadron lifetime measurements with exclusive b → J/ψX decays reconstructed in the 2010 data[END_REF]. The measurement of φ J/ψφ s requires a good understanding of detector effects such as the proper time acceptance and resolution, angular acceptance, mistag fraction and background. The strategy is to trigger and select several b → J/ψX decay modes in a similar way and use them as control channels to calibrate the detector and validate the analysis procedures used when studying B 0 s → J/ψφ. The b-hadron lifetimes are extracted from a maximum likelihood fit to the proper time distributions of the fully reconstructed candidates. In order to avoid as much as possible a proper time dependent efficiency both the trigger and the offline selection are chosen to be lifetime unbiased: the selections avoid cutting on variables that are correlated with the b-hadron proper time, such as impact parameters of final state particles with respect to the primary vertex. The only exception is a cut on proper time t > 0.3 ps which allows to remove the huge prompt background dominated by combinations of tracks originating from the primary vertex.

The reconstructed mass and proper time projections of B + → J/ψK + , B 0 → J/ψK * 0 , B 0 → J/ψK 0 S , B 0 s → J/ψφ and Λ b → J/ψΛ are shown in Figs. 1 to 5. The extracted lifetimes and the signal yields in the proper time range t ∈ [0. [START_REF]The D0 Collaboration, D0 Conference note 6098-CONF[END_REF][START_REF]Tagged time-dependent angular analysis of B 0 s → J/ψφ decays with the 2010 LHCb data[END_REF] ps are shown in Table I. They are compatible with the PDG values [START_REF] Nakamura | Review of particle physics[END_REF]. The proper time resolution measured in B 0 s → J/ψφ event is 50 fs. The systematics uncertainties are given in Table II and detailed in [START_REF]b-hadron lifetime measurements with exclusive b → J/ψX decays reconstructed in the 2010 data[END_REF]. Table II. -Systematic uncertainties in the lifetime measurements (ps). 3.

B + → J/ψK + B 0 → J/ψK * 0 B 0 s → J/ψφ B 0 → J/ψK 0 S Λ b → J/
-Untagged angular analysis of B 0 → J/ψK * 0 and B 0 s → J/ψφ

The decays B 0 s → J/ψφ and B 0 → J/ψK * 0 are both pseudo-scalar to vector-vector transitions. Both decays are described by three time dependent decay amplitudes corresponding to transitions in which the J/ψ and φ (or K * 0 ) have a relative orbital momentum L of 0, 1, or 2. In the transversity formalism [START_REF]Roadmap for selected key measurements of LHCb[END_REF], the initial amplitudes at time t = 0, A 0 (0) and A (0) describe the decays with L = 0, 2 while A ⊥ (0) describes the L = 1 final states. The arguments of these complex amplitudes are strong phases denoted δ 0 , δ and δ ⊥ . The measurement of the polarization amplitudes and strong phases using untagged 36 pb ≈ = 7 TeV, L s Fig. 6. -Fitted PDF with S-wave included projected on the transversity angles compared to the data distributions for the selected B 0 → J/ψK * 0 candidates. Shown are the total PDF, the PDFs for signal (blue), S-wave (green), total background (red) and wrong-signal(purple).

events is presented in [START_REF]Untagged angular analysis of B 0 → J/ψK * 0 and B 0 s → J/ψφ decays[END_REF]. For the B 0 → J/ψK * 0 channel, we find:

|A (0)| 2 = 0.252 ± 0.020 ± 0.016 , |A ⊥ (0)| 2 = 0.178 ± 0.022 ± 0.017 , δ = -2.87 ± 0.11 ± 0.10 , δ ⊥ = 3.02 ± 0.10 ± 0.07 .
The first error is the statistical uncertainty from the 5-dimensional fit (mass, proper time and 3 angles). The second error is the systematic uncertainty, details of which are given in [START_REF]Untagged angular analysis of B 0 → J/ψK * 0 and B 0 s → J/ψφ decays[END_REF]. The 1-dimensional projections of the 5-dimensional fit function are compared to the measured data in Figure 6.

For the B 0 s → J/ψφ channel, assuming φ J/ψφ s =0, we measure:

Γ s = 0.680 ± 0.034 ± 0.027 ps -1 , ∆Γ s = 0.084 ± 0.112 ± 0.021 ps -1 , |A ⊥ (0)| 2 = 0.279 ± 0.057 ± 0.014 , |A 0 (0)| 2 = 0.532 ± 0.040 ± 0.028 , cos δ = -1.24 ± 0.27 ± 0.09 , where the first error is the statistical error from the fit and the second error is the systematic uncertainty detailed in Table 3. The 1-dimensional projections of the 5dimensional fit function are compared to the measured data in Figure 7.

4. -Flavour tagging and measurement of ∆m s using

B 0 s → D - s (3)π +
The tagging of the initial B-flavour in LHCb is a key step towards the measurement of φ J/ψφ s . It is described in [START_REF]Optimization and Calibration of the Tagging performances using 2010 data[END_REF]. The algorithm exploits charged tracks originating from the bhadron opposite to the signal B-meson (kaon, muon, electron and vertex charge) and also tracks close to the signal B-meson (same-side tagging). The algorithm is optimized using B 0 → D * -µ + ν µ and B + → J/ψK + events and calibrated using B + → J/ψK + , B 0 → J/ψK * 0 events. In [START_REF]Measurement of ∆M d in B 0 → Dπ[END_REF], the calibration is cross-checked using B 0 → K + π -events and the B 0 -B 0 =7TeV, L=36 pb s Fig. 7. -Fitted PDF projected on the lifetime and the transversity angles compared to the data distributions for the selected B 0 s → J/ψφ candidates. Shown are the total PDF, the PDFs for signal, the PDFs for the CP-even and CP-odd signal components and the total background PDF.

Table III. -Systematic uncertainties assigned to the extracted physics parameters of the decay B 0 s → J/ψφ. mixing frequency is measured to be:

Systematic effect Γs [ ps

-1 ] ∆Γs [ ps -1 ] |A ⊥ (0)| |A (
∆m d = 0.499 ± 0.032 (stat.) ± 0.003 (syst.) ps -1 .
An additionnal crucial test is performed in [START_REF]Measurement of ∆Ms and calibration and tuning of the Same-Side Tagging algorithm with B 0 s → Dsπ decays using the 2010 data sample[END_REF], by measuring the B 0 s -B 0 s mixing frequency using B 0 s → D - s (3)π + events. In that case, only opposite side tagging is used. The effective tagging efficiency is (3.8 ± 2.1)%. Using the events sample given in Table IV, we measure: ∆m s = 17.63 ± 0.11 (stat.) ± 0.04 (syst.) ps -1 , which is compatible and competitive with the world best measurement [START_REF] Abulencia | Observation of B 0 s -B 0 s Oscillations[END_REF]. The details of the systematics uncertainties are given in [START_REF]Measurement of ∆Ms and calibration and tuning of the Same-Side Tagging algorithm with B 0 s → Dsπ decays using the 2010 data sample[END_REF]. The likelihood profile as a function of the mixing frequency ∆m s is shown in Figure 8. The statistical significance of the signal is evaluated by comparing the likelihood value at the measured ∆m s value of 17.63 ps -1 with the likelihood value obtained on the same sample in the limit of infinitely high

Bs → D - s (φπ -)π + 515 ± 25 Bs → D - s (K * K)π + 338 ± 27 Bs → D - s (K + K -π -)π + 283 ± 27 Bs → D - s (K + K -π -)3π 245 ± 46
mixing frequency. We find a significance of 4.6 σ for the observed mixing signal. The statistical size of the sample is not large enough to illustrate the oscillation pattern of the time dependent asymmetry. However we can more clearly observe the oscillation if we plot the asymmetry as a function of the proper time modulo 2π ∆ms (Figure 9). Additionally we provide an amplitude scan in Figure 9, with all details given in [START_REF]Measurement of ∆Ms and calibration and tuning of the Same-Side Tagging algorithm with B 0 s → Dsπ decays using the 2010 data sample[END_REF].

5. -First observation of B 0 s → J/ψf 0 When LHCb will have accumulated more data, the measurement of φ s will not only be done in B 0 s → J/ψφ, but also in other similar channels. One of them, B 0 s → J/ψf 0 , has been observed for the first time in LHCb [START_REF]First observation of B 0 s → J/ψf 0 (980) decays[END_REF]. The J/ψπ + π -and π + π -invariant masses are shown in Figure 10. We measure:

R f0/φ ≡ Γ(B 0 s → J/ψf 0 , f 0 → π + π -) Γ (B 0 s → J/ψφ, φ → K + K -) = 0.252 +0.046+0.027 -0.032-0.033
Despite a smaller branching ratio, with respect to B 0 s → J/ψφ, the fact that J/ψf 0 is a pure CP-odd final state makes the measurement of φ s simpler, since no angular analysis is required.

-Epilogue

While completing these proceedings LHCb has released its first preliminary results on φ J/ψφ s [START_REF]Tagged time-dependent angular analysis of B 0 s → J/ψφ decays with the 2010 LHCb data[END_REF]. The dataset was too small to calibrate the same-side tagger; the opposite side tagger has a measured effective efficiency of 2.2 ± 0.4%. Although it was not possible to give a point estimate contours in φ s -∆Γ s space could be calculated.

-Conclusions

The B 0 s → J/ψφ channel will allow LHCb to probe possible New Physics effects in the B 0 s -B 0 s box diagram. We have presented, for the first time at this conference, the preliminary results needed for a φ J/ψφ s measurement, obtained with the data taken in 2010. The data sample used corresponds to an integrated luminosity of 35 pb -1 . We have measured the lifetime of B + → J/ψK + , B 0 → J/ψK * 0 , B 0 → J/ψK 0 S , B 0 s → J/ψφ, Λ b → J/ψΛ, the polarization amplitudes in B 0 → J/ψK * 0 and B 0 s → J/ψφ, the width and mass differences of the B 0 s mass eigenstates, ∆Γ s and ∆m s . In particular, we measure: ∆m s = 17.73 ± 0.11 (stat.) ± 0.04 (syst.) ps The invariant mass of J/ψπ + π -combinations when the π + π -pair is required to be within ±90 MeV of the f0(980) mass. The data have been fit with a signal Gaussian and several background functions. The thin (red) solid curve shows the signal, the long-dashed (brown) curve the combinatorial background, the dashed (green) curve the B + → J/ψK + (π + ) background, the dotted (blue) curve the B 0 → J/ψK * 0 background, the dash-dot curve (purple) the B 0 → J/ψπ + π -background, the barely visible dotted curve (black) the sum of B 0 s → J/ψη and J/ψφ backgrounds, and the thick-solid (black) curve the total. Right: The invariant mass of π + π -combinations when the J/ψπ + π -combination is required to be within ±30 MeV of the B 0 s mass. The dashed curve is the like-sign background that is taken from the data both in shape and absolute normalization. The dotted curve is the result of the fit described in [START_REF]First observation of B 0 s → J/ψf 0 (980) decays[END_REF].

Fig. 1 .

 1 Fig. 1. -B + mass (left) and proper time (right) projections of the two-dimensional fit to the B + → J/ψK + candidates with t > 0.3 ps. The total fit is represented by the blue solid line, the signal contribution by the green dashed line and the background contribution by the red dashed line. The mass range for the fit is m ∈ [5.15, 5.40] GeV/c 2 .

Fig. 2 .

 2 Fig. 2. -B 0 mass (left) and proper time (right) projections of the two-dimensional fit to the B 0 → J/ψK * 0 candidates with t > 0.3 ps. The total fit is represented by the blue solid line, the signal contribution by the green dashed line and the background contribution by the red dashed line. The mass range for the fit is m ∈ [5.20, 5.36] GeV/c 2 .

Fig. 3 .

 3 Fig. 3. -B 0 mass (left) and proper time (right) projections of the two-dimensional fit to the B 0 → J/ψK 0 S candidates with t > 0.3 ps. The total fit is represented by the blue solid line, the signal contribution by the green dashed line and the background contribution by the red dashed line. The mass range for the fit is m ∈ [5.15, 5.40] GeV/c 2 .

Fig. 4 .

 4 Fig. 4. -B 0 s mass (left) and proper time (right) projections of the two-dimensional fit to the B 0 s → J/ψφ candidates with t > 0.3 ps. The total fit is represented by the blue solid line, the signal contribution by the green dashed line and the background contribution by the red dashed line. The mass range for the fit is m ∈ [5.20, 5.55] GeV/c 2 .

Fig. 5 .

 5 Fig. 5. -Λ b mass (left) and proper time (right) projections of the two-dimensional fit to the Λ b → J/ψΛ candidates with t > 0.3 ps. The total fit is represented by the blue solid line, the signal contribution by the green dashed line and the background contribution by the red dashed line. The mass range for the fit is m ∈ [5.47, 5.77] GeV/c 2 .

Fig. 8 .

 8 Fig. 8. -Likelihood scan for ∆ms in the range from [0.0,25.0] ps -1 . The line at 20.94 indicates the likelihood value evaluated in the limit of infinite mixing frequency.

Fig. 9 .

 9 Fig. 9. -Left: Mixing asymmetry for signal B 0 s candidates as function of proper time modulo 2π ∆ms . The fitted signal asymmetry is superimposed. Right: Fitted amplitude as a function of ∆ms. See the text for further explanation.

- 1 .Fig. 10 .

 110 Fig.10. -Left: The invariant mass of J/ψπ + π -combinations when the π + π -pair is required to be within ±90 MeV of the f0(980) mass. The data have been fit with a signal Gaussian and several background functions. The thin (red) solid curve shows the signal, the long-dashed (brown) curve the combinatorial background, the dashed (green) curve the B + → J/ψK + (π + ) background, the dotted (blue) curve the B 0 → J/ψK * 0 background, the dash-dot curve (purple) the B 0 → J/ψπ + π -background, the barely visible dotted curve (black) the sum of B 0 s → J/ψη and J/ψφ backgrounds, and the thick-solid (black) curve the total. Right: The invariant mass of π + π -combinations when the J/ψπ + π -combination is required to be within ±30 MeV of the B 0 s mass. The dashed curve is the like-sign background that is taken from the data both in shape and absolute normalization. The dotted curve is the result of the fit described in[START_REF]First observation of B 0 s → J/ψf 0 (980) decays[END_REF].

Table I .

 I -Signal event yields and lifetimes extracted from the likelihood fits to the candidates with proper time t ∈ [0.3, 14] ps. A single exponential is used to fit the proper time distribution.

	Channel	Lifetime (ps)	Yield
	B + → J/ψK +	1.689 ± 0.022 (stat.) ± 0.047 (syst.)	6741 ± 85
	B 0 → J/ψK * 0	1.512 ± 0.032 (stat.) ± 0.042 (syst.)	2668 ± 58
	B 0 → J/ψK 0 S B 0 s → J/ψφ	1.558 ± 0.056 (stat.) ± 0.022 (syst.) 1.447 ± 0.064 (stat.) ± 0.056 (syst.)	838 ± 31 570 ± 24
	Λ b → J/ψΛ	1.353 ± 0.108 (stat.) ± 0.035 (syst.)	187 ± 16

Table IV .

 IV -Number of B 0 s signal candidates used in the ∆msmeasurement.

	Decay mode	# signal candidates

* * * I wish to thanks the organizers of the "Rencontres de Physique de la valle d'Aoste", for the very nice atmosphere during the conference in La Thuile, and all my LHCb colleagues who make possible the first presentation of these 17 new beautiful results.


Rozenn Bouville Berthelot

Jérôme Royan
email: jerome.royan@orange-ftgroup.com

Thierry Duval
email: thierry.duval@irisa.fr

Bruno Arnaldi
email: bruno.arnaldi@irisa.fr

Scene Graph Adapter: An efficient Architecture to Improve Interoperability between 3D Formats and 3D Applications Engines

Keywords: CR Categories: I.3.7 [Computer Graphics]: Three-Dimensional Graphics and Realism-Virtual reality, D.2.12 [Software Engineering]: Interoperability-Data mapping, D.2.13 [Software Engineering]: Reusable Software-Reusable libraries interoperability, 3D format, software architecture, rendering, virtual worlds, web3D

: Our architecture allows the loading of any 3D graphics format simultaneously in any available rendering engine. The scene graph adapter is an interface that adapts a scene graph (SG) of a given format into a renderer scene graph and which also allows the rendering part to request this scene graph.

Introduction

In 1994, the VRML was conceived at the first annual World Wide Web Conference in Geneva, with the goal to provide a language for describing multi-participant interactive simulations, virtual worlds networked via the global Internet and hyperlinked with the World Wide Web. This great and pioneering initiative was and is successful in the industrial domain, but did not reach the success as hoped in the field of applications for the public at large. This problem has been extensively discussed in the Web3D community. Its lack of extensibility and the fact that 3D tools and modelers did not provide a good VRML export were certainly majors issues. However, the main reason of its qualified success was probably the fact that VRML appeared much before processors and networks could support the graphics that the technology enabled, as noticed by Pesce [START_REF] Pesce | Mark pesce, tony parisi -vrml / vrml 97 / x3d 10th anniversary -3d test panorama of web 3d technologiesreal time 3d and interactive media[END_REF]] and Ortiz [START_REF] Ortiz Jr | Is 3D Finally Ready for the Web ?[END_REF]]. Indeed the VRML was essentially used to visualize simple 3D content on the Web. Nonetheless the VRML has served as a basis to develop many 3D formats and platforms for virtual worlds during the last decade, increasing the options to create 3D services within virtual worlds. Unfortunately, this proliferation of virtual world platforms raises a huge interoperability issue: 500 are currently online and more than 900 are forecast for 2012. The various developments concerning Web3D do not respect one of the main and fundamental characteristic of the Web: its uniqueness. This increase of 3D formats, protocols, browsers for virtual worlds generates the following consequences.

First of all, we can maintain that the proliferation of non interoperable platforms for virtual worlds does not encourage industry to invest in virtual worlds. Although the number of users in virtual worlds is estimated at over a billion, a dream come true for a marketer, the fragmentation of users among a large number of virtual worlds disrupts the principle of the current Web 2.0 where investments in a Web service target all users who have access to the Web. In other words, developing a service for a virtual world will target only the users of this virtual world. The ratio between investing in the development of a service in virtual worlds (designing, modeling and scripting) and the number of targeted users cannot be compared to what currently exists on the Web. Unfortunately, this ratio often makes the difference when decision-makers have to choose between improving their current web services or investing in virtual worlds. When we know that the emergence of the web is directly linked to its adoption by the industry, we can conclude that interoperability between virtual worlds is a main issue for the emergence of Web3D.

On the other hand, consortiums committed to the creation and deployment of standards, whether open, royalty-free, ISO or not, provide outstanding efforts of specification to make virtual worlds consistent with each other. To be successful, however, a standard has to be adopted by a great majority of the community. To achieve this, several criteria can improve the promotion of 3D standards such as:

• offering specific functionality required by the community,

• providing a way to create content, such as a dedicated authoring tool, or export modules for authoring tools that are widely used on the market,

• providing a way to visualize the coded content, thanks to a dedicated viewer, thanks to a transcoding module to fit the content to renderers that are not directly compliant with the standard, or finally, thanks to a loader that can be easily plugged in to existing platforms for virtual worlds.

In this article, we focus on the latter item, namely the solutions for using 3D content encoded in a given standard within most virtual world platforms. The development of a virtual world platform around a viewer dedicated to a specific standard is not currently widely used. Indeed, virtual worlds developers require not only a 3D viewer, but a complete platform embedding a set of engines for rendering, physics simulation and networked synchronization.

Concerning the rendering engine, they generally opt to develop it themselves, or reuse "generic" engines (Unity, Ogre3D, Irrlicht, CryEngine), instead of using a viewer dedicated to a specific standard. Thus, a good way to import standardized content within a virtual world is to transcode it to a compliant format.

Unfortunately, these widely used solutions can become restrictive, as the transcoding tools from a standard to a format compliant with an engine have to be developed, and transcoding generally results in the lost or the modification of data such as interactions, physics parameters, texture coordinates and so on. Finally, to provide developers of virtual worlds with a software component that allows them to directly load and run a standardized content appears to be an interesting solution. Except that the architecture of virtual worlds platforms must be well-suited to reduce integration costs.

In conclusion, no real solution exists today to easily integrate standardized content within virtual worlds platforms, which could curb the adoption of 3D standards.

In the remainder of this paper, we aim to propose a new architecture for Web3D platforms providing an easy way to integrate any 3D standard and mix them in the same 3D scene. To achieve this goal, in Section 2, we describe related works concerning the solutions improving the interoperability for Web3D. Then we present in Section 3 a global overview of the proposed architecture which components will be detailed in Section 4. Afterwards, we propose in Section 5 an example of implementation and show the first results. Finally, we discuss the efficiency and usability of the proposed architecture and finally conclude in Section 6.

Related work

VRML was the first attempt to put 3D contents in a web browser and people who were working on that subject had great expectations as told in [START_REF] Lea | Java for 3D and VRML Worlds[END_REF]]. This first initiative did not have the expected success as explained in section 1. Indeed, today, 3D technology is used online but not in a web browser, most often through applications dedicated to games and virtual worlds. Indeed, general web browsers cannot natively run complex 3D content. There are a lot of available solutions, a complete overview of these solutions can be found in [START_REF] Behr | X3dom: a dom-based html5/x3d integration model[END_REF] The aforementioned solutions are very efficient and will surely increase the amount of 3D content on the web but they do not solve the problem of reusing existing content. Creating 3D content is indeed expensive and time-consuming, and the amount of online 3D applications such as games or metaverses is increasing every year. The only solution is to bring interoperability between 3D formats, as stressed by Polys [START_REF] Polys | Future standards for immersive vr: Report on the ieee virtual reality 2007 workshop[END_REF]] it is a "crucial requirement for success".

Interoperability has been studied in various fields of computer science and we use Haslhofer's classification of metadata interoperability presented in [START_REF] Haslhofer | A survey of techniques for achieving metadata interoperability[END_REF] to identify interoperability solutions. There are 3 categories of solutions:

1. the model agreement, 2. the metamodel agreement, 3. the model reconciliation.

The model agreement consists in establishing a standard by means of consensus building. It is an intuitive, technically effective and economically well-recognized way to achieve interoperability.

To be efficient, it requires the acknowledgment of an institution (e.g. W3C, ISO, . . . ). It would have been a good solution for 3D formats, nevertheless it is hard to apply considering the present situation. There are indeed more than 50 3D formats and although some of them are more or less abandoned, new ones continue to appear. The need to bring new features that are not present in existing formats is the reason why new formats are still emerging. Thus, establishing a standard will imply keeping those features to have a real compromise. WebGL seems to be a good alternative but it relies on OpenGL ES 2.0, which is entirely shader-based. It means that we have no real scene graph and that all vertex attributes of a mesh need to be declared before being used in a vertex shader.

To use this standard with existing 3D formats we have no other choice than to resort to transcoding, but this technique often leads to a loss of functionality.

The metamodel agreement consists in agreeing on a common metamodel. For all existing models, instances of each model feature are created in the metamodel as if they were translated in the metamodel. Metamodel agreement implicitly enables interoperability by creating correspondences between the features of an existing model and those of the common model. If we apply this solution to 3D formats it means to create a metaformat that includes every feature of every 3D format. This solution is as efficient as the model agreement but it requires it to be comprehensive and extensible to be widely adopted. However this solution applied to 3D formats seems hardly feasible since there exist too many 3D formats and new ones will continue to appear. This makes this solution non-sustainable because it is not extensible. To our knowledge, there is no such solution for 3D formats.

The last interoperability solution is the model reconciliation. It achieves interoperability by reconciling heterogeneities among formats. This is the most complex way to achieve interoperability because heterogeneities can be of multiple types in a model. However, as for 3D formats, there are many similarities between them making reconciling heterogeneities easier than in other domains. Besides it is an extensible solution so that it is suitable for 3D formats. Some solutions already exist for 3D formats like MPEG-V (MPEG for virtual worlds) [START_REF] Gelissen | [END_REF]] that aims at standardizing intermediate formats and protocols to exchange information between virtual worlds. Another similar initiative is the VWRAP project [START_REF] Bell | Vwrap for virtual worlds interoperability[END_REF] but this solution only works on a set of virtual worlds similar to Second Life (i.e. spatially partitioned into regions hosted by simulation servers, with agents representing users and user-controlled via client application). Fang et al. [START_REF] Fang | Building interoperable 3d virtual world platforms with restful web services[END_REF] propose a solution based on RESTful web services.

The PLUG solution [START_REF] Hu | Plug: Virtual worlds for millions of people[END_REF] presents a single universal client for all online virtual environments. This client can retrieve several virtual worlds from hosting sites. Virtual environments are run on this hosting site and retrieved by the client using image streaming techniques. In the work from Soto and Allongue [START_REF] Soto | Modeling methods for reusable and interoperable virtual entities in multimedia virtual worlds[END_REF], the focus is laid on reusability of virtual worlds entities. They use multiagent concepts and learning techniques to enable the transfer of an entity from a virtual world to another.

From our point of view and as regards reusability as well as keeping heterogeneities of 3D formats, the model reconciliation is the best solution. Thus we propose to design a generic API that interfaces a format and a 3D application. It is based on similarities between 3D formats and 3D application components (rendering engine, physics engine, etc. ). This API enables the adaptation of a format scene graph into a renderer scene graph. Our goal is to provide the use of any available 3D format without functionality loss whatever is the targeted viewer.

Overview of our architecture

In this chapter we present our architecture for building 3D applications that use several 3D formats in most rendering engines. It is based on an API, the Scene Graph Adapter, which aims at interfacing communication between 3D application inputs (e.g. 3D files) and output (e.g. the interactive visualization window).

Concepts and prerequisites

When creating a 3D application we have technical and functional requirements that lead us to the choice of a rendering engine. But rendering engines support a limited amount of input formats that makes the choice even more difficult when we also have formats requirements. These requirements could be the need to reuse existing 3D contents or to work with specific modeling tools which formats are not supported. Even if 3D formats and rendering engines have different usages and functionalities, they nonetheless have many similarities. Most of them are indeed based on a scene graph data structure. They also use similar ways to model and organize data in the scene graph. For example they have a similar shape description structure with a separation between geometry and appearance. They also use similar modeling transformations as well as similar primitive shapes. For 3D formats, this can be explained by the fact that since the concept of scene graphs was introduced by Open Inventor [START_REF] Strauss | An object-oriented 3d graphics toolkit[END_REF] in 1992, no other concept as efficient and flexible as this one has been proposed. It indeed reflects the underlying rendering pipeline.

The explanation for rendering engines is more obvious. In fact they all rely on one or both of the existing low-level API: OpenGL and DirectX. Thus, their evolution follows those API improvements as well as GPUs improvements. It was for example the case when GPUs enabled shader programming.

In [START_REF] Hinrichs | A generalized scene graph. Vision, modeling, and visualization[END_REF]] and later in [START_REF] Döllner | A generic rendering system[END_REF]

Overall architecture

The figure 1 depicts our architecture. The purpose of the Scene Graph Adapter API is to enable communication between an input scene graph of a given 3D format and the output scene graph of a rendering component (rendering engine, physics engine, behavior engine, etc. ) in a 3D application. This application can be a game, a plugin, a GUI for a 3D display and so on. We call the first scene graph the format scene graph and the second scene graph the engine scene graph. In this paper, we will only use a rendering engine, this is why the engine scene graph is called the renderer scene graph.

To complete our architecture we need components that load, decode and adapt a format scene graph using the Scene Graph Adapter API on the input side. Similarly, on the rendering side of our architecture, we need a component that adapts instructions from the Scene Graph Adapter API into instructions of the renderer API to build the renderer scene graph. We call these two components the format wrapper and the renderer wrapper respectively. There is only one format wrapper for every file of a given format as well as one renderer wrapper per rendering engine.

Format wrappers do not depend on an application. They can be reused in any application providing that it relies on the Scene Graph Adapter API. Yet a Format Wrapper depends on a Format Decoder. Format Decoders are composed of existing tools like a parser or a loader that help at developing a format wrapper. Every 3D format indeed comes with at least a viewer so that this part should not be made from scratch. Besides as every 3D format possess specific features, reusing these pre-existing tools helps at keeping them up to date. The Format Decoder decodes and parses the input file and builds an internal scene graph data structure of the format scene graph. Depending on the used decoder, this component may include an update message handler that receives event update messages and updates relevant nodes accordingly. If it is not the case, then it must be implemented in the format wrapper.

The format wrapper then uses this representation to adapt it using methods from the Scene Graph Adapter. Our architecture allows to mix several format wrappers within a single application in order to mix different input formats.

Renderer wrappers do not depend on an application either and can be reused in any application based on the Scene Graph Adapter.

A renderer wrapper relies on the rendering engine API in the same way a format wrapper relies on a Format Decoder. It uses methods from the Scene Graph Adapter API and adapts them using the rendering engine API to build and update the renderer scene graph. As explained in 3.1, the choice of a rendering engine is crucial when designing a 3D application. Therefore it is important to enable the use of most of the available rendering engines.

Benefits

Our architecture addresses the reusability issue and achieves the rendering of any 3D format without functionality loss. It has several benefits:

• First, it fully supports all the scene-graph-based 3D formats without rendering limitation, assuming that we have the appropriate format wrapper. It makes it possible to use old 3D models without transcoding and functionality loss. Thus it allows a more efficient collaborative work. Research teams can share their resources without being hampered by compatibility problems. Furthermore, depending on the requirements of an application, it is possible to use the most appropriate format without rendering engine restriction. It also makes easier the porting of a format into rendering engines; this can help to promote a new format.

• Second, it works with any rendering engine without input format restriction. Once a renderer wrapper is available, it gives access to every available format wrappers. An application can use the most appropriate rendering engine without being hampered by format compatibility. Designers team can use any modeling tool and export their 3D models without compatibility problems. It is also possible to directly import a modeler native format in the application while avoiding transcoding drawbacks.

• Third, it makes it possible to mix and reuse format wrappers and renderer wrappers as required by application. It allows to mix 3D formats and their functionalities. We can for example load a Collada model with physics properties in an X3D world and explore it using X3D's navigation and interaction features. Besides a wrapper can be reused in any application that is based on the Scene Graph Adapter API. It allows development teams to share their wrappers hence facilitating components reuse and teams cooperation. In addition, more and more 3D application use third-party rendering components instead of creating new ones. There are physics engines (Havok 1 , PhysX 2 , Open Dynamics 3 , etc. ), character animation 1 http://www.havok.com/index.php?page= havok-physics 2 http://www.nvidia.com/object/physx_new.html 3 http://www.ode.org/ engines (Granny4 , Havok Animation5 , etc. ) or AI components (Kynapse6 ). Thus, a wrapper for those components can be reused in many applications.

The Scene Graph Adapter

After having introduced the basic architecture of the Scene Graph Adapter, this section illustrates how the different components are working and how they interact together. The Scene Graph Adapter allows the rendering of multiple 3D formats simultaneously in a single view but also manages interactions and animations declared in the input files. To achieve this, the Scene Graph Adapter API provides a two-way communication between format wrapper and renderer wrapper.

The Scene Graph Adapter principle

Let Z be the set of all scene-graph-based 3D formats. A 3D content is defined by the couple (f, z) where f is a file and z is a 3D format with z ∈ Z. A 3D application includes several rendering components that we call engines (rendering engine, physics engine, behavior engine, artificial intelligence engine, etc. ). Let E be the set of all engines. An engine can be characterized by the couple (e, t) where e ∈ E and t is its type (rendering, physics, behavior, etc. ).

Besides N is the set of nodes in a format scene graph and N ′ is the set of nodes in an engine scene graph. Then the triplet (f, z, ni) with ni ∈ N characterizes the node with index i in the format scene graph of the file f encoded in the format z.

Likewise the triplet (e, t, n ′ i ) with n ′ i ∈ N ′ is the node with index i in the engine scene graph of the engine e of type t. Within each scene graph a node has a unique index.

The Scene Graph Adapter allows to retrieve:

1. a format scene graph node given a renderer scene graph node. 2. engine scene graph nodes given a format scene graph node.

For a node n ′

i of an engine scene graph, the Scene Graph Adapter returns ∅ or a node of a format scene graph. Let F ′ be the retrieve function:

F ′ (e, t, n ′ i ) = ∅ or (f, z, ni)
Likewise, let ni be a node in a format scene graph, the Scene Graph Adapter returns ∅ or a set of engine scene graphs nodes. Let F be the retrieve function:

F (f, z, ni) = {(ej, tj, n ′ i ) | F ′ (ej, tj, n ′ i ) = (f, z, ni)}
In other words, a node from a format scene graph can match none, one or several nodes in the engine scene graphs of an application. For example, that node can match one node in the rendering engine and another node in the physics engine of the application. Whereas, in the case of a LOD node, in the format scene graph, not all the level nodes will be present in the renderer scene graph. Only the selected level node matches a node in the renderer scene graph. On the other hand, a node from an engine scene graph can match none or a single node in a format scene graph. Some nodes in an engine scene graph do not match any node from an input file, such as the root node of the renderer scene graph. Figure 2 shows an illustration of this formalism. The Scene Graph Adapter executes this task while the application is running. It keeps those informations in a map which evolves depending on the rendering context (elapsed time, camera position, etc. ).

The Scene Graph Adapter API

As shown in figure 1, the Scene Graph Adapter API is composed of two distinct API:

-the Format Adapter API, -the Renderer Adapter API.

The Format Adapter API provides methods to update and query a format scene graph. These methods are called by the application or by engine wrappers and are implemented in a format wrapper. Implementation of these methods depends on the format and relies on the loader used in the Format Decoder. The Format Adapter API methods can be classified by:

• scene graph loading: loadFile, loadNode, etc.

• frame events: setTime, setViewpoint, etc.

• user events: onClick, onDrag, onRollOver, onKeyPressed, etc. • etc.

The Renderer Adapter API is composed of methods to add, remove, update and query the renderer scene graph. They are called directly by the application or by a format wrapper and are implemented in a renderer wrapper using the chosen rendering engine API. The Renderer Adapter API methods can be classified by:

• environment settings: setViewpoint, setViewport, setBackground, setFog, etc. • camera settings: createCamera, setCamera, etc.

• navigation settings: setNavigation, etc.

• ligths settings : setDiffuseLight, setAmbientLight, etc.

• scene graph settings : createNode, deleteNode, attachNode, etc. • geometry settings : createSphere, createBox, createIndexed-FaceSet, etc. • transform settings : createTransformNode, setTrans-formNode, etc.

• material settings : createMaterial, setMaterial, etc.

• texture settings : createTexture, setTexture, etc.

• etc.

The Scene Graph Adapter API also provides tools that help at building new wrappers and new applications based on our architecture. First, the Scene Graph Adapter API maintains a node indexer. This indexer keeps informations about all the nodes of the renderer scene graph to identify them and retrieve the corresponding node in the format scene graph while the application is running. Moreover, in order to avoid naming conflicts in the renderer scene graph, the Scene Graph Adapter API provides a naming method that delivers an identifier for each node of the renderer scene graph. This identifier is then used as the key in the node index. An example will be given in section 5 to illustrate all these functionalities.

The wrappers

To create an application based on the Scene Graph Adapter API, once a rendering engine is chosen, all that needs to be done is to use an existing renderer wrapper for the chosen engine or build a new one. At this point, the application can load any 3D format provided that there exists an appropriate format wrapper. We have divided wrappers role in two tasks: an adapter task and an adaptee task. We use those terms with reference to the adapter pattern GoF 139 [START_REF] Gamma | Design patterns: Elements of reusable Object-Oriented Software[END_REF]. In this section we explain for each type of wrappers the adapter and the adaptee tasks.

Format wrappers

To build a format wrapper, the format scene graph is parsed by the Format Decoder and methods from the Renderer Adapter API are called to build a renderer scene graph based on this format scene graph. It is the adapter task of a format wrapper. On the other hand, methods from the Format Adapter API are implemented using the scene graph representation used by the Format Decoder. This is the adaptee task of a format wrapper.

Renderer wrappers

Building a renderer wrapper means implementing methods of the Renderer Adapter API using the chosen rendering engine API. This forms the adaptee task of a renderer wrapper. Besides, an action on the renderer scene graph that needs to query the original scene graph (i.e a format scene graph) must be implemented using the Format Adapter API, this is the adapter task of a renderer wrapper. Figure 3 gives an example of these tasks for a format wrapper and a renderer wrapper. Wrappers communicate from an adapter to an adaptee.

Since almost all 3D graphics formats offer the possibility to modify the scene (e.g. switch node, scripts or level of detail), the Scene Graph Adapter provides two exchange modes between wrappers as illustrated in figure 4: a push mode and a pull mode. In push mode, the whole format scene graph is sent to the renderer wrapper which loads it on-the-fly. For example, if the format scene graph has a level of detail (LOD) node, the complete LOD information is sent to the rendering engine which manages LOD

Integration in a 3D application

We have already explained how components are working and how they interact at runtime. We will now present how to integrate this architecture in a 3D application. The application is in charge of configuring the rendering engine and also of sending input files url to format wrappers. Figure 5 shows the messages exchanged by the different components of the architecture when the application is started. First, the application registers all the available format wrappers (message 1), then it configures the rendering engine (messages 2 to 4) and eventually it sends an url to the Scene Graph Adapter (message 5), which loads the appropriate format wrapper (message 6). The format wrapper then begins the adaptation of the format scene graph into the renderer scene graph (messages 7 to 12). The last message, number 13, initializes the animations described in the loaded file. This is carried out during the static rendering phase because the event system must be initialized as soon as possible so that animation can be performed as described in the input file when the rendering loop starts. The rendering loop is controlled by the renderer (message 1). On each loop, an update is made of frame parameters (message 2). This update contains the elapsed time in our example. The renderer then sends an update to the Scene Graph Adapter (message 3) which informs every format wrappers (messages 4 to 5). The time update is transmitted to the Format Decoder (message 6) which is in charge of informing every time listener in the format scene graph such as TimeSensors. The format wrapper is informed of the TimeSensor update (message 7) and updates all its listeners (message 8). In our sample code, the route node sets the sphere transparency as a listener of TimeSensor fraction changes. The transparency field of the material node is updated with the new value and this update is transmitted to the renderer (messages 9 to 10).

Note that if the application needs to import another format, no changes or adaptations need to be done on the rendering part of the architecture. Nevertheless, changing the rendering engine impacts the application. Indeed the application is in charge of configuring the rendering engine and of the loading of its assets: the application controls rendering parameters such as the size of the rendering window for example.

Implementation and results

In this section, we will present the realized implementation of our architecture.

Implementation

We have realized an implementation of our architecture in C++ to prove the concept of our solution. We try to design an as generic as possible API to fit every 3D format as well as every engine scene graph. We choose Ogre 3D7 as a rendering engine because it is open-source, it has a well-documented API and a large user community. Then we use our architecture to load X3D and Collada files in Ogre. We choose X3D because it is the most complete royalty-free open standard; it includes indeed many features that other formats only partially proposed. As for Collada, it seems to us to be a good example since it is also royalty-free and widely adopted since its release.

In order to realize the X3D Wrapper, our first task was to choose the tools that we wish to use in the X3D decoder. We use CyberX3D for C++8 as the parser and the decoder. The X3D Wrapper relies on CyberX3D's scene graph representation. It uses this representation to traverse the scene graph and call the appropriate methods from the Renderer Adapter API. Besides, in order to be able to render animations described in a X3D file, we need an event library. Cy-berX3D does not propose an event handler, that is why we realize this part in the format wrapper. We chose Boost Signals 29 to implement this task. During the parsing of the format scene graph, we create new signals instances for every sensor and interpolator in the graph. Later, when route nodes are parsed, listeners are attached to the previously created signals. Let us consider this sample route to clarify this process: Decoder to decode a time update result. The time update triggers an update of all TimeSensors in the format scene graph. Then, as defined in the route node, the transparency field of the material node is updated. This is done thanks to the listener attached to the Timer node. An illustration of this case is shown in figure 6.

To create the Collada Wrapper we use FCollada 10 as a parser. The Collada wrapper uses FCollada scene graph representation to render Collada files using the Renderer Adapter API methods.

Creating the Ogre Wrapper was a simple task. We use Ogre API to implement all methods of the Renderer Adapter API. We have developed a sample application to test our architecture. The application is in charge of setting Ogre configuration and of sending input files url to the Scene Graph Adapter. The Scene Graph Adapter loads the appropriate format wrapper for each files. Format wrappers exchange data with the Ogre Wrapper to render the content of their input file. Figure 7 illustrates the implementation and figure 8 gives wrappers implementation details. In figure 9 we show the implementation state of the two wrappers.

10 http://www.feelingsoftware.com/ 3D-collada-tools/collada-tools.html

Generalization

At this state of development we can make new format wrappers to load other formats in Ogre without modifying the Ogre Wrapper. Similarly we can use the available format wrappers (X3D and Collada) in another application based on another rendering engine providing that firstly the application use the Scene Graph Adapter and that secondly an engine wrapper has been implemented for the rendering engine. It is also possible to make another X3D Wrapper that uses another parser, for example we can use Xiot11 instead of CyberX3D. One more possibility is to change the wrapper implementation. As explained in section 4.3 the Scene Graph Adapter provides two exchange modes between format wrappers and renderer wrappers. Indeed, we can take advantage of the rendering engine capacities and transmit more information to the renderer scene graph. We can for example delegate LOD management to the rendering engine and change the X3D wrapper implementation in order to send all levels of detail to the renderer wrapper.

We are also able to be compliant with new standards like WebGL. Several WebGL API already exist (SpiderGL12 , GLGE13 , Copper-Licht14 , etc.) on which a WebGL Wrapper can rely. The main difficulty consists in the C++ to Javascript communication, WebGL and all the aforementioned API are indeed javascript based. This point needs to be investigated.

Discussion

The key feature of the presented approach consists in enabling the rendering of any scene-graph-based 3D format in most of available rendering engines. We choose this approach in order to fulfill the interoperability issue among 3D formats without transcoding. However one drawback of this approach is the need of a wrapper instance for each input file. It increases the amount of memory used by an application based on the Scene Graph Adapter. A Format Wrapper indeed keeps an internal representation of the format scene graph at runtime. Nevertheless we have tested our sample application with two running modes:

1. a normal mode; i.e keeping internal representation as required by the Scene Graph Adapter architecture.

2. a lightweight mode; i.e deleting all format wrappers instances before rendering

We estimate the amount of memory used by the normal mode (1) against the lightweight mode (2) of +0,5% for Collada files and of +1,2% for X3D files. We use X3D files and Collada files of equivalent size to make this estimation. We give a result for each file type because the memory use of a format wrapper depends on the parser used in the Format Decoder; it is indeed this component that creates the internal scene graph data structure used by format wrappers. Besides we need to extend our implementation to fully evaluate our architecture.

Conclusion and Future Work

In this paper we have presented an approach to enable the loading of 3D files of different 3D formats in a single viewer using any available rendering engine. Our solution aims at developing components that can be reused in several applications and that can be mixed in order to fit any 3D application requirements. Our goal is to propose a solution to the current multiplicity of 3D formats as well as rendering possibilities and among them the WebGL standard. Indeed we think that the future of 3D on the web does not only depend on standards establishment but also in reusing existing contents and in increasing access to these contents. The Scene Graph Adapter tries to solve this problem. We plan to extend our architecture to other engines and mainly to a physics engine. We also want to investigate a WebGL-based rendering to make our solution compliant with this standard. On the input part of our architecture, we would like to enable inlines of files inside files of different formats. For example, create a X3D file with an inline node that linked a Collada file and being able to render it. Future work also includes handling interactions between files of different formats. Indeed it would be interesting to describe behaviors with X3D interpolators for objects encoded in Collada.

Figure 2 :

 2 Figure2: The Scene Graph Adapter (SGA) principle: to each node of a format scene graph, the SGA gives the corresponding node in every engine scene graph of the application. Similarly, to each node of an engine scene graph, the SGA retrieves the corresponding node in the format scene graph.

Figure 3 :

 3 Figure 3: The two tasks of wrappers: the adapter task and the adaptee task. Wrappers communicate from an adapter to an adaptee.

Figure 4 :

 4 Figure 4: The two exchange modes provided by the Scene Graph Adapter between a format scene graph and a renderer scene graph: a pull mode and a push mode.

Figure 6

 6 Figure 6 gives an illustration of how our architecture works for dynamic rendering. It shows how animations are managed by a format wrapper in order to run the animation described by the following X3D excerpt: < S c e n e > < T r a n s f o r m t r a n s l a t i o n = ' 3 3 3 ' s c a l e = ' 5 5 5 ' > < Shape > < S p h e r e / > < A p p e a r a n c e > < M a t e r i a l DEF= 'MAT' / > < / A p p e a r a n c e > < / Shape > < / T r a n s f o r m > < T i m e S e n s o r DEF= 'TIMER ' l o o p = ' t r u e ' c y c l e I n t e r v a l = ' 5 ' / > <ROUTE fromNode= 'TIMER ' f r o m F i e l d = ' f r a c t i o n _ c h a n g e d ' toNode = 'MAT' t o F i e l d = ' t r a n s p a r e n c y ' / > < / S c e n e >

Figure 5 :

 5 Figure 5: Sample sequences of static rendering through the Scene Graph Adapter (SGA) architecture.

Figure 6 :

 6 Figure 6: Sample sequences of dynamic rendering through the Scene Graph Adapter (SGA) architecture.

Figure 9 :

 9 Figure 9: Features implemented in the X3D wrapper and the Collada wrapper. The X symbol indicates that this feature has not been implemented yet, the O symbol shows features already available and the -symbol stands for features not available in the format.

Figure 7 :

 7 Figure 7: An implementation of the Scene Graph Adapter that loads X3D and Collada files and render them in Ogre rendering engine.

Figure 8 :

 8 Figure 8: Implementation details of the wrappers.

  ]. Most of them create a new format that can be run on a web browser through plugins; among them the most recent are Universal 3D[Standard ECMA-363 2007], 3DMLW[3D Technologies R&D 2009] and 3DXML[START_REF] Sons | Xml3d: interactive 3d graphics for the web[END_REF]]. The problem with these solutions is that users prefer not to use plugins because they find them inconvenient to install.

	The WebGL [Khronos Group 2011] solution does not rely on a
	plugin. It is a standard managed by the Khronos Group that enables
	declarations and interpretations of OpenGL ES 2.0 instructions
	directly in the javascript part of an HTML page. These instructions
	are then run using hardware capabilities of the client machine. This
	represents a huge step toward enabling a widespread use of 3D
	on the web. Latest versions of web browsers like Google Chrome
	included WebGL before the final specification was issued. It shows
	how much it is expected by the web community.
	Further work has been done with the X3DOM project [Behr
	et al. 2010]. The latest HTML5 specification mentions X3D as
	the reference format for 3D contents in XHTML document and
	X3DOM which is based on HTML5 enables the loading of X3D
	files in any web browser that supports WebGL without plugin
	installation. Through their open source framework and runtime,
	they overcome WebGL limitations by providing an adaptation of
	the rendering technique (native X3D, WebGL based or Flash).

http://www.radgametools.com/granny.html

http://www.havok.com/index.php?page= havok-animation

http://usa.autodesk.com/

http://www.ogre3d.org/

http://www.cybergarage.org/twiki/bin/view/Main/ CyberX3DForCC

http://www.boost.org/

http://forge.collaviz.org/community/xiot

http://www.spidergl.org/

http://www.glge.org/

http://www.ambiera.com/copperlicht/


Cédric Clévy

Arnaud Hubert

Joel Agnus

Nicolas Chaillet

A MICROMANIPULATION CELL INCLUDING A MI-CROTOOLS CHANGER

This paper describes the structure of a flexible micromanipulation cell designed to perform precise pick and place operations of objects with typical sizes from 20 to 500 µm. This cell is composed of three linear stages (X-Y-Z), a four degrees of freedom microgripper and a microtools changer. ¡

Introduction

Numerous of recent works concerning micromanipulation stations exhibit the growing needs of micromanipulators able to work automatically and flexible enough to be used for several kind of applications, notably in confined spaces (SEM or TEM chambers or more generally microfactories) [START_REF] Saito | Pick and place operation of a micro object with high reliability and precision based on micro physics under sem[END_REF].

In this aim, we have developed a micromanipulation cell composed of three elements:

• a commercially available three linear DOF micropositionning stage (for pick and place tasks, see figure 1-a),

• a four DOF piezoelectric gripper fixed on it and developed to increase the manipulation dexterity (section I),

• a new microtools changer which has been developed as a way to reach the flexibility required in microrobotic cells (see figure 1-b). The tools are here the end-effectors fixed at the tip of the microgripper (section II). The gripper is constituted by a monolithic piezoelectric actuator and a pair of tools made of nickel (figure 1-a and 3). Several kinds of pairs of tools are available depending on the size, shape or consistency of the object to manipulate (figure 2). The actuator is composed of two piezoelectric ceramic plates with a film of conductive glue between both. Four electrodes per finger are coated on the surface of these plates. Such designed (details are given in [START_REF] Lit | Analytical modelling and finite element analysis of a monolithic piezoactuator offering two uncoupled degrees of freedom[END_REF] and [START_REF] Agnus | Description and performances of a four-degreesof-freedom piezoelectric microgripper[END_REF]), each of both finger's gripper is able to move independently from the other vertically (+/-200 µm of stroke 2 ) and horizontally (+/-80 µm of stroke 2 ) allowing four degrees of freedom. These possibilities of the gripper are useful to perform dexterous micromanipulations (rotation or insertion of an object) or to correct the eventual missaligning of the tools due to the fabrication process. The measured (gripping stroke and first resonance frequencies) and the estimated by model (forces) characteristics of the gripper are:

¡ ¢ £ ¤ ¥ ¦ £ § § £ ¨© £ ¦ ¨© © ¨ £ ¨ © ¤ ¤ ¤ © £ ¡ ¢ ¢ £ ¤ ¥ ¦ § ¨© ¥ § § ¥ § ¨© ¤ ¢ © © ! " © ¥ ¤ ¤ ¤ ¨ # $ ¤ ¢ © © ! " © ¥ ¤ ¤ ¤ ¨ # $ ¤ ¥ § § ¥ % & ' ( ) 0 1 2 3 (a) (b)
• 320 µm of gripping stroke between the totally open and close position,

• 55 mN of blocking force (by finger in the Y direction),

• 10 mN of insertion force (Z direction),

• 1000 Hz of first resonance frequency for the grip motion (Y direction),

• 400 Hz of first resonance frequency for the insertion motion (Z direction).

Finally a user interface, developed with Borland Builder C++ allows to control as well the X-Y-Z stages as the four degrees of freedom of the gripper by using a joystick.

II The tools exchange principle

To develop a micromanipulation cell flexible enough to achieve a sequence of manipulation tasks, different strategies exist. As explained in section 1, different kind of tools are necessary in regard with the diversity of the objects to manipulate (shape, size, consistency). The first strategy consists in using several micromanipulation cells, each of them able to perform one kind of manipulation task. The second one is to develop a system able to change the gripper only. Finally, the last solution is to exchange only the tools. In regard with flexibility gains and the compact size available, the last solution is the best 1 Manufactured by the PI company. 2 Stroke given for a +/-100V as supply voltage. Based on the use of a thermal glue, the developed system allows to fix the pair of tools either on the actuator of the gripper or on a magazine (figure 3). The thermal glue used 3 is solid at room temperature and liquid at 65 ˚C and hundreds of liquefaction/solidification cycles are possible without loss of properties. The operating cycle of a microtools exchange is described figure 4 and allows the succession of two elementary micromanipulation tasks. The first one consist in making a pile of cubic parts (100 µm of side size) needing tools with a flat active side (figure 2). The second one is the pick and place of a micro gear (140 µm of cross section diameter) requiring a different kind of tools. The thermal glue is placed at the contact between tools and the actuator and also between the tools and the magazine. The liquefaction of the glue is generated by surface mounted devices resistances fixed at the tip of the actuator and on the magazine (figure 3).

" ¨¨£ # § © ¢ ¥ $ % " ¨¨£ # § © ¢ ¥ $ & ' & ' % ( ) 0 " ¨ ¥ £ ¡ ¥ ¡ ¡ £ " ¨ ¥ £ ¡ ¥ ¦ © ¤ ¨¨©
Experiments on this new system based on hundreds of automatic tools exchanges show a maximum position error between two consecutive tools exchanges of 4.2 µm, 2.8 µm and 5.4 µm on the X, Y and Z axis respectively with a distribution close to a gaussian distribution (details available in [START_REF] Clévy | A new micro-tools exchange principle for micromanipulation[END_REF]).

First experiments (thermal and degassing characterization) in a vacuum chamber has also been performed proving that this tools changer can be used in a vacuum environment. Moreover, 300 mN can be applied at the extremity of a tool before breaking the glue film. This value is higher than the gripping force (55 mN per finger) but lower than the maximum force before breaking the actuator (600 mN).

This micromanipulation cell is currently used to achieve assembly tasks with the adapted tools. The flexibility of this station enables a succession of different kind of tasks.

Conclusion

3 Commercially available under the name of crystalbond 555 HMP by Aremco Products inc. the gripper releases the pair of tools in the magazine firstly by cooling down the glue between tools and magazine and secondly by heating the glue between tools and actuator (3) reaching the position to take the second pair of tools (4) cooling down the glue between tools and actuator and heating the glue between tools and magazine (5) taking away the second pair of tools (6) manipulation of a circled section gear.

Composed of three linear stages, a piezoelectric microgripper and a micro tools changer, the micromanipulation cell is flexible enough to allow the succession of micromanipulation tasks. The four degrees of freedom skilled gripper permits the pick, place, rotate or insertion of an object from 20 to 500 µm in size. The microtools changer presents satisfactory enough characteristics (precision and thermal characteristics in a vacuum environment) to be used in very confined spaces such as in a SEM, TEM chamber or more generally in a microfactory.

To reach the goal of developing a fully automated and flexible micromanipulation cell, future works will focus on the integration of force sensors and vision capabilities.

Figure 1 :Figure 2 :

 12 Figure 1: Design of the micromanipulation cell: (a) schematic view of the three X-Y-Z axis micropositionning stage and four degrees of freedom microgripper (b) Focus on the microgripper and the tools magazine.

Figure 3 :

 3 Figure 3: Schematic view of the gripper and a part of the magazine.Here the pair of tools is fixed at the tip of the actuator.[START_REF] Winzek | Microgrippers with shape memory thin film actuators[END_REF]. For this reason, we have designed a tools changer able to exchange automatically the two tips (tools) of the gripper.Based on the use of a thermal glue, the developed system allows to fix the pair of tools either on the actuator of the gripper or on a magazine (figure3). The thermal glue used 3 is solid at room temperature and liquid at 65 ˚C and hundreds of liquefaction/solidification cycles are possible without loss of properties. The operating cycle of a microtools exchange is described figure4and allows the succession of two elementary micromanipulation tasks. The first one consist in making a pile of cubic parts (100 µm of side size) needing tools with a flat active side (figure2). The second one is the pick and place of a micro gear (140 µm of cross section diameter) requiring a different kind of tools. The thermal glue is placed at the contact between tools and the actuator and also between the tools and the magazine. The liquefaction of the glue is generated by surface mounted devices resistances fixed at the tip of the actuator and on the magazine (figure3).Experiments on this new system based on hundreds of automatic tools exchanges show a maximum position error between two consecutive tools exchanges of 4.2 µm, 2.8 µm and 5.4 µm on the X, Y and Z axis respectively with a distribution close to a gaussian distribution (details available in[START_REF] Clévy | A new micro-tools exchange principle for micromanipulation[END_REF]).First experiments (thermal and degassing characterization) in a vacuum chamber has also been performed proving that this tools changer can be used in a vacuum environment. Moreover, 300 mN can be applied at the extremity of a tool before breaking the glue film. This value is higher than the gripping force (55 mN per finger) but lower than the maximum force before breaking the actuator (600 mN).This micromanipulation cell is currently used to achieve assembly tasks with the adapted tools. The flexibility of this station enables a succession of different kind of tasks.

Figure 4 :

 4 Figure 4: Successive steps for exchanging tools: (1) manipulation of a cubic part (2)the gripper releases the pair of tools in the magazine firstly by cooling down the glue between tools and magazine and secondly by heating the glue between tools and actuator (3) reaching the position to take the second pair of tools (4) cooling down the glue between tools and actuator and heating the glue between tools and magazine (5) taking away the second pair of tools (6) manipulation of a circled section gear.