The nature of MBX’s HSR

This topic contains 2 replies, has 2 voices, and was last updated by  LFP_sboswell 8 years, 9 months ago.

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • #29679

    I’ve read the PowerVR MBX Technology Overview and the PowerVR 3D Application Development Recommendations from the latest SDK, plus any other MBX info I can get my hands on.

    One common refrain is that there is no need to sort objects from front to back, that Hidden Surface Removal takes care of the problem. It seems that this would imply that a series of OpenGL commands sent to the TBDR-based MBX would draw a different picture than the same series of OpenGL commands sent to a “streaming” renderer.

    Is this really true? Just how much polygon-level Z sorting does the MBX do for us? With a normal streaming renderer, we need to sort all transparent polygons from back to front, which is impractical, so we generally sort objects from back to front and live with the resulting alpha artifacts.

    And just how deep is this per-triangle tile-based analysis? If I draw a batch of geometry with a given state (e.g. Z write, Z test, alpha blend, alpha test, etc. etc.), and later draw another batch of geometry with the same state, do they somehow get interleaved together, or does the later one still get drawn “over” the previous one?

    Thanks in advance for any alleviation of my confusion.

    #32678

    Xmas
    Member
    LFP_sboswell wrote:
    One common refrain is that there is no need to sort objects from front to back, that Hidden Surface Removal takes care of the problem. It seems that this would imply that a series of OpenGL commands sent to the TBDR-based MBX would draw a different picture than the same series of OpenGL commands sent to a “streaming” renderer.

    Is this really true?

    No, PowerVR MBX conforms to the OpenGL ES specification and therefore the image rendered will be identical (with some quality and precision differences) to the output of other OpenGL ES implementations.

    The difference is how efficiently HSR is performed. An immediate mode renderer (IMR) performs HSR based on the current contents of the depth buffer, it does not know which triangles will follow after the current one. Therefore, if you render two overlapping opaque triangles back-to-front, an IMR will perform the fragment processing for both, even though only the second one is visible in the final image. To get good efficiency out of IMR HSR you’d have to sort your opaque polygons front-to-back or do a Z pre-pass.

    A TBDR first collects all the triangles in a scene and assigns them to tiles. Then it determines which triangle parts are visible in each tile, and performs fragment processing only on the visible parts.

    The order in which you render opaque polygons does not influence the efficienty of MBX’s HSR, therefore there is no need to sort your opaque objects front-to-back.

    In addition, TBDRs use on-chip memory for the depth and color buffers, so blending and depth test consume no external bandwidth. However, MBX does not sort transparent polygons. You still have to submit them in the order you want them blended, usually back-to-front.

    #32679

    OK, so I still have to sort geometry in all the ways I normally do, except that fully opaque polygons will tend to cull out useless fragment-processing work, and I don’t have to do a Z prepass or sort fully opaque polygons front to back. But all the other usual rules still apply. That makes sense.

    Thank you for the clarification. I had gotten myself completely lost.

Viewing 3 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic.