I'm building a camera control plugin for a 3D mouse to do navigation in Navisworks 2012 with the plugin API and COM API (since 2012 doesn't support robust camera manipulation in the standard .NET API as far as I know). It looks like I may be able to do this in a more robust manner in the 2013 API (I haven't upgraded yet and am unsure when that would happen) with new .NET API support for camera manipulation, but for the sake of getting it up and running in 2012:
I set up a thread that polls data from my device and uses it to update the translation and rotation of the camera using the COM API. When I do this directly in a C# plugin, the performance is terrible. However, I found a sample camera manipulation plugin from 2010 that utilizes a Windows Form to do one-off camera moves and rotations. When I ran my code through the Windows Form (that opens as a modal dialog in the main thread, suspending the Navisworks window), the performance is MUCH closer to normal/acceptable range. So this is usable but not ideal since I have to close the Windows Form to resume normal Navisworks operation and open the plugin again everytime I want to navigate with my 3D mouse.
Is there anyway to circumvent this and get decent performance/framerate when manipulating the camera in real time directly in a C# plugin with the COM API? Maybe the COM functionality wasn't built for this sort of application, but I was wondering if there was something I was missing that could alleviate whatever calculations Navisworks is doing every time the camera transformation gets reset. I also think it could be related to Naviswork's logging of Undo actions since the Undo button flickers every time the camera is moving. Is there a way to disable logging of Undo actions for camera moves or Undo actions in general? I can set the Undo buffer size to 0 in Options but that doesn't seem to make a difference.
Similar to what I replied in the other post (http://forums.autodesk.com/t5/Autodesk-Navisworks-
it looks one of your problems is about undo. did you group the operations (so you would face the issue of undo)? Have you used BeginEdit & EndEdit? They are grouping the operations. I can misunderstand your problem, though.
I have been using BeginEdit and EndEdit surrounding my camera translation and rotation code in my current Forms implementation and it certainly helps. Without it, moving the camera on two separate axes (both forward and to the right for a diagonal move, for instance) leads to a stair-stepping/jagged motion relative to much smoother motion when the operations are grouped.
I seem to remember this didn't provide noticible performance improvement with the original threading implementation, though, but I can try to test this out again. Either way, I'll put some time into getting this working in the 2013 .NET API which may circumvent this particular probelm.