Speckle in GH / Custom Properties

[FB_ENCODE (Federico Borello)]

Hello everyone!

I’m seeking for a clarification on how to correctly send and receive object with custom properties in GH.

It appears that if i convert a grasshopper geometry to a speckle object first and then extend it (magenta), the attached custom property is read correctly when receiving in GH but it doesn’t show up in the viewer filter groups.

On the opposite, if the grasshopper geometry is extended directly (blue), the attached custom property appears in the viewer filter groups but is not getting read back when receiving in GH.

Am I missing something?
Many thanks for your help!

[JoostGevaert]

I also find this quite confusing, and am actually not 100% about the explanation I’m going to give here, but I’ll give it a shot so I can also learn from it.

I think that if you don’t detach the geometry on the Magenta CSO component, both the magenta and cyan methods are going to give you the same result. I think that right now the only difference between the two is the detachment, because the ESO component actually converts the geometry into Speckle geometry.

I’ve experienced it’s very important to keep track of:

• What you detach. I try to detach as little as possible, and only detach things that actually occur multiple times in a model, such as a doors. However, IDs I try to not detach, because an ID is directly related to a specific object.
• When you convert to and from Speckle objects. These conversions happen on receive, send, CSO, ESO and DSO components.

@AlanRynne, what do you think?

[FB_ENCODE (Federico Borello)]

Hi @JoostGevaert,

many thanks for your reply!

I tested removing the detach on the geometry (magenta part), but the result didn’t change: on the viewer side the properties are not accessible on the filters groups and on the GH side when receiving is all getting read correctly, all the way round if I expand directly the gh geometry. Weird.

[AlanRynne]

Hi there!

This may seem simple but there’s a couple of things to pick apart here:

MAGENTA BOX → Create Speckle Object doesn’t just convert the geometry, it creates a new object that holds the geometry (converted to Speckle) on the given property. The resulting object is not convertible for grasshopper and not considered “displayable” by the viewer, it just provides structure.

BLUE BOX → This directly Converts the geometry into a Speckle object (not wrapped, if you input a mesh you get a Speckle Mesh out). Additionally, it get’s extended with custom properties as expected; but Grasshopper does not support metadata attached to geometry objects, so once that “Speckle Mesh” that holds extra metadata get’s converted back to a “Grasshopper mesh”, the extra metadata automatically gets lost (don’t worry, you can still access it, just not the way you’re doing so here).
As you’ve discovered, the viewer considers all geometry “selectable” and will show it’s metadata which will include the information you attached. You’re only loosing it on the conversion that’s happening after receive.

Do note that the vast majority of components that perform Speckle conversions will try their best to convert things to speckle when possible, so if you input a Grasshopper mesh, we convert it to Speckle for you and attach the speckle equivalent.
The same goes for outputs, if we’re about to output a Speckle mesh but we know it can be converted to Grasshopper, we do so by default.

You can change this behaviour in every node that performs conversions by right-clicking it and selecting “Do not convert”. This way the information stays in it’s “Speckle form” and still contains the metadata you attached.

Once there, you can extract your extra properties and convert the mesh to Grasshopper as 2 separate parallel steps (if you don’t see the “To Speckle/To Native” nodes i suggest you activate them on the Speckle 2 top-level menu → Show/Hide components → Show dev components"

Possible solution

I suspect what you’re after is to have the MAGENTA strategy also be selectable in the viewer to see it’s properties. For that, you just need to name the property that holds the “displayable geometry” with a specific name: displayValue and set it as List access.

This will turn this

Into this

I’m aware these is somewhat of a power-move that is not really very well documented… but it is the basis for the selection behaviour of every object in Speckle (walls, beams, floors, all follow the same pattern, placing the meaningful displayable geometry in a displayValue property.

I would discourage you from using the BLUE BOX strategy

Blue box strategy is lossy, as many applications do not support nor recognise this. It is only useful in rare cases and usually you’re better of following the “displayValue” strategy, as “displayable objects” have higher chance of being supported in other apps gracefully.

[FB_ENCODE (Federico Borello)]

Thank you @AlanRynne for your clear explanation, using “displayValue” as property name actually resolved the issue

On a separate note, I’m noticing a display inconsistency between the viewer on the “backend” (https://speckle.xyz/) and the “frontend” app (https://app.speckle.systems/). Some properties are getting filtered correctly but the colors are not matching the filtered groups, this on “frontend” viewer. All correct on the backend viewer.

Backend

Frontend App

[alex]

Hi @FB_ENCODE

Can you please share the stream so we can have a look?

Cheers

[FB_ENCODE (Federico Borello)]

https://app.speckle.systems/projects/a29e5c7772/models/f636b6c8f1
https://speckle.xyz/streams/a29e5c7772/commits/a8cfae2645

[alex]

Great, thanks! Now can you please clarify which of these links is displaying incorrect behavior? I can’t tell from the original post (links do not match image titles)

Cheers

[FB_ENCODE (Federico Borello)]

Ups sorry Alex, first link is the incorrect one, the second is working as expected.

[alex]

Hi @FB_ENCODE

The issue is now fixed on https://latest.speckle.systems/ and will be patched through to production soon.

Thank you for reporting it!

Cheers

[FB_ENCODE (Federico Borello)]

Great news Alex, thanks for the update.
I’m not able to access the server link, can you grant access?
Cheers

[jonathon (jonathon@stardotbmp.com)]

The link @alex posted is for the Speckle development server - new developments go live there first for some time. Once seen to be stable, they migrate to the public server app/xyz.

You can make an account on latest.speckle.systems and test if your GH and the result is indeed fixed and get back to us - or wait for the server release on app/xyz to update.

[JoostGevaert]

Thanks a lot for the great explanation Alan!

Also amazing to see how quickly that bug in the FE2 viewer was fixed

@AlanRynne

displayValue and set it as List access

Why does the displayValue need be set to List access?

[jonathon (jonathon@stardotbmp.com)]

It defines it as an array, it matches the Schema object in that way.

List<T> displayValue

[JoostGevaert]

Ah, I see, you’re talking about this Schema object of the Base object, right?

The Base Object | Speckle Docs

public List<Mesh> displayValue { get; set; }

from

// Class definition with additional display properties
public class Foo : Base {
	[DetachProperty]
	public List<Mesh> displayValue { get; set; } // Mesh objects that represent the geometry of this Base object, e.g. used to render surfaces, or solid objects in our viewer
	// or
	[DetachProperty]
	public Polyline displayValue { get; set; } // a polyline used to render complex curve objects in our viewer
	
	public Box bbox { get; set; } // a bounding box used to assist with object selection in our viewer
}

[jonathon (jonathon@stardotbmp.com)]

correct yes - Though I believe that we now prefer List always

[JoostGevaert]

Always, as in?
As in, you prefer all properties and nested objects of all objects to be List<T>?

[jonathon (jonathon@stardotbmp.com)]

Nope. just displayValue

[JoostGevaert]

This is very well explained, but it is very hard to wrap your head around, let alone explain this to colleagues who are new to Speckle, let alone to colleagues who are new to Speckle and Grasshopper.

It also becomes even more complicated when you want to use a renderMaterial to change the color of the displayValue:

• The renderMaterial MUST be spelled renderMaterial NOT RenderMaterial, which is how it comes out of the Speckle Schema Object (SSO). (pink highlights)
• The displayValue MUST be a SpeckleMesh, therefore you MUST use ESO, not CSO. (middle green check vs red cross)
• The final result MUST be a SpeckleObject with a displayValue attached, therefore you MUST use CSO, not ESO. (middle right red cross)
• You cannot attach a renderMaterial to a Speckle Object. The renderMaterial MUST be a property of the displayValue. (bottom right red cross)
• I just noticed that my green check CSO isn’t completely correct either, because it doesn’t have the list access…

Now that I’ve given it some thought, I do understand the logic behind all this, but explaining why people their scripts don’t work as they expect is going to be hard. That is, in case people actually come to ask, instead of just giving up…

Would it be an idea to make the CSO component come with some default optional inputs like the displayValue that accepts a SpeckleMesh and only a SpeckleMesh, and create a CreateDisplayValue with SpeckleMesh and renderMaterial inputs?
If you then don’t need the displayValue, and don’t want to see it, you could zoom in and remove it from the CSO.
Well, I guess this isn’t the solution either, because you could use a CSO for a Brep + renderMaterial directly…

Complicated…

Oh, and if someone could give a good rule to follow for detaching properties, that would also be great
As in:
“Always detach, except 1. 2. 3.”
“Never detach, except 1. 2. 3.”

[jonathon (jonathon@stardotbmp.com)]

@JoostGevaert

The renderMaterial MUST be spelled renderMaterial NOT RenderMaterial, which is how it comes out of the Speckle Schema Object

Fair point

@JoostGevaert

You cannot attach a renderMaterial to a Speckle Object. The renderMaterial MUST be a property of the displayValue.

Well, you can, but it would have no effect.

@JoostGevaert

if someone could give a good rule to follow for detaching properties

The description in our docs sums it up, I think: Decomposition API | Speckle Docs

@JoostGevaert

Would it be an idea to make the CSO component come with some default optional inputs like the displayValue that accepts a SpeckleMesh and only a SpeckleMesh, and create a CreateDisplayValue with SpeckleMesh and renderMaterial inputs?

We are always looking for ways to make users’ lives easier and have been inspired by @cgburgos and UNStudio’s work to assist their teams’ workflows. Given that this is a new suggestion on a solved thread - Could you add it as a feature idea post, and others could chime in - either specifically on that idea or a thread to collect other user-assisting nodes?

And as I’ve mentioned already @JoostGevaert, we are always open to open-source contributions.