BHoM_Engine: Design the representation system

[alelom]

NOTE: Depends on

BHoM/BHoM#1179

Issues addressed by this PR

Closes #2288

Test files

Changelog

Additional comments

[al-fisher]

Happy to have a quick chat on this

[al-fisher]

Following comments here also: https://github.com/BHoM/BHoM/pull/1179/files
Might separate the two problems of Colouring/Rendering/Text etc. as a Graphics question.
And the Geometry question of - do you want to return 1D, 2D or 3D to represent the object.

A simple approach could then be to have for IElements - a common method which returns 3D geometry. Unifying Extrude methods etc.
The parent method could then also check inside Fragments as a fall back - for the case where user wants to store solid geometry representation.

Will be good to focus on this a primary example as immediately useful.

[al-fisher]

Suggestions from initial review of code for BHoM/BHoM#1179 and associated PRs to help potentially simplify.

I would do this work in a couple of phases - which I think will unblock and simplify reviews and also mean we can start using some features sooner.

As mentioned in my comment above - would separate the three tasks of:
1. Creating Graphical Entities,
2. Allowing common extraction of 3D Geometry from IElement3Ds and
3. the overall Representation framework.

---

1. Graphical Entities
First I would just implement the two or three new Graphical objects - Coloured Geometry, Text Tags, perhaps Arrows.
I would do these in the Graphics oM and implement in Rhino/Grasshopper the ability to convert and render them.
I would do this before adding complexity of a representation interface - as that can come later.

2. Extraction of 3D Geometry
After that / in parallel as it is independent, I would focus on creation of engine methods that enable returning of 3D volumetric geometry from Element1D and Element2Ds. I would focus on the use cases we have already which is Beams, Columns (FramingElements), Floors/Slabs, Analytical Bars, Panels, Ducts etc.
I think I would again as per comment above, keep this simple and maybe create a new query method called IGeometry3D in BH.Engine.Base - which works very similar to the default Geometry - but naturally returns 3D geometry. This centralises the calls - but allows the objects to decide to call their Extrude, or generate a mesh, or perhaps a bounding box etc. We could worry about options now - or can worry about it later as part of the Representation framework

As also commented above - this approach will allow implementation of a fall back to look for the specific mesh representation fragment when calling IGeometry3D. (really useful for attaching meshes etc on object for revit workflows etc.)

1 and 2. then become simpler and are already hugely useful. The IGeometry3D() method on its own is needed also to generalise at scale the IsContaining method in 3D for all IElements and our Spatial Specs. So good to decouple fully from representation work.

3. IRepresentation
The third part of this exercise around the Representations and centralising control though settings and configs etc. can come after the above - and then can I think potentially be very simple.
As discussed in the meeting for this issue #1877 the GetRepresentation can be a method which basically switches and attempts to call any of the above 1D, 3D, extract Coloured Geometry etc. methods on each object, depending on the config or user settings fed into the method, and or whether they are available as a method.

@alelom @rolyhudson @IsakNaslundBh - what do you think of above comments?
Can pick up in call tomorrow morning. Happy to do a hack with you to perhaps contribute and commit to this PR

[rolyhudson]

@al-fisher
Yes your break down above makes good sense for moving this forward in digestible chunks.

I had a quick chat with @IsakNaslundBh and I think that breakdown aligns with our discussion too.

@alelom and I have been nudging this forward and today I have focused in on 1 above. Working from the perspective of 3 use cases:

1. structural arrows
2. stadium
3. environmental floor based results

I have added test scripts for the 3 ucs and some initial results below.
Note the structural one is slightly different in that it uses an edited (for demo purposes only) Visualize method to output the geometrical representations while stadium and environmental floors are intended to show canvas (UI) representation creation.
stadium is a bit of a performance check as we are colouring 36k spectators.

Also solid surfaces looking a little murky in the floors image as I think we need to allow control of transparency as currently defaults to previous hardcoded 0.6!

A bit of candy text:

[IsakNaslundBh]

@IsakNaslundBh - what do you think of above comments?

@al-fisher Nothing to add really, as @rolyhudson alluded to in his comment. 100% agree with that strategy, and breakdown of 3 individual tasks that touch on the same subject but can be done in the order you have outlined above. So big +1 from me on your comment! 👍

[alelom]

Closed as replaced by BHoM/BHoM#1190 and #2304