3D Paths Issue

[TJ-OVERSITE]

I am trying to simulate crane lifts in my Synchro model and use the model in Unreal Engine via the plug in, the Synchro 4D model is working correctly, I have checked t he movement on BIC and it is simulating the rotations as I was expecting.
However, when I bring the model into Unreal Engine via the plug in, there seems to be something that sends the rotating object (crane mast and cabin) very far away from its original location.

Any support on ensuring the paths maintain their true location would be really helpful.

[GhisBntly]

Hi,
The only unsupported case that I am aware of is when some geometry used to center the crane rotation in SYNCHRO 4D Pro is not exported to the cesium tiles that we receive in the Unreal Engine plugin, for example when lines are used.
For any other situation, would it be possible to share a basic project showing the issue?
Please share with ghislain dot cottat at bentley dot com, thank you.

[TJ-OVERSITE]

Hi Ghislain,
I’ve added you to the project. I noticed the location data in the BIC iModel it opens zoomed out far beyond the model extent. Although this wasnt the case in my Synchro 4D model.
The Synchro model is centred using keyframe handles and locations. Please take a look and let me know if there’s anything I can do to fix it.

Cheers!

[TJ-OVERSITE]

@GhisBntly I think I may have found the issue.
The original file wasnt linked to the same geolocated file, synchro may have adjusted the 3D paths in the uploaded file to BIC.

Which is abit weird how it managed it in BIC, but I found the incorrect path location on in the uploaded Synchro path and I am awaiting on it to re-sync

[GhisBntly]

Thanks for the feedback!
I am stuck with Unreal build issues on my end and have not actually started investigating... -_-

[TJ-OVERSITE]

Unfortunetly @GhisBntly the repositioning and sync didnt fix my problem... -_-
When you do get an opportunity this issue is still open, thank you!

[GhisBntly]

Hi,
Even in the latest version of your project, I cannot locate the crane in the 3D view, even zooming on a single Element :-/
But I downloaded the SP file, deleted all 3D objects except OOC_TC05.glb, and uploaded the resulting SP file into a test project: I have to admit there has been a glitch the first time I loaded it (a concurrency issue between the various loading threads streaming the different kinds of data), as the animation was not working :-/
BUT I reloaded it a few minutes ago without doing anything else on the project, and now it is working:

crane-isolated.webm

So the problem is not related to the 4D animation and iTwin Engage.
I will test uploading the full original SP file to my test project: if it still works, it could mean there is a problem with the creation of the cesium tileset, or with the (geo)referencing of the iModel.

[TJ-OVERSITE]

@GhisBntly I am abit confused about the (geo) referencing of the iModel, as the rest of the model the steel beams are staying in location correctly.
It seems to only be an issue for the objects with 3D paths added to it.

2026-06-09.23-08-11.1.mp4

[GhisBntly]

Indeed, if georeferencing works for everything but 3D paths, there must be something to fix with 3D paths :-/
As expected, uploading the original SP into a new iModel "fixes" the huge extent and the 4D animation works:
https://github.com/user-attachments/assets/d5b8a1c0-d244-48d6-b5ff-6007dcdf928d

I will investigate the problem further in your iModel to try and understand why 3D paths fail there.

[GhisBntly]

Still, there is a problem either with the iModel or iTwin, or with the BIC viewer itself, as I am unable to focus on a selected Element:

Do you have to manually zoom in to the location in BIC, or is there another way I am not aware of?
Thanks,

[TJ-OVERSITE]

I have been having to manual zoom to the location, which is Old Oak Common Lane, London.
I am wondering if I am losing geolocated information by uploading changes offline potentially?

The Itwin video you sent earlier, did you just upload it into a new imodel and it fixed 3D path issue, were you able to turn on cesium and see the location in Unreal Engine? Did it hold its correct location?

[GhisBntly]

When I load your iModel in Unreal, the view briefly shows the correct location with the railtracks, then jumps to the middle of nowhere. I just noticed this error in the logs which certainly explain this:
LogITwin: Error: [ITwinAPI] Geographic conversion failed, geo-location for iModel Severfield Visualisation Model may be incorrect or imprecise
It happens when we use Bentley's conversion service to get the exact geographical location of the center of the project extents using the iModel's registered geographical projection:

• First, it looks like we are treating as an error what is merely a warning ("Out of useful range"). The center of the project extent is well inside the EPSG:9300 extents, but the iModel cartographic origin's latitude seen in the logs is indeed below the specified low boundary of 51.45 (from https://epsg.io/9300), which may explain the warning.
  LogITwin: Display: iModel cartographic origin: lg.=-2.29352766 lat.=50.21958743 H=52.45
• Also, the fallback in case of error seems to be incorrect...

When I ignore the warning and let the geolocation proceed, though, I still end up in the middle of the sea when I try to frame the crane in Unreal :-/ So, making some progress, but still not there yet...

[GhisBntly]

Forgot to reply to your question: no, my own iModel was not georeferenced, because the SP file does not contain that information.
But I don't think that you are losing the geolocation information by uploading changes since you are updating an existing geolocated iModel.

[TJ-OVERSITE]

@GhisBntly , if you go into the project I added you to, I have resolved the georeference issue. It seems to point at the right location now and isnt zoomed far away from the models.

However, now I am getting this error when loading it into the ItwinAPI.

[GhisBntly]

Geolocation looks correct indeed, no more geographical conversion warning/error.
I am getting the InfosToQueryIModel request errors as well: this happens when trying to obtain iModel Elements data from the remote iModel database, this is really unusual :-/ I will try to investigate. I see three new changesets in quick succession this morning, maybe some update tasks are queued, although it shouldn't take so long for this project which does not look that big (unless there's a lot of hidden geometry/Elements?)

The other error about the "latest" changesetId is a protection we added against trying to play the 4D animation on an older changeset: in earlier versions it was allowed, but mapping the tasks/resources to the Elements relies on IDs that may change from one changeset to the next, so the schedule is only guaranteed to work on the latest changeset. So when working with an iModel that has a schedule, you now have no other choice than using the string "latest" in the "changeset" field of the iModel actor. You can still use an old changeset to visualize an old version of the iModel, but the schedule should then be disabled (the logs show the 4D data starts loading nonetheless, that's because it loads concurrently, but it will not be applied).