Upbge: Bug: Alpha sort slower in UPBGE than in Blender 2.78c

Created on 15 Mar 2017  路  16Comments  路  Source: UPBGE/upbge

blend: http://pasteall.org/blend/index.php?id=45937

In the material tab, game setings switch to alpha sort.

bug

Most helpful comment

The issue is that we need to flush the index array of the sorted polygons every frame, this wasn't done before, anyway the way i designed it in 0.1.2 is not so good.
What i propose now is to replace:

    if (material->IsZSort() && rasty->GetDrawingMode() >= RAS_Rasterizer::RAS_SOLID) {
        m_mesh->SortPolygons(this, args.m_trans * MT_Transform(m_meshUser->GetMatrix()));
        m_displayArrayBucket->SetPolygonsModified(rasty);
    }

By:

    if (material->IsZSort() && rasty->GetDrawingMode() >= RAS_Rasterizer::RAS_SOLID) {
                int *index = m_displayArrayBucket->GetIndexMap()
        m_mesh->SortPolygons(this, args.m_trans * MT_Transform(m_meshUser->GetMatrix(), index));
        m_displayArrayBucket->FlushIndexMap();
    }

And use the glMap/UnmapBuffer function to avoid extra copy of the indices.

All 16 comments

?

I tested in 0.1.0 and 011, they give big performance while 012 gives less.
Can anyone else test?

I confirm the slow down, in 0.1.1 i have 0.75ms for the rasterizer whereas i have 1.21 in 0.1.2.

Commit : 5718bff90f5158a66dcc9f3255855d2c6e6ebd10

The issue is that we need to flush the index array of the sorted polygons every frame, this wasn't done before, anyway the way i designed it in 0.1.2 is not so good.
What i propose now is to replace:

    if (material->IsZSort() && rasty->GetDrawingMode() >= RAS_Rasterizer::RAS_SOLID) {
        m_mesh->SortPolygons(this, args.m_trans * MT_Transform(m_meshUser->GetMatrix()));
        m_displayArrayBucket->SetPolygonsModified(rasty);
    }

By:

    if (material->IsZSort() && rasty->GetDrawingMode() >= RAS_Rasterizer::RAS_SOLID) {
                int *index = m_displayArrayBucket->GetIndexMap()
        m_mesh->SortPolygons(this, args.m_trans * MT_Transform(m_meshUser->GetMatrix(), index));
        m_displayArrayBucket->FlushIndexMap();
    }

And use the glMap/UnmapBuffer function to avoid extra copy of the indices.

@Akira1San : Could you test with latest master please ?

Tested, the same low fps.

About this issue, I did tests in last master.
I have 500 fps with the test file. I remarked that the issue came from storage->GetIndexMap() called each frame.

So do you think we can cache the buffer returned by GetIndexMap() ?

When I cache the buffer in the test file I have 800+ fps

Made a test: http://pasteall.org/pic/index.php?id=117793

Looks great, even fixed the lamp slow down as can be seen from the images(I mean when switching the hemp to point) However, theres still a regression as can be seen, compared to bf bge. I think, that regression comes after .010 version.

In fact I don't know in what case alpha sort option is used, I don't have good test files in my files so I can't tell if I don't break the feature with the branch I pushed. This was just to show the impact on performances of GetIndexMap.

@Akira_san: In the image you shared, the shading looks not the same in BF bge/upbge. Is this normal?

Else is there is still a performance difference this can also be explained with NodeUpdateGS called each frame for ApplyRotation in the code.

I see.
The difference of light is from changing the lamp from hemi to point.

The vertex memory model changed in 0.2.4 and many modifications happened.

I retested with this file:
ge_mesh_sort_test.zip

I get for UPBGE 0.2.4 (086255edf5c8abbf298a92d95fde71b4c4e79452) 26.0ms for rasterizer,
for blender 37.5ms.

@Akira1San, @youle31 : Can you confirm the test please ?

I have these results in BF master and upbge master:

BF:
bf master

upbge:
master

heres my test; image 023 - 024: http://pasteall.org/pic/f730f61d5b7931c55a4be51e61a45dab
In bf bge it shows better result. - pic bf bge: http://pasteall.org/pic/167cba229ccef184efb46f1ce2f67e9a

Was this page helpful?
0 / 5 - 0 ratings