The Model Derivative supports over 60 file formats from various desktop formats. The service is powered by various machines running optimized version of the various desktop file readers, which enable maximum fidelity when extracting viewables and metadata, accessible through Model Derivative and Viewer.
These various extractors, as expected, need updates from time to time. For instance, when there is a new version of Revit (and new version of .RVT format), there is a need for a new version of the extractor. Or even for other general patches or improvements.
To improve your application’s control over the extractor versioning, the Model Derivative team is introducing 3 options for POST Job endpoint when translating Revit files (other formats coming soon):
- Next: newest prerelease version
- Current (default): official release version
- Previous: last released version
{
"input": { "urn": " dXJuOmFkc2sub….yb2plY3QucnZ0" },
"output": {
"formats": [
{
"type": "svf2",
"views": ["2d", "3d"],
"advanced": { "extractorVersion": "previous|next" }
}
]
}
} And newly extracted files will have an extractorVersion in the manifest. This information helps you identify the version used and possible changes by comparing the manifest of different extraction processes.
{
"urn": "dXJuOmFkc2sub….yb2plY3QucnZ0",
"derivatives": [
{
"extractorVersion": "2024.0.2022.18",
….. How does it work?
Consider a scenario where current is v18 (as shown in the manifest sample above): the Revit team decides to make some improvements and, for that, prepare a new version, v19. That new version is then released into the next channel for at least 2 weeks. After all testing & validations are completed, v18 will move to previous, version v19 will move to current, and next will remain with v19.
For the above scenario, in case of unexpected break on your workflow with the newly released v19, your application can immediately switch to previous (v18) and keep working. Or you may decide to experiment with v19 using next before it is promoted to current.
Important behaviors:
- not all next versions will move to current, for instance in case issues are identified and some extra work is required.
- current may be updated directly, without coming from next, for instance in case of important security patch.
- previous will always keep the version that was on current, that way your application will always have this fallback.
What about performance?
Applications in production should always use current, which is default and does not require any change on existing code. Only this channel will have the expected performance level.
The previous channel can scale up to production level in case of increase in demand, such as applications needed to fallback to it. As it takes time to scale up, the performance will take several minutes to meet incoming traffic.
Last, the next channel is on-demand and intended only for testing & validation. Do not use in production environment.