Skip to content
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

Merged
merged 30 commits into from
Jun 27, 2024
Merged

Blocks POC (Rhino, Acad) #3519

merged 30 commits into from
Jun 27, 2024

Conversation

didimitrie
Copy link
Member

@didimitrie didimitrie commented Jun 17, 2024

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:

  • Adds IInstanceObjectManager interface
  • Implements InstanceObjectManager in Rhino
  • Implements InstanceObjectManager in Acad

The above provide support for sending and receiving blocks (static blocks, not dynamic blocks) to and from Rhino and Acad.

Extras:

  • Have to deal with conversion of Matrix4x4 to native app in the InstanceObjectManager, this means that there's some scaling code in there. The good news is there's no dependency on the old Transform class.
  • Had to add a RhinoLayerManager class to simplify conversions

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

@didimitrie didimitrie marked this pull request as ready for review June 18, 2024 11:57
@didimitrie didimitrie changed the title Blocks POC (Rhino, Acad) - WIP Blocks POC (Rhino, Acad) Jun 18, 2024
@didimitrie didimitrie requested a review from BovineOx June 18, 2024 11:59
Copy link
Contributor

@BovineOx BovineOx left a 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;
Copy link
Contributor

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

Copy link
Member Author

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
Copy link
Contributor

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

Copy link
Member Author

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
Copy link
Contributor

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.

Copy link
Member Author

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?


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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should traversal be updated?

Copy link
Member Author

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

{
_instanceObjectsManager.PurgeInstances(baseLayerPrefix);

using var transaction = Application.DocumentManager.CurrentDocument.Database.TransactionManager.StartTransaction();
Copy link
Contributor

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)
Copy link
Contributor

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>>
Copy link
Contributor

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

Copy link
Member Author

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)

@JR-Morgan JR-Morgan self-requested a review June 20, 2024 21:26
Copy link
Contributor

@BovineOx BovineOx left a 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
Copy link
Contributor

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

@BovineOx
Copy link
Contributor

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

@adamhathcock
Copy link
Member

@oguzhankoral oguzhankoral merged commit 0568a29 into dui3/alpha Jun 27, 2024
33 checks passed
@oguzhankoral oguzhankoral deleted the dim/dui3/blocks-poc branch June 27, 2024 20:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants