bhom / speckle_toolkit Goto Github PK

Description:

With latest version of Speckle, they have changed something with the Deserialisation (see also #53 (comment)).

This "trick":

where I was setting the wrapper SpeckleObject Type property to be the Name of the BHoMObject type no longer works, because now the Deserialisation from SpeckleAbstract is always attempted by SpeckleCore, somehow.

Actions to solve:

• Remove that Type override.

BHoMObject type name to go in the private _type field instead.

Description:

Consider multithreading for running the SpeckleSerialiser as a (temporary?) workaround to #49

Description:

Speckle_Serialiser is responsible for almost all computation time while performing the Push. We're talking several seconds per <10 Structure.Bars. I suspect it's due to a limitation of how speckle does its "serialisation" together with the deep nesting of our objects, which probably Speckle wasn't designed for.
SpeckleSerialiser does in fact expose a maximumNestLevel parameter, which we cannot afford to use as we need to send eveything. (Edit: changing it does not seem to do anything).

Already highlighted the issue to Dimitri. I need to produce more detailed profiling; based on that potentially raise an issue in their Github.

In the meantime, perhaps #58 could help.

The BHoM issue templates have been updated, they need updating here.

The Pull Request template should also be housed within the .github folder, as should any CodeOwner files (if applicable).

Implement https://github.com/BuroHappoldEngineering/Operations_Toolkit/issues/73#event-2450638845

Description:

Create a Sphere in GH and Push it. The sphere is not visualised in the SpeckleViewer.

All BHoM files need to contain a BHoM copyright statement as their header.

For more information see Code Compliance - HasValidCopyright

Description:

Some breaking changes must have happened in Speckle -- the BHoM-Speckle_Toolkit scripts are not working anymore with few component missing. Replacing them with new ones makes the Push return an error "Could not deserialise the response body".

Investigate and apply needed changes.

How to replicate:

Try any script in the Speckle_Toolkit script folder.

Expected behaviour:

Scripts should work.

Needed to see whether tags can be successfully implemented together with the Replace/DistinctProperties/etc methods

As per BHoM/BHoM#499

Currently the adapter completely overrides the Pull. Ideally we should implement the Read.

Problem is, the Read only can return IBHoMObjects while we need it to be able to return also IObjects and object in general.

Broken rules:

As title

Basically, if it's possible to define these:

Parent issue(s) or Pull Request(s) causing the changes:

BHoM/BHoM_Adapter#151

Description:

Updating toolkit to align with refactoring of the parent BHoMAdapter.

Broken rules:

AssemblyFileVersion is at 2.4.0.0 and should be 3.0.0.0 for the beta development cycle.

Suggestions to restore compliance:

We should also check the AssemblyVersion value, which should be 3.0.0.0
AssemblyCopyright should also read [assembly: AssemblyCopyright("Copyright © https://github.com/BHoM")] and not have a year in it.

Problem statement

Most "visualiser platforms" like Rhino, Speckle and 3DRepo use meshes to visualise objects.
For example, when you want to visualise a BH.oM.Structure.Elements.Bar in the Rhino space, the following steps are actually done:

1. The centreline and the section property are extracted.
2. The section property extruded along the line to generate the external surface
3. The external surface is processed by Rhino, that renders it by meshing it.

Another example can be done for Node (see below), but we can imagine many other cases.

This means that for a variety of BHoMObject types we could compute a Mesh Representation, useful for visualisation purposes.
The whole process of generating a visualisable mesh should be definable and customisable per individual BHoM Types.

If there is agreement on this, we need to formalise how and where this should happen.

Example of the current workflow in Speckle

When you push a BH.oM.Structure.Elements.Node:

1. You may want to visualise the node in several ways, depending on its properties:

   • For a pinned node we want a Mesh containing a sphere on top of a cone.

   • For a fixed node we want a Mesh containing a box.

   Basically it returns a different mesh to represent different constraints based on the Constraint6DOF. Reason to return a Rhino Mesh is because it's the only way we currently have to build "composite" meshes, AFAIK.

2. The mesh is converted into a Speckle Object, that acts as a bucket.

3. All BHoMObject data is stored into the Speckle Object.

I've now isolated 1 into MeshRepresentation methods. It could be the case that those are moved up in BHoM_Engine, so they can be used also for other cases where we want to get a Mesh representation of a BHoMObject.

Description:

Getting a build error in Speckle_Adapter/CreateIBHoMObjects.cs due to an ambiguous reference between BH.Engine.Speckle.Compute and BH.Engine.Rhinoceros.Compute

This is a 2 sec simple fix -- will do now.

Steps to reproduce:

Build the project in Visual Studio.

Conditions: #2 is done; #10, #11 and #15 are doable/done

The previous would open up the possibility of using tags (the whole procedure of the Replace() method).
We could Push (upload) only portions of the model via the tags.
The procedure would be:

• Ask Speckle to clone the stream (#15)
• Targeting the cloned stream, delete specific objects from it (#11)
• Create (upload) only the specific objects being updated

The AssemblyFileVersion attribute should now be updated to read 3.2.0.0 for all AssemblyInfo.cs files within this repository for the start of the 3.2 milestone

• Meshes

Description:

Currently Speckle already has an Endpoint to get the diff of two streams.
The current response is similar in format to the AEC deltas specification, but it will need to match it exactly.

As a first step, implement a Read that receives the current JSON diff format.

This will be simplified when the fork of SpeckleServer by @PaulPoinet will then implement the right Delta format.

Additional note

As feature requires a way for the user to specify the Stream Revisions to diff, this should be tackled together with #9

Description:

Happens when pulling from Speckle objects that are NurbSurface.

The deserialised NurbsSurface has properties that are always inaccessible: upon access they return Rhino.Runtime.DocumentCollectedException.

Description:

Currently we always push everything to one layer called "Default Layer".
Ideas:

• Expose the choice somehow to the user.
• Add options for automatic layer generation (e.g. Structural Layer, Environment Layer, etc, based for example on the object namespace)

Think how we could implement history (versioning) in Pull.

Push now can be configured to save Children Streams -- also called Clones in the Speckle viewer -- that can effectively be used as versions of the same model.

In the Pull we could implement a Query to get a specific version out.

1. See if Speckle allows deletion of specific objects from a Stream.
2. The same, but with Children streams ("Clones" in the Speckle Viewer).
3. Implement them in the Delete() CRUD method of the Speckle_Toolkit adapter.

@PaulPoinet could you have a look at point 1 and 2?

This includes:

• Develop a simple test case/script
• Add the if-else case for IObject/Delta object
• Serialise the Delta object as per AECDeltas specification.
• Add the call to the new endpoint (to be developed by @PaulPoinet). This is a new Endpoint that should answer a PUT request as described in the REST API specification.
• Review of any mechanism in the Diffing_Engine as required

Scenario

Tell speckle "how to diff" based on the specified objects' Hashcode.

For some (quite convoluted/do not ask) reason, we would like to calculate the Hash for the BHoMObject externally to the object, not overriding/calling bhomObject.GetHashCode(), in order to pass it to Speckle's Serialise method (see question below).

Question

With reference to the Serialise method of Speckle:
https://github.com/speckleworks/SpeckleCore/blob/9545e96f04d85f46203a99c21c76eeea0ea03dae/SpeckleCore/Conversion/ConverterSerialisation.cs#L39-L53

is it possible to pass a custom HashCode, perhaps in the Dictionary<int, string> traverse parameter? If so, how am I supposed to populate the string part of the dictionary (which apparently represents some sort of "path")?

Broken rules:

We are currently referencing a copy of SpeckleCore.dll included in the repo

Suggestions to restore compliance:

Switch to nuget package

Description:

E.g. Bars are always extruded and represented with Meshes now. This is heavy and might impact larger models. Add option to toggle.

Important to allow speed on larger models.
Due to the bug #49 this issue can be considered as a critical workaround ATM.

IElement interfaces are migrating to Dimensional_oM

This will cause every project which uses any of the IElements or any class inheriting from IElement to need a reference to Dimensional_oM.
Further more, any file using any of the IElement interfaces explicitly, will need to add
using BH.oM.Dimensional;

Follow these steps to include in your toolkits:

Branch Name:

Dimensional_oM698-Migrate-IElementXD-Interfaces-from-Geometry_oM

For every project in your toolkit

1. If you had a reference to Geometry_oM, add a reference to Dimensional_oM

For every file in your toolkit

2. If you have any direct use of any of the IElement interfaces, add using BH.oM.Dimensional;

Description:

All referenced SpeckleCore assemblies "Copy Local" must be set to False, otherwise you might get conflicting version and loading errors, in case you have another version of Speckle Installed (different from the one we target in Speckle_Toolkit).

Note!

SpeckleCoreGeometry instead needs Copy Local to true in order for the Toolkit to work.

Description:

There should be no direct reference to local dlls anymore and only reference through NuGet. This is necessary to enable CI through AppVeyor.

Messages from Speckle need to be returned to the UI.
Those may be "appended" to the component balloon via the Engine.Reflection.Compute.RecordError mechanism.
However that could be problematic -- consider scenario where a message is given for every object pushed. See if speckle has different logging levels.
Another option for returning the would be to somehow add some "info" output from the Push.

In order to do #59,
the Speckle library called SpeckleCoreGeometryRhino has to be referenced by the Speckle_Toolkit.

A Nuget package is still not available for that library, however it's on the roadmap to be produced.

Therefore, we decided to temporarily copy the library in this newly created _tempRefs folder in the repo.
This will have to be removed once the Nuget is available.

Description:

Context: get a visualisable representation of Surfaces and Nurbs in SpeckleViewer.

Unlike Meshes, Lines and Points, for which we already are the converts, other types (like Breps) are not so simple to convert.

It would be an easy job if we could reference SpeckleCoreGeometryRhino, because that project contains all the converts from Rhino classes to Speckle classes.
However, the only nuget package for SpeckleCoreGeometry seems only to include the SpeckleCoreGeometryClasses, which are the base geometry types (SpeckleLine, SpecklePoint etc).
We could solve this by

1. Rewriting the convert ourselves (I just attempted to do it and it's definitely not recommendable)
2. Hard-copying the .dll in our repo.
3. Waiting for the Nuget package to be produced: speckleworks/SpeckleCoreGeometry#22.

If we clarify the strategy for this one, we might as well just pass through rhino for all our geometry types, then use the speckle converter for them.
This could be quite advantageous for us, because we could maintain less convert methods (the BHGeom to Rhino and vice-versa are needed anyway).

Parent issue(s) or Pull Request(s) causing the changes:

BHoM/BHoM_Adapter#164

Description:

Updating toolkit to align with refactoring of the parent BHoMAdapter.

To be done by 24th January 2020

Description:

Update toolkit assembly file versions to the new milestone - file assembly version should now be 3.1.0.0

To be done by 10th January 2020

Description:

First time you push objects to a new Stream, they don't get added.
You need to push a second time in order for them to be actually Pushed by the speckle client.

Might this be due to the fact that we use the method StreamUpdateAsync every time we push?
Needs investigation.

Steps to reproduce:

Create a new stream with speckle using the Data Sender component. Attach the ID to the SpeckleAdapter component. Push some objects.
Objects will not appear at the first push.
If you push again, they will appear.
From there onwards the Push behaviour will always be correct (stream will be updated every time you push without having to do it twice).

Expected behaviour:

Object should appear at the first push also for newly created streams.

Description:

After ploughing on with the development I realised the Push is unnecessarily complex.

Broken rules:

AssemblyFileVersion is now at 2.1.0.0 for most assemblies.

Suggestions to restore compliance:

The plan is to update the AssemblyFileVersion property of the assembly to 2.3.0.0 and leave the AssemblyVersion as it currently is.

Broken rules:

Suggestions to restore compliance:

In line with the discussion on BHoM/BHoM#733 and subsequent changes to BHoM in BHoM/BHoM#734 it is desirable for all objects to now contain the virtual modifier to provide greater flexibility for developers and users wishing to create BHoM objects in their workflows.

This issue is to instruct @BHoMBot to carry out the task of adding the virtual modifier to any object in the oM of this repository where it does not already exist.

Speckle exposes some kind of history in the viewer. Check how we could use that.

Edit:
The SpeckleStream can have children streams -- also called Clones in the Speckle viewer -- that can effectively be used as versions of the same model.