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
renderMaterialMUST be spelledrenderMaterialNOTRenderMaterial, which is how it comes out of the Speckle Schema Object (SSO). (pink highlights) - The
displayValueMUST be aSpeckleMesh, therefore you MUST use ESO, not CSO. (middle green check vs red cross) - The final result MUST be a
SpeckleObjectwith adisplayValueattached, therefore you MUST use CSO, not ESO. (middle right red cross) - You cannot attach a
renderMaterialto a Speckle Object. TherenderMaterialMUST be a property of thedisplayValue. (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.”