-
Notifications
You must be signed in to change notification settings - Fork 171
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Blocks POC (Rhino, Acad) #3519
Blocks POC (Rhino, Acad) #3519
Conversation
…baking to instance manager, etc.
more testing still needed!
...Connectors/Autocad/Speckle.Connectors.AutocadShared/Bindings/AutocadBasicConnectorBinding.cs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I need more context but some observations....
- I think there are some opportunities to simplify and improve unit testing of this in the future.
- I do wonder if there's a better way to obtain the order list of instances and proxies and I'd like to understand if the index depth works
- There are some direct references to the acad and probably rhino docs that should be replaced
DYI the Rhino interfacing out is about done also. We will need probably Bilal to give Revit and Rhino a good bashing when he is back as these complex changes may have added some regressions that are hard for Adam to spot but it's a hump and lump worth swallowing so we can test things
I also stopped after Acad as I wonder if I'd start being a bit repetitive
/// <summary> | ||
/// The units of the host application file. | ||
/// </summary> | ||
public string Units { get; set; } = Kits.Units.Meters; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How dare you mention Kits ;)
We should move that definition and avoid binding tighter to it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure how at this stage? I'm hesitant to move this out of core right now...
/// <summary> | ||
/// A proxy class for an instance definition. | ||
/// </summary> | ||
public class InstanceDefinitionProxy : Base, IInstanceComponent |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
InstanceDefinitionProxy will be serialiseable and hence is derives from Base? I am circling Base atm with a view to us setting fire to it, at least in its current state, and moving to more concrete types, though I don't imagine we can avoid using it here if it is going to be serialized in place
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep! We can move things away from base when we get to it imho
/// <summary> | ||
/// Abstracts over <see cref="InstanceProxy"/> and <see cref="InstanceDefinitionProxy"/> for sorting and grouping in receive operations. | ||
/// </summary> | ||
public interface IInstanceComponent |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems a very small interface and the name and the prop seem a bit incongruous, possibly you're expecting the interface to grow to have more props/ Just wondering if this is the right place. I can sort of see I think, but maybe worth a discussion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't expect it to grow (yet), i just need to sort both by max depth in the same pass. Not too clean, i agree, but then again could we live with this as a POC?
...Connectors/Autocad/Speckle.Connectors.AutocadShared/Bindings/AutocadBasicConnectorBinding.cs
Outdated
Show resolved
Hide resolved
...Connectors/Autocad/Speckle.Connectors.AutocadShared/Bindings/AutocadBasicConnectorBinding.cs
Outdated
Show resolved
Hide resolved
|
||
var objectGraph = _traversalFunction.Traverse(rootObject).Where(obj => obj.Current is not Collection); | ||
|
||
// POC: these are not captured by traversal, so we need to re-add them here |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should traversal be updated?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope, traversal is fine as is. I'd revisit this once https://spockle.atlassian.net/browse/DUI3-10 is ironed out
...tors/Autocad/Speckle.Connectors.AutocadShared/Operations/Receive/AutocadHostObjectBuilder.cs
Show resolved
Hide resolved
{ | ||
_instanceObjectsManager.PurgeInstances(baseLayerPrefix); | ||
|
||
using var transaction = Application.DocumentManager.CurrentDocument.Database.TransactionManager.StartTransaction(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
context stack :)
|
||
public static class RhinoUnitsExtension | ||
{ | ||
public static string ToSpeckleString(this UnitSystem unitSystem) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, we should have a neater version of this I believe?
/// <inheritdoc/> | ||
/// Expects to be a scoped dependency per send or receive operation. | ||
/// </summary> | ||
public class RhinoInstanceObjectsManager : IInstanceObjectsManager<RhinoObject, List<string>> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are into Rhino now and my brain is melting and it's probably worth considering my ACAD comments first.
Also I wonder if these can be made to be more DRY though I suspect not, maybe that's one for later IF
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They could be with an abstract class in between, but i'd settle with them as they are as "good enough" for now. We'd need to test this against other host apps to fully understand the patterns at play first (eg., tekla, revit)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally okay but lots of other changes making it tricky to read, probably unavoidable atm
@@ -52,14 +53,15 @@ private void UnpackInstance(InstanceObject instance, int depth = 0) | |||
{ | |||
var instanceId = instance.Id.ToString(); | |||
var instanceDefinitionId = instance.InstanceDefinition.Id.ToString(); | |||
var currentDoc = RhinoDoc.ActiveDoc; // POC: too much right now to interface around |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we have the ticket for this and drop that into the POC comment? This is easily unit testable and this would block that, we could make the ticket to complete this an add some unit tests
I did just ask for a ticket to make it interfaced out and add some tests and a question about splitting the interface but that's all |
Unfortunately does more things that originally intended 😅
What/why? Adds support for sending blocks (non-dynamic!) between rhino<>rhino, acad<>acad, and rhino<>acad. It's also driving this in a new, "cleaner" approach that was discussed... since pretty much the retreat in Athens 😅
Tl;dr:
IInstanceObjectManager
interfaceInstanceObjectManager
in RhinoInstanceObjectManager
in AcadThe above provide support for sending and receiving blocks (static blocks, not dynamic blocks) to and from Rhino and Acad.
Extras:
InstanceObjectManager
, this means that there's some scaling code in there. The good news is there's no dependency on the old Transform class.A question that arises fast but i do not want to solve in this PR: formalisation of the root commit object structure: yes, it's a collection, but where do we store definition proxy objects? currently attaching as a dynamic prop, so we're relying on convention. Imho, good enough to merge for now as I'd want to implement one extra similar case before we generalise (eg., rhino groups? materials?)
more notes: https://www.notion.so/speckle/Blocks-Journal-e358f6a4db7c46859ae419ff2c7dbdd6
jira tix: https://spockle.atlassian.net/browse/DUI3-120