Navisworks Connector - PreAlpha contributions requested

jonathon · 20 July 2022 19:12

ConnectorNavisworks

I have nearly wrapped up an alpha release of a Navisworks > Speckle connector.

Mostly, I only need to finesse a currently makeshift UI/UX. There are a few options that I have built in that should be optional.

When moving from Alpha to Beta I will attempt to adopt the Speckle UI properly but may lean on The Specklers™ for help with that.

Call for contributions

In the meantime, I’m looking to source NWDs for test conversions to a collaborative stream. By test, I mean also looking for help with the review of the conversions.

If you can share anything, you would then be happy (and permitted) to:

QA review
view online
try downloading to Blender/Rhino/Notion etc.

I propose to assemble a closed stream and add all who offer submission as collaborators. This is my best attempt at reaching wide for material that is ok to be shared. I have plenty of my clients’ material but can’t really share them.

I hope this is of interest to folks.

I share a lot on Twitter but would like to keep this between us for now.

Don’t fret, my Windows are activated - it’s a BootCamp thing.

teocomi · 22 July 2022 07:26

Fantastic work!

@bcall we just discussed a Navis connector recently

bcall · 22 July 2022 16:51

@jonathon , I would love to contribute some NWD’s to help with this! Let me know what all you need!

@teocomi Thank you for pointing me to this!

jonathon · 22 July 2022 17:19

Great!

Let me know what all you need!

Nothing specific, and can be as simple or as tricky as you like.

As a caveat, solids convert but not linework geometry; embedded CAD will be discarded and not added as cruft. I have stress-tested the conversions a bunch (Big models === Slow) and sadly still experience occasional inexplicable crashes ¯\(ツ)/¯. Because Navis models are always from someplace else, sometimes odd quirks arise that need ironing out.

Essentially, If you share an example file(s), I’ll run a few different conversions from the options UI I’m still working on:

full conversion (again, big can be a pain)
by layers,
by selection sets
by search sets,
colour overrides (temporary or permanent),
move-to-zero or real location.

All these are working just need to convert from flags embedded in code to sensible UI options.

I’ll make a branch per contribution and probably sub-branches to that which describe what selection or transformation options have been applied. Using all the Speckle commenting goodness.

I have another thread where I have been thinking in public about what the object model should be and have settled on something I think works well (based only on my own needs for data QA really)

If you have other ideas - I’m also gathering those and super keen to receive them too.

DM me to share links here or jonathon @ stardotbmp . com

jonathon · 22 July 2022 20:09

Basically, these, but too often to be funny.

Always when dealing with some of Navisworks crusty old c++ COM interop functions

Ricardo_Zepeda · 25 July 2022 12:16

Count me in with the testing! im based in Chile so i can provide nwds federated from some of the most used softwares around here. have been thinking for a while on how speckle could help with AWP in some mining projects im part of.

jonathon · 27 July 2022 23:36

Because building an embedded UI should be easy right?

It probably would be in daylight hours nothing of progress to see here, just pleased with myself getting vue-devtools to look at the embedded plugin

Behold my clacky keyboard and post-bedtime chillout choons

dimitrie · 28 July 2022 05:26

Ha, nice - something i’ve never achieved! Out of pure curiousity, have you tried using WebView2 in there (or are you already!!!) vs CefSharp?

jonathon · 28 July 2022 06:44

Nope. Cefsharp for now, just because I know it. (ish)

teocomi · 28 July 2022 06:48

Happy to look at integrating it with Desktop UI anytime!

jonathon · 28 July 2022 06:54

Soon. Soon.

Appreciate it.

jonathon · 29 July 2022 16:48

I’m curious if these options mean the same to others as they do to me. I’ve tussled with trying to avoid needing to type negative numbers?

jonathon · 30 July 2022 02:00

What else are Friday nights for?

jonathon · 1 August 2022 11:30

Thanks to @Ricardo_Zepeda’s contribution, I have found a bunch of places where the conversion is broken. Obviously, that sucks in some ways but is AWESOME in others.

The nature of the suckage is problematic:

After quite a lot of digging (some of it in unofficial sources), most errors appear to stem from ADSK’s own .NET wrappers around its legacy COM interface to the underlying code.

My conjecture
It seems it is suffering from pre-emptive garbage collection. This may explain why all the errors are associated with memory access. If an object has been garbage collected, it is logical that accessing its properties will no longer be possible…

When the conversion routines were simple loops, this wasn’t occurring as garbage collection while debugging is less vigorous/strict to allow for stack traces to work etc. When trying to improve efficiency with multithreading, it becomes a bigger issue - or worse, occurring in Release, not Debug, with no other changes.

Solution (attempt 1)
I am porting the conversion to use more and more of the crusty old COM API ¹. Handling the GC better and using more primitive types. This is with 2 objectives in mind:

have the bugger, not crash (probably)
speed up the conversion (hopeful)

A long way of saying: bear with me, peeps.

¹ Largely undocumented, because of course it is.

jonathon · 4 August 2022 18:44

Today’s unhelpful update:

List<Task> Tasks = new List<Task>();
ConcurrentStack<bool> stack = new ConcurrentStack<bool>();
        
foreach ( var thing in NavisArseholeObjectsColl) {      
    Tasks.Add( Task.Run( () => {    
        ForegroundWorker fw = new ForegroundWorker();
        _ = fw.Send( o => {
            stack.Push( true );
 
            fw.Response = Autodesk.Navisworks.Api.Application 
              .ActiveDocument.CrazyThreadUnsafeCollection
              .DoThingWithEvneIfItIsJustARead( thing );

        }, this.Context );

        _ = fw.Send( o => {
            var hWnd = Autodesk.Navisworks.Api.Application.Gui.MainWindow.Handle;
            UpdateWindow( hWnd );
        }, this.Context );

        Console.WriteLine( $"{fw.Response}" );
     } ) );
 }

GC.KeepAlive(NavisArseholeObjectsColl);
await Task.WhenAll( Tasks );

Where Context is SynchronizationContext

and ForegroundWorker is a magic class I made to wrap around Context.Send and have it fake a return.

Seems to help … sometimes. ¯\(ツ)/¯

teocomi · 5 August 2022 05:32

Love the variable name NavisArseholeObjectsColl

In my experience most of these AEC API are not capable of handling multithreading well so, maybe it’s the case to avoid it?

jonathon · 5 August 2022 06:33

Yeah, you ARE right; it’s one last roll of the dice.

Thing is, the APIs are semi able but unstable, some work and some don’t. Those that don’t fail hard so it’s not worth trying. Some that do sometimes (property reads for example) are tantalisingly close to making it worth trying and for the times that the call fails falling back to a main thread read.*

As you might know, iterating over 1000s of nested objects is slow. Multi-threading massively helps of course.

If this doesn’t work (the example loop is kinda dumb) I’ll abandon it for the alpha and open the hacky code to y’all and the internet to help.

For now I’m bitten by the “I will make it work, I must” bug.

jonathon · 5 August 2022 07:10

Some of this, of course, is me learning by doing. So nothing is wasted.

Also some is just weirdness brought about by WPF and not Tasks

jonathon · 19 December 2022 14:43