I am trying to convert a SVF using linked Revit files. I uploaded a zip to model derivative API which contains all the Revit files.
After conversion, the revit files are combined into one single SVF, but I discovered that at least some of the objects might be duplicated in a weird way.
For example, I have an object which have an unique attribute defined. When I select that object, I can see its position inside the model browser, as well as its properties. (Screenshot 1)
When I try to search in the whole model using that unique attribute, I discovered that another object has the same attribute and properties. When I try to select it using its dbId, I found that the object is invisible in the model, and it does not show where does it belong inside the model browser. (Screenshot 2)
Any idea why is there a duplicated object inside the SVF? Thanks.
Related
My model in Autodesk construction cloud contains several properties which I need to track. I have downloaded the sqlite file using fetch derivative download URL without any errors.
However when comparing export with what I see in ACC, or the Fetch all properties call, some properties are entirely missing. For instance, the fetch all properties call returns the 20 expected property values whereas only 3 of these values exist in the SQLite download. Any explanation why the SQLite file may be incomplete? There doesn't seem to any size restriction or filter in the call returning SQLite which may explain partial results.
It is expected that the design metadata returned via sqlite and via JSON may not be the same. For example, the metadata captured in the sqlite database use "instancing" where multiple design elements may inherit certain properties from another element (and the resolution of the inherited properties is left to whomever is reading this file). The JSON format on the other hand does not support any kind of inheritance, so properties are duplicated for each individual design element.
I have tried couple of methods loading a DWF model in Forge viewer (v7):
using Autodesk.DWF
translating using Derivative APIs
With both methods, the whole properties are combined together into one single Tab, although the initial model has separate tabs for item properties.
When I open the DWF file in Navisworks I can see those tabs.
I have also noticed when I downloaded the parts (after translating) the properties.db is 0kb but there is a section_properties.db file which has the data. the 'category' field (_objects_Attr table) for item properties is empty (except for internal Forge fields that start and with __)
Is there any way to preserve the tabs (categories) when translating the model?
Thanks,
Afshin
EDIT 1:
This is the image from Forge viewer, there is no category:
This is from original dwf file, same item selected, with properties id different tabs:
I have developed an application that gets the JSON object tree of a BIM 360 revit model's view, using the Forge Model Derivative endpoint, then downloads the SQLite PropertyDatabase to query properties of several object tree entities. That was working fine until now. Recently, I am having trouble with some models where the object tree derivative object ids don't match the PropertyDatabase object ids.
I have seen this post Temporary workaround for mapping between SVF1 and SVF2 IDs but this method is not valid in my case because my app works on the server side and not uses viewer API at all.
My question is: if there is a workaround using APIs from the server side, and if there are plans to solve this inconsistency between APIs shortly.
Unfortunately, this behaviour is expected with your approach. SVF and SVF2 do not share the same IDs, SVF2 IDs are optimised to process data faster and to try keeping them identical across versions. The article you make reference to is only working in the context of the Viewer, for server side processing you need to get the dbid.idx file to map IDs. This utility has a command to help you downloading the file. Try:
./forge.js version-svf2-idmap project_id version_id output_dbid.idx
This file is a gzip compressed file of a uint32 array.
What happened is that you did download the SVF SQLlite db using SVF ids. But when using the MD endpoints, you actually using the SVF2 ids because the target format is SVF2. If you did request a SVF target format, the MD endpoint would work with SVF ids. Unfortunately, you do not control BIM360 target format which could either be SVF or SVF2 depending of the source file format. For example, IFC, RVT, NWD, DWG are SVF2, but others are not. You can determine which format is used by reading the outputType and overrideOutputType. If overrideOutputType says 'svf2', then you should do the mapping.
The relevant code for the version-svf2-idmap is here
On the other hand, if you got the SQLite database, why do you need to call the MD endpoints, you got everything you need, and can extract the information much faster from there. See my example here. It has functions for properties extraction, and/or building the hierarchy tree.
Please let us know if you know.
I am having trouble getting the floor level and height when converting the NWD file to SVF.
If the RVT file is converted to SVF, the value can be obtained from the AEC data (the method below). Is there an alternative method?
"getDocumentNode().getAecModelData().levels"
I think you are right the feature of getAecModelData applies with Revit file only. If it is a Navisworks file, the level or room of Revit file has been extracted, and the related information is attached as properties of the objects. So you could use Search method of Forge Viewer to get out all objects in one level, and get their merged bounding box, which can be the value for the range of a level.
If the browser nodes name have contained some keyword with 'level', you could simply get out those objects in one level by their names. Similarly, get their merged bounding box, which can be the value for the range of a level. One sample is produced by our team, which is based on such model.
https://forge-rcdb.autodesk.io/configurator?id=5a7185a92a0a7aeb152725d5
The source code is available at Level Extension of RCDB Sample. It can also be a reference for you on how to get merged boundingbox, and how to view the level by sectioning feature.
I've been using the externalId to uniquely refer to objects in the forge viewer and connect them with outside data about these objects. This has worked well for revit files, which have a kind of GUID 86715290-fa28-4ff5-aef9-8c75d7c81e77-0012917b. Now I'm working with a Navisworks file, and their externalId use looks very different with values like a, 0 or 0/0/0/. How persistent are these, I can imagine not globally unique, but do changes/removals/additions keep them unique within the file? What is the suggested strategy to globally refer to solids in Navisworks files?
The external id of the path through the model selection tree to that element started from 0, see the snapshot below:
As I know:
In Revit case, it uses a unique id of the element (saying Element.UniqueId of the Revit API) as the externalId. However, the Navisworks doesn't have a concept unique id since it will have to handle different formats and some source models don't have unique id either. Therefore, it uses the selection tree path as the externalId instead.
Thus,
To preserve the identity information of the Revit elements, I would like to advise you to add a Revit shared parameter to store the value of the Element.UniqueId, and identify the element by this parameter.