Refactoring / Improving the rebar tool codebase...

A forum dedicated to the Arch module development
Joel_graff
Posts: 573
Joined: Fri Apr 28, 2017 4:23 pm
Contact:

Refactoring / Improving the rebar tool codebase...

Postby Joel_graff » Mon May 14, 2018 4:53 pm

I was trying to fix a problem with the rebar tool where sketches ahd their placements rotated 180 degrees. However, while I can reassign a placement, it won't persist after a recompute. (The original conversation is here: https://forum.freecadweb.org/viewtopic.php?f=23&t=28346)

As I looked at it more, I realized there might be a better way of specifying how to lay out the rebar in the first place. Specifically, in addition to selecting a candidate face before selecting the rebar tool, an edge should also be selected which defines the rebar orientation. For example, in the image below, the selected face and it's bottom edge provide the orientation information necessary to generate a rebar layout parallel to the bottom face of the structure:
Capture.JPG
Capture.JPG (21.04 KiB) Viewed 384 times
This has a few advantages - first and foremost is no longer needing to specify "horizontal" or "vertical" orientations - the orientation is defined entirely by the selected face and the selected adjoining edge. Another advantage is that it becomes easier to parametrically bind the rebar sketch to the underlying structure, such that changes in the structure will update the rebar sketch (though the rebar objects would probably still need to be regenerated).

Anyway, I've started writing some code just to flesh out the idea, but it seems at this point the entire effort would require refactoring the entire code base. I don't think the rewrite would result in a more complex solution, and it would follow much the same file structure.

Obviously, I'd rather not rewrite anything, but I don't see an easy way to adapt the existing code to support what I'm interested in accomplishing... and I can't convince myself that my approach isn't worth pursuing. :)
chakkree
Posts: 258
Joined: Tue Jun 30, 2015 12:58 am
Location: Bangkok Thailand

Re: Refactoring / Improving the rebar tool codebase...

Postby chakkree » Wed May 16, 2018 3:05 am

I used DWire for an axis of rebar. In the figure is set of rebar shape(Not all case).
Attached DWire to face of the structure by map mode property, set to Plane Face and set offset(and rotation), then use Arch.makeRebar function.

RebarAttach.png
RebarAttach.png (240.68 KiB) Viewed 333 times
WireRebar.py
(21.89 KiB) Downloaded 10 times
Joel_graff
Posts: 573
Joined: Fri Apr 28, 2017 4:23 pm
Contact:

Re: Refactoring / Improving the rebar tool codebase...

Postby Joel_graff » Wed May 16, 2018 12:29 pm

chakkree wrote:
Wed May 16, 2018 3:05 am
I used DWire for an axis of rebar. In the figure is set of rebar shape(Not all case).
Attached DWire to face of the structure by map mode property, set to Plane Face and set offset(and rotation), then use Arch.makeRebar function.
I took a look at your example - very impressive.

I'm interested in parametrically constraining the sketches to the structure itself, so that the rebar layouts adjust to match later changes in the structure, so your example doesn't quite help, there. Still, it's a great example and it has me thinking about creating a rebar library made up of sketches / DWires to make it easier to maintian / add new shapes...
Joel_graff
Posts: 573
Joined: Fri Apr 28, 2017 4:23 pm
Contact:

Re: Refactoring / Improving the rebar tool codebase...

Postby Joel_graff » Wed May 16, 2018 7:14 pm

Here's a quick demo of the idea that I have for the rebar tool.

Essentially, the user picks the face and three edges. The selected edges represent the edge to which the rebar is parallel, and the edges which control the rebar cover. In the video, the macro uses a default 50mm cover value everywhere.

This would eliminate the ambiguity in laying out the rebar, making it obvious exactly how it's going to be laid out every time. I also used the macro to auotmatically constrain the rebar sketch to the structure sketch to ensure that the rebar sketch would resize / adjust with the structure (see image below)

phpBB [video]

Capture.JPG
Capture.JPG (36.53 KiB) Viewed 272 times
Joel_graff
Posts: 573
Joined: Fri Apr 28, 2017 4:23 pm
Contact:

Re: Refactoring / Improving the rebar tool codebase...

Postby Joel_graff » Wed May 16, 2018 8:31 pm

Another quick example of the selection technique. This demonstrates the use case I initially designed this for.

phpBB [video]
User avatar
bernd
Posts: 5823
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland

Re: Refactoring / Improving the rebar tool codebase...

Postby bernd » Fri May 18, 2018 11:20 am

do I understand you the right way? You would like to indroduce a direction for the rebar spaces? This could be a straight line as well as a curvrd line or a bspline?
Joel_graff
Posts: 573
Joined: Fri Apr 28, 2017 4:23 pm
Contact:

Re: Refactoring / Improving the rebar tool codebase...

Postby Joel_graff » Fri May 18, 2018 12:43 pm

bernd wrote:
Fri May 18, 2018 11:20 am
do I understand you the right way? You would like to indroduce a direction for the rebar spaces? This could be a straight line as well as a curvrd line or a bspline?
EDIT: It occurs to me I may have misunderstood your first question. I don't intend to do anything that would require touching Yorik's rebar code - i.e. the generation of the rebar solids. I'm only focused on generating and managing the rebar sketch.

Yes. I had two goals in mind with this:

1. Provide a more flexible / less ambiguous way to describe the rebar orientation within a structure than the current rebar tool allows
2. Constrain the rebar sketch to the structure geometry so that changes in the structure (small changes, anyway), will be reflected in the rebar sketch as well. The array of solids that Yorik's code generates will still be broken, but that's a simple matter of deleting the rebar object and re-running Yorik's rebar tool.

I hadn't considered circular / curved structures, though it would stand to reason that they should be accommodated as well. It may make goal #2 difficult / impossible to achieve, but I'd rather time was spent making something everyone finds useful. :)

I also had two other thoughts for generating rebar shapes instead of hard-coding it in python:

1. Create a library of shapes as existing sketches that can be used directly
2. Generate rebar shapes directly from structure edges... For example, if I pick an arc-shaped edge, that edge is cloned and used as the rebar shape directly in the sketch.

But those are stretch goals at the moment. :)
User avatar
bernd
Posts: 5823
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland

Re: Refactoring / Improving the rebar tool codebase...

Postby bernd » Fri May 18, 2018 4:05 pm

In my daily business I'm involved in rebar modeling and drawing. But since I'm heavily involved in FEM development I haven't had a look at the rebar code for at least two years.

My idea was to split the rebar tool (object) into two objects, one just for the shape of the rebar. The shape should be possible to take from a library, depending on a wire, depending on a sketch, may be directly depending on the structure (later will be difficult because of topological naming problem, but may be this will be solved ... ). The second tool ( FreeCAD object) is the placement in the structure and the direction and the spacing of the rebar shape. This includes the covering at begin and at the end of the spacings too. This should again possible with a simple vector or with a edge of a structure but a curved edge or a b-spline should be possible as well. Furthermore one rebar shape object could be used on dozens of places in a structure. For example in one floor if one has 40 columns of the same cross sections they may be use all the same stirrup. Thus they should use all the same stirrup rebar shape object, but any column has it's own placement object for the stirrups. May be one column could even have multiple placement objects or one stirrup shape because the space between the stirrups can change in one column.

Have you thought about this problem too?
Joel_graff
Posts: 573
Joined: Fri Apr 28, 2017 4:23 pm
Contact:

Re: Refactoring / Improving the rebar tool codebase...

Postby Joel_graff » Fri May 18, 2018 4:28 pm

bernd wrote:
Fri May 18, 2018 4:05 pm
My idea was to split the rebar tool (object) into two objects, one just for the shape of the rebar. The shape should be possible to take from a library, depending on a wire, depending on a sketch, may be directly depending on the structure (later will be difficult because of topological naming problem, but may be this will be solved ... ).
This reflects some of my thoughts as well. Thus far, I've only considered using sketches, but wires and existing structure edges are certainly valid as well. Even though chakree's example is auto-generated from python code, it makes a nice library of wire shapes to test with... As I previously indicated, I have considered using existing structure edges as a template for a custom rebar shape, which would be especially helpful for curved structure faces.

bernd wrote:
Fri May 18, 2018 4:05 pm
The second tool ( FreeCAD object) is the placement in the structure and the direction and the spacing of the rebar shape. This includes the covering at begin and at the end of the spacings too. This should again possible with a simple vector or with a edge of a structure but a curved edge or a b-spline should be possible as well. Furthermore one rebar shape object could be used on dozens of places in a structure.
I hadn't considered referencing a single object for repeated use throughout a structure. It makes obvious sense, though. The second object I suppose would be a FeaturePython object that perhaps contained the generated solids in addition to the placement data you described. That might make regenerating the solids based on structure changes more feasible.. ?

I don't really know. Admittedly, most of my FreeCAD experience is limited to the Sketcher.
User avatar
amrit3701
Posts: 166
Joined: Mon Jun 13, 2016 5:37 pm

Re: Refactoring / Improving the rebar tool codebase...

Postby amrit3701 » Fri May 18, 2018 5:03 pm

Joel_graff wrote:
Mon May 14, 2018 4:53 pm

This has a few advantages - first and foremost is no longer needing to specify "horizontal" or "vertical" orientations - the orientation is defined entirely by the selected face and the selected adjoining edge. Another advantage is that it becomes easier to parametrically bind the rebar sketch to the underlying structure, such that changes in the structure will update the rebar sketch (though the rebar objects would probably still need to be regenerated).
I think we can solve this problem. For eg., we will add a trigger which works like if specific host property (i.e. Structure Length) changes then recompute rebar tool rebars.