Solved

FBX with Mesh and ortophoto in Navisworks

sigtill
Rank
Badge +21

After a week+ of trial and error I wonder. Have anyone managed to create an FBX-file with FME that contains terrainmodel + ortophoto draped on top. That can be opened WITH materials/texture directly in Navisworks? I have tried all settings - but can not make it work. The files open correctly in FME Data Inspector, Autodesk FBX Reviewe, 3dsmax, Lumion and even Infraworks. And also the export from Infraworks to Navisworks work OK! However I cant seem to be able to open the FBX-file directly in Navisworks - it only shows the terrain with no texture/material. Even when it shows the texture in the "materials" pane. Material is added on a Mesh-group and displays nicely before writing and as mentioned in the other software above.

Some stuff I have tried:

- All settings on the FBX-writer

- Manually changing the scaleuints on the ASCII

- file from 1 to 100 to scale to meters instead of default cm.

 

It seems that there is some scaling issues between geometry / material or bug related to materials not connected to geometry, or problems working with real-life coordinates. Or something completely different. The strange thing is that the export from Infraworks to Navisworks works ok and when examining the header of the FBX I cant see any difference between that FBX and the one I generate with FME.

 

From Autodesk FBX Reviewer:

From Autodesk Navisworks, same FBX-file!:

icon

Best answer by daveatsafe 10 April 2019, 21:03

View original
The real SigTill

14 replies

daveatsafe
Rank
Userlevel 2
Badge +17

Hi @sigtill,

I think we should let out development team have a look at this problem. Would you mind sending copies of both the FME and Infraworks created FBX files (or download links if they are over 5 MB)?

sigtill
Rank
Badge +21

Hi @sigtill,

I think we should let out development team have a look at this problem. Would you mind sending copies of both the FME and Infraworks created FBX files (or download links if they are over 5 MB)?

Thanks - file is on FTP and Case: C144295 . Please bare in mind that this might be a bug in Navisworks - but, its very difficult to figuer out. Let me know if I can be of any help. I also asked on the Autodesk forum here. https://forums.autodesk.com/t5/navisworks-forum/fbx-with-mesh-and-ortophoto-in-navisworks/td-p/8721543 Thaks @daveatsafe !

The real SigTill
atle_hoidalen
Badge +3

Hi Sigbjørn,

This is a classical Autodesk Issue. Same model/format is handled differently within two different Autodesk software. I'm having the same issue myself, gone down the exact same path as you. Not only do you have the texture problem with fbx, but also unit problem. My "solution" was to export to Sketchup instead, open the file in Sketchup and then export to fbx. A fbx-file will be created toghether with a texture forlder. This will import correctly in Navisworks. However this method requires manuel work in addition to automating the progress in FME and that's not what we want...

Seems like Navisworks do not like the embedded texture model from FME so maybe there should be a choice to export fbx without embedding textures, but rather create the separate texture folder. I've tried setting "Embed textures" to "No" in the writer but it seems to have no effect.

sigtill
Rank
Badge +21

Hi Sigbjørn,

This is a classical Autodesk Issue. Same model/format is handled differently within two different Autodesk software. I'm having the same issue myself, gone down the exact same path as you. Not only do you have the texture problem with fbx, but also unit problem. My "solution" was to export to Sketchup instead, open the file in Sketchup and then export to fbx. A fbx-file will be created toghether with a texture forlder. This will import correctly in Navisworks. However this method requires manuel work in addition to automating the progress in FME and that's not what we want...

Seems like Navisworks do not like the embedded texture model from FME so maybe there should be a choice to export fbx without embedding textures, but rather create the separate texture folder. I've tried setting "Embed textures" to "No" in the writer but it seems to have no effect.

Yes, I have tried on numerous occasions to get Autodesk to reply (for instance this https://forums.autodesk.com/t5/fbx-forum/using-sdk-to-write-fbx-valid-for-navisworks-manage/td-p/9075324 ) but with no luck.

 

 

With FME you can have embed textures = no - and then the texture-files gets written in a subfolder - this seems to work nicely.

 

 

Also there is a change in FME2020 to support ASCII / binary 7.7 version of FBX. But it does not seem to fix this issue.

 

 

I was hoping the correct unit (meter, not centimeter) could be written to FME so that can solve the issue. However I wonder if there are some more issues with Autodesk - but there might be an easy way to test atleast.

If I remove some of the very small areas, and tile them into smaller tiles then some of them will have correct texture. I am thinking that Navisworks is more picky about each object being a proper Surface/Mesh where all the coordinates that are shared need to be 100% equal (so if you round them 0,001 wrong then the whole tile does not get textured).

 

 

For now I have given up Autodesk - and will try to see if they can support this again in 2020.

 

 

I have also tried to supply a "correct" fbx-file created with Infraworks to see if that can open OK in FME, but it does not seem to work. So there is definitely something here - however I just dont know how to solve it.

I was hoping that Autodesk could help by specifying how to write a proper FBX-file using the SDK (http://docs.autodesk.com/FBX/2014/ENU/FBX-SDK-Documentation/ ) - however this seems to be of no interest unfortunately.

Have had great support from Safe Software and @daveatsafe regarding this. Unfortunately I do not think it is possible to do anything without getting someone from Autodesk that knows the correct specifications of a file that can be opened with texture in Navisworks works.

 

I`ll put this on my christmaslist - for 2020!

The real SigTill
atle_hoidalen
Badge +3

Hello again Sigbjørn. I just spoke to Arne. I have a workaround that works. Before you write the fbx-file, use a feature writer to write the model to Sketcup/skp. Then use a feature reader to read the skp-file and then write out to a regular fbx-writer with "embedd textures=no". This creates the fbx-file including the texture folder. Voila, input the file into Navisworks and it reads the textures. Merry Christmas! ;)

PS: @daveatsafe, something to look into? Why does this workflow work and not when writing directly to fbx?

sigtill
Rank
Badge +21

Hello again Sigbjørn. I just spoke to Arne. I have a workaround that works. Before you write the fbx-file, use a feature writer to write the model to Sketcup/skp. Then use a feature reader to read the skp-file and then write out to a regular fbx-writer with "embedd textures=no". This creates the fbx-file including the texture folder. Voila, input the file into Navisworks and it reads the textures. Merry Christmas! ;)

PS: @daveatsafe, something to look into? Why does this workflow work and not when writing directly to fbx?

Thx @atle_hoidalen - just spoke with @geogaard . I`ll try it out today. The models are fairly large and detailed so I`m afraid the SKP-file will be to big - but we`ll see. I`ll post here once again when I get the result! Thx!

The real SigTill
sigtill
Rank
Badge +21

Hello again Sigbjørn. I just spoke to Arne. I have a workaround that works. Before you write the fbx-file, use a feature writer to write the model to Sketcup/skp. Then use a feature reader to read the skp-file and then write out to a regular fbx-writer with "embedd textures=no". This creates the fbx-file including the texture folder. Voila, input the file into Navisworks and it reads the textures. Merry Christmas! ;)

PS: @daveatsafe, something to look into? Why does this workflow work and not when writing directly to fbx?

@atle_hoidalen did you translate to "local origo" first or did you use real-world coordinates? Seems that the SKP-writer is taking its time to write anyting (10minutes with no action now) - I seem to remember it was quite slow on large dataset - but we`ll see if it finishes.

The real SigTill
atle_hoidalen
Badge +3

@atle_hoidalen did you translate to "local origo" first or did you use real-world coordinates? Seems that the SKP-writer is taking its time to write anyting (10minutes with no action now) - I seem to remember it was quite slow on large dataset - but we`ll see if it finishes.

Hi, I have tested both with a fairly large model and it is quite fast. However I do clip down the terrain model during the workspace, my example model ends up being 4 km2 in size.

sigtill
Rank
Badge +21

Hi, I have tested both with a fairly large model and it is quite fast. However I do clip down the terrain model during the workspace, my example model ends up being 4 km2 in size.

1m resolution on ortophoto. 800MB sketchupfile took 1h45min to create. Trying to read skp and write fbx now. Can say that the skp-file could not be viewed easily in Sketchup - so it might be too large.

 

Might have to move to local zero to get smaller filesize.

The real SigTill
atle_hoidalen
Badge +3

1m resolution on ortophoto. 800MB sketchupfile took 1h45min to create. Trying to read skp and write fbx now. Can say that the skp-file could not be viewed easily in Sketchup - so it might be too large.

 

Might have to move to local zero to get smaller filesize.

Wow, that is a long time. How large are the datasets you are using? I will also test with bigger data. I might be wrong but I find SKP to actually create smaller filesizes than identical models in FBX? I've exported fbx-models of terrain with sizes over 2gb from IW before, it takes some time but not as long as that.

sigtill
Rank
Badge +21

Wow, that is a long time. How large are the datasets you are using? I will also test with bigger data. I might be wrong but I find SKP to actually create smaller filesizes than identical models in FBX? I've exported fbx-models of terrain with sizes over 2gb from IW before, it takes some time but not as long as that.

The FBX of same area straight from FME (binary, 7,7 external texture) is 32MB fbx + 20 MB texture. So there is something strange.

The SKP-format does not like large coordinate values, so I might have to move to local x,y to reduce the number of digits.

The real SigTill
atle_hoidalen
Badge +3

The FBX of same area straight from FME (binary, 7,7 external texture) is 32MB fbx + 20 MB texture. So there is something strange.

The SKP-format does not like large coordinate values, so I might have to move to local x,y to reduce the number of digits.

Hm.. In my case the SKP-file is 107mb and the identical FBX is 151mb plus external jpg of 60mb. So yes, something is strange? Have you looked into the SKP writer parameters to see if anything is set up wrong there?

X

Hello @atle_hoidalen​ @Sigbjørn Herstad​ ,

I have exactly the same problem:

I would like a textured FBX with my aerial photos that I can import into Navisworks. Today I can do this with infraworks but it's a manual workflow. I would like to be able to automate this task via FME. Everything seemed to work, however my fbx are readable in all software except Navisworks...

 

Does your workflow with skechup writer/reader work? if so, could you detail your workflow?

If not, have you found another solution?

 

Thank you in advance !

 

sigtill
Rank
Badge +21

Hello @atle_hoidalen​ @Sigbjørn Herstad​ ,

I have exactly the same problem:

I would like a textured FBX with my aerial photos that I can import into Navisworks. Today I can do this with infraworks but it's a manual workflow. I would like to be able to automate this task via FME. Everything seemed to work, however my fbx are readable in all software except Navisworks...

 

Does your workflow with skechup writer/reader work? if so, could you detail your workflow?

If not, have you found another solution?

 

Thank you in advance !

 

Are you using Navis 2022? Haven't had the "opportunity" to work with this lately so cant see if there have been changes.

The real SigTill

Reply


Community Stats

28,731
Posts
109,530
Replies
36,567
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.