[Experimental] Drop fast faces

[numberZero]

@Fixer-007 @paramat Can you test performance, please? This mostly affects CPU, and only solid and liquid nodes.
I plan to base several features on this part, but if it affects performance significantly I will have to rethink my decision.

[numberZero]

Note: as a side effect, this fixes #6777 .
Note: Travis job errored, that’s its fault, not mine.

[nerzhul]

no need for this you already have this in directiontables.h if i'm correct

[numberZero]

sadly no, the order is different, and it is important here.

[Wayward1]

Upon initial testing, FPS seems to be a bit higher, but movement is significantly more choppy, dtime jitter tends to skyrocket, and there are significant visual artifacts.

OS: Linux Mint 18.3 x86
CPU: Quad core Intel Atom Z3736F
Graphics: Intel Atom Processor Z36xxx/Z37xxx Series Graphics & Display

Edit: I received the same results on my main device (minus the significant choppiness), that one being:

OS: Linux Mint 18.3 x64
CPU: Quad core AMD A8-5545M APU with Radeon HD Graphics
Graphics: Radeon HD 8510G

Note the dtime jitter here:

Edit: new high dtime jitter (on my main device):

[numberZero]

Fixed glitches. Water glitches were not visible with waving water. Grass glitches were due to the face grass side is not tileable vertically; a nodebox would look the same.

But dtime jitter difference is sad.

[paramat]

Why drop 'fast faces' if that seems to be an optimisation?
What features do you have in mind to be based on this? It may not be worth doing this depending on the features you are considering.

[numberZero]

@paramat Depends on how fast these faces actually are. If they are significantly faster than this simple solution, it doesn’t worth that.

[Wayward1]

With further testing, FPS seems to be a bit lower, for me at least, hovering around 52 versus the latest Minetest at around 57. There are also visible lines between certain nodes, like default:snow and default:snow_with_grass.

Minetest master:

This PR:

[Fixer-007]

Did 4 fly straight tests over same newly gen mg7 terrain with PR and without (2 each), seems like minimal effect on rendering for me on Core i3-2120 3,3GHz, ATI X800GTO 256mb OpenGL 2.1, win7.
However, CPU usage seems higher, about 14-15% more cpu cycles with this PR.

[numberZero]

@Fixer-007 Only 15%? I was afraid it would rather double CPU usage. Nevertheless, I added several optimizations, it should be significantly faster now.

Note: I just realized it computes lighting wrongly. Fixing that is possible but is non-trivial.
Note: I can’t test performance/stutter/etc. myself as my new CPU is too fast, it can handle way more load.
Note: This PR is experimental and may not be a good decision.

[rubenwardy]

What's the benefit and what PRs are relying on this?

[numberZero]

No PRs currently rely on this.
The benefit should be, less weird and fragile code amount. The benefit should be, reusing of same code where appropriate.
By the way, I found some interesting details that might be handy to fix by themselves, like nodeboxes not supporting non-tiling textures.

[Fixer-007]

Only 15%?

That's according to Process Explorer figures. CPU cycles are good as benchmark, right? I don't use profilers or other fancy stuff.

[lhofhansl]

So. Much. Simpler. :) I definitely like that part of it.
Going to try it - although I also have a pretty fast machine.

[lhofhansl]

I see a measurable drop in FPS. Without the patch FPS is capped at 60 (have not tried with a higher limit), with the patch it hovers around 49.

If that's typical we should keep fast faces.

[numberZero]

@lhofhansl The reason for lower FPS may be lack of tiling, as the mesh my PR produce should be identical otherwise, and meshgen time shouldn’t affect FPS much. On my GPU, that does not affect FPS at all, vertex shaders take way less time than fragment ones. On your GPU the situation seems to be different.
Note: I suppose you tested in vanilla MTG (or minimal), full of flat solid areas. On messy landscape the FPS difference should be lower.
Nevertheless, this appeared to be a bad idea; fast faces should be improved and not dropped. Closing.
P.S. Thanks for testing.

[lhofhansl]

@numberZero Yeah, vanilla MTG. This was a "scene" with water, some islands, and some mountains visible.

[lhofhansl]

@numberZero I'm looking at this one again, as fast faces prevent many vertex shader effects, since you get lines between long faces.
I wonder if the rational for fastfaces still holds today. I think removing them would lead to more draw calls, right? That would be bad.

[numberZero]

I think removing them would lead to more draw calls, right? That would be bad.

No-no, draw call number is not affected. Vertex number would be higher, sometimes (on plains) significantly.

[lhofhansl]

I see, not reducing the number of meshes, just the (average) count of vertices per mesh.

I'm going to try this again. The patch obviously does not apply anymore. I assume you did not keep a current version... (Had to ask, just in case.)

Tiling is already turned off for water (when waves are enabled).

[numberZero]

@lhofhansl to test rendering performance, just forcing next_is_different (if it still has that name...) to true in the fastface generator should be enough.

[lhofhansl]

@numberZero I did that already :) I see the extra vertices rendered (F6 shows 8.8m instead of 6.9m), but FPS stays the same (31 FPS). This is a new laptop, so not sure whether that is typical. I'll play with it some more.

[numberZero]

Minetest is probably limited by drawcalls and not rendering itself on any more-or-less modern discrete GPU (except of maybe some nVidia® cards under nouveau which just can’t get them off the power-saving mode), and the former is mostly unaffected by fast-faces. But there are also integrated GPUs...

[lhofhansl]

And here I am looking at this again. This time for large view_ranges, where the fastface (getTileInfo) is the CPU hog.