This project is a proof of concept of writing parser for X3D format using code generation based on standard definition in xml file. But this approach can be used for other formats or other languages. The code generation is not using the new Source Generators because this code is not dependent on existing code, but it's creating new code only based on the version of the X3D standard in the X3D Unified Object Model xml file.
So for ease of use the (mainly easy debugging) the code is generated on build of each project using the Generator and the new files are stored in Generated folder.
This allows inspection of codebase and debugging of the generator within single instance of IDE.
For now the use case is to investigate the use of code generation to create variants of a parser based on standard definition. To easy create and update hundreds of classes created based on standard and to create some common logic which requires knowledge about these hundreds of classes (e.g. prototype expansion or XML parser itself).
The project is a console application. Upon execution it searches for MyX3DParser.Generator.json files in the working directory (and subdirectories) and it generates the code based on this configuration file.
The generator can create 3 variants of the parser, based on the underlying math types. This is chosen mainly for performance reasons, since it prevents the need to convert data structures before use (e.g. in Unity).
Some code is expected to be present, see MyX3DParser.Shared for code shared between all variants. And some missing code which each variant fills in based on it's own specificities.
This allows to expect some methods to be there, which are then injected by each variant.
To improve performance, the code of each variant is not injected at runtime (e.g. via DI) but is kinda 'injected' already at compile time.
Some methods/properties need to be provided to even build the variant (each variant already handles all required methods), and some methods are specified via the partial keyword allowing optional definition at a later point.
But these extension have to happen at compile time, most likely in this repo structure.
Otherwise the shared/variant specific code would be missing, since the generator based on the configuration file currently does not generate the shared/variant specific code.
This use case is mainly intended to improve development of parser within this repo/solution.
It is not intended yet to be shared e.g. as nuget package where a project could define a config file and generate know code and fill in any extra functionality. Although this is considered as long term goal.
This variant (generated by the Custom value of the dataTypes config) creates codebase without dependency on any external library providing math types.
This variant (generated by the Numerics value of the dataTypes config) creates codebase where as many as possible math types are from the System.Numerics library.
This allows easy interop with other libraries using these types and has performance benefits for some targets (console and servers).
Demo where you can convert X3D to GLTF using the Numerics variant is available at Demo.
This variant (generated by the Unity value of the dataTypes config) creates codebase where as many as possible math types are from Unity3D.
This allows direct usage inside Unity3D. It also defines all operations in Unity's coordinate system, which means that there is no need for extra conversion from X3D space to Unity space.
Unity test project MyX3DParser.Numerics.Tests is available for testing the Unity variant and it's support scripts.
For more information about the X3D standard see the following links: