Refactoring / Improving the rebar tool codebase...

A forum dedicated to the Draft, Arch and BIM workbenches development.
Joel_graff
Posts: 1000
Joined: Fri Apr 28, 2017 4:23 pm
Contact:

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

Postby Joel_graff » Fri May 18, 2018 5:26 pm

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.
User avatar
yorik
Site Admin
Posts: 10725
Joined: Tue Feb 17, 2009 9:16 pm
Location: São Paulo, Brazil
Contact:

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

Postby yorik » Fri May 18, 2018 7:02 pm

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...
Joel_graff
Posts: 1000
Joined: Fri Apr 28, 2017 4:23 pm
Contact:

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

Postby Joel_graff » Fri May 18, 2018 7:38 pm

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...
chakkree
Posts: 258
Joined: Tue Jun 30, 2015 12:58 am
Location: Bangkok Thailand

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

Postby chakkree » Sat May 19, 2018 2:44 am

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
Posts: 1326
Joined: Wed May 04, 2016 3:58 pm

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

Postby paullee » Sun May 20, 2018 9:23 pm

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.
Joel_graff
Posts: 1000
Joined: Fri Apr 28, 2017 4:23 pm
Contact:

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

Postby Joel_graff » Sun May 20, 2018 11:31 pm

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...
User avatar
yorik
Site Admin
Posts: 10725
Joined: Tue Feb 17, 2009 9:16 pm
Location: São Paulo, Brazil
Contact:

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

Postby yorik » 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.
paullee
Posts: 1326
Joined: Wed May 04, 2016 3:58 pm

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

Postby paullee » Tue May 22, 2018 12:48 am

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