Community
Navisworks Forum
Welcome to Autodesk’s Navisworks Forums. Share your knowledge, ask questions, and explore popular Navisworks topics.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Smart3D VUE Plugin

8 REPLIES 8
SOLVED
Reply
Message 1 of 9
Anonymous
3116 Views, 8 Replies

Smart3D VUE Plugin

We have quite an issue with the Smart3D VUE Plugin for Navisworks. The plugin uses and installs the 64-bit version of the Microsoft Access Database Engine regardless the Office version already installed. Microsoft Office does not support mixing modes and several features in Office breaks following the installation, i.a. Excel and Outlook. We could switch to x64 versions of Office, you might say, but this is where it gets tricky. Smart3D does not support x64 Office - only x86. Fixing a plugin that reads Smart3D exports by breaking Smart3D - the very program producing the files is awfully close to being a Catch 22. Any suggestions?

8 REPLIES 8
Message 2 of 9
Patrick_Aps_9121
in reply to: Anonymous

Export on a computer with 32-bits office

and Import the Vue file on a computer with 64-bits office.

would be the obvious suggestion

Message 3 of 9
Anonymous
in reply to: Patrick_Aps_9121

That is indeed the/an obvious method and in fact roughly the workaround we use, by having an array of VMs without Office running Simulate and by way of a file system monitor, feeds Simulate with files automatically when dropped to those systems. This is a workaround and certainly not the optimum solution. We have way too many users for that.

Message 4 of 9
dgorsman
in reply to: Anonymous

Which version of Office are you using?

----------------------------------
If you are going to fly by the seat of your pants, expect friction burns.
"I don't know" is the beginning of knowledge, not the end.


Message 5 of 9
Anonymous
in reply to: dgorsman

We use Microsoft Office 2010 x86 on Windows 7 x64. We are currently in the process of rolling out Office 365 but still in x86 version due to compatibility with other applications. We are 13,000 employees with literally thousands of applications that interact in countless ways, so there is a balance to keep :-). Unfortunately Navisworks is only one tiny piece in the puzzle, if not (at least from my standpoint) a quite important one.

Message 6 of 9
Patrick_Aps_9121
in reply to: Anonymous

I would have only one special computer set up to convert the VUE files with data into an NWD

and then have all the other users open or append that NWD to the overall Collaboration model.

That one special computer may even to that conversion scheduled or only when a new version of a VUE model arrives.

In that way, you do not need every user world-wide to have the VUE reader and the right Office version installed.

 

Message 7 of 9
Anonymous
in reply to: Patrick_Aps_9121

That is exactly the workaround we have. It is fully automated (the pains of that setup caused by a bug in Simulate 2017 can be read elsewhere on this forum) but still instills some issues:

 

  • We lose traceability by having Simulate running in a service account
  • The service account needs to have excessive permissions to have access to all project files
  • The computer array is a bottleneck
  • Simulate does not handle errors very well when running headless
  • There are no ways for users to change parameters (F12)
  • Conversions take a long time making it unviable for quick checks when users combine 3D models from different systems

There are two scenarios that are covered by this method:

 

  • Conversion of single files simply by dropping them in a shared folder. They are picked up and converted to NWD and returned to the sender.
  • Scheduled conversions that run more complex jobs that may include VUE files.

It certainly works but definitely not user friendly. We have a rather sophisticated queuing system we made our ourselves some years back that we are opening up now for new features. A system that can handle some of these problems. For some reason, however, the VUE plugin causes errors when accessing Simulate via the API. That's another story entirely.

Message 8 of 9
dgorsman
in reply to: Anonymous

2010 Office in x86 does indeed have some problems, and we had similar problems.  That was one of the driving forces for updating everyone here to Office 2013, and thankfully IT was talked into rolling out the x64 version.  In the 2013 version you can install the x64 Access driver separately; I think the required process is install that first, then the x32 Office program.  Then programs on the computer have "access" to both drivers based on their own bit-ness.

 

I'm not certain how that interacts with Office 365 but it should work in a similar fashion.

----------------------------------
If you are going to fly by the seat of your pants, expect friction burns.
"I don't know" is the beginning of knowledge, not the end.


Message 9 of 9
Anonymous
in reply to: Anonymous

That is wonderful news. I didn't know that. If MSO accepts both versions, it should be straight forward to customise the deployment packages to allow either order. Thank you for that info.

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Rail Community


 

Autodesk Design & Make Report