Giving a point, which of the inputs can you see.

@radumg might need some pointers on how to implement this.

IN[0] - Point, to analyse.
IN[1] - Objects to check if visible from IN[0].
OUT - visible objects from IN[1] (Might be a dictionary {Visble objects, Not visible objects})

1. How do we handle the fact that IN[1] can be different types? (ie. you want to check visible spaces from a desk, IN[0] - Desk Location IN[1] - Spaces as polygons.
   Or you want to check which surrounding buildings can you see from a new building, IN[0] - New Building mass IN[1] - Surrounding Buildings masses)

2. Should we make helper functions like, generate space polygons from rooms or do we leave that to be a user option so users define how the inputs for IN[1] should be. And if so how do we handle that this can be of different types.

Get Marks code

Look into 2d boolean operations

Need comments from Jacob

change hard-coded references to the type (gEdge in this case) to use this.GetType().ToString() in all occurrences of this pattern

Originally posted by @radumg in https://github.com/_render_node/MDE3OlB1bGxSZXF1ZXN0UmV2aWV3MjE5MzAyODgy/pull_request_reviews/more_threads

comment from PR #37

Also, it seems to be a glitch on the Isovist, getting inside the internal polygons. I know that is an error somewhere on the Graphical code but will need to be assessed.
(link)

Add to the description what the node returns eg. returns a number from 0-1 where 0 indicates no points are visible and 1 indicates all points are visible.

this could also be changed to be 0-100 and the description says a 'returns a percentage number between 0-100 that indicates how many points can be seen'

Shortest Path Node

• Implement Graphical in the GenerativeToolkit.Graphs project (Talk to Alvaro about removing all code not necessary).

• Quickest path & Sensible Path

are the classes defined in this namespace used elsewhere (like here) or just internally in Graphs functionality? if the former, we should move them to the GenerativeToolkit.Geometry namespace instead.

Originally posted by @radumg in #36

fixing comments related to PR #30

Since @alvpickmans kindly allowed Graphical to be forked for this work via the MIT license, we need to

• add a note to the source code files that were forked from Graphical, linking back to original repo & credit @alvpickmans
• include Graphical's license file in repo

For all other packages

• include licensing note as per that individual license

Packages

This applies to the following packages :

• Graphical
• MIConvexHull
• 3DContainerPacking

Rename the input of the PathFinding.ShortestPath from visibility to visGraph so it matches the PathFinding.CreateVisibilityGraph output port

Make the node accept cuboids and handle all CromulentBisgetti in the background

figure out if we can add a DisposeGeometry extension to all lists containing DS geometry so we can do curves.DisposeGeometry() instead of curves.ForEach(crv => crv.Dispose())

example use https://github.com/designtechIO/GenerativeToolkit/blob/eda36ca1abe58024491b092e7a53ab9c2b0aa935/GenerativeToolkit/Generate/AmenitySpace.cs#L96-L112

Copy from Alvaros code

When dealing with long methods (>30 lines of code), we should either

• split up functionality into private util methods in that class, based on the distinct steps in the method
• add // comments to document the distinct steps required, in plain English (the WHY, not just the WHAT code is doing).

Tasks

• identify long methods & create task here for each
• refactor them

I think this is confusing. We are driving the value from the point but the point really has no relationship to anything as you have to build the object width and length. Maybe this should be Openess.FromSurface and we remove the reference to the point. I also think we should remove the hardcoded values of 0, 0.25, 0.5 etc and instead use a percentage of the perimeter. So find the perimeter of the surface and calculate how much is open. Include a tolerance, so it takes into account objects that are a given distance away too, not just the ones that are coincidental. This should mean it can work on irregular shapes not just rectangles.

Set up default values where possible so the nodes can run without the need to add every input. As an example ViewsToOutside.ByLineSegments has 4 inputs - boundary, internals, view segments and origin. Internals should have a default empty list so the node can run with no internal obstructions. I'm thinking of L-Shaped or other irregular floor plates where by internal boundaries dont come into play but you want to understand the view from a point partly round a corner.

Like shortest path in 3D

Expected structure is having folders for :

• src
• docs
• test
• release (latest version of package for package manager)
• samples

Get Marks code

Individual nodes with placement methods (BSSF, BLSF, BAF)

• move Geometry out of Utilities namespace and into its own (folder, etc)

• move each internal geometry class to its own file and mark as internal

• if class actually only has extensions to DS geometry ), name it accordingly (CurveExtensions), move to Geometry.Extensions namespace, host in separate file and use the extensions pattern as mentioned here #70

Check openess of desk. give "Openess" score based on how many sides of desk is against a wall.

Score from 0-1. E.g -> if desk against two walls, score = 0.5, if desk against 3 walls score = 0.75.....

Need to complete documentation for the package and update the readme.md file to at least include :

• getting started (with screeshots)
• releases
• contributing
• authors
• licensing

The package needs to have

• documentation on how to use it

• well-documented samples in a samples folder on repo that gets shipped in the package's extra folder

Adjacency nodes with points

• List of points, find common point (2D/3D)

markdt [8:51 AM]
Another one for the finding closest point to a set of points.
You could add in a surface to this and the point cannot sit in that space
Sylvester Knudsen [8:55 AM]
So one of the inputs would be something like "areasToAvoid"?
markdt [9:33 AM]
Yes exactly
Dunno if any of this is possible
But they would have some epic use cases

• List of points and surface/polygon - find the farthest point.

Be able to make colors lighter or darker.

Expose Isovist method from Graphical as Node in GenerativeToolkit

Dynamo standard here : https://github.com/DynamoDS/Dynamo/wiki/Coding-Standards
(background : based off the Microsoft standards that we adopted at @designtechIO anyway)

We need to cover

• formatting
• namespaces
• documentation
• testing

Formatting

• format if statements as per standard, for example this one doesn't need { }

• remove un-needed code regions (see here for example and here. As a guide, only do a #region when it encompasses multiple methods, so in the last example, we can do a Constructors but don't need a distinction between public & private since they're one each.

• not have multiple public classes in one file : either spin them into a separate file and make internal or if not used elsewhere make them private

• remove dead/commented out code ([example] (https://github.com/designtechIO/GenerativeToolkit/blob/eda36ca1abe58024491b092e7a53ab9c2b0aa935/GenerativeToolkit/Analyse/AdjacencyPreference.cs#L85)) (use VS2019)

• determine if methods that are not used are still needed (for example OpenessScore)

• lift up magic values to private constants if applicable only in that class (example and in a public static class Constants if used across multiple namespaces. (use VS2019)

• throw when a method cannot return a valid response, for example when return is conditional on something (example) we throw instead of continuing and returning something potentially invalid/malformed

• rename output constants to something recognisable (here for example, rename to pathOutputName & lengthOutputName )

• use var instead of type where type can be inferred from right-hand side of expression/statement (example) (use VS2019)

• methods with 2 or more parameters should have them on separate lines for legibility, for example (use VS2019)

• make sure multi-return nodes/methods use private constants to specify output name (see here)

• clean up redundant namespace qualification for types where possible, for example Autodesk.DesignScript.Geometry is not needed since we added the using already. If we hadn't, nice fix would be to add it.

Namespaces

• rename Analyse to Analyze as we agreed to use US English (😞), both namespace and folder

• remove Evaluate folder & namespace as it's not in Generative Primer stages

Documentation

• add XML descriptions to classes
• convert // comments into XML comments even when classes/methods are private

Testing

• ensure Tests namespaces, classes & unit tests are named according to [Dynamo standard](https://github.com/DynamoDS/Dynamo/wiki/Coding-Standards#testing

• figure out performance benchmarking strategy (with @saintentropy )
• add unit/integration tests for performance testing

we need to

• convert Utilities.List class to host extension methods (rename to ListExtensions, make static, add this to the method's list parameter).

Anything else matching this pattern should also be an extension

@MarkThorley @radumg - a few notes on what this needs to do exactly?

Many methods can leverage the bail early principle to

• ensure a valid context & input before going further
• reduce the depth of code nesting and complexity of if/else branching.

For example, what happens when this method is given 2 points or 5 ? The first thing we should do is check the list of valid length (3 or 4 here) and if not bail
https://github.com/designtechIO/GenerativeToolkit/blob/eda36ca1abe58024491b092e7a53ab9c2b0aa935/GenerativeToolkit/Analyse/AdjacencyPreference.cs#L20-L30

In this context, bail means throw new Exception, using the appropriate type of Exception and having human-legible messages.

create Binpacking node for 3D volumes.
https://github.com/davidmchapman/3DContainerPacking

Change the example origin point so it is a uv value on the input surface. This will ensure the graph cant fail by the point falling outside the boundary

• identify all points where we create new DS geometry objects
• make sure we dispose of them

• Giving a point how many views do you have to the outside
• Giving a point how much view do you have to the outside (how do we measure the amount of view?)

IN[0] - Point
IN[1] - Outside (should this be an area, if so how should it be represented?)
OUT - ???

@radumg @MarkThorley

Need to confirm with ADSK @saintentropy if we'd like to expose all 19 standard colours as individual nodes.

Right now, it's not hard for users to get to them by using the ContrastyColorRange node and then a GetItemAtIndex node to get a specific colour. Would adding 19 nodes add any value ?

Comment from PR #37

Change placement method nodes.

AND Combine intersecting rooms separated only by boundary lines