iTwin - Issues with rendering of NWD files

[edgoks]

Hi guys,
I’ve been throwing lots of different files/filetypes etc at iModel to understand better what it can handle. One of the biggest worries/challenges that I’ve encountered is how well it copes with NWD files.

We’re hoping to be able to bring in federated NWD files as part of this programme (that’s the agreed format for the client to share), so it’s really vital for us to be able to consume them. These are often large files with many objects.

I’ve witnessed a couple of issues.

A. Peculiar rendering of NWD files
B. Failure to present any model at all

My assumption is that it’s to do with the complexity/size of the models I’m attempting to load.

I’ve managed to get around this for some files by converting them to dgns – which then load much better.
(Open in Navisworks, export as FBX, open in Microstation, convert to dgn) – I’m assuming this is the same kind of process that’s going on in the background?
Could it be that the processing of the files needs greater resources than are available and so are failing with lack of memory perhaps?

The report an issue details for the Connection run is:

{ "projectDetails": { "projectName": "iTwin-XXX", "iModelName": "26 v2", "enviroment": "PROD" }, "reportedJobRun": { "jobRunId": "36b7e266-cb60-4cb3-9276-242b26cb6b8b", "jobStatus": "Failed", "startTime": "2022-01-25T00:24:41.5092937Z", "endTime": "2022-01-25T00:25:42.3373192Z", "details": "Failed to orchestrate Run.", "triggerType": "Manual", "fileRuns": [], "errorCode": "RNE_BGS_1201", "projectId": "XXXXe-7d45-XXXX-b33a-09f2b1223911", "iModelId": "XXX-d2db-4XXX-9e45-25XXX59dc29", "connectionDefinitionId": "1cc60f1b-fad9-4592-837a-56932bb03b03", "dataLocationId": "d69db76c-eb42-435e-8bbd-33e62b4c4908" }, "jobDefinition": { "id": "XXXXXXX-fad9-4592-837a-56XXXbb03b03", "uniqueSettingName": "", "name": "A - raw federated file", "files": [], "repositoryType": "PROJECTSHARE", "repositoryUrl": "XXXXXXX-7d45-4369-b33a-XXXXXXX3911/folderId/FileId", "datasourceUrl": "XXXXXXX-7d45-4369-b33a-XXXXXXX23911", "iModelId": "005b1a72-d2db-484a-9e45-25960059dc29", "lastModified": "2022-01-25T01:23:50.509645Z", "userId": "XXXXXXX-2a38-41c7-b3e9-XXXXXXX7ff5ce", "isScheduled": false, "isSchedulePaused": false, "clientId": 2996, "scheduleInfo": null, "scheduledTimeUtc": null, "scheduleStartTimeUtc": null, "lastRunDetails": { "startTimestamp": "2022-01-25T00:43:07.8820925Z", "state": "Completed" }, "isDeletePending": false, "apiVersion": "v2", "version": "1.0", "executionStrategy": "NonAffinity", "createdTimeStamp": "2022-01-25T00:24:34.4203321Z", "bridgeParameters": { "embeddedFileBasenameRegex": null, "fileBasenameRegex": null }, "isActive": true }, "jobSchedule": null }

Thanks
Ed

[pmconne]

@jffmarker

[jffmarker]

I haven't been able to find the logs for the Connector run, so I've had to reach out to our cloud orchestrator team for assistance, and am still waiting.

[jffmarker]

For visibility, we are continuing to investigate this over other support channels. Logging has not been able to explain the issue yet, so we are working on analyzing the source data and iModel more closely.

[glenworrall]

Please be aware that NWD is also a "federated" file type and has some transformation of the source content.
Where possible publishing of the source model using the source connector would generally provide better results.
In this scenario a query of select * from bis.geometricelement3d results in >500K elements. I managed to locate these in the iModel and it showed that the gcs and the extents of the iModel were extremely large and the zoom extents was preventing the expected display.
The NWD was reprocessed against a dgn published gcs and the nwd was loaded as expected.
If the NWD looks like it has failed, but the changeset shows elements loaded, you can navigate down the tree to find a single element and then zoom to that element to find the area where the elements are.