How can aggregation engine pickup different rules in a field driven?

Hello everyone,

I am currently working with Assembler plugin and I am stuck and want help.
Idea is to create an assembly of H-shaped block that pickup planar rules in the planar region (wall & floor area) and it should also pick up turn rules in the turing region (wall and floor junction). I find assembler as tool for doing that. I am not sure why my setup is not working the way I want.
How to apply rules for different iWeights
Currently, I am trying to aggregate in a field based environment. I have setup different iWeights (0-2) and I have setup 3 different rulesets in 3 different branches.


Ruleset_0: I want iWeight β€œ0” to pick up ruleset_0 (0;0) which comprises of planar rules.
Ruleset_1: I want iweight β€œ1” to pick up ruleset_1 (0;1) which are turn rules.
Ruleset_2: I want iWeight β€œ2” to pick up rueset_2 (0;2) which are again planar rules.

I am using a H-shaped block to create interlocking rules (Heuristic Set)


I am not sure why this setup is not working if someone could tell me how can I approach this? You can see a gif attched that shows aggregation stopping at the floor system and not turning to create wall system.
assemblageanimation

For refrence, I have attached the rhino8 and Gh file here.
H-shaped_block.3dm (255.4 KB)
H-block_Aggregation.gh (65.5 KB)

Hi @naitik264,

the issue is in the field points distribution: the field points, especially in the case of sparse fields and concave geometries, must be distributed as homogeneously as possible, otherwise weird things can happen in the areas where the points follow an abrupt direction change due to the geometry. In your case, this is in the floor-to-wall corner. If points are not equally distributed in space, the engine might find a closest point in the wall before finding one in the corner. When this happens, the chosen ruleset is the β€œwall” one and it runs out of applicable rules because the geometry continues horizontally and exceeds the field.

So, instead of creating the field point distribution with Construct Field XYZ, I suggest using Construct Field N, using the largest number of cells as the N input. For comparison:


You can also use the ConstructFieldFromResolution to control the distance between points.
Also, with individual values in XYZ and Sparse Fields, you risk other weird effects such as the Assemblage not even starting for certain irregular points distributions: right now, if an object is found outside the search radius (which is computed during setup based on distances between Field points), it is marked as unreachable to prevent assemblages from growing too far away from a Field. If points are too sparse, the starting object might be classified as too far and marked unreachable, thus preventing the Assemblage from even starting. This happened when increasing some individual values in Construct Field XYZ. When I switched to Construct Field N it never occurred again. I might revise the method Assembler uses to compute how and when objects are considered too far away form a Field, but for now consider building Fields with points placed as regularly as possible.

I’ve included a different way of creating the L geometry: I do not have Pufferfish, but since I’ve seen you use a Mesh offset method, be careful: offsetting corner faces with different areas might lead to irregular results.


H-block_Assemblage_AE.gh (111.3 KB)

Thank you @ale2x72 for your explanation, it is now clear why it failed in my attempt, yes I see your method of creating mesh offset is better than what I was using earlier, earlier one had unequal offset. :100: