Selection
The problem with selection arises when we have a non-quad shape in a rule production.
Indexing of regions, for instance in the context of the grid rule works well as long as we have [0-3] indexes for W(est), N, E, S directions.
Instead of one type of index based on orientation, or distance from the boundary, we need other types of indexing methods, for instance those that are semantically-aware.
It would be nice to have the following selection modes
- Edge interval that was result of the peel operation
- when placing something between the peeled regions
- Outer iregion edges
- when placing something on the boundary
- Direction based (W N E S) edge selection. If we have multiple edges facing West, parametrisation, by length, will be of the combined edge length – those facing west
- we want to place trees on the south-facing borders
- Direction continuity selection. Selection for West-dc edges will also include edges NOT facing west, IF they are resulted from operation from west facing edge OR (!) when they are enclosed by west facing edge.
- we want to place trees on the west side of the park but not all edges may face west
Index operators v2.1
Peel based selection
Shapes that result from the peel operation allow edge selection based on what was peeled. For instance a is the selection passed to the peel operation; b and c were extruded.
- PEELED_BASE, short version – PB, the ‘a‘ segment in the image
- PEELED_INNER, PI, ‘b’
- PEELED_SEGMENT, PS, ‘cbc’
Implementation Details
During peel operation a and b are recorded by storing copies of the points. Another operations on the derived shapes can make selection based on these edges, for instance for PEELED_INNER selector if an edge endpoints are in b, then it is selected.
Boundary Indexing
Two options for such:
- Edges incident to iregion (corners). The problem is that there may be more vertices between two corners – we need to consider an ‘edge’ between two corners NOT vertices.
- All edges resulted of splitting or modifying iregion edge. Edge implementation does not need to be changed however more operations – intersections – are required; extra problems might arise from the intersections.
Enumerated Indexing for Grid
We are returning to enumerated indexing.
Lets consider the 1×1 path (2×2 regions) case again.
Indexing shall start at the iregion corners. The direction will be determined where the second index is.
Since iregion indexing starts at SW – the lower left corner, it shall be mirrored to the remaining elements (in 2×2 regions it is simple!).
Polygons are ALWAYS oriented one way, in our case clockwise. The indexing system allows us to avoid re-ordering vertices after each operation!