I have a Revit file around 200MB. I am using forge SDK and below endpoint to extract manifest.
https://forge.autodesk.com/en/docs/model-derivative/v2/reference/http/urn-manifest-GET/
However, process of extracting manifest is taking a HUGE amount of time, which is longer than 30 minutes. How can I shorten this period and prevent timeout issues? Is there any configuration to extract manifest of large files?
SDK version: Assembly Autodesk.Forge, Version=1.9.0.0
Sometimes it can happen that you submit a conversion job at a moment when there are many other jobs queued, and the system hasn't auto-scaled up to the increased load yet. It could also be an issue with pathological designs which might be causing the extraction to take an unusual long time to process.
If the issue persists, please consider sharing one of your designs (confidentially - we would not share it with anyone outside of Autodesk) via forge (dot) help (at) autodesk (dot) com so that we could debug the translation on our end.
Related
Our customers would like to know what happens to their data, that is being processed by the Design Automation plug-in. As I understand, the input files are downloaded from the bucket and stored on the Design Automation VM instance while the plug-in runs. But what happens with input and output files when the job is finished? When and how are these resources erased? What happens to the VM itself? Also, could other service/program/user gain access to these files?
Secondly, is there a way to perform RVT->SVF conversion without using cloud services? Does Autodesk provide any desktop tool or API to do it locally?
Thanks in advance.
To the 1st question, in general, the Design Automation Cloud Sandbox will be destroyed as soon as the workitem is done, all the input and output files will be destroyed, that means there should be no other service/app could access these files after the DA workitem is done.
To the 2nd question, No, Rvt-Svf should be done by Model Derivative service, there is no local tool or API to do that from Autodesk at this moment.
After showing the house to the forge viewer using a Ravit file, the user wants to modify the contents of the viewer and receive it as a Ravit file again. What function should I use to implement the above?
https://learnforge.autodesk.io/#/
I referred to it.
my project
I make input data and transfer this to design automation and get output file and file to translate viewer (this is 2 minutes).
This process is very slow I want better then this process.
https://www.autodesk.com/autodesk-university/class/Its-Not-Too-Late-Automate-Using-Forge-Design-Automation-Inventor-2021#video
This video looks very fast on work process. How to get fast work process like this video?
Thank you
The Forge Viewer is a viewer, not an editor.
The Forge viewer displays the translated version of a seed CAD model, in this case, a Revit RVT BIM.
You cannot edit or modify the CAD seed file in the viewer.
To achieve such a modification, you have to either use the original modelling software, in this case, Revit on the Windows desktop, or you can use the Forge Design Automation API for Revit.
That is what was used to create the Inventor sample you refer to.
Oops... re-reading your question, I see that you are already using design automation yourself as well. Congratulations on that.
However, there is no guarantee on the turn-around time for this process. The video may very well have been edited to eliminate a waiting period, of the user creating the video may just have been very lucky to achieve a faster turn-around time.
I am checking for you with the Forge team whether they used any additional tricks to speed things up in the video or in the true real-time processing. They confirm:
For Revit, a basic DA job should take up to 30-40 secs for the processing time alone. The derivative job for translation to viewer format could take another minute. So, 2 mins is expected. The sketch it demo video has a timer on the side to indicate real time.
After switching over to SVF2 await aggregated.waitForLoadDone() sometimes blocks indefinitely. Unfortunately I can't reproduce the issue deterministically. It can happen right after starting my app, after loading/unloading models or not at all.
I did not observe this behavior previously, but I wasn't able to (ab)use the viewer like this until now (eg. rapidly switching between very large models, some half-broken). Kudos for SVF2, performance is mind-boggling.
My current workaround is to Promise.race the waitForLoadDone() and reject after 10 seconds. This is working ok and keeps my app in a consistent state.
I have a suspicion that the problem might be network related.
Edit: I narrowed it down to the property model.getData().loadDone which sometimes remains false forever.
Edit2: This is getting worse with every release. I'm now on 7.60 and the viewer constantly breaks. Some objects never load, websockets get stuck and don't transfer any data, users need to manually clean their browser cache. How can this possibly pass any QA?
I'm afraid that this could be - as you pointed out - a network issue. You may have noticed that the SVF2 format uses WebSockets to transfer the granular asset data to the browser, but if that persistent connection breaks, it's possible that the viewer wouldn't be able to recover.
Next time you see this happen, please check the console logs (and share them here if possible) and the network tab, to see if the WebSocket connection is still active. If it is, and the model still isn't loaded successfully, please submit a report to forge (dot) help (at) autodesk (dot) com with as much info as possible so that we can debug it on our side.
I tried to translate a big IFC file (150mb) for the veiwer and it took around 15 minutes only the translation without the uploading part. So is such translation time normal and can it be done something about it? I am currently using the free credits only for testing. Is there a performance increase with the paid credits?
The /modelderivative/v2/regions/eu/designdata/job is used with the advanced conversionMethod:modern.
No, there is no performance difference between trial and paid accounts. Forge dev account with a valid trial plan can use full Forge features as paid one as I know.
What happened after submitting a translation job?
After submitting a translation request and it returns success, it means that your translation request is sent to our service and has been put into the translation queue successfully. It doesn't mean that your model will be processed by our service immediately.
Instead, you have to line up! Since our service resources are limited and shared worldwide, you will need to wait for enqueued IFC translation jobs from other Forge users completed, and then our service will start to process yours. Therefore, waiting for 15mins is not slow from my perspective.
Starting a few days ago (Jan 10, 2018 to be really accurate...), IFC files converted to SVF format (using Autodesk Forge or directly uploaded to A360/BIM360) have lost their textures/colors and turned into dark grey.
Is it related to some (new) option in the viewer? or is it due to the conversion process itself which has been somewhat modified?
I have tried the same process with a Revit file (*.RVT), and the colors are preserved, so it might be related only to non-native files (just guessing).
The visualization of IFC files has worked very nicely for more than a year now, so it's a bit frustrating that the quality of the IFC rendering has been so much degraded in the recent days.
Thanks for any help!
This might be a known issue logged as NW-54041 in our internal case system. According to our engineering team, they have updated the IFC translator recently, maybe there is something changed after this upgrading.
It might take times to figure out what happened to this issue. You can track updates on this issue via sending the issue id to forge.help#autodesk.com in the future.
Apologies for any inconvenience caused.
For those looking for more information: Forge developers are currently [as of Jan 24, 2018] investigating the issue, as mentioned here:
https://forge.autodesk.com/blog/model-derivative-ifc-issues