I've been trying to get room information / geometry from a linked model, and I was able to get the geometry of the rooms on the "New construction" phase view, and nothing else on that view, like walls geometry from linked models. On the other hand,I get the geometry of these walls on the other views, but, for some reason, not of the rooms.
I need to see all geometry on the same view so I can keep up with the work. I've already tried to use the skipHiddenFragments:false on the loadDocumentNode options and calling the https://developer.api.autodesk.com/modelderivative/v2/designdata/job POST Api endpoint with generateMasterViews advanced option and x-ads-force header on the request, all of this with no luck.
In case you're using the SVF2 file format, try and see if the same issue happens when you convert the Revit model into SVF(1). I've seen a case where the combination of SVF2 and generateMasterViews was causing some issues, so I'm wondering if this could be something similar.
Related
I'm working on creating a forge viewer-based web system linking with my client's BIM360 environment. For the model data extraction part, I refered to the examples below.
(1) https://github.com/xiaodongliang/forgeviewer_embed_in_powerbi_report/tree/master/forge-model-properties-excel
(2) https://github.com/Autodesk-Forge/bim360appstore-model.derivative-nodejs-xls.exporter
However, I realized that the dbIds from the Forge Viewer and the sample codes are different. Is this the reason because of the SVF version discrepancies (i.e., SVF1 vs. SVF2)? If yes, any suggestion to resolve it?
Moreover, some models were not correctly processed when I tried to extract model data using the second example code (i.e., ForgeXLS.js example). The code was not processed after calling "prepareTables" function. It seems like it has issues to conduct "getMetadata", "getHierarchy", and "getProperties" functions. Could you let me know some possible reasons?
SVF version discrepancies
yes, the dbId of SVF is not consistent in all versions of the model. SVF2 dbId can be same in different versions, but the ideal is to take advantage of external id of the object. i.e. build a map from the first version of the model with external id. When you want to use dbId, search the dbId by external id
extract model data using the second example code (i.e., ForgeXLS.js example)
I'd believe it is just because the metadata / properties of the model version sis too large. you may try to add the header forceget when fetching the properties
https://forge.autodesk.com/en/docs/model-derivative/v2/reference/http/urn-metadata-guid-properties-GET/
I configured our viewer to use SVF2 format yesterday as per these instructions: https://forge.autodesk.com/en/docs/model-derivative/v2/developers_guide/notes/
I have observed that when selecting a node in the model, we get different Id's from SVF vs SVF2.
I usually pull the metadata and properties using the following GET calls:
https://forge.autodesk.com/en/docs/model-derivative/v2/reference/http/urn-metadata-guid-GET/
https://forge.autodesk.com/en/docs/model-derivative/v2/reference/http/urn-metadata-guid-properties-GET/
It has been mentioned here that the SVF2 Id's are computed differently, is there a way to get the Id's of a SVF2 model without loading it into the viewer first?
Apologizing for any inconvenience had caused. This is a known issue that our engineering team is evaluating, and we're hearing customers' voices. Could you consider providing your use case to SVF2 objectId with more details and the paint points you might have if the objectId between GET properties and viewer are inconsistent? Currently, there are two workflows that we're interested in as the below. Could you kindly point out which one your workflow is?
Normal workflow (GET properties -> Viewer), e.g., get dbIds(objectIds) by filtering properties with some conditions with GET properties, then partial load objects with LMV.
Reverse workflow (Viewer -> GET properties), e.g., select some objects in LMV, then post back to GET properties to get specific properties to store in DB.
Note. If the information you want to share cannot be posted publicly, please send it to forge[DOT]help[AT]autodesk[DOT]com instead. Meanwhile, please remove any confidential information and personal data from anything you want to share with us before sending it out.
Update 2021/07/21
Just to let future devs know that SVF2 is now GA, article is here.
My understanding was that the derivative properties were base on the PropertyDatabase. However it seems in Revit type parameters (as opposed to instance parameters), for example used in a custom family based on shared parameters seem to be handled differently.. They appear in the derivative properties of the {3D} view, but not in the PropertyDatabase. Why aren't they in the PropertyDatabase as well, where else is that information kept?
Whether you're accessing the properties via the GET :urn/metadata/:guid/properties endpoint, through Forge Viewer APIs, or any other way, the data is still the same.
You are correct though that the "inherited properties" are handled slightly differently. For example, in case of Revit documents, certain properties may be defined on the "family type" node, and it's up to the consumer of this data to make these properties visible on "instances" as well. It's possible that the Model Derivative endpoint handles this, including the family metadata in each instance as well.
Btw. we've recently discovered this issue in Forge Viewer's search function as well. When searching for a specific string, the method would only return "family type" objects as matches, but non of their instances. This is currently being addressed by the engineering team.
I use forge API in my application. I added an arcGis map to display the model using the methods from the post https://forge.autodesk.com/blog/dump-geometries-2d-curve in GEOMETRY_LOADED_EVENT.
When I work with small models, the data is displayed on the ArcGis map well, but info about layers are lost.
When the models are large, I get a very large data object(100mb + ) and my program does not work. Is it possible to save the model in threejs-friendly formats or to get a more compact object with model and layers data? Or are there still ways to display the model on the map? I would be very grateful for the advice.
I tried methods from the post https://forge.autodesk.com/blog/dump-geometries-2d-curve in GEOMETRY_LOADED_EVENT.
Not sure if this fits your use case, but I've been working on a tool for converting Forge models into glTF format (which is pretty three.js-friendly I'd say): https://github.com/petrbroz/forge-extract.
I am trying to hide the complete model in forge-viewer, for that I am calling forge visibility API as follows:
viewer.impl.visibilityManager.setNodeOff(viewer.model.getModelId(),true)
where viewer is a object of GUIViewer3D.
But this is not hidding the complete model, some components in the model are still visible.
I think it is a bug in forge-viewer because if I pass a root node of model to setNodeOff() API it has to hide whole model. I am sure that there is only one model loaded in my viewer session.
Refer this image for the elements which are still visible after calling viewer.impl.visibilityManager.setNodeOff(viewer.model.getModelId(),true)
getModelId() returns model IDs, and the visibility APIs expect node IDs. In order to hide the entire model, consider the following:
viewer.hide(model.getRootId());
Could you try something for me...
Could you try adding the header 'x-ads-force':'true' to the POST job request when you are converting the .RVT file?
Here is the documentation on the API request...
https://forge.autodesk.com/en/docs/model-derivative/v2/reference/http/job-POST/#headers
Then, retrieve the URN and feed it to the Forge Viewer, as before, like this example:
https://forge.autodesk.com/en/docs/model-derivative/v2/reference/http/urn-manifest-GET/#example
.
So... What's going on?
When you convert a RVT to a SVF (for the the Forge Viewer), it produces a random set of DBIds.
When you call the GetProperties API, it uses that cached SVF to pull the DBIds and provide you with a result.
Back in August, the GetProperty API engine, was updated. It produces a different order of DBIds compared to the old converted SVF.
Since the old SVF is cached, even if you submit a new job, it will use the old SVF.
To avoid the old SVF, we need to 'force convert' the RVT to SVF conversion, to flush that cache, so that the new SVF is visible and the Forge Viewer can retrieve it.
Once the Forge Viewer can see the new SVF, it should match the DBIds of the GetProperties API.
Complicated huh?
Let me know if that fixes the problem.
As my goal is to completely hide model from viewer, I achieved this by following:
viewer.clearSelection();
viewer.model.setAllVisibility(0);
viewer.impl.toggleGhosting(false);
viewer.impl.toggleGroundShadow(false);
This gives me the required behavior. The elements which I was not able to hide are now hidden through this approach.
to completely hide the model you can isolate an empty list, which will show the whole model ghosted, then you can turn off ghosting globally
viewer.isolate([]);
viewer.setGhosting(false);