Goede morgen Kelvin, I’ll answer on the parts that i’m credible on! I’ll leave the rest to y’all structural folks.
I remember we did discuss this previously, but only for visualising results (e.g., moment diagrams). This can definitively happen though, albeit there’s going to be quite some artistry and threejs-magicness involved. Some points:
- would be good to have a set of “prior art”, so we can understand how these are usually displayed
- anything line based is not optimised for display yet, as @cristi didn’t have time yet to look at that, and this might influence a bit how we structure those conversions into threejs objects.
My gut feeling here is to go, at first, with adding them as dynamic props, and being defensive on the conversion toX side (ie, checking if the prop exists and isn’t null before actually using it). We can always cement those props later in actual classes. (why i’m thinking like this: it’s very easy to add props to a class, but it’s very difficult to remove them afterwards)
Why not? I think @Jedd needed some too. I would, though, include them in a separate project, outside of the Object model. B
Oh yeah, i kinda wanted that too for some time. IIRC, the default toString() of a base object returns it’s fully qualified type (by speckle deserialisation standards), but we’re not relying on the toString() method itself. Two options:
- we decide on a common way to do it in Base, e.g., just use the last, most specific type
- override it on a class by class basis
The problem is one takes the arguments from the schema info constructor, and ESO just uses alphabetical order. Not sure what the best way would be, perhaps ensuring the schemainfo constructor’s args are in the same alphabetical order? this might not always make sense 
Over to @Reynold_Chan for the structural parts, and @AlanRynne if you have time, feel free to chime in on the grasshopper parts!