tudo-seal / cls-cad Goto Github PK

Documentation for the Add-In is insufficient in it's current state, consisting mainly of simple sporadically used one-line comments.

To resolve this, the following should be implemented:

• #7
• #8
• #9
• #6

The Joint API internally uses JointGeometry or JointOrigins to create a joint.

JointGeometry is created from Faces or Curves by specifying a JointKeyPointType. These KeyPoints seem to correspond to the snap points seen in the Joint command, and the documentation vaguely supports this notion.

JointGeometry is persisted when a Joint is created, as the snap-points can be edited and highlighted when editing an existing joint.
JointGeometry is however denoted as "transient" by the Documentation, so it might not be standalone saveable.

It should however be possible to annotate the JointGeometry's associated entity with the associated KeyPointType and GeometryType. This would allow recreating the JointGeometry during assembly, akin to the Joint API example in the documentation.

Questions:

• Is the preSelectMouseMove hook no longer broken?
• Can the KeyPoints be visualised? Their Origin can be retrieved and visualised on hover.
• Can the KeyPoints be visualised with adequate performance? Calculating all KeyPoints, creating JointGeometries and retrieving the Origins could be done on preSelect, which shouldn't be to bad.
• If the KeyPoints can be visualised, what needs to be selected? The Joint commands usually selects the underlying face and visualises the JointGeometry.
• If the KeyPoints can be visualised, how are they selected? The mouse coordinates would need to be checked and projected to see which point is currently closest.
• Implementing this means that transient objects need to be recreated. Additionally, removing types is no longer as simple as jsut deleting the origin. Is it worth the additional complexity? (Probably no, more relevant for a company than a Ph.D)

Non-Technical Questions:

• Creating JointOrigins has the "Reorient" Feature. Especially for difficult parts, like sliders, this is very useful to accurately model the joint. Can this be recreated without JointOrigins? (Maybe, but it's a pain. I am not quite sure how sliding axis change work or if they are possible in the GUI. Should test)
• From an UI perspective, is it less clear or unnecessary to switch? Arguably, the type needs to be displayed at the JointGeometries origin either way, and an indicator is necessary either wayfor clarity. Switching everything to then just display a custom graphic there instead of a JointOrigin seems a bit absurd.

Could be fixed by displaying a dialog to pick the taxonomy and then opening the palette on "Okay".

Could also use multiple BrowserCommandInputs and Tabs, but if using more than the three recommended taxonomies, this could get ugly fast in the future.

Due to the way that Fusion 360 handles references, it unpacks all instances of the part, thus losing multiplicities, e.g. a part that was contained 4 times is now contained one time.

Parts do not provide "themselves", as such only tips of an assembly can be requested.

By adding a virtual joint to a part that the assembly machine either interprets as a RigidGroup to the Origin, or just doesn't mage at all, that can be fixed.

The way that the parser parses the configuration, the Constructor would have to be "uuid1_uuid2_uuid3_self" or something like that, a magic string to make sure we can differentiate.

• assembleresult
• checkandsubmit
• downloadtaxonomy
• jointtyping
• parttyping
• requestsynthesis
• taxonomyediting
• togglecustomgraphics
• typecrawlinghub
• typecrawlingproject
• uploadtaxonomy

In its current state, the Add-In uses the built-in baseline python SocketServer to host the contents of the resources/html.

This is due to when ES6 modules are loaded, Chromium enforces that a Javascript MIME-type needs to be present. This is not the case when the Fusion 360 palette loads the files.

Theoretically, it might be possible for Fusion 360 to enhance that feature, as the presence of debugging on localhost implies that it is serving the files anyways, it is simply not properly loading *.js files with MIME-types.

To enhance serving the webapps and make the extra SocketServer obsolote, the following need to happen:

• The issue needs to be reported on the Fusion360 API forums (Enhancements Thread?)
• The issue needs to be accepted and fixed on Fusion360s end
• The developed webapps need to be changed to using a purely relative publicPath (probably "" instead of "./")

The issue can be closed if:

• The Fusion360 enhancement gets rejected
• The Fusion360 enhancements gets accepts and previous task 3 is implemented

In the current state, the project uses "baseline" cls-python to inhabit requests. However, if the inhabitation fails, there is no additional debug info. Such debug info is very necessary, as especially with a large project, it is not easy to differentiate the following use-cases:

• There is actually no suitable part present at some point of the inhabitation
• A JointOrigin is mistyped, but the intended part is present.
• A part is mistyped, but the requesting JointOrigin is correct

To aid with making a synthesis request in a project work, the inhabitation should output for every request at which first occuring point in the tree it was caused to fail.

• Try and ask Jan if this is possible (theoretical/implementation/framework perspective)
• Implement a suitable synthesis failure response

A casual user/reviewer/academic/professional can not be expected to just figure out how to use the add-in, as taxonomies, synthesis, and so on are all only intuitive to people that have prior knowledge of (CL)S. As such, there needs to be a way to teach a new user how to create/convert a project that can use the add-in.

• Short-term options could be creating a specific "Help" or "Tutorial" command, that is integrated in the add-in and shows the necessary steps to get going.
• Long-term options could be a set-up example project like the ones that are shipped with Fusion360, however it needs to be analyzed if this is possible.

Having both is desirable.

• Tutorial Command
• Check Feasiability of Loadable Example Project

• assembleresult
• checkandsubmit
• downloadtaxonomy
• jointtyping
• parttyping
• requestsynthesis
• taxonomyediting
• togglecustomgraphics
• typecrawlinghub
• typecrawlingproject
• uploadtaxonomy

• assembleresult
• checkandsubmit
• downloadtaxonomy
• jointtyping
• parttyping
• requestsynthesis
• taxonomyediting
• togglecustomgraphics
• typecrawlinghub
• typecrawlingproject
• uploadtaxonomy

This is due to parts not linking to a logical ID in the taxonomy, but instead actually referencing the real names of the taxonomy.

This makes any form of renaming an excessively dangerous operation.
This could be fixed by type aliasing, or by using persistent IDs for everything in the taxonomy.
Similar problems arise from deleting entries in the taxonomy.

Due to this, currently, the plugin is unsuitable for large and long running projects.

• assembleresult
• checkandsubmit
• downloadtaxonomy
• jointtyping
• parttyping
• requestsynthesis
• taxonomyediting
• togglecustomgraphics
• typecrawlinghub
• typecrawlingproject
• uploadtaxonomy