3D Models (FBX) never import to the correct location

[srksphillips]

Hi,

Whenever I import FBX model originating from 3DS Max into InfraWorks I have found that the model are always slightly rotated and offset. This means that the open pit models (quarries) I import do not line up with the terrain holes and always require rotation around Z and translation of the X and Y to get a best fit. Despite my best efforts they never align perfectly.

The odd thing is that the terrain, pits and terrain holes all originate from the same C3D drawing. I import the pits into 3DS Max using Civil View and report no 'Global Import Shift' in my 'Scene Settings'. All I do there is apply my textures and save to FBX.

I cannot confirm if this is an issue caused by 3DS Max as I am unable to import using 'AutoCAD Civil 3D DWG' or AutoCAD DWG (3D Objects); in fact these options have never worked on any of my machines. I have also tried importing the terrain holes in SDF and SHP format so I don't believe the issue is with the terrain holes.

I have tried shifting my 3DS Max model closer to the Origin and then shifting my FBX import accordingly but that changes nothing. 

Any ideas are welcome as I'm getting fed up of InfraWorks!

Cheers,

Steve

[srksphillips]

I have just imported the pits as an IMX file and I can confirm that the terrain holes are in the correct position and that the FBX imports are definitely in the wrong location.

[Karsten.Saenger]

Hello @srksphillips,

if you'd said you are working with Revit model I'd have said "yes, this is s know issue and it will be fixed".
But for FBX files I have not heard it before.

Is it possible to share the FBX files with me and the surface so that I can double check it in InfraWorks on my side?

I can create a support case for you so that you cann attach data directly to the case.

Regards,

Karsten

[srksphillips]

Hi Karsten,

Thanks you for the offer. I can send you test data to try out. Please let me know how to send to you.

Cheers,

Steve

[Karsten.Saenger · Accepted solution]

Feedback for the community:
The placement issue of the FBX file could be confirmed in InfraWorks 2019.1.

It is not existent in InfraWorks 2019.2, so everyone having the same issue should update.

Regards,

Karsten.

[srksphillips]

Thanks for your help Karsten - you're a legend!

[pricej]

Just following up on this. I am still having an issue with IW 2019.3. I have solids for long sheet piles modelled in a Civil 3D. When I import them they come in offset from each other even thought they abut each other in the dwg. I have split them in 10 or so separate drawings and each of them comes in in a different offset.

Opening in Navisworks 2019 shows them abutted neatly and in the right location. Connecting to the nwc’s that Navisworks created results in the same problem. Exporting to IFC then importing gives the same result. Very frustrating. Any ideas on what I can do?

[srksphillips]

---

---

---

@pricej wrote:

Just following up on this. I am still having an issue with IW 2019.3. I have solids for long sheet piles modelled in a Civil 3D. When I import them they come in offset from each other even thought they abut each other in the dwg. I have split them in 10 or so separate drawings and each of them comes in in a different offset.

Opening in Navisworks 2019 shows them abutted neatly and in the right location. Connecting to the nwc’s that Navisworks created results in the same problem. Exporting to IFC then importing gives the same result. Very frustrating. Any ideas on what I can do?

---

I have had similar problems with 3D models being corrupt or shifted in the past due to the 'rounding bug'. This is due to the reduced mesh accuracy the further the model is from the origin. This will be more apparent on a model that is mm accurate within a projected coordinate system such as UTM.

Try looking at this post: Import DXF corrupts/changes mesh

Essentially try shifting the FBX closer to the origin within the software you used to create it. Make a note of the shift and then export it out. Then when you import into InfraWork you just need to offset it back by flipping the x and y values.

---

[pricej]

That solves the issue, but what a pain. I wish they would fix this.

Thank you

[srksphillips]

---

@pricej wrote:

That solves the issue, but what a pain. I wish they would fix this.

Thank you

---

This isn't an Autodesk specific problem and I encounter this is many different software applications so I don't know if a fix will ever happen. This is why there are 'Local Grids' and 'Mine Grids' (the latter a mining-specific term). When your objects are close to the origin you have a huge number of available digits after a decimal place meaning that you can draw with extreme precision and accuracy. When you are hundreds of thousands of units away or more from the origin you have less precision as you have fewer or no digits after the decimal place. This is why it cannot accurately draw an object that is smaller than your main units e.g. mm.

I agree that it's a pain, especially if like me you were not immediately aware of the issue. If you use 3DS Max for instance, you can use Civil View and specify the offset on import. Failing that I usually save a text file in a visible location of my project to remind me or other of the offset value to use.

[Glenn.Coppard]

As others have said, it's a well known problem to the Autodesk / IW development team, and is a particularly embarrassing problem for us as Users / Clients to explain the 'technical challenges' to our Managers / Clients.

The fact that the three products we use, cannot share/coordinate/collaborate the content is a complete failure really.

Have a look through some of my older posts and you'll see a few workarounds we have used, none are 100% though.

@srksphillips original query.

I would change your workflow completely and share in the 'Terrain' (mine pits) as LandXML files or IMX's if they behave (never had any luck with those myself either), and apply the textures in IW itself from some coverage area's exported from the C3D model as SHP / SDF, then script the texture application.