Hi, I find a problem in sorting order of opaque meshes in forward rendering.
here is my environment: Win10, Intel Core i-5, NVIDIA GTX1060, Unity 5.4.2p1, OpenVR(Vive), forward rendering mode.
I’m using forward rendering mode because of I’m using MSAA, this means I have to rely on Unity’s sorting order to draw closer opaque meshes first, then when draw farther ones, most pixels fails z-test, so no shading cost introduced on these pixels (I’ve tested early z-test feature and it is working on my graphic card). This way I can minimize the overdrawn issue to a level I can accept, but it all depends on a proper drawing order, which Unity seems not able to guarantee.
So according to the picture above, I can not understand why Unity fails to sort when vent is moved a little farther away from camera. Besides, if I’m using two floor meshes to run this test, there’s no sorting issue at all, seems the custom vent mesh makes Unity to sort incorrectly.
Currently my VR project is totally GPU(fillrate) bound, so overdrawn has a huge impact on performance, please someone has any suggestion or explanation? Thanks.
Sorting is never going to be perfect with traditional forward renderers, so expect there to be some amount of overdraw no matter what. Basically I wouldn’t get too hung up on this.
It does look like this specific case is wrong though so it might be worth submitting as a bug.
Hi, bgolus, I can accept a certain level of overdrawn in forward rendering, like props placed near each other, or due to batching, but if two mesh placed at least 2 meter away and their bounding box has no intersections, if Unity is unable to handle simple situations like this, the overdrawn issue can be escalated quickly and easily with scene complexity increases.
I believe Unity sorts by closest bounding sphere, either sorting by center depth (for 2D projects) or bounds distance (for 3D projects). Batching messes with that, as you mention, but there also seem to be some kind of additional fudge factors at play. Again what you’re seeing looks especially wrong, even from the oddness I’ve seen, which is why I suggest a bug report.
