I would like to to read my bim360 models which is in otg format in my Forgeviewer (version 7.3). The projects have been converted using the https://otg-bim.herokuapp.com/ app.
Is there any guidelines of how to make my Forge viewer read otg format from Bim360? I found this guideline (https://github.com/wallabyway/OTG-client-sample/blob/552c78b1fe8e1177f6694fd947a17fd189a8505b/public/js/ForgeViewer.js#L26-L29), however it uses Autodesk.Viewing.ViewingApplication which I find in version 2 of the Forge API, but not in version 7.3.
You can use this version of the ForgeViewer.js to work with latest versions of the viewer. https://github.com/jaimerosales/OTG-client-sample/blob/master/public/js/ForgeViewer.js
It seems that it is the same svn. Fault was that options requires autorization, even though I am allready autorized through bim360 login. Providing the access token there, uncomment useCookie and useCrentials and it works.
const options = {
env: 'FluentProduction',
api: 'fluent',
//useCookie: false,
//useCredentials: false,
accessToken: "add access token even though you are allready authorized in in bim360"
};
So far, I have seen a significant improvement loading using otg :-).
The latest version of svf2 works fine when using buckets instead of bim360. I have not vertified it with bim360. Example code which was helpfull for me was this npm package. https://www.npmjs.com/package/ng2-adsk-forge-viewer
Related
We have a Forge Viewer (GuiViewer3D, v. 7) implementation in our Nuxt app, using a few extensions (MarkupsCore, Measure, FullScreen) and custom docking panels such as a list of viewables to select from. Ever since we upgraded from Revit version 2021 to 2022, we haven't been able to display the 2D viewables from our svf files in the viewer. When we select any 2D viewable, the viewer freezes in this state:
With a few warnings thrown in the console:
Deprecated API usage: No “GlobalWorkerOptions.workerSrc” specified.
and
Warning: getOperatorList - ignoring errors during "GetOperatorList: page 0" task: "r: Cannot read properties of undefined (reading 'X')"
of which the former lead to this stackoverflow post, to which Augusto Goncalves suggested we tried uploading our revit file in your online viewer at https://viewer.autodesk.com/designviews. This works, and so we tried to create a new Nuxt app with a simple Forge Viewer implementation following the v. 7 example guide. This also works.
What we did next was to re-implement the v. 7 viewer in our production app by following the official documentation once again, thus removing any customization and leaving out everything else than the bare minimum. With this v. 7 viewer, running in a node environment on either node version 10.0 or 14.9, the bug persists, ruling out the possibility of any custom code being the cause.
Upon further debugging of scripts (loaded in via Autodesk) such as pdf.js, CompGeom.min.js, PDFLoader.js, path2d.js etc., we’ve gotten to a point where this message appears, and this is where our current trail ends:
TypeError: Cannot read properties of undefined (reading 'X') at c.strokeClipperContour (https://developer.api.autodesk.com/modelderivative/v2/viewers/7.*/extensions/CompGeom/CompGeom.min.js:17:173979) at https://developer.api.autodesk.com/modelderivative/v2/viewers/7.*/extensions/CompGeom/CompGeom.min.js:17:177686 at https://developer.api.autodesk.com/modelderivative/v2/viewers/7.*/extensions/CompGeom/CompGeom.min.js:17:177811 at Array.map (<anonymous>) at c.fill (https://developer.api.autodesk.com/modelderivative/v2/viewers/7.*/extensions/CompGeom/CompGeom.min.js:17:177413) at t.value https://developer.api.autodesk.com/modelderivative/v2/viewers/7.*/extensions/CompGeom/CompGeom.min.js:17:16067) at t.value (https://developer.api.autodesk.com/modelderivative/v2/viewers/7.*/extensions/CompGeom/CompGeom.min.js:17:9554) at e.beginDrawing (https://developer.api.autodesk.com/modelderivative/v2/viewers/7.*/extensions/PDF/PDF.min.js:39:211570) at t.value (https://developer.api.autodesk.com/modelderivative/v2/viewers/7.*/extensions/PDF/PDF.min.js:39:185323) at ttps://developer.api.autodesk.com/modelderivative/v2/viewers/7.*/extensions/PDF/PDF.min.js:39:158419
We cannot effectively debug these minified scripts, and are hoping you can provide some insight as to what might be causing this issue.
I have tried setting up Forge Viewer in headless mode using the following link: https://forge.autodesk.com/en/docs/viewer/v6/tutorials/headless.
I have hard-coded the URN and the access token but the model is not displaying.
Please provide any sample source code to load the model.
Here's a couple of tips:
Check the browser console. Perhaps the URN or the access token is incorrect, which is why the model does not load.
The link you're working with is for an older version of Forge Viewer (v6). I'd suggest using version 7.*. Try using this basic app as a starting point: https://github.com/petrbroz/forge-basic-app, and replace this line of code:
const viewer = new Autodesk.Viewing.GuiViewer3D(document.getElementById('preview'));
with
const viewer = new Autodesk.Viewing.Viewer3D(document.getElementById('preview'));
With this I've been able to load a model with a headless viewer:
I have a two-part WPF App and Revit Addin that runs a series of routines to create and activate a new BIM 360 project via the FORGE BIM 360 API, launches Revit and creates and sets up a collection of Revit models from a "seed" Revit model. The primary requirement is to have zero user interaction in this process: to be fully automated.
Given that background, I am having trouble linking the newly saved BIM 360 models to one-another. I have the option to do this either in the Revit Addin with Revit API hooks (preferred) or through the manager WPF App with FORGE API REST calls after the models are created.
Is either one possible?
I have successfully linked with the cached local models as described here and here. However, this does not meet the requirement fully, since when any other user (besides the automation machine user) opens the model the links are Not Found.
Screenshot of links Not Found.
Current "sort-of-working" code:
var wId = GetWorksetId(doc, w);
if (wId != null)
{
string localPath = settings.CloudModels.Where(x => x.ModelName == _linkModelNames[i]).Select(x => x.LocalFilePath).First();
ModelPath path = ModelPathUtils.ConvertUserVisiblePathToModelPath(localPath);
using (var options = new RevitLinkOptions(true))
{
using (var t = new Transaction(doc, w))
{
t.Start();
doc.GetWorksetTable().SetActiveWorksetId(wId);
using (var result = RevitLinkType.Create(doc, path, options))
{
_ = RevitLinkInstance.Create(doc, result.ElementId);
}
t.Commit();
linkPlaced++;
}
}
}
I was able to get the correct ModelPath via the Revit API thanks to this helpful tip. I can save this value in my Addin, close the model, and access the property later after opening a different model (saved in the CloudModels class referenced in the linq statement in the code snippet above). Unfortunately for me RevitLinkType.Create() that takes a ModelPath does not accept the cloud path, so I may have hit another dead end. Unless it is possible with an ExternalResourceReference. Has anyone tried this option? If so, how do you assemble a Revit ExternalResourceReference? I am not familiar with this process, and looking over this course from AU 2017, I don't see that it necessarily applies to BIM 360 cloud models. A BIM 360 cloud example would be very helpful if this is possible.
Alternate strategy: I do not see any reference to loading links in the FORGE Data Management API or other FORGE APIs. If I have somehow missed it, please share a link.
Any help would be very much appreciated!!
EDIT: I have since found these two (1) (2) similar questions that, at least for my purposes, were not answered satisfactorily. Any updates I should be aware of?
As of now (Jan 2020), unfortunately, we do not have a Link API for cloud models. It is on the roadmap.
Revit API 2022 docs mention that
The methods:
RevitLinkType.Create(Document, ModelPath, RevitLinkOptions)
RevitLinkType.LoadFrom(ModelPath, WorksetConfiguration)
have been enhanced to support creation of new cloud model Revit links.
You may use ModelPathUtils.ConvertCloudGUIDsToCloudPath() to
create a cloud path to use as an argument to these methods.
Additional Resource:
This Youtube Video showcases an example and its respective Github repo.
For Revit 2021 and below, you can use ExternalResourceReference() as a workaround, but I've noticed that this is not always reliable.
Its also mentioned in the documentation of InSessionPath property to not rely on this property:
Do not rely on this path (InSessionPath ) to look up an ExternalResourceReference, as the path is neither unique nor stable. It isn't unique because multiple servers might use the same server name and display name format. It isn't stable because some servers allow renaming, and because a server might change its name at some point.
Below is the code to do that:
var linkCloudPath = doc.GetCloudModelPath(); // the cloudpath of a BIM360 model
Guid linkedmodelguid = linkCloudPath.GetModelGUID();
Guid linkedprojectguid = linkCloudPath.GetProjectGUID();
Dictionary<string, string> Dictionary_ExternalResource = new Dictionary<string, string>(){
{"LinkedModelModelId", modelGuid.ToString()},
{"LinkedModelProjectId", projGuid.ToString()}
};
Dictionary<string, Guid> servers = new Dictionary<string, Guid>();
foreach (var service in ExternalServiceRegistry.GetServices())
{
if (service.Name == "External Resource Service")
{
IList<Guid> server_ids = service.GetRegisteredServerIds();
foreach (var server_id in server_ids)
{
servers.Add(service.GetServer(server_id).GetName(), server_id);
}
}
}
Guid BIM360ServerID = servers["BIM 360"];
ExternalResourceReference ERS = new ExternalResourceReference(BIM360ServerID, Dictionary_ExternalResource, "", "");
RevitLinkOptions options = new RevitLinkOptions(false);
LinkLoadResult result = RevitLinkType.Create(gcdoc, ERS, options);
RevitLinkInstance.Create(gcdoc, result.ElementId);
Please note that this seems to be working fine in Revit 2020, but not in Revit 2021.
I believe it is possible to create links to the Cloud Models in Revit 2019 or higher (with ModelPathUtils.ConvertCloudGUIDsToCloudPath()). You'll need the ProjectGUID and ModelGUID to make the cloud model path.
Regarding the ExternalResource approach, that also works - but it's super messy - you can read the properties associated with existing BIM360 links and you'll see how an ExternalResource is defined for BIM360 links.
Finally - as of today, the Forge Design Automation for Revit approach would not work for you at all:
1. Not possible to open a live cloud workshared model (only published/uploaded models).
2. No network access while you're running in a Design Automation for Revit session.
Good luck...
-Matt
My file is not being translated due to an exception:
Invalid value for 'role', must be one of '2d', '3d', 'graphics', 'manifest', 'thumbnail','Autodesk.CloudPlatform.PropertyDatabase','viewable', 'ifc'
I debugged the SDK and the role that is causing the exception is Autodesk.AEC.ModelData.
The file that I am trying to translate is the same I am used to translate in my application, so I think it is a problem in Forge PHP SDK.
Yes, this is most likely an issue with the PHP SDK for Forge being out-of-date. I see that you already submitted a PR to the codebase - I will contact the dev team to make sure the new role type is recognized properly.
I see the Viewer still uses 'AutodeskProduction' environment which uses Viewing Service v1, not 'AutodeskProductionV2' which uses Derivative Service v2.
I try 'AutodeskProductionV2' and see it fails (404 Not Found) to GET at /derivativeservice/v2/:urn
With Model Derivative API, we POST job at /modelderivative/v2/designdata/job, but the translated data still get(s) from /viewingservice/v1/:urn, not from /derivativeservice/v2/:urn
The OSS still map to /oss/v1, regardless of whether the OSS bucket is in v1 or v2.
When will we use the full version of v2 of Data Management and Model Derivative API? Thank you.
For the short answer, read the last paragraph.
i have been using my Node.js command line sample and cannot reproduce what you are describing.
I executed the following commands:
node forge-promise.js 2legged
node forge-promise.js bucketCreate cyrille20160916a
node forge-promise.js upload samples/Au.obj
-> get a response with location = https://developer.api.autodesk.com/oss/v2/buckets/cyrille20160916a/objects/Au.obj
node forge-promise.js translate Au.obj
-> get a response with urn = dXJuOmFkc2sub2JqZWN0czpvcy5vYmplY3Q6Y3lyaWxsZTIwMTYwOTE2YS9BdS5vYmo
node forge-promise.js translateProgress Au.obj
-> when I got a completed translation
node forge-promise.js manifest Au.obj
node forge-promise.js html Au.obj Au.test
-> here I generate a file using the recommended production server and latest viewer version 2.9
Using the https://developer.api.autodesk.com/viewingservice/v1/... is fine but not recommended for production. v1 in this case is unrelated to the REST API you are using for OSS or DM... it is the viewing service version, so you do not need to worry.
OSS version v2 is not available and should be preferred to version v1 (see documentation here for v2 OSS. You will see for example that it says https://developer.api.autodesk.com/oss/v2/buckets/.
Now the DataManagement API is versioned as v1 (i.e. https://developer.api.autodesk.com/project/v1/hubs) but that does not has any relation to the Model Derivative v2 API. v1 in this case only means that we have release:
OSS v2
Data Management v1
Model Derivative v2
and are the latest API available. With REST API, data is backward/forward compatible, only the REST call are versioned, but should work fine all together. For example and highly not recommended for future, you may decided to use the old viewing service v1 to start the translation, using OSS v2 or v1, and everything should continue to work today (as September 2016), but these 'old' API will be retired in future.
Now if you got a a problem with one or another API, maybe you can share with us a code sample / snippet, so I better understand the issue.
An error 404, means that the resource wasn't found, which can translate in multiple causes. For example a base64 encode string, a non urlencoded parameter - but with the new Model Derivative API (i.e. v2) when you post a translation job, and request the manifest immediately after, you will get a 404 error because the manifest does not yet exist. It would exist only when the translation Job has really started on the server. And depending how busy is the server, it can take many 'seconds' (up to a minute or two). I believe this is the issue you are facing, but if not please provide me a code sample.