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)?
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 !
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.
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!
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?
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!
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.
@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.
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.
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.
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 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?
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 !
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.
