Well, yes there is a de-facto dependency, but what’s the problem with this? If you delete the second wall, the first wall will just stay like it is, unless you force it to recompute it’s shape. Can you explain more this point?
And 2) A wall geometry would not be self-contained anymore. It would depend on another external to have its shape calculated. What if a user deletes the solver object? What if for any case it goes wrong? It could screw a lot of things. I really think that a wall should calculate its geometry itself, alone.
I got your point, I did this to avoid circular dependency, but if we use object names (App::PropertyString) istead of App::PropertyLink, this would be not necessary anymore. And yes, deleting the solver is an awkward perspective. So let’s go with App::PropertyString!
I’m thinking we could really implement your idea inside the Wall object.
Very happy to hear that, but also a bit worried I’m able to finish it
Let’s see!
what would you think of this:
- The wall object gains a PropertyStringList that holds the names of other walls this one should connect with
- For example, if Wall1 holds the name of Wall2, Wall1 is trimmed to Wall2 but Wall2 is not modified. If both Wall1 has Wall2 and Wall2 has Wall1, then it’s a corner case (both walls get trimmed to join)
- A function that tells the wall in which case we are above
- The wall object contains all the code to perform the trim
- The wall notifies all other walls that are in its PropertyStringList in case its shape changes
As for:
1 and 2) 90% agree, that’s exactly what I had in mind, but I’m not sure yet this can handle all usecases (but we’ll see when implementing it);
3,4,5) 100% agree.
I think we should also implement some basic methods in the wall object:
- get_base_point —> returns the center point of the wall
- get_core_axis —> returning a Part shape of the axis (Part.Line, Part.Arc, etc. )
- get_wall_axis
- get_inner_core
- get_outer_core
- get_outer_layer
- get_inner_layer
- and some more… what I think is that, in the usecase of the wedgewall, the functions could be forwarded to the BaseGeometry object, that will return the correct value to the wall… (but this could be performed also with a wall based on a sketch of course)..
Yes, I can understand this. But I think that’s good, because the graph will become a mess… we could eventually build our own wall joining graph in the future… And I don’t see any other option at the moment if we want to be the wall the actor who performs the joining operation.
Anyway, though my approach use Sketch which tackle many edges in one go, I had been thinking to treat the Junctions condition when calculating the baseplate profile for the Wall. So I hope if there is some mathematics codes could be shared here >
Oh, I didn’t know that. For sure there will be!
Also, I was thinking a bit about the approach of integrating archsketch into this new prototype… but thoughts are not enough mature to share. ![]()



