How do a transition’s Offset Options and Rise/Run property values work?

Problem

When placing a transition, I can’t figure out how the Offset Options and Rise/Run values work.  For example:

• It’s unclear exactly what Rise and Run represent.
• When the Offset Options value is s; I cannot change the Rise/Run values. I suppose that makes sense since it is symmetric and therefore the Rise and Run are both half the difference between Diameter 1 and Diameter 2. But if I change the Offset Options value to “a;” instead then the Rise/Run values both change to 0.
• If I change the Offset Options value to “b;” then the Rise value becomes the entire difference between Diameter 1 and Diameter 2 and the Run value changes to 0.

Also, when using a catalog based transition, I sometimes see the same Rise/Run value regardless of the database and size selected, and the Offset Options value doesn’t seem to make any difference. Certain transitions will display an Offset Options value of “s;” and Rise/Run values of "0" even though it’s clearly not a symmetric transition.

Solution

To see what the Rise and Run properties themselves represent, after placing the transition you can go to a front view to adjust the Rise value and switch to a top view to adjust Run.  This may help to better visualize how each property is affecting the shape of the transition.

However, there is a level of complexity to how the Offset Options, Rise and Run property values interact.  To begin, let’s first look at a generic/non-catalog transition:

Offset Options defines the Rise and Run values either based on the size of the two transition diameters or based on the Offset Option value itself:

• This simplest case is when using s; since this results in a symmetric transition where both Rise and Run = (D1-D2)/2.
• Using b; results in a flat bottom transition, so the Rise value (front view) is D1-D2 while Run (top view) is 0.
• Using a; is different because it generates a transition based on angle with no regard to Rise/Run, which is why both display a value of 0. If set to just “a;” then the angle generated will accommodate the difference between D1 to D2 along the length of the transition, from both a top and front view. If a value is added, such as “a15;”, then that value of 15 will be added to the baseline angle resulting a steeper slope, again in both a top and front view.

There are of course other options available including Left (l;) and Right (r;) in both numeric and angle variations:

All of these options are described in the OpenBuildings Designer help here.

For transitions using a catalog, the starting point for Offset Option and Rise/Run is the last used placement value for a generic/non-catalog transition since these properties are not mapped, and therefore there are no database values to use.  So, if you were to place a generic “s;” (symmetric) transition followed by a catalog transition then it should also be symmetric.  Likewise, if the last placed generic transition was based on “a;” (angle) then the next catalog transition should also be “a;”.   However, there is a caveat – the combined dimensional values need to make sense.  If the last placed generic transition had values of D1=3 and D2=1 using s; then the Rise and Run values would both be 1, or (D1-D2)/2. But if the next catalog transition placed is D1=4 and D2=3 then those last used Rise and Run values of 1 no longer make sense in terms of being symmetric, so instead that catalog transition using D1=4/D2=3 would have an Offset Value of a; instead.  

Once the catalog transition is placed, changing only the Offset Option value (say s; to a;) won’t have any effect because Offset Option is not mapped to the database. However, you may be able to change the Rise/Run values because they are numeric, but only if the values generate correct geometry based on the transition’s D1/D2 + length values.  So like the example mentioned above, the math needs to add up.

Lastly, if needed these properties can be added to the MDB file of your choice and mapped accordingly.  You will need to include all three properties so they can be linked as they are for generic/non-catalog transitions.