Proposal for GSoC'17

[yorik]

Hi @amritpal3701,

Here is a little "preparatory task" that I suggest you start with, before attacking your GUI work. It is not much work, but I believe it will be beneficial both tothe Rebar object and to you to get the hand on the "internal" working of the Rebar object. Basically it implements the points that have been discussed with Bernd in a previous topic, to make the Rebar object ready for any kind of situation. @bernd, feel free to add what you feel is needed to what I explain below.

The current situation:

The current Rebar object is defined in src/Mod/Arch/ArchRebar.py. It is a Part::FeaturePython object (L160), that produces a shape, which is basically a series of tubular objects, made by sweeping a circle along a path, then duplicating that sweep at regular intervals. This is all done in its execute() function (L240).

The circle that is being swept is defined by a Radius property of the Rebar object. The sweeping path is defined by a Base property (inherited from ArchComponent.Component), which is a link to another Part-based object, for example a sketch, or a Draft wire, but any shape that contains at least one wire will work. Before doing the actual sweep (at L290), a fillet is applied to the wire, controlled by the Rounding property (L263)

The problem:

Once the sweep is done, the resulting shape is duplicated a certain amount of times, at a certain interval (L310). This is fine for "straight" elements like a straight beam or a column, where rebars are regularly spaced (ex: stirrups), but falls short in a number of more special situations: curved beams, or irregularly spaced copies (for ex. groups of rebars all based on the same profile but placed at different positions in the beam), or radial situations (in a cylindrical column).

The solution I propose:

I have introduced a couple of weeks ago, a new property type: App::PropertyPlacementList, that hols a list of placements. We could use that property to make the rebar object able to fullfill the problematic situations explained in the above paragraph. At the moment of duplicating the sweeps, we could use a different placement for each duplicate, and therefore we could meet just any situation. I propose therefore to do the following:

1. Add a new App::PropertyPlacementList in the Rebar object's __init__() function
2. Around (L310), instead of immediately applying the base offset to each duplicate, create a list of placements instead. The first one being a null placement, and the next ones each getting spaced by the base offset.
3. Store that list of placements inside our new PlacementList property
4. Instead of applying the base offset to each duplicate, apply each placement of the list to each duplicate. So instead of one loop at L310, we will now have two (one that fills the PlacementList, and another that applies the placemetns of the list to each duplicate).
5. Move all this code that calculates the Placements list out of execute(), in another function, for example calculatePlacements(). This would allow us, in the future, to build other kinds of Rebar objects, that might calculate the Placements in a different way. Those objects will then just need to override the calculatePlacements() function. That is more or less from L303 to L310, including the changes we will do in the points above.

This will have no apparent change to the user. You will stil control the rebar object the same way as before. And the user won't see the PlacementList property, because it won't be visible in the properties list (it has no editor yet). But this is fine, because this property is only for internal use, it is not meant to be edited directly by the user.

But, internally, our rebar shapes are not controlled just by a straight array of distances anymore. Each rebar now has its own placement. So the possibilities are now much more. So this sets us right for the future, and we don't build something on a limited data structure anymore. For example, we could now havea complex GUI that calculates the placements directly.

I think this will aslo give you a good grasp at how the Rebar object works internally, which will be very useful for your GUI work later. Also, the list above can be done (and committed) step-by-step, which will help (although you already did pull requests before) getting the whole git / pull request routine rolling too.

What do you think? If anything is not clear, tell me and I'll explain better.

[amrit3701]

If anything is not clear, tell me and I'll explain better.

Thanks for too much detailing.
Everything is cleared till now. I will give updates here as soon.

Regards,

[bernd]

@Yorik: I do not even find some typo on you explanation. It is just unbelievable detailed ...

For the structures I do (mostly buildings) I would need such flexibility quite seldom but the guys who do bridges and other structures along roads they need exact such flexibility to use make rebars along curved line quite often. Ahh and if Santiago Calatrava or Frank Gehry ever knock on my door ( It is a pitty Zaha Hadid can not anymore ) I would need that feature for sure ...

As Yorik said it would be a very good start !

[amrit3701]

What do you think?

I have sent pull request at (https://github.com/FreeCAD/FreeCAD/pull/780) in consideration of your recent proposed solution. Kindly review it.

Thanks.

[yorik]

That seems perfect @amrit3701! I'll give it a quick test then commit.

[saso]

When running unit tests from the gui there is this error, I believe it is there actually already for some time

Code: Select all

typecheck[scaleTo]: -20000000000 is not (<type 'int'>, <type 'float'>)
Traceback (most recent call last):
  File "C:\Users\saso\Desktop\FreeCAD_0.17.11203_x64_dev_win\Mod\Arch\ArchRebar.py", line 274, in execute
    size = (ArchCommands.projectToVector(father.Shape.copy(),axis)).Length
  File "C:\Users\saso\Desktop\FreeCAD_0.17.11203_x64_dev_win\Mod\Arch\ArchCommands.py", line 534, in projectToVector
    return DraftVecUtils.scaleTo(vector,maxl-minl)
  File "C:\Users\saso\Desktop\FreeCAD_0.17.11203_x64_dev_win\Mod\Draft\DraftVecUtils.py", line 92, in scaleTo
    typecheck ([(u,Vector),(l,(int,float))], "scaleTo")
  File "C:\Users\saso\Desktop\FreeCAD_0.17.11203_x64_dev_win\Mod\Draft\DraftVecUtils.py", line 50, in typecheck
    raise TypeError("fcvec." + str(name))
<type 'exceptions.TypeError'>: fcvec.scaleTo

OS: Windows 10
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.11203 (Git)
Build type: Release
Branch: master
Hash: e2e1f44b45737f8b900a4ac7766f8f064c434638
Python version: 2.7.8
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.1.0

[amrit3701]

When running unit tests from the gui there is this error, I believe it is there actually already for some time

Hi saso,

Can you please tell all the steps so that I can regenerate this error?

Regards,

[saso]

Can you please tell all the steps so that I can regenerate this error?

Test Framework WB -> Self-test -> TestApp.All -> Start

[yorik]

No error for me, that's strange!

[amrit3701]

Test Framework WB -> Self-test -> TestApp.All -> Start

No error found here.

Regards,