A clash check is unsuccessful when it fails or times out. The most common reason is because there is too much clash data, caused by:
Even if a clash check is successful, too much clash data can negatively impact performance. Signs that there is a large amount of clash data include:
If the latest clash check is unsuccessful, Model Coordination will show one of two error messages by the coordination space picker:
Error | Details |
---|---|
Can't display latest models | The clash check on the latest models has failed, so Model Coordination shows the models involved in the most recent successful clash check. This means Model Coordination could be showing older model versions, models that have since been deleted from the folder, or be missing newer models which are in the folder. |
Clash check unsuccessful | This means that there has never been a successful clash check in the coordination space. Model Coordination shows the latest models in the coordination space, but without any clash results. |
Most unsuccessful clash checks are due to an excessive amount of clash data. One way project administrators can reduce clash data is by removing duplicate or redundant content from the clash check:
If you have sub-folders containing duplicate or similar models to other folders in the coordination space (e.g. Consumed folders containing models from another Team folder), change the coordination space settings to remove the redundant sub-folders.
Other ways to reduce the amount of clash data include:
There are also various causes that can't be solved by reducing model numbers or size, or changing your coordination space setup. If these troubleshooting steps don't work, or you experience a spinner on the Clashes tab that doesn't resolve, the support team can investigate and help to resolve the error.
The Clash Settings page always shows the models involved in the last clash check, whether the clash check was successful or not.
If the last clash check failed, Model Coordination may be showing models from a previous successful clash check, while Clash Settings shows the models from the failed clash check. This would mean that Clash Settings shows a more up-to-date list of models than the rest of Model Coordination.
Data in the Clashes column will reflect the last successful clash check, even inside Clash Settings.
If you see this icon on the coordination space picker, it means that the clash check has processed successfully overall, but certain models couldn't be checked.
The specific models will be marked with the yellow warning icon next to the model's name in the Models and Clashes tools. These models do not show any clash data, because something has gone wrong when processing the models for clash.
This is often due to temporary problems and can be resolved by simply uploading the model again to Docs. Try this before attempting another solution. If reuploading the model does not solve the problem, then contact support.
This scenario only applies when all the following criteria are fulfilled:
A common example is a column or wall that extends through multiple levels, with a Revit view defined for each level. These kinds of objects can show as clashing against another object that they are not visibly touching due to the objects clashing in a different Revit view.
Clash in V2 coordination spaces uses the Revit master model view (all the geometry in the Revit file) instead of using the model geometry in each Revit view. We use the master model view to optimize clash performance.
Model Coordination clash is based on object IDs, and when an object spans multiple Revit views it will still retain the same object ID. Clashes in the viewer are then shown by highlighting the two objects (based on the object IDs). This can result in two objects which may not be visibly touching showing as a clash, due to these objects clashing in a different Revit view.
When a clash is noted as an issue or not an issue, all instances of this clash will be removed across multiple Revit views.
Previously, when navigating to the Clashes tab from another tab in the viewer, the camera orientation would reset to a plan view. Similarly, when selecting a clash in the viewer panel, or creating an issue or non-issue, the camera orientation would change to look from the South-East corner.
To reduce potential disorientation and loss of context, the camera now remains in its original, user-specified position by default. If you prefer the previous camera positions, use the ViewCube to change orientations as required.