Refactoring / Improving the rebar tool codebase...

A forum dedicated to the Draft, Arch and BIM workbenches development.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
User avatar
Joel_graff
Veteran
Posts: 1949
Joined: Fri Apr 28, 2017 4:23 pm
Contact:

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

Post by Joel_graff »

amrit3701 wrote: Fri May 18, 2018 5:03 pm 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.
That would certainly help. I would point out in my approach I added specific constraints to ensure the ends of the rebar were always a specific offset from a selected edge. Also, if the structure edge changes orientation, because the rebar is constrained in parallel, it's orientation will change as well.

I can provide the code I developed if you're curious - it took surprisingly little to build it.
Last edited by Joel_graff on Fri May 18, 2018 7:11 pm, edited 1 time in total.
FreeCAD Trails workbench for transportation engineering: https://www.github.com/joelgraff/freecad.trails

pivy_trackers 2D coin3D library: https://www.github.com/joelgraff/pivy_trackers
User avatar
yorik
Founder
Posts: 13640
Joined: Tue Feb 17, 2009 9:16 pm
Location: Brussels
Contact:

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

Post by yorik »

Several additional thoughts:

About splitting the Rebar object: The rebar object is just an extrusion of a circle along a 2D "path", to form a pipe, and then a number of repetitions (which can be only one) of that pipe. I don't really see the point to split that any further?

What we could do, however, is this: Suppose you have one rebar definition, for example a stirrup. It is a standard rebar object like any other, but its number of repetitions is set to one. In other words, it has only one bar.

Then, we could use it as a base for other rebar objects, instead of a sketch. But then, instead of calculating an extrusion, it would just copy the base rebar. So you could have one base stirrup, then place series of that stirrup, with different spacings and quantities, in different situations. That would be pretty simple to code, and I think pretty flexible. How does that sound?

About Joel's experiments, that's interesting. The current rebar tool is made to work with any 2D object that can be used as an extrusion path, being sketch or any other object. I think the best way to work with an automatic offset from existing edges would indeed be to create an intermediary object, that would be used as a base for the rebar.

Working with sketches is useful from a graphical interface point of view, but programatically I wonder if it wouldn't be easier to use another kind of objet, maybe a combination of the lattice shapebinder, to create a copy of some edges form the solid, and a Part2Doffset?

About the trigger to recompute, it is normally there already (see onChanged method of ArchRebar.py at L253), but it might be buggy...
User avatar
Joel_graff
Veteran
Posts: 1949
Joined: Fri Apr 28, 2017 4:23 pm
Contact:

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

Post by Joel_graff »

yorik wrote: Fri May 18, 2018 7:02 pm Then, we could use it as a base for other rebar objects, instead of a sketch. But then, instead of calculating an extrusion, it would just copy the base rebar. So you could have one base stirrup, then place series of that stirrup, with different spacings and quantities, in different situations. That would be pretty simple to code, and I think pretty flexible. How does that sound?
I'm certainly fine with whatever - I'm mostly interested in seeing the rebar retain it's sizing and spacing relationship with the structure as the structure dimensions are changed (hence my interest in a constrained sketch and automatic recompute for the solids).
yorik wrote: Fri May 18, 2018 7:02 pm About Joel's experiments, that's interesting. The current rebar tool is made to work with any 2D object that can be used as an extrusion path, being sketch or any other object. I think the best way to work with an automatic offset from existing edges would indeed be to create an intermediary object, that would be used as a base for the rebar.
The only complicating factor to this approach (as I've considered it), has been more complex rebar shapes. In my example, I used a simple straight bar. To place it, I selected three edges. The first and third provided the edges from which the bar ends were offset. The second was the edge to which the bar itself was held parallel. A more complex shape could require more references.

Nevertheless, because I transformed the rebar coordinate system so that the x-axis was always along the reference edge (the second edge selected), it didn't matter how the structure was rotated or which face I chose, and that made orienting and constraining the rebar really easy. I don't assume, however, that it's better. It solves one problem with the rebar tools as they are, but trades off a bit on the user experience. It doesn't really add that much, IMO.
yorik wrote: Fri May 18, 2018 7:02 pm Working with sketches is useful from a graphical interface point of view, but programmatically I wonder if it wouldn't be easier to use another kind of object, maybe a combination of the lattice shapebinder, to create a copy of some edges form the solid, and a Part2Doffset?
Definitely out of my depth ;) It's got me curious though - I should start playing around with that stuff...
FreeCAD Trails workbench for transportation engineering: https://www.github.com/joelgraff/freecad.trails

pivy_trackers 2D coin3D library: https://www.github.com/joelgraff/pivy_trackers
User avatar
chakkree
Posts: 327
Joined: Tue Jun 30, 2015 12:58 am
Location: Bangkok Thailand

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

Post by chakkree »

yorik wrote: Fri May 18, 2018 7:02 pm
Then, we could use it as a base for other rebar objects, instead of a sketch. But then, instead of calculating an extrusion, it would just copy the base rebar. So you could have one base stirrup, then place series of that stirrup, with different spacings and quantities, in different situations. That would be pretty simple to code, and I think pretty flexible. How does that sound?
I agree with this concept. I think it will be easy to coding for make Bar-cut list and export rebar to IFC.
In the Bar-cut list:
  • get the SVG shape for base rebar put it to a sheet and get length and number of copy's rebar to make full rebar schedule.
Export to IFC:
  • Export base rebar -> IfcRepresentationMap
  • Export copy of rebar -> IfcMappeditem
paullee
Veteran
Posts: 5098
Joined: Wed May 04, 2016 3:58 pm

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

Post by paullee »

Joel_graff wrote: Fri May 18, 2018 12:43 pm
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.
...

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.
I do not use rebar (tested only) as I am not structural engineer.

You know well that, as the structure changes, the 'link to external geometry' will break. I can't help myself to experiment how sketch's edge 'identity' could persist - abdullah advised that there will unlikely to be fixed in sketcher for that.

https://forum.freecadweb.org/viewtopic. ... 01#p234801
https://forum.freecadweb.org/viewtopic. ... 01#p232797

If sketch edges' certain identity is somehow persistent, which build a wall, I can set out e.g. a door from these walls (edges) and changes the layout / sketch's edges would not break it. Likewise, if the structures were built from sketches, the selection of edges may persist over changes.
User avatar
Joel_graff
Veteran
Posts: 1949
Joined: Fri Apr 28, 2017 4:23 pm
Contact:

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

Post by Joel_graff »

paullee wrote: Sun May 20, 2018 9:23 pm If sketch edges' certain identity is somehow persistent, which build a wall, I can set out e.g. a door from these walls (edges) and changes the layout / sketch's edges would not break it. Likewise, if the structures were built from sketches, the selection of edges may persist over changes.
Thanks for the links. I wasn't aware of that conversation.

It's a given that links break. Just making a large change in the structure will likely break something. I still see value in at least allowing for this feature if only because rebar design is a finishing detail. That is, the user is likely to have dialied in the structure design for the most part by the time they start working on the rebar layout. I'll grant, that's a broad assumption, but I'll be that in most contexts, that holds true.

Honestly, I wouldn't worry about anything else beyond sketch-to-sketch constraints...
FreeCAD Trails workbench for transportation engineering: https://www.github.com/joelgraff/freecad.trails

pivy_trackers 2D coin3D library: https://www.github.com/joelgraff/pivy_trackers
User avatar
yorik
Founder
Posts: 13640
Joined: Tue Feb 17, 2009 9:16 pm
Location: Brussels
Contact:

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

Post by yorik »

The whole issue with TopoNaming (the problem that reference names can change), depends largely on how predictable a shape is. A sketch is largely unpredictable, because the solver will constantly reevaluate everything and might choose a different "path" next time, and therefore reorder its output. But more basic shapes like Arch structures are very predictable, especially when based on also very predictable draft profiles. They are always built in the same order, and the chances that it can change over time are very reduced.
paullee
Veteran
Posts: 5098
Joined: Wed May 04, 2016 3:58 pm

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

Post by paullee »

Joel_graff wrote: Sun May 20, 2018 11:31 pm
It's a given that links break. Just making a large change in the structure will likely break something. I still see value in at least allowing for this feature if only because rebar design is a finishing detail. That is, the user is likely to have dialied in the structure design for the most part by the time they start working on the rebar layout. I'll grant, that's a broad assumption, but I'll be that in most contexts, that holds true.
Fair enough. In fact a very good point :D Nothing to worry about.

That's why usually some structural engineer around do not even do re-bar design until construction starts - seem architect like to change always, structural engineer wait until everything settle! Civil engineer handle all design and detailing?

yorik wrote: Mon May 21, 2018 2:51 pm The whole issue with TopoNaming (the problem that reference names can change), depends largely on how predictable a shape is. A sketch is largely unpredictable, because the solver will constantly reevaluate everything and might choose a different "path" next time, and therefore reorder its output. But more basic shapes like Arch structures are very predictable, especially when based on also very predictable draft profiles. They are always built in the same order, and the chances that it can change over time are very reduced.
Thanks for explanation!

For sketch, 'internally', I find there is no TopoNaming problem to my best knowledge. I find 'problem' come from how other feature/object use sketch and sketcher 'mechanism'...
  1. Every sketch element has an Geometry Index, and they are just Stable - in the sense that recomputing etc. won't change it. (Afterall, it is user who 'create' each element, not automatically generated by OCC, so it shouldn't suffer from 'randomness' of 'TopoNaming' issue).
  2. But other object/feature use the 'external' shape of a sketch but not the geometry 'internally'.
  3. Then, sketcher 'shift' the index when a user delete an element 'in the middle' within, say of 'index 5' out of index 1 to 10, sketch 'shift' 6 to 5, 7 to 6 (still in order) - not much a problem if this index is 'propagated' to all others.... then learn from abdullah about sketch.geometry[index].tag ...
So, if internal index/tag is used ( + track the change in index etc.) no more problem and I can always find the same line no matter what change / recompute are committed - a troublesome circumvent before works like Realthunder's will be incorporated.

- Lessons learned (after suffering sketch attached to Walls changed position after recompute :( ) bit by bit thanks to lots of peoples here :D
User avatar
eccioloste
Posts: 37
Joined: Tue Sep 26, 2017 2:59 pm
Contact:

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

Post by eccioloste »

Hello. I hope this is the right forum page to post this!

I have been using the rebar reinforcement addon for a while. I find it awesome.
example.JPG
example.JPG (302.72 KiB) Viewed 1157 times
I have found some issues with the rebars of structural walls. I created a wall in the arch wb and then I modeled the vertical main rebars in it, I need to draw the secondary reinforcement (horizontal rebars along the front face) but the "Straight bar reinforcement..." option doesn't support wall. In the help screen you are instructed on how to draw rebars on beams, pillars and slabs, but walls are not contemplated. Whichever face I choose, the rebars will end up as straight rebars on the wrong side.
My only way through this is to create an auxiliary beam, but it's really not an elegant way for solving this issue.
I tried to change the IFC type as well, but that doesn't work.
wall_straight reinforcement.JPG
wall_straight reinforcement.JPG (198.21 KiB) Viewed 1157 times
I'll attach my model.

Regards
FS
Attachments
wall_reinforcement.FCStd
(360.08 KiB) Downloaded 24 times
Post Reply