Improvement: Implement Lightweight geometry library

[ThomasMahon]

Dynamo version

1.2.1

Operating system

Win 10

Improvement Suggestion

Would it be possible to implement the equivalent of GC's Lightweight DGeometry in Dynamo? Firstly, I'll explain what it is: a basic library of geometry - in fact the Revit API Xyz object is effectively the same thing - which doesn't implement all of the overheads (associations) that are typical with top-level features. For example, a Circle can be created using a number of methods: Point, plane and radius. In this example a top level Cricle stores all of these elements as properties, and each of these properties stores their own properties and so forth. The 'data-tree' therefore becomes complex and the feature itself becomes 'heavy' (as it uses more memory).

Lightweight geometry is the opposite; all features depend on a single world coordinate system XYZ(0,0,0) and as a result all of the aforementioned overheads are minimised. In GC a lightweight DEllipse3d has few creation methods, primarily vectors, points and sweep angles. These 'properties' reference the global coordinate system which therefore simplifies the data-tree hierarchy making it 'lightweight'. These features are geared towards advanced users working on projects with a large amount of data as they are not user-friendly and rely more on applied mathematics to operate.

In Dynamo I recently attempted to create a few 1000s points from an Excel spreadsheet and noticed it became unresponsive after about 20000 points were created. Using GC I got up to 100,000 using its Lightweight DGeometry library and it was still fully responsive. Implementing this type of functionality would make Dynamo far more versatile, particularly where large datasets or complex models are concerned.

This library could be a user-controlled feature, i.e. the same as T-splines, where the user has to turn it on, so as to not interfere with typical Dynamo usage by the vast majority of users.

[tatlin]

@ThomasMahon yes, good idea! we have thought about that a bit. CC: @ColinDayOrg @aparajit-pratap @kronz

[kronz]

@ThomasMahon Yes! this is something we have just barely begun discussing. One approach we have thought about is to try and make a low level primitives functionality (possibly even just points and lines) and actually replace regular points and lines with these tools, then allowing an automatic conversion to ASM based points and lines when/if user wants to do anything else with them. The idea here is that Points and Lines are such basic elements and so widely used, that making an interface to these that are easy access is worth it for accelerated geometry creation for all users (not just the advanced). You are suggesting creating an entirely parallel geometry library with (I think) more restrictive interfaces and a full contingent of primitives (cones, cylinders, etc). Can you say more about what it is you would be doing with these, and why you (as an advanced user) would use the one library versus another.

[ThomasMahon]

@kronz Points and lines would be a great start and would certainly provide benefits to users of all levels, especially if it can be converted to top-level features where needed, as you suggest. Vectors, bounding boxes and 'plane-like' objects such as arcs and ellipses would also be welcome additions. Transformations and other functions such as angle measurements would also fall within these features.

Since lightweight geometry relies on a single world CS (and calculus), as far as I understand, it wouldn't be possible to create a parallel geometry library so I wouldn't expect one. Typically, lightweight geometry is used as construction geometry (as only primitive elements can be created) in cases where there is a significant overhead employing top-level features. The lightweight geometry is largely an intermediate step in a broader process that usually ends with a top-level feature. A project I recently worked on involved rationalisation of a complex double-curve roof structure using lightweight geometry, and it was only the final step that involved any top-level feature, significantly improving model efficiency.

To fully answer to your question then, I typically use lightweight geometry when dealing with optimisation processes as it can become counter-productive to use top-level features. Since optimisation normally involves generative iterations of the same construction geometry until the optimal goal is found, top-level features can severely hamper performance and all of the properties they implement are largely redundant for such exercises. The use of lightweight geometry is not limited to optimisation techniques though, there would be many other benefits:

1. Point Cloud workflows
2. Clash Detection optimisation
3. Large and/or geometrically complex buildings (airports, towers, master-plans etc) that generate large amounts of building information (i.e. pure parametric modelling)

Assuming that this library would be restricted to a few fundamental types, another possible side-benefit, that could see it exposed in the main geometry library is the implementation of lightweight geometry properties in all top-level features (so all curve types implement a lightweight vector and transformation etc). Its this kind of functionality that I believe would add to Dynamos versatility.

[radumg]

Not sure if this is still something you'd need @ThomasMahon , but we've essentially had to do this for the Refinery Toolkits to enable the speedy computations we needed. Workflow was very similar, use the lightweight versions in all computations and output normal Dynamo geometry to end-users as the final step.

Have a look here : https://github.com/DynamoDS/RefineryToolkits/tree/master/src/Core/Geometry

If this is something @Amoursol thinks would be valuable to more users as a stand-alone item, we could look at spinning it out as a separate package to be consumed as nodes.

[ThomasMahon]

@radumg Yeah that's essentially what I'm after however this was many years ago...and times have moved on - plus I really want to avoid having to write everything from scratch when there are already libraries out there which off this and a lot more. In any case I'm gradually moving away from Dynamo/Revit for anything geometry related in my apps, and exploring other geometry engines which already have the functionality I need.

Also if we want to achieve high performance, C++ and minimising the use of linq etc is really the way to go if there is an effort to create such a library.