METHOD FOR GENERATING A BINDING BETWEEN A C / C++ LIBRARY AND AN INTERPRETATED LANGUAGE AND EXECUTION OF THE METHOD FOR TRANSFORMING A THREE-DIMENSIONAL (3D) MODEL

Description

Field of invention

[0001] The present invention relates to a method for generating a link ( binding ) between a C / C++ library and an interpreted language.

[0002] It also aims at implementing this link generation process for the transformation of a three-dimensional (3D) model, in particular to be embedded in a human-machine interface of mobile equipment.

[0003] The field of the invention is that of human-machine interfaces, and more particularly human-machine interfaces embedded in mobility systems, whether land, air or sea. State of the art

[0004] A binding generator is a tool that allows you to efficiently perform the binding between a C / C++ library and an interpreted language. The challenge of binding is to provide access to the functionality / performance pair of a low-level language (C++) from a high-level language (Python, Java, C#, Haskell, etc.)

[0005] Generally, high-level languages ​​have lower performance than low-level languages. They are slower and / or consume more memory. On the other hand, high-level languages ​​free developers from many tasks, including memory management, such as creating and destroying objects.

[0006] High-level languages ​​are considered more accessible. They allow for faster delivery of functional results, making them ideal for rapid prototyping. Performance issues, however, exclude them from the industrialization phase. The need is therefore to have both the performance of C++ and the accessibility of high-level languages.

[0007] This problem is found in project management, particularly when designing a human-machine interface, which requires the joint contribution of hardware engineers using low-level languages ​​and business experts using high-level languages. The difficulty is to organize a methodology that is the synthesis of skills as diverse as they are antagonistic.

[0008] In particular, in the production of an interactive application with 3D content, one of the main challenges is to "translate" (convert) the 3D models from a CAD application into the proprietary format of the 3D engine in which the application is developed. This complex task lies at the intersection of the skills mentioned above. Business experts have knowledge of the functional and aesthetic objectives to be achieved, but their technical scope does not allow them to act in the industrialization phase. On the other side of the spectrum, low-level engineers have the technical skills in processing and displaying 3D data on an industrial platform, but do not have the necessary background to convert / translate 3D data in line with the business experts' objectives.There is therefore a gap between these professions which prohibits the creation of human-machine interfaces which comply with the functional and aesthetic objectives and the technical specifications imposed by industrial hardware.

[0009] Conversion / translation always results in a loss of information, and the 3D CAD model does not contain the "material" attributes necessary for 3D rendering. The palliative to bridge the gap mentioned above is to make adjustments after the translation is complete. This is the approach taken by solutions like Unreal Engine and Unity 3D, which consists of accumulating human resources and labor, especially near the end of the project. This practice, while admittedly working in the entertainment industry, is not suitable for the industrial sector.

[0010] We can thus see that there is no solution for creating a link between high-level and low-level languages ​​and, as a corollary, making it possible to synthesize multidisciplinary teams within industrial HMI projects.

[0011] Furthermore, there is currently a strong demand, expressed in particular by car manufacturers, for ergonomic, efficient and highly dynamic human-machine interfaces (HMIs).

[0012] SWIG is a state-of-the-art program for generating such bindings. It is open-source, freely available, and allows programs written in C / C++ to be linked to a variety of high-level programming languages. Target languages ​​include common scripting languages ​​such as Javascript, Perl, PHP, Python, Tcl, and Ruby. SWIG suffers from too much technical debt and uneven treatment of supported target languages. Thus, it is common for a desirable feature to be supported in only a few target languages, and sometimes in none at all, which is a significant handicap for integrating expert scripts into an automated 3D model conformation process.

[0013] Furthermore, if it proposes to fully automate the generation of the binding,In practice, we see that projects using SWIG require explicit intervention from the developer in order to correct the automatically generated non-functional code. The paradox is thus reached when the amount of code written to correct the erroneous generated code is significantly higher than what would reasonably be expected to achieve the expected level of functionality of the binding.

[0014] Furthermore, in the context of a project carried out by a multidisciplinary team, access to clear and concise documentation by business experts is an absolute condition for achieving the objectives. SWIG, since the advent of version 2.0, no longer offers this functionality. If the binding generated gives access to low-level functionalities from a high-level language, business experts and those capable of producing high-level code have no documentation and reference support for the exposed API.

[0015] Document US5083262A describes a method of language linking (“ binding language") intended for graphics functions, with the aim of allowing an application program to be used in different processing environments.

[0016] Establishing a language-specific link between high-level graphics application programs written in a specific programming language allows a graphics application program to be transported between and used in different graphics processing systems. A single portable graphics application program can be used with any of the graphics processors with which an application language link has been established to produce graphics on an output device.

[0017] CN101814024A discloses a cross-platform 3D interface design tool, mainly used for developing large-screen 3D human-machine interactive interfaces. The tool includes a system kernel capable of invoking system functions in a cross-platform manner, wherein the kernel supports the main functions of a current mainstream platform and can perform self-checking to find the difference between the system functions of different operating systems.

[0018] The combination of SWIG's legacy technology and its fragmented support for C++ features makes it extremely complicated and expensive to evolve and maintain. The few software alternatives to SWIG generally focus on a single target language and are much more limited in terms of supported C++ features.

[0019] Additionally, with the arrival of the new C++ standard (C++11), new language constructs have little or no support, and many configurations for using new C++ features are not properly supported by SWIG.

[0020] In the absence of a solution, in many human-machine interface design and development centers, the code of a 3D model generated by a CAD tool is rewritten to be able to embed it on a mobile platform. The use of a specific format inherited from the CAD environment for the storage of 3D data adapted to the constraints of the embedded system poses the problem of versatility and flexibility to cope with the constraints of an embedded environment.

[0021] The paper "Automated scientific software scripting with SWIG" by DM Beazley in the journal Future Generations Computer Systems 19 (2003) pages 599-609, discloses a method for generating a binding between a C / C++ library and one or more high-level interpreted languages, with a view to exposing the functionalities of this C / C++ library to this interpreted language; comprising a step for writing a definition of this binding in the form of a high-level language, a step for processing this definition so as to produce binding elements and a step for compiling the C++ code and linking it to the C / C++ library.

[0022] The paper "AutoWIG: Automatic Generation of Python Bindings for C++ Libraries" by P. Fernique et al, XP080950591, discloses a method for automatically generating bindings for C++ libraries.

[0023] The aim of the present invention is to propose a method for generating bindings, which makes it possible to combine the performance of a 3D library in C++ with the flexibility of a high-level language on embedded hardware. Summary of the invention

[0024] The invention is set out in the appended claims. This objective is achieved with a method for generating a binding between a C / C++ library (A) and a software environment of one or more high-level interpreted languages, in order to expose the functionalities of said C / C++ library to said interpreted language, comprising the following computer-implemented steps: a step for processing a definition of the link or binding (C), said definition having been previously written in high-level language and comprising a list of functions, so as to produce binding elements, a step for generating a list of binding elements exposed to high-level languages, so as to produce a set of functions in C++ which are exposed to the high-level language(s), a step for compiling said C++ code (D) and linking it to said C / C++ library (A), characterized in that the binding generation step is further configured to allow the C / C++ library to call a function written in high-level language (callback), so as to extend its functionalities.

[0025] The binding definition may also include a list of functions, expected parameters for those functions, and return values.

[0026] In a particular version of the invention, the definition processing step comprises a distribution of the processing between: features of each of the said high-level language(s) [B],. features of the C++ language which are transparently supported by the binding and will be made accessible in the high-level language.

[0027] The linking method according to the invention can also advantageously comprise a step for processing documentation attached to the C / C++ library (A) as a target high-level language (B2) and generating an XML file.

[0028] This method may further comprise, following the compilation step, obtaining a dynamic library (E) integrating the C / C++ library (A) and an interface layer compiled from the C++ code (A) resulting from the compilation step, and a static library (E) intended to embed the high-level interpreted language(s) directly in the C++ code resulting from the compilation state.

[0029] According to another aspect of the invention, there is provided a computer module implementing the binding method according to any one of the preceding claims, operating with a C / C++ library (A) and one or more high-level interpreted languages, in order to expose the functionalities of said C / C++ library to said interpreted language, comprising: means for processing a definition of the link or binding, previously written in a high-level language and comprising a list of functions, so as to produce binding elements, means for gathering said binding elements to each of said high-level language(s), so as to produce a C++ (D) binding code, means for generating a list of binding elements exposed to high-level languages, so as to produce a set of functions in C++ which are exposed to the high-level language(s), means for compiling said C++ (D) code and linking it to said C / C++ (A) library,

[0030] According to the invention, the binding generation means are further configured to allow the C / C++ library to call a function written in high-level language (callback), so as to extend its functionalities.

[0031] According to yet another aspect of the invention, an implementation of the linking method or binding according to the invention is proposed in a method of transforming a 3D model originating from a C / C++ library (A) with a view to being embeddable in equipment, in which a so-called business application is written in a high-level language (B) by importing a dynamic library (E) and by accessing through said dynamic library (E) the functionalities of said C / C++ library (A).

[0032] This implementation of the linking or binding method according to the invention may in particular concern the transformation of 3D models originating from a C / C++ (A) library into 3D models suitable for being embedded in equipment within mobility systems.

[0033] In the linking method according to the invention, translation rules are implemented, based on the needs of each project, so that the translation automatically gives the optimal result once the 3D models are transferred into the 3D engine. For the writing of these rules to be accessible to those skilled in the art ("graphic designer / integrator"), it is inconceivable to have to implement them in C++.

[0034] The linking method according to the invention can in particular take into account the language Lua which is a free scripting language well known to 3D model designers. which allows you to write translation rules in Lua.

[0035] The connection generator according to the invention is used to easily integrate the language Lua within all the tools of a 3 model transformation system.

[0036] The linking method according to the invention thus offers the developer the ability to describe in a simple way the “high level” interface that he needs and is responsible for automatically producing the C++ linking code as well as the resource management mechanisms.

[0037] The inventive generator method gives the developer in charge of the binding the possibility of implementing the functionalities of the target languages, language by language. The developer thus specifies what is exposed explicitly, unlike SWIG which attempts, but fails, to expose everything implicitly)

[0038] With a single description, the link generator according to the invention automatically produces all the bindings to supported languages. Adding support for a language therefore benefits all projects already linked.

[0039] The translation of a business application from one target language to another target language is almost direct and automatable, APIs (for “Application Programming Interface”) generated by the binding generator being strictly identical.

[0040] Documentation is considered a target language in its own right.

[0041] The binding generator of the invention supports conversion of C++ types (STD and STL), and provides access to modern C++ features. This generator allows exposing library-specific object types in a target language debugger.

[0042] In a high-level language, all data is encapsulated with an associated metadata. For efficiency in the occupation of RAM, these languages ​​offer the possibility of storing the data directly within the metadata. This mechanism is made accessible by the link generator according to the invention. The direct benefit thus obtained is a gain in performance, memory space and complexity (example: integers, floating points, vectors, etc.)

[0043] We want to be able to call a C++ function from Python or Lua, but we also want to be able to call a Python function or Lua from C++. The generator according to the invention implements this mechanism uniformly in all supported languages. It allows a person skilled in the art to extend the functionalities of C++ without having to know the implementation details.

[0044] An example is the implementation of an optical effect on the image that requires being able to be inserted precisely into the heart of an image rendering pipeline, with a callback from a finalizer module, and a callback from a real-time physics engine. The generated binding can be used via a dynamic library (DLL) or a static library (integrated into the binary).

[0045] This flexibility allows, for example, the integration of language Lua to the 3D model display and manipulation library, without impact on performance or memory usage and leads to the apparent paradox of being able to import Lua In Lua, which helps provide multi-core capabilities to non-C++ developers. Similarly, Lua is accessible to all Python developers. Detailed description of the invention

[0046] Other advantages and particularities of the invention will appear on reading the detailed description of implementations and embodiments which are in no way limiting, and the following appended drawings: there figure 1 is a block diagram of an exemplary embodiment of a binding generator according to the invention; figure 2 schematically describes a finalizer process (or “Finalizer”) implementing the linking method according to the invention; the figure 3 schematically describes a business application implementing the linking method according to the invention; the figure 4 is a block diagram of an overall transformation process implementing the linking method according to the invention; Figure 5 schematically describes an embedded graphics engine implementing the linking method according to the invention; and the figure 6illustrates a particular example of implementation of the connection method according to the invention in a multi-user configuration. Example of realization

[0047] These embodiments being in no way limiting, it will be possible in particular to consider variants of the invention comprising only a selection of characteristics described or illustrated subsequently isolated from the other characteristics described or illustrated (even if this selection is isolated within a phase comprising these other characteristics), if this selection of characteristics is sufficient to confer a technical advantage or to differentiate the invention compared to the state of the prior art. This selection comprises at least one preferably functional characteristic without structural details, and / or with only a part of the structural details if this part only is sufficient to confer a technical advantage or to differentiate the invention compared to the state of the prior art.

[0048] We will now describe, with reference to the figure 1 , an example of an embodiment of a link generation method (or binding) according to the invention.

[0049] Step 1. The user of the link generator according to the invention is in possession of a third-party C or C++ library [A] whose functionalities he wishes to expose to a language [B] such as Python, Lua or C#.

[0050] The user writes the binding definition as a Python [C] program using the binding generator API (itself written in Python) which describes the library API [A] as it should be exposed to high-level language developers, by a list of functions as well as their expected parameters and returned values.

[0051] Step 2. The definition of the binding [C], which does not depend on any specificity of the high-level language, is processed by the binding generator which distributes the processing between: the features of each high-level language [B] (data management, data lifetime, data transfer between C++ and high-level language, specific paradigms). the features of C++ that are transparently supported by the binding and will be made accessible in the high-level language (STL / STD types)

[0052] In parallel, the documentation is treated as a target high-level language [B2] and generates an XML file.

[0053] Step 3. The final step of the binding generator gathers the binding elements to each high-level language to produce the C++[D] binding code.

[0054] Step 4. The C++ code produced [D] at the output of the generator is intended to be compiled and linked to the third-party library whose functionalities are exposed.

[0055] In parallel, the list of symbols in the binding can be augmented by the documentation written in step 1, thus producing an intelligible and more accessible reference than documentation Doxygen which is the state of the art of automatically generated C++ documentation.

[0056] Step 5. The result of compiling [D] is, at choice: a dynamic library [E]. The library [E] integrates the library [A] as well as the interface layer compiled from [D] a static library to embed Python / Lua etc directly into the final C++ program.

[0057] The final step is the use of this binding. The user writes a "business" application in language [B] by importing the dynamic library [E] and accessing through it the functionalities of the library [A].

[0058] The binding generator of the invention gives the binding developer the ability to implement the target language features language by language. The developer specifies what is exposed explicitly, unlike SWIG, which attempts, but fails, to expose everything implicitly.

[0059] With a single description, the binding generator according to the invention automatically creates all bindings to supported languages. Adding support for a language therefore benefits all already linked projects.

[0060] The translation of a business application from one target language to another target language is almost direct and automatable, the APIs generated by the binding generator being strictly identical, which further increases the portability of projects developed in C++, the target language chosen at the start of the project no longer being a blocking point.

[0061] Furthermore, the binding generator according to the invention supports the conversion of C++ types (STD and STL), and provides access to modern C++ features. It allows exposing the types of library-specific objects in a debugger of the target language.

[0062] The generated binding can be used via a dynamic library (DLL) or a static library (integrated into the binary). This flexibility allows us, for example, to integrate Lua to a library of 3D models without impacting performance or memory usage.

[0063] We will now describe, with reference to the figure 2 , how binding operations are implemented in a model conversion process involving a so-called finalizer module. 1. Translating a 3D model from a C / C++ library automatically invokes a finalizer module. By a system of callbacks,the interpreter, which operates in parallel with the translation, invokes a set of functions implemented by a person skilled in the art, project by project, and which detail the transformations to be made so that the 3D models sent by the on-board equipment comply with the designers' expectations. 2. If the finalizer module has received instructions to intervene on the transformation of the 3D model, it has the possibility of modifying the morphology of the 3D model, its density, its orientation, etc. All these transformations must aim to make the 3D model compatible and optimized for the on-board equipment. This modification is done via a callback ( callback ) which causes the interpreter to execute a series of instructions. 3. If the Finalizer has received instructions to intervene in the transformation of materials, it has the possibility of redefining them entirely, of factorizing them, of assigning them light and material processing algorithms (or shaders), to convert image streams with the aim of making the data compatible and optimized for the on-board equipment. This modification is done via a callback (“ callback ") which makes the interpreter execute a sequence of instructions 4. The finalizer module is invoked as many times as a 3D model or materials are processed by the 3D development tool in high-level language. 5. When storing the 3D model, the finalizer module can choose the format most suited to the on-board equipment (binary, XML, Json, etc.).

[0064] We will now describe, with reference to the figure 3 , how a linking or binding method according to the invention is implemented in a process of transforming a 3D model from a development tool into a model embedded in equipment equipped with a human-machine interface. 1. We consider a human-machine interface designed by a designer and processed by the 3D development tool to be embeddable, 2. A business application provides the user of the embedded equipment with business functionalities, 3. An interpreter of the interpreted language runs the business application and exploits the functionalities of the C++ library, 4. A C++ library exposes, via an API, 3D, video and audio functionalities, 5. A 3D graphics driver exposes, via an API (OpenGL), the capabilities of a GPU graphics processor and transforms the instructions given into GPU primitives, 6. The 3D GPU graphics processor processes the GPU primitives and transforms them into video signals, 7. The screen of the embedded equipment displays the video signal transmitted by the GPU and therefore the HMI (1).

[0065] We will now describe, with reference to the figure 4, the role played by the binding process according to the invention, in the different phases of design, production and operation.

[0066] In the design phase, carried out on a computer or on board, we manipulate 3D models (A) coming directly from CAD tools.

[0067] In the production phase, also carried out on a computer or embedded, the 3D models are submitted as input to an FXB converter including a program written in C++ and integrating a finalizer module, a Lua linker module and a Lua virtual machine. The finalizer module executes conversion rules. The results of the FXB converter are 3D production data including models, shader algorithms, images and videos. These results are accessible via user scripts and plug-in modules. They are applied as input to a visual 3D development tool including a program written in C++ and including a Lua linker module and a Lua VM virtual machine. This C++ program is controlled by a Lua linker program. At the output of this C++ program, we have optimized 3D data adapted for optimized 3D embedded platforms.

[0068] We will now describe, with reference to the Figure 5, an example of the structure of an embedded engine implementing the binding method according to the invention. This embedded engine receives a business application as input. It includes a Lua virtual machine whose deliverables are embedded in a VM virtual machine whose output is connected to the input of a Lua binding module which feeds the input of a dedicated C++ core. This C++ core generates a 3D rendering system, a physics system and a scripting system.

[0069] This embedded module also contains a set of VM1-4 virtual machines, some of which are associated with user tasks. These virtual machines are also connected to the Lua link module.

[0070] In reference to the figure 6 , the linking or binding method according to the invention can be implemented in a multi-platform and multi-use environment: On-board device or smartphones:

[0071] The binding method according to the invention can be embedded in a vehicle or a smartphone. In this use case, a C+ API is used and the business application is implemented in C++. However, thanks to the binding, the 3D development tool still integrates a virtual machine. Lua who knows how to execute micro scripts (or even more complex scripts), which are generally used to set visual elements in motion. a. Smartphone Application using real-time 3D, intensively or mixed with other elements, such as a visualization of 3D objects in augmented reality. b. Automobile Application using real-time 3D intensively to replace all or part of physical equipment (infotainment, cluster, etc.) Computers or web applications

[0072] The binding method according to the invention, which offers a direct gateway to Python, allows the rapid development of complex 3D applications without requiring in-depth knowledge of low-level real-time 3D APIs.

[0073] If the entire business application is written in Python, using Lua in parallel is possible / recommended, depending on the nature of the tasks and the expected performance. a. Desktop Written in Python, the application is advantageously portable on all reference platforms (Windows, OS X, Linux). It is the ideal format for developing business applications running directly on a conventional workstation b. Server The modularity and portability of the C++ 3D engine / Python business application pair offer the possibility of operating it in "render less" mode, that is to say by deactivating the image generator. We obtain the paradox of a real-time 3D imaging engine that calculates 3D images in real time but does not display them. This is a very common feature in the "massively online" world, where several client software programs connect to the same server and must find the same simulation there. Python is again perfectly suited to the development of a "server-side" application. This functionality is available under Unreal engine, in C++ only, and under Unity3D in C# only.The software environments implementing the linking method according to the invention open this functionality to C++ / Python / Lua / C#. Computers or smartphones

[0074] The binding method according to the invention is particularly suitable for a high-performance and compact application on a desktop computer or smartphone / embedded device, while offering maximum accessibility to developers via Binding & Lua. a. Desktop Fast, compact business application with moderate interoperability needs b. Smartphone Fast, compact business application with high real-time 3D imaging needs Web Client Side

[0075] This is a recent development for "client-side" web applications (run by the browser or browser). Developing a business application 100% in C++ opens a first door to the WebAssembly / WebGL target. The virtual machine Lua,extremely compact (12,000 lines of C), offers a second gateway.

[0076] Compiling C++ to WebAssembly is a very recent technology. It's an assembler language for a virtual CPU target. Consensus on the specifications for a common platform for major web browsers (Firefox, Apple, Google, Microsoft) was just validated in March 2017.

[0077] Due to the compactness and portability of its C++ source code, the linking method according to the invention and its implementation for model transformation constitute an ideal technology to operate in WebAssembly. The major issue is the size of the binary. To date, the WASM binary of a C / C++ library used with the linking method according to the invention represents 5 MegaBytes. For example, that of UnrealEngine represents 35 MegaBytes. In WebAssembly, Unity3D must be limited to a subset of the functionalities present in C#.

[0078] Of course, the invention is not limited to the examples which have just been described and numerous adjustments can be made to these examples without departing from the scope of the invention. Of course, the different characteristics, forms, variants and embodiments of the invention can be associated with each other in various combinations insofar as they are not incompatible or mutually exclusive. In particular, all the variants and embodiments described above can be combined with each other.

Claims

1. Method for generating a binding between a C / C++ library (A) and a software environment of one or more high-level interpreted languages, in order to expose the functionalities of said C / C++ library to said interpreted language, comprising the following computer-implemented steps: - a step of processing a definition of the binding (C) between the C / C++ library (A) and a software environment of the one or more high-level interpreted languages, said definition having been previously written in high-level language and comprising a list of functions as well as the expected parameters thereof, and the returned values, so as to produce binding elements, this step comprising a distribution of the processing between: - functionalities of each of said high-level language(s) [B], - functionalities of the C++ language that are transparently supported by the binding and will be made accessible in the high-level language. - a step of gathering said binding elements towards each of said high-level language(s), so as to produce a C++ binding code (D), - a step of compiling said C++ code (D) and linking it to said C / C++ library (A). this method being implemented in a transformation of a 3D model from the C / C++ library (A) in order to be embeddable in a human-machine interface of a device, wherein a so-called business application is written in a high-level language (B) by importing a dynamic library (E) and accessing, through said dynamic library (E), the functionalities of said C / C++ library (A).

2. Method according to claim 1, characterized in that the definition of the binding is written in the form of a high-level language program using an application programming interface, API, describing the API of the library (A) as it is to be exposed to developers of said high-level language.

3. Method according to any of the preceding claims, characterized in that it further comprises a step of processing documentation attached to the C / C++ library (A) as a target high-level language (B2) and generating an XML file.

4. Method according to the preceding claim, characterized in that it further comprises, following the compilation step, obtaining a dynamic library (E) integrating the C / C++ library (A) and an interface layer compiled from the C++ code (A) resulting from the compilation step.

5. Method according to the preceding claim, characterized in that it further comprises, following the compilation step, obtaining a static library (E) intended for embedding the high-level interpreted language(s) directly in the C++ code resulting from the compilation state.

6. Computer module implementing the binding method according to any of the preceding claims, operating with a C / C++ library (A) and one or more high-level interpreted languages, in order to expose the functionalities of said C / C++ library to said interpreted language, comprising: - means for processing a definition of the binding, previously written in high-level language and comprising a list of functions, so as to produce binding elements,- means for gathering said binding elements towards each of said high-level language(s), so as to produce a C++ binding code (D), - means for compiling said C++ code (D) and linking it to said C / C++ library (A), - means for generating a list of binding elements exposed to high-level languages, so as to produce a set of C++ functions that are exposed to the high-level language(s), characterized in that the definition processing means are arranged to distribute the processing between: - functionalities of each of said high-level language(s) [B], - functionalities of the C++ language that are transparently supported by the binding and will be made accessible in the high-level language. this module being further intended to implement said binding method in a transformation of a 3D model from the C / C++ library (A) in order to be embeddable in a human-machine interface of a device, wherein a so-called business application is written in a high-level language (B) by importing a dynamic library (E) and accessing, through said dynamic library (E), the functionalities of said C / C++ library (A).

7. Implementation of the binding method, according to any of claims 1 to 5, for transforming 3D models from a C / C++ library (A) into 3D models suitable for being embedded in devices within mobility systems.