Joints with screws not adapting to parametric joint depth

[yck011522]

Adjusting joint height of a planar lap joint with a screw will result in a screw embedded in the joint.

Need to fix this to model the hyper roof with customized joint depth.

[yck011522]

This can be logic to assign screw type. Basically, the choice of which screw to use depends on MovingSide/ScrewheadSide Thickness (MST) and the Total Thickness (TT)

[yck011522]

[yck011522]

Joint_halflap is defined in ocf while JointNonPlanarLap is defined in wcf. This is annoying as hell because one always needs to be fed with the beam to be able to compute where things are. Trying to put the Screw (defined in wcf) inside the joint is very annoying.

I have refactored to have one screw object for both joint sides. They will be shared. I have added set_joint_shared_attribute and get_joint_shared_attribute to Assembly to deal with this sharing. (Other joint_attributes that are shared among the joint can also benefit from this sharing in the future.)

• joint_attrivute has_screw ,

compute_joint_screw_hole() has to be rewritten (TODO)

Joint_halflap_from_beam_beam_intersection

I'm struggling with whether to put the screw outside or inside the Joint class.

• In the past, the screws belonged to the joint. but it doesn't make sense because now one screw can be shared with both joints.
• If inside, the joint can serialize it. But when it comes to flipping, it is

Things that called the add_joint_pair() function. I probably should do the add screw there.

• assembly.shift_beam_sequence()
• assembly.search_for_halflap_joints_with_previous_beams()
• rhino.assembly._add_beams_to_assembly()

Especially because we need to support the flip joint function. Which will also flip the screw.

• Changing assembly sequence of planar
• Flipping a planar joint screw is simply reversing it and flipping the head_side_thickness.
• Flipping a NP joint screw require recreating it.
• It is better to always re-create the screw anyways.

I'm also struggling how we can compute the screw center line of the joint intersection. Ideally, it is computed when the joint intersection took place. But the actual computation is ...

[yck011522]

okay, I refactored the screw to Assembly level.

There are two parameters needed to create a screw: screw_line and head_side_thickness. However, there are two possible Screw types and each covers a different parameter range (screw_line and head_side_thickness). Some parameter combinations are not valid and a warning is necessary to inform the user (When Assembly method demands a screw but the parameters are not possible)

However, the problem seems to be much more complicated than I expected due to the many functions that can change a screw:

• Add Beam -> New Joints -> New Screw
• Delete Beam -> Delete Joints -> Delete Screws
• Changing Assembly Method -> Add or Delete Screw
• Flip Beam assembly direction -> Flip Joints -> Flip Screw
• Change of assembly sequence -(may cause)-> Joint_flip -> Flip Screw
• Change of Joint.thickness -> Change screw intrinsic (size) / extrinsic (head_side_thickness)
• Manual override to another Screw Size

It needs to work with both JointHalfLap (flippable) and JointNonPlanarLap (non-flippable).

There are two design time workflow: (1) Stateful approach

• Screws are computed and stored (manual add or based on heuristic)
• when dependent variable changes, recheck if parameters are still valid
• if not, attempt to auto reassign
• if fail, prompt error message.

(2) Functional / Stateless approach

• Screws are not stored but are computed on-demand from the dependent variables (including user preference)
• user preference may not be respected if it is not one of the valid options
• If no valid solution, prompt a error message.
• (User Preference / Override is a top level parameter, if it is not valid, we can either erase that or keep it but ignore it)

In both cases, the dependent variables (screw_line and head_side_thickness) need to be available to the recompute function at those times. In our case, these dependent variables are also subject to changes, and therefore must be updated before or are declared functionally (stateless).

Stateless / Functional approach has less dependence ordering to manage.

[yck011522]

Close by 421974a9231fc55609628a0620404dcf6f5ddfa5

[yck011522]

I think Grasshopper did a fantastic job at dealing with dependency updates and the visual nature makes the hierarchy very obvious.

The problem I currently face is that the hierarchy is not obvious within Dependency Class. Because the Dependency class does not keep tract of state (parameters as beam and joint attributes), it is very hard to for me to trace and make sure there are no circular dependencies for these parameters. Where as in GH, this gives a warning immediately when attempting to make such a func graph.