google
Get the full version API
Is your feature request related to a problem? Please describe. Get the full version API, like 1.28.2
Describe the solution you'd like The version information is generally the basic API
Describe alternatives you've considered Version comparison, version analysis, problem reporting, debugging, etc
OS and backend It has nothing to do with OS and backend.
I don't quite understand what you want? Where do you need the full version number?
The version is updated too frequently, which may cause the external call binary library to be updated frequently.
Scenario 1: Manual replacement of binary may lead to misoperation
Scenario 2: There may be potential bugs in the new binary, leading to rollback of the old version before it can be used
Scenario 3: When the code of the new version changes too much, some things still exist in the last version, and the new version may disappear
........
With version output information, the above problems may be easily found during debugging.
I still don't quite understand what problem you would like to see fixed and how. You do not have to update to the latest version of Filament.
@ccworld1000 do you just want something like Engine::getVersion() that would return something like 1.28.2 (e.g. a string or struct)?
string or string_view or char *
You can decide for yourself.
The version number of the automatically updated version is added to the script corresponding to the release of a new version.
@pixelflinger
It feels that it can be output together with "FEATURE_LEVEL", so that you can easily identify the version number. It is also easy to identify other people's questions. For example, if there is a problem in the last version and the new version has just been repaired, you can easily locate it by looking at the version number.
Of course, it's no problem to only provide interfaces without output.
You can also decide for yourself.
@pixelflinger
We could also display the version number in the --help output of our command line tools.
It can also be extended to other ends For example, the web side can compare versions and support coexistence of multiple versions.
@pixelflinger @romainguy
Perhaps at the same time, you can discuss "MATERIAL_VERSION" internally. Replace "MATERIAL_VERSION" with a new version.
@romainguy @pixelflinger
No, we are not going to do this. The material version is independent of Filament's version number as the material version doesn't always change.
66.N.1 66.N.2 66.N.3 66.N.4 66.N.5 66.N.6 66.N.7 66.N.8 66.N.9
The actual version has changed. It is possible that N has not changed. If there are fluctuations in versions 1-9, they have actually changed.
The material version only changes when we make changes to the data structures used between shaders and filament (UBO). The current material version is 30 (it's a single integer, not a semver version number) and there have been 125+ versioned releases of Filament itself.
It seems that compatibility is not considered, forward or backward compatibility.
In fact, material versions can cross versions, unless there is no change in the corresponding part of the fluctuating version. Considering that the code has changed a lot and there are also human factors, whether to change it depends on your decision.
Filament will reject incompatible materials as a runtime error. Providing compatibility for older materials is something we could do but it would require (potentially) a lot of extra code for very little benefits. Note that all that's required is to recompile the materials. The source code of the materials is itself guaranteed to remain compatible.
We need a way to track the engine version. Yes would could inject meta data in our CI/CD, but we need the origin of authority to be Filament as found in GIT. This is unrelated to materials version.
@pixelflinger something like Engine::getVersion() that would return something like 1.28.2 (e.g. a string or struct)? Yes exactly this simple.
