Y-Coordinate Reversal when using "warp" for AlignH

Issue #103 resolved
Benjamin Blasen created an issue

It seems that when I import library objects into a project the y-coordinate gets reversed when switching between AlignH "Orient" and "Warp".

For example, this project is using some library objects called "Abutment Backwall" and "Stem Abutment (BB)", both of these library objects use a parameter called "PedSlope" to set the bottom edge z-position based on a calculation of "y-distance * PedSlope"; the value of "PedSlope" is positive in both library objects and both appear correct in library view.

With these objects brought into my project with the same positive slope and both the backwall and stem set to "warp", the slope is reversed from what it should be:

AlignH warp slope pos.jpg

With the AlignH set to "warp" and the slope negative, the correct view is produced:

AlignH warp.jpg

With the AlignH set to "orient" and the slope postive, the bottom edge does have the correct slope but the top of the backwall is mirrored about the z-axis:

AlignH orient slope pos.jpg

With the AlignH set to "orient" and the slope negative, the bottom edge has the incorrect slope and the top of the backwall is also incorrect:

AlignH orient slope neg.jpg

However, I can achieve the correct look by setting the backwall to "warp" with negative slope and the stem wall to "orient" with a positive slope.

AlignH warp.jpg

Why is the y-coordinate reversing from the library definition when using "warp" for AlignH?

Also see my comment on Issue #99 which may not be fully resolved.

Comments (5)

  1. Ali Koc

    These objects should not use warp as you do not really want them to be warped to the horizontal or vertical alignment.

    And the reason for Y axis flipping is due to the difference between global and alignment coordinate systems.

    For global axis, where Z is vertical and looking towards positive X, the positive Y is towards left. For alignments, Looking up station positive Y is towards right.

    The global axis system convention is standard in most (if not all) engineering applications. Changing this will cause many problems for applications connecting to OpenBrIM.

    Alignment coordinate system convention is what bridge engineers expect. So we want to keep it.

    So, we have two different conventions. let's have a function f(p) that takes a point and transforms the points into alignment coordinate system. For warp, every individual point that makes up the graphical object individually passes through f(p) function. Hence alignment to global transformation occurs and Y axis flips.

    For None and Align, we do not touch the individual points that make sup the graphics object but simply move and orient the overall graphics object to be placed on the align. for f(p) is only applied the location of the object, but not to the object's points. So the object does not flip but simply placed on the alignment with whatever orientation it has.

    Let me know if this does not answer your question.

  2. Benjamin Blasen reporter

    ok, this makes sense, but I do need the top of the backwall to warp to the transverse contour (see issue #102). When I set AlignT to "warp" it reverses the y coordinate.

    AlignT warp.jpg

    And also something strange happens to the internals of the backwall volume:

    AlignT warp2.jpg

    Can you tell what is happening here?

  3. Ali Koc

    Issue #1: Applying warp in project causes object in project to not match the object in the library. If you know your object will be used with Warp option, you can use AlignH="Warp" on the geometric object (Surface/Volume/Line) in the library object. This way library object will match the instances of this objects in projects.

    Issue #2: About strange shape of backwall -- I am not sure how this volume is defined. It seems the backwall is not a valid volume, right? You may want to define this using two volumes.

  4. Ali Koc

    I will close this as the behavior of warp is by design. If backwall rendering is still an issue, it should be submitted as a separate issue.

  5. Log in to comment