Automatic ‘configuration’, not automatic ‘placement’

1Automatic ‘placement’ and automatic ‘configuration’

Many products talk about automatic rebar placement. But automation has two levels, and without that distinction no comparison holds.

Placement draws the picture for you. But without configuration, where to put the lap splices and how far to take the development still have to be decided by a person. The real saving in people and time lies not in placement but in configuration.

2Where BuilderHub stands

It maps directly onto the sequence of steps set out in Part 1. If structural calculation answers as far as the section table, and drawings, BIM and fabrication pick it up afterwards, BuilderHub fills the space between.

• Input — integrated structural calculation data, or automatic recognition of 2D drawings (DWG)
• Generation — automatic rebar placement per bar in accordance with the rebar placement code (hooks 90/135/180°, development, anchor plates)
• Verification — automatic detection of rebar clashes, with the offset needed to resolve them given in mm
• Output — precise quantities that can be checked

Giving the offset as a number in clash review makes a large practical difference. “These overlap here” is detection; “move it this far and it is resolved” is judgement.

3It is light because of architecture

BuilderHub-R is not an add-in to a BIM platform but standalone software. It runs without a Revit licence.

That choice is the answer to the weight problem in the previous part. Generating rebar placement and judging clashes are geometric computation and code rules; they are not work that requires the functions of a BIM platform. If you never put the heavy computation inside the platform in the first place, you do not inherit the platform's ceiling.

It is light not because it was built well, but because the computation happens somewhere else.

So Revit add-in style auto-rebar products — for example a third-party Revit add-in such as Lightning BIM — inherit this handling directly. To keep the model from bogging down, they need display-lightening devices, such as switching the rebar from its actual diameter to a simple line (実径表示切替) — an approach that eases the symptom, not the cause.

BuilderHub-R is standalone, so it handles rebar as separate, lightweight data. However much rebar there is, the slowdown caused by rebar stays small. It is a structural avoidance: the computation is never placed inside Revit.

In short, the weight difference comes from architecture, not features. The add-in changes the display to ease the symptom; BuilderHub-R keeps the computation outside the platform and avoids the cause.

For the same reason, there is no need to change your structural calculation tool. We do not require our own analysis package to be used alongside, so you can leave your existing tools as they are and simply add this layer.

4How this differs from Revit and Tekla

This is the question we are asked most often, so let us be clear about it. Tekla Structures has powerful rebar functionality. Rebar sets automatically recognise openings and cut-outs; when a bar exceeds its maximum length it is split automatically and laps are created; and the software produces rebar detail drawings and bar bending schedules.

And to be honest, in that area Tekla is ahead of BuilderHub. As we set out just below, BuilderHub still has no drawing generation of its own. The difference is not one of capability but of where each tool sits in the process, and who decides the rebar conditions.

The third row is the crux. In Tekla, lap splice length, cover and hook shape are values the user sets. Regional environment files and components supply defaults, but the party deciding which values apply is a person. That presupposes a detailer who knows how to drive Tekla.

In BuilderHub the engine makes that judgement. It takes the structural calculation output and, in accordance with the rebar code, decides hook angles, development lengths and splice positions by itself — and goes on to verify whether the bars can actually pass one another at the joints.

The two tools are not competitors; they occupy different positions in the workflow.

Tekla is strong where the decisions have already been made and the model is detailed to fabrication level; BuilderHub sits where those decisions themselves are automated.

5What about the rebar tools built on Revit?

Revit has several add-ins that automate reinforcement. SOFiSTiK Reinforcement, GRAITEC PowerPack for Revit, Naviate Rebar, CADS RC3D — all mature products with real users. To establish how they differ, we collected only sentences the vendors themselves publish on their product pages and in their manuals.

First, a correction to a claim that circulates widely. It is not true that the competing add-ins force you onto the vendor’s own analysis software. GRAITEC states in its own documentation that there is “no need for external analysis software” and that the tool “even operates as standalone”; CADS states that it imports required-reinforcement contours “from any suitable FEA program”. On this axis there is no difference.

The difference is in the last column. Here are the vendors’ own words.

All four are well automated. But what is automated is execution, not judgement. Lap length, anchorage length, cover and hook shape are decided by a person; the tool then applies those values quickly and accurately.

We could not find a product that says it decides the lap length itself.

What we found was “specify”, “type in”, and “read from the project settings”.

This is not a flaw. These tools sit where rebar is created on a Revit model, and deciding the values belongs to the step before that. But if that earlier step is not automated, the empty layer described in Part 1 is still there.

Element coverage, again in the vendors’ own words — this is what actually decides fit.

6Why the prices cannot simply be lined up

Price is the first question in any evaluation. Yet in this market putting the sticker prices side by side does not produce a comparison. Among the four add-ins above, some publish a list price and some are quote-only, and it varies by product within the same vendor. So we do not print figures here. We print what to check instead.

So the number to compare is not the licence but the total cost of processing the same volume of work: the host licence, every module you actually need, and the hours of the person deciding the conditions. BuilderHub removing the first two is a consequence of its architecture. Removing the third is the point of the product.

7What it still cannot do

Stated plainly: there are things BuilderHub cannot do at this point.

The third point in particular bears directly on the adoption decision. It cannot be applied today to projects that require a code other than Korea's or Japan's.

8Where it makes sense

One last word on markets. Whether a tool for this layer is needed differs by country. The dividing line is not market size but “who does the rebar detailing”.

In markets where designers and contractors review rebar placement at the design stage, it is clear who would use this tool. Conversely, in markets where rebar detailing is handled entirely by the fabrication side, the very character of the software needed is different.

Japan is a particular case in point. There is a practice of assuring structural safety and constructability simultaneously at the design stage, and rebar clash review has become effectively a standard step. It is not a legal obligation, but the fact that major contractors have each built their own in-house systems shows the demand.