Using the Autodesk Forge Model Derivative API, we've observed that for a few of our customers' models, the translation from RVT to IFC fails, after one or two hours of conversion.
Unfortunately these models are confidential, so they cannot be shared, but they are all above 250-300 MB (in Revit format). Is there a limit on the model size to be converted? I doubt that it's related to the upload itself, or the file being corrupted, because we have no problem with smaller files (~100MB), and all these models can be opened in Revit without any problem. (I've also checked for open source Revit sample models as test models, but they are all below 120 MB.)
Thanks for any recommendation on the subject.
Thanks to #EasonKang's help (and Forge support in general), the problem has been solved since the new release of the Model Derivative API (Autodesk Revit 2022.1).
Related
We are currently translating, downloading and viewing models within our application using the derivatives API, forge viewer, and targeting the SVF format. I am exploring doing the same thing using the SVF2 format but I have found evidence that this is not supported (for various reasons).
https://aps.autodesk.com/en/docs/model-derivative/v2/developers_guide/basics/preperation/
"...This means that SVF2 derivatives cannot be downloaded for offline viewing."
Wondering if this documentation is stale and this is actually possible now, or might be in the near future. I am looking for a concrete answer on this before I explore this any further. Thanks.
Currently there is NO public sample code that demonstrates how to download and view SVF2 in Forge Viewer. Only SVF1.
For SVF2, once you have figured it out (it's not that hard to download the 1000's mesh pieces), you'll need to host these mesh bits statically via the web-socket protocol. Finally, point Forge Viewer to your new host.
Don't forget to cache the viewer3d.min.js file, to comply with the EULA (found in the header). Since it's a cache, you'll need to show that the device can pull this file directly from Autodesk servers, when a cache flush occurs.
That's how I would do it.
We have a large .nwd model (1.6GB) that we are uploading directly to forge. I have hidden some elements in the viewer so only some of the elements are translated in the view to make it lighter. I am still having issues with SVF and SVF2 times to fully load the models on Forge. However I did a test on uploading to our hub on BIM360 and noticed it was significantly faster to upload and also the viewer renders the model a lot faster.
My question: Is it better to directly upload to the OSS on Forge or are there benefits in terms of load and rendering times to take the files directly from BIM360 via the Plugin integration workflow? Note: I am only considering upload and rendering times in this question and not other factors that could be beneficial to the end user.
BIM360 is built on top of Forge and it uses the exact same stack to store, translate, and preview your designs, so there should be almost no difference in loading and performance.
If you do see a significant difference in rendering performance, try the following:
open the model in your custom Forge Viewer app, and run the following command in the browser console:
NOP_VIEWER.model.isSVF2()
This should tell you whether your model really uses the SVF2 format.
open the model in another sample app, for example, https://github.com/petrbroz/forge-simple-viewer-nodejs (there's a branch called test/svf2 that is configured to load your models in SVF2), and see if the performance is the same
This should rule out any potential issues in your app's own code that could be affecting the performance.
I am currently developing a web application integrated with Autodesk Forge platform. Application is hosted on AWS. Basically, users upload their Revit files, the model is translated and rendered on the viewer, and the metadata is extracted and do some visualization. Small models (upto 200 MB) are able uploaded and rendered on the viewer within 60 seconds. But when I upload a large (1-2 GB) Revit file, it takes more than 5 minutes(which is not a good user experience) to translate and render on the viewer. Is there a way to make this upload and render process faster? What are the factors this translation speed depends on? Is this something to be addressed by optimizing my code? I looked everywhere for a solution but couldn't find any. Please advise.
Thank you!
To make upload task faster, we can make use of resumable upload to upload the big model in chunks parallelly: https://stackoverflow.com/a/70034186/7745569
Note. We're migrating to the direct-to-s3 approach of uploading/downloading files to Forge OSS service, so here are the migration references:
https://forge.autodesk.com/blog/data-management-oss-object-storage-service-migrating-direct-s3-approach
https://forge.autodesk.com/blog/upload-large-file-chunks-s3-signed-url-opennetwork-revit-design-automation
https://forge.autodesk.com/blog/direct-s3-nodejs-samples
https://forge.autodesk.com/blog/direct-s3-net-samples
https://forge.autodesk.com/blog/design-automation-api-using-aws-s3
For viewing performance, I would advice you to check out the svf2 format. It aids to resolved large model performance issues.
https://forge.autodesk.com/blog/update-svf2-ga-new-streaming-web-format-forge-viewer-now-production-ready
https://forge.autodesk.com/blog/model-derivative-svf2-enhancements-part-1-viewer
https://forge.autodesk.com/blog/model-derivative-svf2-enhancements-part-2-metadata
Can we access the data used by Revit Material Takeoff from forge viewer API?
For example, I have a wall (1 element) that have 2 layers:
And now I want to get the volume for each layer from BIM360 viewer API, in the same way I can in Revit Material takeoff.
Thank you,
Please always remember that the Forge viewer and environment is completely generic and not tailored towards any specific domain or functionality.
In the case of an architectural wall, Forge is mainly interested in displaying the entire wall element and managing the parameters and properties directly associated with that top-level element.
The material takeoff information you are interested in is part of the wall's internal compound structure. Managing and accessing that information is domain specific, architectural and structural, and thus beyond the scope of the Forge viewer.
I rather doubt that that information is accessible in Forge or the BIM360 viewer.
So, it will not be available via the model derivative API either.
However, you can certainly access this data via the Forge Design Automation for Revit API.
The details of such an approach are discussed in a previous thread
on how to get wall structure from Autodesk Forge metadata.
is there any way to revive data about what has been changed between versions (remove and add and modify):
via forge Model Derivative API, now I am able to get all the metadata of any Revit files but in total so I am not sure what elements added or .....
the problem we have a lot of files, and it's really hard to run a test to compare modes for each object
thank you :)
I am not aware of any built-in BIM360 or Forge functionaloity for obtaining that information.
I would suggest that you very clearly define exactly what information you wish to keep track of and determine how that can be obtained from a model, e.g., as you suggest, via the Forge Model Derivative API.
Then, you can create a snapshot of that data yourself and implement the functionality to track changes in it as you wish.
The Buiilding Coder discusses and shows how to solve the exact same task for Revit BIMs using the Revit API on the Windows desktop:
Tracking Element Modification
Implementing the TrackChangesCloud External Event
Those articles provide ideas and guidelines on some aspects to take into consideration addressing the same task in Forge.