Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reduce server FOV with forward speed. #6552

Closed
wants to merge 1 commit into from

Conversation

Projects
None yet
2 participants
@lhofhansl
Copy link
Contributor

lhofhansl commented Oct 22, 2017

Related to #6447 .
This will reduce the server FOV for retrieving and sending blocks, when a player moves in the direction (s)he is looking. This avoids rendering blocks that will soon be out of sight (the player is moving forward). If the player is looking in a different direction this effect it reduced or turned out (see dot product in the code)

The result is that rendering artifact are mostly visible on the side and not in front where the player is likely looking.

Check it out. Typically the rendering artifact are not noticed on the side, while the server sends fewer blocks and the client has to render fewer blocks as well.

The numbers can be tweaked still. Right now the speed factor is capped at 300 (i.e. 30 n/s). At fly speed (20 n/s) the fov is reduced by 40% reducing the number of blocks render by almost 3x. Can probably still increase the effect slightly to be 50% at 20n/s, for a 4x reduction in blocks (still with visible artifacts pushed to the sides).

@paramat

This comment has been minimized.

Copy link
Member

paramat commented Oct 22, 2017

To be clear you mean the FOV used for loading blocks is reduced, not the view frustrum FOV.

@lhofhansl

This comment has been minimized.

Copy link
Contributor Author

lhofhansl commented Oct 22, 2017

@paramat Yes. Server-side FOV so to speak. Pretty effective to save blocks sent and rendered.

@lhofhansl lhofhansl changed the title Reduce fov with forward speed. Reduce server FOV with forward speed. Oct 22, 2017

@paramat

This comment has been minimized.

Copy link
Member

paramat commented Oct 24, 2017

Block load FOV reduces to 88% at walking speed. Just for information.

@paramat

This comment has been minimized.

Copy link
Member

paramat commented Oct 24, 2017

Works ok, at 20n/s the blocks on the very edge of the view, which are of little importance to the scene, are not loaded but go out of view within 2s.
The dot product means that when view and velocity are at 90 degrees, when flying sideways, the effect is zero.

@paramat

This comment has been minimized.

Copy link
Member

paramat commented Oct 24, 2017

Only thing i was concerned about was the reduction when walking, but it's not really noticeable at all.

@paramat

This comment has been minimized.

Copy link
Member

paramat commented Oct 24, 2017

The stress test seems to be 30n/s while flying diagonally, because you fly towards the unloaded areas, occasionally unloaded blocks get quite close, not a big problem because it is rare.

screenshot_20171024_054742

@paramat

This comment has been minimized.

Copy link
Member

paramat commented Oct 24, 2017

Ok i certainly support this, it will make things smoother when flying. The way it is tuned seems ok. I'd like other devs to look at this. I'll probably +1 a little later.

@lhofhansl

This comment has been minimized.

Copy link
Contributor Author

lhofhansl commented Oct 24, 2017

Thanks for testing.
In the diagonal case the effect would also be reduced to 1/2 (assuming the player looks forward) the effect would be 66% of fov. Kindof a worst case.

One could also tilt the view cone somewhat in that direction.

@lhofhansl

This comment has been minimized.

Copy link
Contributor Author

lhofhansl commented Oct 25, 2017

I can also limit the effect to 20n/s instead of 300n/s.
Btw. with ethereal and the crystal boots on the flying speed is 40n/s :)

@paramat

This comment has been minimized.

Copy link
Member

paramat commented Oct 25, 2017

I think tilting the view cone is overkill. I did think about limiting the effect to 20n/s, maybe.

@lhofhansl

This comment has been minimized.

Copy link
Contributor Author

lhofhansl commented Oct 25, 2017

Then the question is: Is it better to lose some of the blocks on the side (in this worse case) or the block in front.

@paramat

This comment has been minimized.

Copy link
Member

paramat commented Oct 25, 2017

Since the worst case rare occurence is only for diagonal at 30n/s i don't see it as an issue. I will test but i guess the worst case screenshot i posted probably doesn't happen at 20n/s.
Blocks in front are more important of course.

@paramat

This comment has been minimized.

Copy link
Member

paramat commented Oct 25, 2017

It still happens at 20n/s but never mind 👍

@lhofhansl

This comment has been minimized.

Copy link
Contributor Author

lhofhansl commented Oct 25, 2017

I suppose I can do followup fixes in this area.
Generally the server should be able to generate blocks faster and the to render them faster. I looked at MC on Android and it seems we're doing better already :)

Perhaps moving away from the rigidity of Irrlicht will improve performance as well.

@lhofhansl

This comment has been minimized.

Copy link
Contributor Author

lhofhansl commented Oct 26, 2017

@lhofhansl lhofhansl closed this Oct 26, 2017

@paramat

This comment has been minimized.

Copy link
Member

paramat commented Oct 27, 2017

I very often fly around at 20n/s and i think i noticed smoother behaviour, before i used to get momentary freezes. So this will be very useful for devs, server admin and anyone using fast vehicles.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.