Author Topic: How are polygons sorted before rendering ?  (Read 2431 times)

arcanis

  • *
  • Posts: 3
    • View Profile
How are polygons sorted before rendering ?
« on: 2013-08-24 12:21:10 »
Hi,

I'm working on a BattleScene exporter for FFIX (I'm aware that one of them already exists, but it was fun nevertheless). I've currently got the exact same output than Zidane's one, but I'm struggling on one issue.



You can see that some elements which should be transparent are actually too much transparent - they ignore the objects behind them and are filled with the screen background color (here, grey). Zidane's viewer does not have this issue because it does not follow the PSX object description : it basically says that each polygon should be drawn appart from the others, so they can be easily sorted. The problem is that it can't be a general solution, since it is very heavy : instead of 7 draw calls, you have 7000. In a webgl context, the FPS drops from 60 to 20, and I assume that on PSX, it would be worse.

So I'm wondering : how does the PSX (or maybe the game engine of FF7 / FF9) handle the polygon sorting ?

Thanks,

Iros

  • 7th Heaven Crew
  • *
  • Posts: 229
  • Files for the file god! Mods for the mod throne!
    • View Profile
Re: How are polygons sorted before rendering ?
« Reply #1 on: 2013-08-24 12:30:40 »
Not familiar with the PSX engines; but, that looks exactly like what you would see if you hadn't enabled alpha testing (and should do).

What alpha values do the objects have? If it's only 0 or 1 (i.e. completely transparent, or completely solid) then you don't need to sort the polygons at all, and rendering order doesn't matter. What you can do instead is enable alpha testing, and tell GL to discard pixels/fragments with a alpha value (e.g.) < 0.01

Then, the transparent pixels won't update the depth buffer, and so they won't 'mask off' things behind them that you would normally be able to see through the 'gaps'.

(If the polygons are semi-transparent - e.g. alpha value 0.5 - then this won't work, and you will need some polygon sorting. But you should still be able to get around it using far less than 7000 draws.)