Hi,
I am trying synchronize quite simple 3D model, but this error is reported during the synchronization:
ERROR [0x0000475c] iModelBridge - Project extents are too narrow: 0.000000 (ratio of largest footprint dimension to height; expected greater than than 0.100000). Element geometry this expansive will affect display performance, and often indicates corrupt elements or transforms.
I do not understand what is wrong and how DGN file should be corrected.
With regards,
Jan
Hi Jan,Not sure how the 3D model is created, but could you check if you have the correct geometry in the dgn.
Generally we have an issue that the 3D geometry is set to large or we have some outliers, but it looks like there it is a 2D flat model, is that the case ?
We do have ways of setting the extents, but for the z element, you may want to consider adding some height. I am going to guess that in this case we could downgrade the message to a WARNING rather than an ERROR
Hi Glen,
thanks a lot for your answer.
Glen Worrall said:Not sure how the 3D model is created, but could you check if you have the correct geometry in the dgn.
Unfortunately I am not author of the model, so I am not sure, but I guess it was done in a plain MicroStation., or maybe OpenRoads Designer. I do not see anything specific in the model, it's composed from SmartSolids mainly.
Glen Worrall said:Generally we have an issue that the 3D geometry is set to large or we have some outliers, but it looks like there it is a 2D flat model, is that the case ?
No, it's 3D model.
I was able to finish the synchronization, when I removed GCS definition (EPSG 5514) and moved the model to 0,0,0. Right now I am not sure what from these two modifications solved the problem, but I guess the movement to 0,0,0.
Unfortunately it's not applicable solution, because when models (civil 3D model in this case) are created in our state system, they are placed e.g. at -824909m,-1069967m,328m position. To move them to origin makes no sense, because different models from different sources have to be placed to real geographic areas.
Maybe these huge coordinates can cause the problem?
I am not allowed to share the original model, but I can create (not sure when I will find free extra time) simple 3D model with just a few object and can try to synchronize it.
Bentley Accredited Developer: iTwin Platform - AssociateLabyrinth Technology | dev.notes() | cad.point
One more comment...
The biggest object in model has its range:
So it's flat (6 meters height), but large (> 160 meters length), placed in big negative coordinates. Common situation for all civil projects in Czech Republic.
Regards,
The validation is based on width/height (x/y) vs. depth (z), not the absolute position. The intention is to detect very tall but narrow extents (e.g. bad geometry up in space), so a model that is very flat should not trigger this (the larger of width/height divided by depth will be a large number, not less than 0.1).
I think the bigger problem here is actually a crash in the MicroStation bridge. It seems related to converting the GCS information. I'll let the Connector team know about the crash. It is also quite possible the extent report is a red herring due to the incomplete conversion.
Answer Verified By: Jan Šlegr
Thanks a lot!
If there will be any need for testing with specific data, I am ready
Hi Jeff,
Jeff Marker said:It seems related to converting the GCS information.
I did a few more tests and it seems you are right about GCS:
Both tests were done with the same DGN file, where elements are placed in "correct" location (big negative coordinates). Target iModels had no limits assigned.
Fortunately, because we have one standard coordinate system in Czech republic only, to synchronize models without GCS assigned is possible. Even though it can cause troubles when GCS has to be assigned for any other reason in MicroStation (e.g. to reference data sources published in WGS84).