asynchronous reprojection

Post Reply
c56
Member
Posts: 307
Joined: Wed Apr 21, 2021 03:05
GitHub: tigercoding56
In-game: bm5 or bemo5 also sell_her_on55

asynchronous reprojection

by c56 » Post

i just stumbled upon a video explaining asynchronous reprojection -- which is a technique that makes the percieved framerate much more than the actual framerate
https://www.youtube.com/watch?v=IvqrlgKuowE
so i just thought maybe start a discussion about it (& maybe other techniques to make minetest more playable on low-end hardware )
this is a signature not a place to post messages also if i could change my username i would change it to sell_her_on55

x2048
Developer
Posts: 68
Joined: Mon Feb 15, 2021 22:41
GitHub: x2048

Re: asynchronous reprojection

by x2048 » Post

This is really good and should be doable with the latest changes in the rendering pipeline. Can you post it to the roadmap discussion on github?

User avatar
Festus1965
Member
Posts: 4181
Joined: Sun Jan 03, 2016 11:58
GitHub: Festus1965
In-game: Festus1965 Thomas Thailand Explorer
Location: Thailand ChiangMai
Contact:

Re: asynchronous reprojection

by Festus1965 » Post

c56
yes, you found that also - and how old is that technique ? hmm

but see it on another way:
* most max now with 60 fps = a new shown (actual) picture of our view every 16.667 ms

then check how often minetest itself is recreating the possible view as of
* dig or build nodes
* chanched position of gamer, mobs
* grown trees (here most abm = every 1 s for 200 ms)
* most gamer distance transfer time, maybe also

so MOST of shown new frames are the same as before as
* mt server can't deliver faster then every 1 s (abm) or the other set parameter
* mt client don't even get this information so fast (rtt)
* most clients are even not able to revalculate it faster (how much gamer you know don't have even 30 fps)

IF, that feature makes only sense for the client itself ... but just getting MORE same frames as before AS new data still is not faster
Human has no future (climate change)
If urgend, you find me in Roblox (as CNXThomas)

c56
Member
Posts: 307
Joined: Wed Apr 21, 2021 03:05
GitHub: tigercoding56
In-game: bm5 or bemo5 also sell_her_on55

Re: asynchronous reprojection

by c56 » Post

Festus1965 wrote:
Thu Dec 08, 2022 00:47
c56
yes, you found that also - and how old is that technique ? hmm

but see it on another way:
* most max now with 60 fps = a new shown (actual) picture of our view every 16.667 ms

then check how often minetest itself is recreating the possible view as of
* dig or build nodes
* chanched position of gamer, mobs
* grown trees (here most abm = every 1 s for 200 ms)
* most gamer distance transfer time, maybe also

so MOST of shown new frames are the same as before as
* mt server can't deliver faster then every 1 s (abm) or the other set parameter
* mt client don't even get this information so fast (rtt)
* most clients are even not able to revalculate it faster (how much gamer you know don't have even 30 fps)

IF, that feature makes only sense for the client itself ... but just getting MORE same frames as before AS new data still is not faster
this is not the purpose i think
now say your GPU is able to get 15 frames per second (not everyone has a good pc or maybe using the IGPU would improve battery life on laptops)
asynchronous re-projection makes it so that when you move your camera ,
the display updates before your gpu is able to push out a new frame (by moving the image (not fully rendering it again but instead shifting it and filling in the unknown portion with the last line of pixels bevore it )
which makes it so the application seems more responsive which could in ctf for example improve your aim
this is a signature not a place to post messages also if i could change my username i would change it to sell_her_on55

User avatar
Festus1965
Member
Posts: 4181
Joined: Sun Jan 03, 2016 11:58
GitHub: Festus1965
In-game: Festus1965 Thomas Thailand Explorer
Location: Thailand ChiangMai
Contact:

Re: asynchronous reprojection

by Festus1965 » Post

c56 wrote:
Sat Dec 10, 2022 23:27
which makes it so the application seems more responsive which could in ctf for example improve your aim
without actual data from the server, including new data from the other client (which might be the aim like in ctf)
a faster update of the client is (maybe not) useless,

depending what you mean with aiming ... read to the end ...

Imagine both gamer, group red and blue, are both just 50 ms rtt from the server, that also has its own lag of 100 ms.

The one gamer moves straight (so other client "could" predict the positions for another 200 ms)
this data will be at server after 50 ms,
the server itself is able to workout all incoming data in 100 ms and send them out again to all gamer clients
the new correct data leaves server after 100 ms,
need another 50 ms again to reach the other (all) client,
and has to be processed at client, lets take ONLY the drwatime of maybe 17 ms I see at me (= fast)

This mean you wanna force to re-show graphics at client, that is around 200 ms old,
or at a drawtime of near 17 ms or fps of 60 fps you show 11-12 times old data.

Or whatever how fast you redraw the screen maybe with 120 fps,
the client can only show old data again, now 8 times

as an update from the server including all other clients comes only after about 200 ms or 4 updates with 60 fps.

So with 15 fps on a slower client (CPU GPU, phone) what is about 1000 / 15 = repeat every 66 ms ?
you still have 3 times shown an old data, where movements might depend on guessing the last known movement of all other player, before the client get new data ... that is already again 200 ms old.

And if you got a "hit" depends on MEETING your and other client data at server at same time, that both (bullet and target) have been calculated at same time on same location.
This is more a system for calculating meteor hits on earth ... then ctf.

CTF (server and player) HAS to life with that problem, or
* must be fast server and send new data as often admin know that are calculated
* server adjust data send time to server calculation (lag) or faster, to make sure new data is out as often as possible
* clients / player must be under a set rtt to reduce distance lag

all other PvP on server face a similar problem but its not the main purpose,

and server with mobs already saved half of rtt, as mobs are moved at server itself

but to fasten the repeating frames on a client alone it just nice ... better just glue a colored point on the aim center will help more much easier,
after learn to guess how the enemy moves ... and try to get the 'hit' meeting at server.


Or go back to the start:
The position of a moving other object (mob or player) is the same wrong one after not 200 ms or until 'update' (if you can call it like that), whatever how often you redraw its guessed ! position for less than 200 ms, either you show it 1 or 12 times as of fps.

and the other side:
better let the slow fps screen keep movable, instead of freeze it of too much new calculations for nothing new shown.

it seam to be more important, that the player keep a fast moving screen allow him/her/it to aim free, and not stuck with frozen screen, to BE ABLE to aim what might be the write position,
but whatever you try rtt and server lag itself deny any faster real seen aim/target depending on other player or mob

to aim to 'correct' position depends on
* client graphics speed for free fast SCREEN movement (able to point aim), but depend on old data
* player brain
as new actual data of moving things (player, mobs, even cart ?) is always LATE and so shown guessed.
Human has no future (climate change)
If urgend, you find me in Roblox (as CNXThomas)

c56
Member
Posts: 307
Joined: Wed Apr 21, 2021 03:05
GitHub: tigercoding56
In-game: bm5 or bemo5 also sell_her_on55

Re: asynchronous reprojection

by c56 » Post

Festus1965 wrote:
Sun Dec 11, 2022 00:28
c56 wrote:
Sat Dec 10, 2022 23:27
which makes it so the application seems more responsive which could in ctf for example improve your aim
without actual data from the server, including new data from the other client (which might be the aim like in ctf)
a faster update of the client is (maybe not) useless,

depending what you mean with aiming ... read to the end ...

Imagine both gamer, group red and blue, are both just 50 ms rtt from the server, that also has its own lag of 100 ms.

The one gamer moves straight (so other client "could" predict the positions for another 200 ms)
this data will be at server after 50 ms,
the server itself is able to workout all incoming data in 100 ms and send them out again to all gamer clients
the new correct data leaves server after 100 ms,
need another 50 ms again to reach the other (all) client,
and has to be processed at client, lets take ONLY the drwatime of maybe 17 ms I see at me (= fast)

This mean you wanna force to re-show graphics at client, that is around 200 ms old,
or at a drawtime of near 17 ms or fps of 60 fps you show 11-12 times old data.

Or whatever how fast you redraw the screen maybe with 120 fps,
the client can only show old data again, now 8 times

as an update from the server including all other clients comes only after about 200 ms or 4 updates with 60 fps.

So with 15 fps on a slower client (CPU GPU, phone) what is about 1000 / 15 = repeat every 66 ms ?
you still have 3 times shown an old data, where movements might depend on guessing the last known movement of all other player, before the client get new data ... that is already again 200 ms old.

And if you got a "hit" depends on MEETING your and other client data at server at same time, that both (bullet and target) have been calculated at same time on same location.
This is more a system for calculating meteor hits on earth ... then ctf.

CTF (server and player) HAS to life with that problem, or
* must be fast server and send new data as often admin know that are calculated
* server adjust data send time to server calculation (lag) or faster, to make sure new data is out as often as possible
* clients / player must be under a set rtt to reduce distance lag

all other PvP on server face a similar problem but its not the main purpose,

and server with mobs already saved half of rtt, as mobs are moved at server itself

but to fasten the repeating frames on a client alone it just nice ... better just glue a colored point on the aim center will help more much easier,
after learn to guess how the enemy moves ... and try to get the 'hit' meeting at server.


Or go back to the start:
The position of a moving other object (mob or player) is the same wrong one after not 200 ms or until 'update' (if you can call it like that), whatever how often you redraw its guessed ! position for less than 200 ms, either you show it 1 or 12 times as of fps.

and the other side:
better let the slow fps screen keep movable, instead of freeze it of too much new calculations for nothing new shown.

it seam to be more important, that the player keep a fast moving screen allow him/her/it to aim free, and not stuck with frozen screen, to BE ABLE to aim what might be the write position,
but whatever you try rtt and server lag itself deny any faster real seen aim/target depending on other player or mob

to aim to 'correct' position depends on
* client graphics speed for free fast SCREEN movement (able to point aim), but depend on old data
* player brain
as new actual data of moving things (player, mobs, even cart ?) is always LATE and so shown guessed.
you are 100% correct ; the network transfer speed is a issue
even with normal rendering for example buying a new GPU
will not make your network better this is why minetest has client side
predictions for moving entities such as minecarts (improving delay from server to pc is out of
scope of client programs for the most part ) , as for the purpose of asynchronous re-projection it is to allow the player to see where he is aiming (not what things are there but instead the change in direction ) before the GPU is able to
push out a new frame
as for gluing a colored block on to the spot your aim is at , it would kind of look a bit choppy (when new frame is recieved and block jumps to center again) why not just move the image under the crosshair ?, this is basically what i am trying to suggest to clear up confusion (zoom in/out could be used for vertical movement )
this is a signature not a place to post messages also if i could change my username i would change it to sell_her_on55

User avatar
Festus1965
Member
Posts: 4181
Joined: Sun Jan 03, 2016 11:58
GitHub: Festus1965
In-game: Festus1965 Thomas Thailand Explorer
Location: Thailand ChiangMai
Contact:

Re: asynchronous reprojection

by Festus1965 » Post

c56 wrote:
Sun Dec 11, 2022 01:04
...
push out a new frame
as for gluing a colored block on to the spot your aim is at , it would kind of look a bit choppy (when new frame is recieved and block jumps to center again) why not just move the image under the crosshair ?, this is basically what i am trying to suggest to clear up confusion (zoom in/out could be used for vertical movement )
ok, we have set the basics it depends on

client side:
make the client as fast as possible - for smooth screen movement
* faster client mt (as maybe irrlight was)
* faster GPU (other unit, add external card)
* make GPU less work (distance view, details, resolution)
* choose a less detailed, less mod server ?
* choose a faster server (server lag itself)
* choose a more nearby server (lower rtt)

so far fast ideas ... some of them are so old discussed ... like
* continent depending server-list = show local server with real rtt etc.
* use faster server (hardware based)
* use faster server (mods based) = less hard lag mods, what force server to delay new data as not ready as wait for lag mods)

so the player can only
* change the server as of distance or server speed
* change the unit or what most is unknown, optimize some rtt wifi problems, or add hardware
* most easy reduce details as settings and resolution

as for me a client (on linux, ubuntu) proofed to be able to do fps 120, redraw often
the user, player must find the best settings, and even they are discussed and written often,

smooth lighting, particles, 3d clouds, opaque water, OFF
simple leaves, select
...
low distance view, closer fog = less to show faster calculated
AND keep data longer (unused data timeout) to HAVE the area (nodes) to show out of memory

everything that just make it LOOK nice, but force the client to work more and GPU to calculate longer = low fps

and most player with that issue don't know it for sure.

but, sorry - there is a last thing that has to work in the mind of users:
there ARE limits that we can't break, as of money for better unit or upgrade or to find settings (as player has no ability to think or understand this even) and so the possibility to use a app for something ...
accept it and play (bad) or let it go and choose something else
Human has no future (climate change)
If urgend, you find me in Roblox (as CNXThomas)

User avatar
Desour
Member
Posts: 1469
Joined: Thu Jun 19, 2014 19:49
GitHub: Desour
IRC: Desour
In-game: DS
Location: I'm scared that if this is too exact, I will be unable to use my keyboard.

Re: asynchronous reprojection

by Desour » Post

We can also make a very large (sidelength of 256 nodes or so) cube around the player, and draw on it mapblocks that are outside of the cube (=> mapblocks in the distance). The cube position is then only updated every 10 frames or so. And in each of those 10 frames we draw parts of the next cube's sides (we can split each side into 4), and use the cube center as camera pos. We can also use the depth map for parallax mapping.

It's not a new idea to do such things for far-away mapblocks, but I'm not sure how much discussion there has been about it, and I didn't know of the name "asynchronous reprojection".
Anyway, we should first pick the low hanging food and reduce the number of draw calls.
he/him; Codeberg; GitHub; ContentDB; public personal TODO list; "DS" is preferred (but often too short)

c56
Member
Posts: 307
Joined: Wed Apr 21, 2021 03:05
GitHub: tigercoding56
In-game: bm5 or bemo5 also sell_her_on55

Re: asynchronous reprojection

by c56 » Post

DS-minetest wrote:
Sun Dec 11, 2022 16:29
We can also make a very large (sidelength of 256 nodes or so) cube around the player, and draw on it mapblocks that are outside of the cube (=> mapblocks in the distance). The cube position is then only updated every 10 frames or so. And in each of those 10 frames we draw parts of the next cube's sides (we can split each side into 4), and use the cube center as camera pos. We can also use the depth map for parallax mapping.

It's not a new idea to do such things for far-away mapblocks, but I'm not sure how much discussion there has been about it, and I didn't know of the name "asynchronous reprojection".
Anyway, we should first pick the low hanging food and reduce the number of draw calls.
i am open for discussion about other optimisations on this thread so
to reduce the number of drawcalls could we smooth out blocks far away (maybe up to 25-40 nodes bevore far-view-cube) ?
so for example :
demo.png
demo.png (198 Bytes) Viewed 1466 times
if done right , this should be able to lower the complexity of the scene and make it a bit low-poly looking (but i am sure grouping similar nodes together could be a setting (would give more detail far away at cost at performance )
this is a signature not a place to post messages also if i could change my username i would change it to sell_her_on55

c56
Member
Posts: 307
Joined: Wed Apr 21, 2021 03:05
GitHub: tigercoding56
In-game: bm5 or bemo5 also sell_her_on55

Re: asynchronous reprojection

by c56 » Post

Festus1965 wrote:
Sun Dec 11, 2022 01:30

...
low distance view, closer fog = less to show faster calculated
AND keep data longer (unused data timeout) to HAVE the area (nodes) to show out of memory

everything that just make it LOOK nice, but force the client to work more and GPU to calculate longer = low fps

and most player with that issue don't know it for sure.

but, sorry - there is a last thing that has to work in the mind of users:
there ARE limits that we can't break, as of money for better unit or upgrade or to find settings (as player has no ability to think or understand this even Except about 80% of players ) and so the possibility to use a app for something ...
accept it and play (bad) or let it go and choose something else
all those things that increase performance at the cost of lower visuals could be added to the tradeoffs for performance setting(which i found by simply searching performance in settings menu) or maybe a settings menu to enable / disable them separately


as for finding settings is hard for certain users ,
Spoiler
maybe we ought to make a tutorial for doing basic stuff like that (maybe even a intro to computers, terminals ,opensource, and really anything about computers they probably will not know ), that only plays when minetest is compiled for windows or macOS as to not bother people that know what they are doing
this is a signature not a place to post messages also if i could change my username i would change it to sell_her_on55

User avatar
Desour
Member
Posts: 1469
Joined: Thu Jun 19, 2014 19:49
GitHub: Desour
IRC: Desour
In-game: DS
Location: I'm scared that if this is too exact, I will be unable to use my keyboard.

Re: asynchronous reprojection

by Desour » Post

c56 wrote:
Sun Dec 11, 2022 18:38
to reduce the number of drawcalls could we smooth out blocks far away (maybe up to 25-40 nodes bevore far-view-cube) ?
so for example : demo.png
if done right , this should be able to lower the complexity of the scene and make it a bit low-poly looking (but i am sure grouping similar nodes together could be a setting (would give more detail far away at cost at performance )
That would reduce the number of vertices, but that's not the bottleneck.
The issue with minetest's rendering is, AFAIK, that per mapblock there's one mesh per tile-type. So, if you have 10 differently textured nodes in a mapblock, it will be (at least) 10 meshes. And each of these meshes is drawn in a draw-call. And for each mesh you need to bind the texture and the vertex buffer before drawing it, this is slow. (I should probably mention that at least meshes are grouped by texture when drawing, I guess it probably helps (but it's bad for the gpu's occlusion culling).)
To improve, we have to group more faces into fewer, bigger meshes. This can be done by making meshes over multiple mapblocks, and (more importantly) by using texture atlases.
he/him; Codeberg; GitHub; ContentDB; public personal TODO list; "DS" is preferred (but often too short)

c56
Member
Posts: 307
Joined: Wed Apr 21, 2021 03:05
GitHub: tigercoding56
In-game: bm5 or bemo5 also sell_her_on55

Re: asynchronous reprojection

by c56 » Post

DS-minetest wrote:
Sun Dec 11, 2022 20:55
c56 wrote:
Sun Dec 11, 2022 18:38
to reduce the number of drawcalls could we smooth out blocks far away (maybe up to 25-40 nodes bevore far-view-cube) ?
so for example : demo.png
if done right , this should be able to lower the complexity of the scene and make it a bit low-poly looking (but i am sure grouping similar nodes together could be a setting (would give more detail far away at cost at performance )
That would reduce the number of vertices, but that's not the bottleneck.
The issue with minetest's rendering is, AFAIK, that per mapblock there's one mesh per tile-type. So, if you have 10 differently textured nodes in a mapblock, it will be (at least) 10 meshes. And each of these meshes is drawn in a draw-call. And for each mesh you need to bind the texture and the vertex buffer before drawing it, this is slow. (I should probably mention that at least meshes are grouped by texture when drawing, I guess it probably helps (but it's bad for the gpu's occlusion culling).)
To improve, we have to group more faces into fewer, bigger meshes. This can be done by making meshes over multiple mapblocks, and (more importantly) by using texture atlases.
Oh hmm i understand why is minetest grouping meshes by texture and not using 1 mesh for all the mapblocks maybe using vertex colors for faraway nodes ?
maybe this should be fixed
this is a signature not a place to post messages also if i could change my username i would change it to sell_her_on55

User avatar
Festus1965
Member
Posts: 4181
Joined: Sun Jan 03, 2016 11:58
GitHub: Festus1965
In-game: Festus1965 Thomas Thailand Explorer
Location: Thailand ChiangMai
Contact:

Re: asynchronous reprojection

by Festus1965 » Post

DS-minetest wrote:
Sun Dec 11, 2022 20:55
The issue with minetest's rendering is, AFAIK, that per mapblock there's one mesh per tile-type. So, if you have 10 differently textured nodes in a mapblock, it will be (at least) 10 meshes. And each of these meshes is drawn in a draw-call. And for each mesh you need to bind the texture and the vertex buffer before drawing it, this is slow.
upps, so that explains, why my simple builds (very less different nodes) are most low lag for gamer.
OR the spawn get laggy, when you offer all nodes possible there to show ...

but on the other side:
what could be done from client hardware or software (OS and/or driver side) to speed it up / tune it ?
Human has no future (climate change)
If urgend, you find me in Roblox (as CNXThomas)

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests