METHOD FOR GENERATION OF A BINDING BETWEEN A C / C++ LIBRARY AND AN INTERPRETED LANGUAGE, AND IMPLEMENTATION OF THIS METHOD FOR THE TRANSFORMATION OF A THREE-DIMENSIONAL (3D) MODEL

Abstract

A method for generating a binding between 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 high-level language(s), comprising the following steps: - a step to write a definition of the binding (C) in the form of a high-level language, - a step to process this definition so as to produce binding elements, - a step to assemble the binding elements into each of the high-level language(s), so as to produce C++ binding code (D), and - a step to compile this C++ code (D) and link it to the C / C++ library (A). This method is particularly useful for developing human-machine interfaces for mobile land, air, or sea equipment.

Description

Detailed description of the invention 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: - figure 1 is a block diagram of an exemplary embodiment of a link generator or binding according to the invention; - figure 2 schematically describes a finalizer process (or “Finalizer”) implementing the linking method according to the invention; - figure 3 schematically describes a business application implementing the linking method according to the invention; - 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 - figure 6 illustrates a particular example of implementation of the connection method according to the invention in a multi-user configuration. Example of realization 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. We will now describe, with reference to figure 1, an exemplary embodiment of a method for generating a link (or binding) according to the invention. Step 1. The user of the binding 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#. The user writes the binding definition as a Python [C] program using the API of the binding generator (itself written in Python) which describes the library API [A] as it should be exposed to developers of the high-level language, by a list of functions as well as their expected parameters and returned values. 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 functionalities of each high-level language [B] (data management, their lifetime, data transfer between C++ and high-level language, specific paradigms). C++ features that are transparently supported by the binding and will be made accessible in the high-level language (STL / STD types) In parallel, the documentation is treated as a target high-level language [B2] and generates an XML file. 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. Step 4. The C++ code produced [D] at the generator output is intended to be compiled and linked to the third-party library whose functionalities are exposed. In parallel, the list of binding symbols can be augmented by the documentation written in step 1, thus producing an intelligible and more accessible reference than Doxygen documentation which is the state of the art of automatically generated C++ documentation. 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. 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], 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. 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. 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. 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. The generated binding can be used via a dynamic library (DLL) or a static library (embedded in the binary). This flexibility allows us, for example, to integrate Lua into a 3D model library without impacting performance or memory usage. We will now describe, with reference to 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. Through 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 conform to the designers' expectations. 2. If the finalizer module has received instructions to intervene in 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 which makes the interpreter execute a series of instructions. 3. If the Finalizer has received instructions to intervene in the transformation of materials, it has the possibility to redefine them entirely, to factor them, to assign them light and material processing algorithms (or shaders), to convert the image streams with the aim of making the data compatible and optimized for the on-board equipment. This modification is done via a callback which makes the interpreter execute a series of instructions 4. The finalizer module is invoked as many times as a 3D model or materials are processed by the high-level language 3D development tool. 5. When storing the 3D model, the finalizer module can choose the format most suited to the on-board equipment (binary, XML, Json, etc.). We will now describe, with reference to 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 on-board 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 given instructions into GPU primitives, 6. The 3D GPU graphics processor processes the GPU primitives and transforms them into video signals, 7. The on-board equipment screen displays the video signal transmitted by the GPU and therefore the HMI (1). We will now describe, with reference to Figure 4, the role played by the binding method according to the invention, in the different phases of design, production and operation. In the design phase, carried out on a computer or on board, we manipulate 3D models (A) coming directly from CAD tools. 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. We will now describe, with reference to 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. 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. With reference to Figure 6, the linking method according to the invention can be implemented in a multi-platform and multi-use environment: On-board device or smartphones: 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 Lua virtual machine that can 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 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. 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 making it work in "render less" mode, that is to say by disabling the image generator. We obtain the paradox of a real-time 3D imaging engine that calculates real-time 3D images but does not display them. This is a very useful feature. used in "massively online", where several client software 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 / / .un / C#. Computers or smartphones 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 computer Fast, compact business application with moderate interoperability requirements b. Smartphone Fast, compact business application with a strong need for real-time 3D imaging Web Client Side This is a recent development for "client-side" web applications (executed by the browser). Developing a business application 100% in C++ opens a first gateway to the WebAssembly / WebGL target. The Lua virtual machine, extremely compact (12,000 lines of C), offers a second gateway. 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. 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#. 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 various characteristics, forms, variants and embodiments of the invention can be associated with each other in various combinations to the extent that they are not incompatible or mutually exclusive. In particular, all the variants and embodiments described above can be combined with each other.

Claims

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, with a view to exposing 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 to generate a list of binding elements exposed to high-level languages, so as to produce a set of C++ functions 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 callback function written in high-level language, so as to extend its functionalities.

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 one of claims 1 or 2, characterized in that the definition of the binding comprises a list of functions, parameters expected for said functions, and returned values.

4. Method according to any one of the preceding claims, characterized in that the definition processing step comprises a distribution of the processing between: - functionalities of each of the said high-level language(s) [B], - C++ language features that are transparently supported by the binding and will be made accessible in the high-level language.

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

6. Method according to claim 5, 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.

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

8. 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, with a view to exposing the functionalities of said C / C++ library to said interpreted language, comprising: - means for processing said definition of the link or binding, previously written in high-level language and comprising a list of functions, so as to produce binding elements, - means for generating a list of binding elements exposed to high-level languages, so as to produce a set of C++ functions which are exposed to the high-level language(s), - means for compiling said C++ code (D) and linking it to said C / C++ library (A), characterized in that the binding generation means are further configured to allow the C / C++ library to call a function written in high-level language (calIback), so as to extend its functionalities.

9. Implementation of the linking method or binding according to one of claims 6 or 7 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).

10. Implementation of the linking or binding method, according to claim 9, for the transformation of 3D models originating from a C / C++ library (A) into 3D models suitable for being embedded in equipment within mobility systems.

Images