This sounds like it could be another instance of #119, as documented in known_bugs.txt
Bounding boxes should confirm - can you screenshot with them turned on?

Seems like the pylon bounding boxes are not high enough for the sprite sorter to recognize them as relevant. you might try to make them taller, but that might collide with other things (stations, bridges, etc.)

(also, the sloped catenary bounding box seems too wide)

It should be noted that it only draws them incorrectly in the NW-SE situation (left in this image), but I can't see a real difference between the two bounding-box wise. Making the bounding boxes taller might help. There is some space left before they start overlapping with the bounding box of tunnels and bridges, so that might be an idea.

I am wondering if making them taller indeed solved the issue, and/or if this issue is still relevant?

Sorting anything in an isometric world is very difficult, and often there is no right answer. But we do our best :D So please let us know if this is still relevant :) Tnx!

I asked the original reporter if this problem still exists, and they said yes.

I can confirm this is still a problem. Poles show behind wires they should be in front of, sometimes with glitching as a vehicle drives past. Poles also show underneath bridges they should be in front of. Test grf attached.

wiretest.zip

I suspect making the bounding boxes for the poles taller would help. Station tiles can disable the default pylons and draw their own (or not), so sprite ordering there is not too much of a concern.

A few issues have been raised here. I'll comment some of them:

• Generally: sprite sorting is an unsolvable problem.
  • In certain cases (some listed below) it's impossible to sort sprites correctly, because the order requirements are contradicting.
  • As long as OpenTTD uses sprites and no 3D models, this problem will remain unsolvable forever.
  • The best result you can get with sprites: If there are contradictions, break the sorting so that only a few pixels glitch instead of large areas.
• The last major change to bounding boxes was in 7d32567
  • Prior to this change there were many noticeable glitches with vehicles when passing under bridges or over foundations.
  • These glitches were on the scale of whole foundations and bridges flickering, while a vehicles passed by.
• The fix back then boils down to these things:
  • Reducing the number of bounding boxes in total by presorting sprites with known order into the same bounding box using Start/EndSpriteCombine:
    Example: Bridge sprites, catenary pylons and wires on bridges used to have separate BB, now there are only two BB for things in-front and behind vehicles on the bridge.
  • Separating the vertical Z space into "above" and "below" bridge surface. This is enforced via named constants

    /**
     * Some values for constructing bounding boxes (BB). The Z positions under bridges are:
     * z=0..5  Everything that can be built under low bridges.
     * z=6     reserved, currently unused.
     * z=7     Z separator between bridge/tunnel and the things under/above it.
     */
    static const uint BB_HEIGHT_UNDER_BRIDGE = 6; ///< Everything that can be built under low bridges, must not exceed this Z height.
    static const uint BB_Z_SEPARATOR         = 7; ///< Separates the bridge/tunnel from the things under/above it.
    

  • Ensure that bounding boxes do not overlap. Overlapping bounding boxes are a non-solution, and "kick the can down the road" until something else glitches.
• Sorting of catenary pylons vs bridges.
  • Due to the changes mentioned above, there is a strong separation of "stuff above bridge" and "stuff below bridge".
  • Example 1: Pylon on west corner under bridge:
    
    • Vehicle must be drawn in-front if pylon. (Vehicle > Pylon)
    • Bridge floor must be drawn in-front of vehicle. (Bridge > Vehicle)
    • This implies that the bridge must be drawn in-front of the pylon. (Bridge > Vehicle > Pylon)
    • Trying to draw the pylon in-front of the bridge would either result in drawing the pylon in-front of the vehicle, or the vehicle in-font of the bridge.
  • Example 2: Pylon on south corner under bridge:
    
    • The order Pylon > Bridge > Vehicle is no contradiction. So it is possible in theory.
    • To make room of the pylon BB in-front of the bridge, you would have to make the bridge BB smaller in XY direction. This will have further implications on bridge ramps.
  • Example 3: Pylon behind wires:
    • The order Wires > Vehicle > Pylon is no contradiction. This is the current behavior.
  • Example 4: Pylon in front of wires:
    • The order Pylon > Wires > Vehicle is no contradiction. So it is possible in theory.
    • Changes to the Pylon bounding box need to account for bridges.
  • Example 5: Pylon on south corner in front of depot:
    
    • The order Pylon > Depot-roof > Vehicle is no contradiction.
  • Example 6: Pylon on east corner in front of depot:
    
    • The order Depot-roof > Vehicle > Pylon contradicts with Pylon > Depot-roof.
    • I do not know when OpenTTD puts pylons on one side of the rail or the other. But this could be fixed by putting the pylon always on the south corner.
• Summary:
  • Unsolveable cases: Example 1
  • Solvable by changing the visuals: Example 6
  • Maybe solvable by changing many BB: Example 2, Example 4
  • Already works: Example 3, Example 5
• Requirements for future changes:
  • There are many dependencies between things around vehicles: foundations, bridge ramps, bridge floors, signals, pylons, wires, ...
  • 7d32567 solved the Z position/order of things by introducing named constants (BB_).
  • The examples in this issue ask for changes in the XY order, so I would expect any fix for this to introduce named constants for XY positions on track tiles.

For reference here is the savegame for the screenshots from above:
catenary_sorting.zip