| Time |
Nick |
Message |
| 04:01 |
|
Taoki joined #minetest-dev |
| 04:48 |
|
YuGiOhJCJ joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 06:22 |
|
fluxflux_ joined #minetest-dev |
| 06:38 |
|
TLuna joined #minetest-dev |
| 06:51 |
|
appguru joined #minetest-dev |
| 07:16 |
|
lisac joined #minetest-dev |
| 08:00 |
|
ShadowNinja joined #minetest-dev |
| 08:02 |
|
mizux joined #minetest-dev |
| 08:15 |
|
zughy[m] joined #minetest-dev |
| 08:21 |
|
amk joined #minetest-dev |
| 08:22 |
|
TC01 joined #minetest-dev |
| 08:22 |
|
Shara joined #minetest-dev |
| 08:22 |
|
cheapie joined #minetest-dev |
| 08:22 |
|
Kray joined #minetest-dev |
| 08:22 |
|
thePalindrome joined #minetest-dev |
| 08:55 |
|
calcul0n joined #minetest-dev |
| 09:11 |
|
hecks joined #minetest-dev |
| 09:21 |
|
GreenXenith joined #minetest-dev |
| 09:47 |
|
TLuna joined #minetest-dev |
| 10:21 |
|
proller joined #minetest-dev |
| 10:27 |
|
unclouded joined #minetest-dev |
| 10:46 |
|
Fixer joined #minetest-dev |
| 12:02 |
|
proller joined #minetest-dev |
| 12:10 |
MTDiscord |
<srinivas> but again, hasnt storage become very cheap over the years |
| 12:12 |
MTDiscord |
<srinivas> A lot of folks have invested quite a bit in learning it + there are tons of tutorials that will get you started with it quickly |
| 12:12 |
MTDiscord |
<srinivas> Try doing that on a piss poor connection + unified inv |
| 12:14 |
MTDiscord |
<srinivas> and userd by most of the world? so you ave ready made documentation (to an extant + a lot of tutorials) |
| 12:55 |
|
nore joined #minetest-dev |
| 13:03 |
MTDiscord |
<srinivas> note: message 1 repiles to > > Full HTML/JS would probably 30x the download size of Minetest, would be crazy |
| 13:03 |
MTDiscord |
<srinivas> message 2: > Seeing as we are already developing our own markup (formspecs) and styles (formspec styling), we probably shouldn't move to web stuff |
| 13:04 |
MTDiscord |
<srinivas> message 3: > until then, forms aren't that bad |
| 13:04 |
MTDiscord |
<srinivas> message 4: > the only reason for using these is that they are "standard" |
| 13:06 |
MTDiscord |
<appguru> webdev is bad |
| 13:06 |
MTDiscord |
<srinivas> but its what turns the world |
| 13:06 |
MTDiscord |
<srinivas> hell, i hate it too |
| 13:06 |
MTDiscord |
<appguru> > A lot of folks have invested quite a bit in learning it + there are tons of tutorials that will get you started with it quickly > and userd by most of the world? so you ave ready made documentation (to an extant + a lot of tutorials) If you argue this way, we can directly go full Minecraft |
| 13:07 |
MTDiscord |
<srinivas> well |
| 13:07 |
MTDiscord |
<appguru> > hell, i hate it too Then it is time to reinvent the wheel! |
| 13:07 |
MTDiscord |
<srinivas> but why? |
| 13:07 |
MTDiscord |
<srinivas> it works, its open source |
| 13:07 |
MTDiscord |
<appguru> There is no issue with replacing JS with Lua for instance |
| 13:07 |
MTDiscord |
<srinivas> its well documented |
| 13:07 |
MTDiscord |
<srinivas> ye |
| 13:07 |
MTDiscord |
<srinivas> lua rocks |
| 13:07 |
MTDiscord |
<srinivas> but again |
| 13:07 |
MTDiscord |
<appguru> and then there's no issue with replacing HTML + CSS with better standards |
| 13:08 |
MTDiscord |
<appguru> I'm thinking SVG-like |
| 13:08 |
MTDiscord |
<srinivas> arent svg's vector art? |
| 13:09 |
MTDiscord |
<srinivas> or am i horribly misnformed/mistaken |
| 13:12 |
MTDiscord |
<srinivas> oh |
| 13:12 |
MTDiscord |
<srinivas> looks like i was half informed |
| 13:15 |
|
TLuna joined #minetest-dev |
| 13:16 |
pmp-p |
anything but with proper bidi/ltr/kerning/diacritics support and differential updates (vdom) |
| 13:17 |
pmp-p |
or it will be a giant wheel to reinvent |
| 13:17 |
MTDiscord |
<srinivas> so some sorta react for mt? |
| 13:18 |
|
turtleman joined #minetest-dev |
| 13:21 |
pmp-p |
i don't know what react, but a good gui should be asynchronous, updating cost minimal with draw calls batched and should support all types of scripts |
| 13:22 |
pmp-p |
and ideally it should compile out of the box in less than 5 minutes |
| 13:24 |
MTDiscord |
<srinivas> https://reactjs.org/docs/react-dom.html |
| 13:24 |
MTDiscord |
<srinivas> btw, compilation is largely cpu specific |
| 13:25 |
pmp-p |
i was more thinking of something ultra-light and C/C++ish like https://lvgl.io/demos |
| 13:27 |
pmp-p |
also +1 for markdown instead of html |
| 13:28 |
MTDiscord |
<srinivas> you do realise that markdown normally transpiles into html? |
| 13:28 |
MTDiscord |
<srinivas> and that you can use raw html in md |
| 13:32 |
pmp-p |
html rendering add useless complexity for both machine and human reader, simplistic md rendering should be enough for most use cases http://pmpp.ddns.net/paste/screen/shot-2020-12-08_1607454094.png |
| 13:33 |
MTDiscord |
<srinivas> m, and forms? |
| 13:34 |
rubenwardy |
using markdown for UI is a terrible idea - markdown is for documentation but you want structure for GUIs |
| 13:35 |
rubenwardy |
would be good to get a matrix for existing GUI solutions |
| 13:35 |
pmp-p |
excuse me gui is widget stuff, markdown is text display, and the textedit widget is a whole problem on its own |
| 13:36 |
MTDiscord |
<srinivas> looks at luacontrollerCode IDE |
| 13:37 |
pmp-p |
if you mix all that then that's not a wheel to implements, but a wheelS + the whole vehicule over it |
| 13:37 |
rubenwardy |
for GUIs you want to be able to build a tree of UI elements |
| 13:38 |
rubenwardy |
a tree because it's easier to layout and structure, and build things from reusable components |
| 13:38 |
MTDiscord |
<srinivas> that are ideally client side |
| 13:38 |
rubenwardy |
maybe I misunderstand "markdown instead of html" |
| 13:39 |
pmp-p |
what i mean is html is a mess because it mixes text + ui widgets |
| 13:39 |
MTDiscord |
<srinivas> dont think so, or i do too |
| 13:39 |
MTDiscord |
<srinivas> > what i mean is html is a mess because it mixes text + ui widgets so you want model-view-controller to be more seperated? |
| 13:40 |
rubenwardy |
oh right |
| 13:40 |
rubenwardy |
yeah, I'd like to have data and layout more separate |
| 13:40 |
rubenwardy |
MVVM is much nicer than MVC |
| 13:40 |
MTDiscord |
<srinivas> huh |
| 13:40 |
MTDiscord |
<srinivas> moment |
| 13:41 |
pmp-p |
ideally you should have localized text identifiers as numbers , then send you ui widget tree pointing those |
| 13:41 |
rubenwardy |
MVVM is when your UI knows about a view model (ie: the data), but the data doesn't know about the view |
| 13:41 |
pmp-p |
this way you know what lentgh you have before rendering widgets |
| 13:41 |
pmp-p |
and if cesure is required |
| 13:41 |
MTDiscord |
<srinivas> ah i see, thanks |
| 13:42 |
rubenwardy |
so your UI changes to match the data rather than writing a controller to change the UI |
| 13:42 |
pmp-p |
yep that's less network traffic |
| 13:42 |
rubenwardy |
however, it's possible to set up MVVM from MVC so this is probably something for later |
| 13:43 |
MTDiscord |
<srinivas> hm, i see, i often use php for my web dev, so i am all for tigt integration of view-controller |
| 13:46 |
|
NetherEran joined #minetest-dev |
| 13:51 |
rubenwardy |
My job is writing WPF (with MVVM) and I previously an Android dev (using MVC then MVVM) |
| 13:51 |
rubenwardy |
MVVM is so much cleaner to write and much easier to test |
| 13:51 |
rubenwardy |
but modders don't care about unit testing |
| 13:54 |
MTDiscord |
<srinivas> ah i see |
| 13:54 |
MTDiscord |
<srinivas> also |
| 13:55 |
MTDiscord |
<srinivas> in an aside |
| 13:55 |
MTDiscord |
<srinivas> is it possible to get screen resolution via the api? |
| 13:56 |
|
olliy joined #minetest-dev |
| 14:04 |
MTDiscord |
<appguru> not yet# |
| 14:05 |
MTDiscord |
<srinivas> oh, there is something in the works? |
| 14:05 |
rubenwardy |
what's your usecase? |
| 14:06 |
rubenwardy |
There's debates over how it should be done, just having screensize may not be especially helpful |
| 14:06 |
rubenwardy |
for things like showing less detailed GUIs on phones, there could be a boolean field |
| 14:06 |
rubenwardy |
also, phones have massive screen resolutions but small screens - so DPI is important |
| 14:07 |
rubenwardy |
well, screen res on phones vary a lot |
| 14:07 |
MTDiscord |
<appguru> I have a usecase for it |
| 14:07 |
MTDiscord |
<appguru> HUDs |
| 14:07 |
MTDiscord |
<appguru> say you want an image with 10vh height and 10vh width |
| 14:08 |
MTDiscord |
<appguru> currently impossible without using pixel sizes |
| 14:08 |
MTDiscord |
<srinivas> > also, phones have massive screen resolutions but small screens - so DPI is important or you can astract that with rem |
| 14:08 |
MTDiscord |
<srinivas> so you shouldnt care about display size/dpi |
| 14:08 |
MTDiscord |
<appguru> player:get_screen_info() returning {width, height, dpi} |
| 14:09 |
|
Taoki joined #minetest-dev |
| 14:09 |
rubenwardy |
except you should care about display size - there's not much different between two phones of different resolutions, they tend to make GUIs bigger in pixels to be the same size |
| 14:09 |
MTDiscord |
<srinivas> but does the client even send the scren data? |
| 14:09 |
rubenwardy |
no |
| 14:19 |
|
TLuna joined #minetest-dev |
| 15:59 |
|
absurb joined #minetest-dev |
| 16:13 |
hecks |
I don't know what you guys are talking about but please do something about the crappy item sprite scaling when you have the chance. |
| 16:31 |
|
fluxflux_ joined #minetest-dev |
| 16:51 |
MTDiscord |
<IhrFussel> Regarding phone resolutions: They vary so much that you can still buy smartphones from 2019 with a resolution of 480x854 |
| 16:54 |
MTDiscord |
<IhrFussel> Oops mixed up the 2 numbers haha |
| 17:00 |
|
lhofhansl joined #minetest-dev |
| 17:04 |
lhofhansl |
!tell hecks to have a look at https://sourceforge.net/p/irrext/code/HEAD/tree/trunk/extensions/scene/IMesh/ |
| 17:04 |
ShadowBot |
lhofhansl: O.K. |
| 17:06 |
hecks |
lhofhansl: no dice, this only helps with stuff I did in my branch already |
| 17:07 |
hecks |
we should look for some more specialized, voxel aware solution |
| 17:08 |
hecks |
I think atlasing is going to help us the most if it can be pulled off |
| 17:11 |
lhofhansl |
I'm looking for something simple or existing first, that we can get in quickly - like your batching code. |
| 17:11 |
hecks |
did you miss the part where all the surrounding issues were eating any gains from it? |
| 17:11 |
lhofhansl |
Perhaps :) |
| 17:12 |
hecks |
stupid things like cracko(verlay) triggering remeshes |
| 17:13 |
hecks |
I already wrote helpers to clobber meshes together efficiently so that's not a problem |
| 17:13 |
hecks |
the problem is that it still has a cost and we want to do it as rarely as possible |
| 17:13 |
hecks |
any frivolous remesh will hurt ten times as much on a batching branch |
| 17:14 |
hecks |
lastly I would really like to try atlasing before merging blocks, it would cull a lot better |
| 17:15 |
hecks |
of course it still requires mesh batching code, but perhaps a few extra clever things can be done in this special case |
| 17:15 |
celeron55 |
regarding texture atlases, did you know MT had them at a point in time? |
| 17:15 |
hecks |
I recall such a thing |
| 17:15 |
lhofhansl |
Would need to be done lazily on a separate thread - like meshgen. |
| 17:15 |
hecks |
tell me, how were they implemented? |
| 17:16 |
celeron55 |
then they were removed because of... i don't even remember why, probably rotten code and nobody wanting to fix it |
| 17:16 |
lhofhansl |
Is it still in the git history? |
| 17:16 |
hecks |
okay, well, I think I got a plan to do them right, checkout the "optimize map rendering" issue for details |
| 17:16 |
celeron55 |
lhofhansl: for sure |
| 17:17 |
hecks |
I want to use RTTs and hardware accelerate as much of the process as possible |
| 17:17 |
celeron55 |
the TileSpec and such classes were designed to carry texture atlas information with them |
| 17:17 |
celeron55 |
it shouldn't be very difficult to implement |
| 17:17 |
hecks |
interesting |
| 17:17 |
hecks |
I can also utilize the fact that everyone has shaders now, even android clients |
| 17:17 |
hecks |
use fragment shader texcoord windowing instead of tessing the geometry to make it work |
| 17:21 |
celeron55 |
https://github.com/minetest/minetest/commit/8161ab573fd6f8a45b3986278ce7fc1596140526 |
| 17:21 |
celeron55 |
for any historians out there |
| 17:22 |
MTDiscord |
<wwar> I think a mode like whitelist must be on default |
| 17:22 |
MTDiscord |
<wwar> That can be needed for new players who will host a server and it makes the game looks... more orginazed? |
| 17:27 |
celeron55 |
https://irc.minetest.net/minetest-dev/2013-02-27#i_2901090 |
| 17:27 |
celeron55 |
ah found something written by no other than myself |
| 17:27 |
celeron55 |
hecks: ^ |
| 17:28 |
celeron55 |
that's completely irrelevant now of course |
| 17:29 |
lhofhansl |
Sorting by material reduces the number of the draw calls for sure! |
| 17:29 |
celeron55 |
but it looks like at the time the atlas wasn't useful anymore |
| 17:30 |
lhofhansl |
Still... I instrumented that part and using large viewing_ranges can easily lead to 10-15k drawcalls per frame. |
| 17:31 |
celeron55 |
well these days people are wanting much larger render distances so there's more importance in optimizations |
| 17:31 |
lhofhansl |
Yep... I've been looking at that on both client and server. |
| 17:32 |
lhofhansl |
For me it was eye-opening to just compile with MAP_BLOCKSIZE of 32 and see my FPS triple in many cases. And the only difference is fewer drawcalls. I had no idea it's that important. |
| 17:33 |
rubenwardy |
> Compiling with MAP_BLOCKSIZE set to 32 (instead of 16) doubles or triples my FPS, and my card it at least 50% busy. (But MAP_BLOCKSIZE is also the unit of map loading/generation so it needs to stay small). |
| 17:33 |
rubenwardy |
The map is loaded in chunks, you could reduce that to 2 blocks |
| 17:33 |
rubenwardy |
for faster generation |
| 17:33 |
celeron55 |
over the years GPUs haven't gotten any faster processing a drawcall, but anything inside the drawcall is much faster now |
| 17:33 |
rubenwardy |
also, won't that be a network breaking change |
| 17:33 |
rubenwardy |
I guess you could have clients have their own unit of map |
| 17:34 |
lhofhansl |
rubenwardy: I tried chunksize=3 but it hardly made a difference. |
| 17:34 |
rubenwardy |
like, they could combine MapBlocks into a larger unit for rendering |
| 17:34 |
rubenwardy |
could it be the network? |
| 17:35 |
lhofhansl |
Doesn't look that way. The loadtime of the map is the same (even with chunksize=5), it |
| 17:35 |
lhofhansl |
's just more choppy. |
| 17:36 |
lhofhansl |
And yes, I think client and server could have different block sizes. But that's in the end batching, and atlasing is likely more effective. |
| 17:37 |
celeron55 |
decoupling the disk and render sizes should be done on the client anyway i think |
| 17:37 |
lhofhansl |
Agreed. |
| 17:38 |
celeron55 |
regardless of why or what the sizes should be |
| 17:39 |
celeron55 |
but mostly because changing the network protocol doesn't really benefit us, and that already makes batching to be the client's responsibility |
| 17:39 |
lhofhansl |
So that we have two different knobs to tweak. One for map loading/generation/network and one for rendering. |
| 17:40 |
lhofhansl |
right now they have opposite goals :) |
| 17:40 |
celeron55 |
well i'm still going to be the grumpy old man and tell you hardcoded 16 is fine right until rendering |
| 17:40 |
celeron55 |
and a good idea |
| 17:40 |
lhofhansl |
Oh I agree. |
| 17:41 |
celeron55 |
but even if it's not so, the client will want to convert between sizes |
| 17:42 |
lhofhansl |
And all interaction on the client would still be on 16-node blocks I assume. Just rendering would batch more into larger blocks (or smarter batching) |
| 17:42 |
celeron55 |
also in reality converting those for rendering doesn't necessarily mean almost anything in terms of how the data is laid out in memory, if it can only use multiples of disk mapblocks |
| 17:43 |
celeron55 |
the mesh generator is simply fed all the individual blocks it needs and then it puts out a mesh representing all of them at once |
| 17:43 |
celeron55 |
and that's enough for reducing drawcalls as much as one likes |
| 17:44 |
celeron55 |
if you configure the meshgen to make one mesh of the entire world, then you get only as many drawcalls as there are materials |
| 17:44 |
celeron55 |
and stupidly slow mesh generation speed |
| 17:45 |
lhofhansl |
IMHO that qualifies as a "simple solution". Although the details looks tricky. Need to update the large batches when one block changes, etc. Hecks solved part of this in the batching branch, but said there also were issues. |
| 17:45 |
celeron55 |
but still in memory the mapblocks are laid out like before and yes, interaction would happen like before |
| 17:46 |
celeron55 |
it's a many-to-one relationship from mapblocks to mapblock meshes then |
| 17:48 |
celeron55 |
or maybe many-to-many if you also store the non-combined meshes for various situations where you might want to use them (eg. if a mapblock updates, you might want to drop the bombined mesh, generate a mesh for only the updated mapblock and put the combined one into a less prioritized background queue) |
| 17:48 |
celeron55 |
combined* |
| 17:49 |
lhofhansl |
many-to-one seems fine as long as the meshes are updated in the meshgen thread, I think. |
| 17:49 |
celeron55 |
well, lots of details of course |
| 17:49 |
hecks |
okay I'm back, let me catch up on a couple things |
| 17:49 |
lhofhansl |
:) |
| 17:50 |
hecks |
so doing meshgen as we're doing right now is fine, even with atlasing or batching |
| 17:50 |
hecks |
batching meshes for atlasing in particular can involve more move operations or small gaps in the vertex buffer |
| 17:51 |
hecks |
it's okay to have a few unused vertices not indexed by any primitive if it makes a rebatch faster |
| 17:52 |
celeron55 |
so you intend to do the batching by combining the already generated small meshes? |
| 17:52 |
hecks |
yup, there's little benefit to having an atlased path for the mesher |
| 17:52 |
celeron55 |
makes sense for sure |
| 17:53 |
hecks |
if the work is broken up into smaller portions, mesher updates should block less |
| 17:53 |
celeron55 |
...for that exact reason |
| 17:53 |
hecks |
integrating the individual meshes into the batch must be done as lazily as possible |
| 17:54 |
lhofhansl |
and not on the render thread |
| 17:54 |
hecks |
yeah, I suppose another thread would be responsible for receiving the mesher output and integrating it |
| 17:54 |
celeron55 |
if it's fast enough, then why not in the render thread. but what exactly has to be done? |
| 17:55 |
hecks |
there is an advantage to doing it in the render thread actually |
| 17:55 |
hecks |
you want to gather all possible mesh updates and integrate them in one go |
| 17:55 |
hecks |
so maybe scratch that thread part |
| 17:55 |
lhofhansl |
is this different in principle from the meshing done in the meshgen thread? |
| 17:56 |
|
olliy joined #minetest-dev |
| 17:56 |
lhofhansl |
that used to cause a lot of client stutter |
| 17:56 |
|
antims joined #minetest-dev |
| 17:56 |
celeron55 |
think more like cutting and pasting the already generated meshes as-is into larger batches |
| 17:57 |
hecks |
I'm just afraid that a series of remeshes can trigger a series of rebatches when it could be done in one rebatch |
| 17:57 |
lhofhansl |
I'm running out of my depth here... Don't need to need to translate the meshes to be in the same coordinate system? |
| 17:57 |
hecks |
no, nothing gets translated |
| 17:57 |
hecks |
not ever since I destroyed the camera offset translation |
| 17:58 |
hecks |
every block mesh is in the block's space and that's it |
| 17:58 |
hecks |
this is precisely why the batching branch had that in the first place |
| 17:58 |
lhofhansl |
so each mesh has its own model matrix? |
| 17:58 |
hecks |
each block |
| 17:58 |
hecks |
all meshes in a block currently share the model matrix |
| 17:58 |
hecks |
which is just the block's position * BLOCKSIZE * BS |
| 17:59 |
lhofhansl |
right, so how do you combine meshes from multiple blocks without translating the vertices? (as I said, out of my depth) |
| 17:59 |
hecks |
ok so in that case you apply the offset, local to the batch |
| 17:59 |
hecks |
but as I've said, I want to ditch the idea of merging blocks in favor of atlasing |
| 18:00 |
hecks |
in any case the offset can be done on the fly while blitting the vertex data because you have to do that anyway |
| 18:00 |
celeron55 |
what kind of atlasing do you intend to do? |
| 18:00 |
celeron55 |
atlas per block? |
| 18:00 |
hecks |
yes |
| 18:00 |
celeron55 |
and then you have one drawcall per block, always |
| 18:00 |
hecks |
shared between some blocks if possible but generally very dynamic |
| 18:00 |
hecks |
assembled just-in-time, hardware accelerated |
| 18:01 |
hecks |
maybe not one per block, closer to one per block per material type |
| 18:01 |
hecks |
one for opaque, one for alpha |
| 18:01 |
celeron55 |
how many drawcalls per block per material type are there currently? |
| 18:01 |
celeron55 |
as many as there are textures? |
| 18:01 |
hecks |
yes |
| 18:01 |
hecks |
+ soft overlays |
| 18:01 |
hecks |
this is why we have 4 thousand drawcalls on a pretty normal scene |
| 18:02 |
hecks |
a "sane" game's metric would be closer to 400 |
| 18:02 |
celeron55 |
so it depends on the map data a lot |
| 18:02 |
celeron55 |
but in any varied situation there are quite many |
| 18:02 |
celeron55 |
i mean if you have a grass field, you might have just 1 or 2 textures |
| 18:02 |
hecks |
yup, another reason why my batching sucked - mall servers still chugged, it was good in minimalist games but underperformed in a real scenario |
| 18:03 |
celeron55 |
of you have a jungle or an urban environment, then who knows |
| 18:03 |
hecks |
atlasing handles this much better |
| 18:03 |
celeron55 |
if* |
| 18:03 |
hecks |
I also want to do another thing |
| 18:03 |
hecks |
exclude very sparse nodes from meshing entirely, draw them as objects |
| 18:04 |
hecks |
one vending machine, nyancat block, table, whatever does not deserve the overhead of being "meshed" |
| 18:04 |
hecks |
it can just be culled and rendered as an individual thing |
| 18:04 |
hecks |
or dynamically batched if there are a few in the frustum |
| 18:04 |
celeron55 |
well, usually they are also interacted with a lot |
| 18:04 |
hecks |
exactly, and they change materials, which triggers more remeshes |
| 18:04 |
hecks |
again, a typical "mall server" or busy city or however you call it has a lot of these inside buildings |
| 18:05 |
hecks |
being able to cull them individually would help a ton |
| 18:05 |
hecks |
probably a lot more than attempting to treat them as normal nodes |
| 18:05 |
celeron55 |
but for this you need some kind of list of such nodes, either based on a heuristic or measured dynamically |
| 18:05 |
celeron55 |
or listed manually |
| 18:05 |
hecks |
just a metric of a node count per block |
| 18:05 |
hecks |
say, more than 4 instances in a block deserves a meshing |
| 18:06 |
hecks |
and lua_api overrides could be possible |
| 18:06 |
hecks |
like always mesh or never mesh |
| 18:06 |
celeron55 |
preferably it should work fine enough without manual tuning |
| 18:07 |
celeron55 |
people will misuse any manual stuff and then complain |
| 18:07 |
lhofhansl |
^ that |
| 18:07 |
hecks |
this would really be obscure |
| 18:07 |
hecks |
I doubt anyone would even dare touch a property like meshing_hint |
| 18:07 |
hecks |
since it's controlled by the game developer, he shouldn't complain |
| 18:08 |
lhofhansl |
(comes back to my gripe about all the distance options you'd have to configure just to increase the viewing_range past the default) |
| 18:08 |
celeron55 |
of course MT is full of settings that people misuse and then complain so what am i to say this 8) |
| 18:08 |
lhofhansl |
:) |
| 18:08 |
hecks |
well that's a good argument to not make the heuristic a .conf entry |
| 18:09 |
hecks |
but a per-node property to set it would be fine |
| 18:09 |
celeron55 |
anyway this sounds fine, feel free to stop talking and start coding |
| 18:09 |
lhofhansl |
every time I want to remove the config option and derive the value, someone complains |
| 18:09 |
hecks |
meshing_hint = [number], "always" or "never |
| 18:09 |
lhofhansl |
*a* config option |
| 18:10 |
|
TLuna joined #minetest-dev |
| 18:10 |
hecks |
every time anyone wants to do anything wise, people complain |
| 18:10 |
hecks |
this is why developers have the final word |
| 18:10 |
celeron55 |
to any end user, i'd describe this optimization as not helping much in a natural environment, but helping a lot in a built-up environment |
| 18:11 |
hecks |
I cannot imagine a user ever wanting to globally tweak the meshing threshold |
| 18:11 |
hecks |
let's talk about something else |
| 18:11 |
hecks |
greedy meshing and how it actually causes a ton of remeshes |
| 18:12 |
hecks |
if greedy meshing wasn't a thing, a simple light update wouldn't cause a remesh |
| 18:12 |
hecks |
because the vertex color could be updated by itself |
| 18:12 |
hecks |
greedy meshing isn't very greedy in the first place and doesn't save us a ton of geometry |
| 18:12 |
hecks |
is there a chance we could just kill it? |
| 18:12 |
celeron55 |
yeah greedy meshing is probably a thing of the past when vertex counts mattered more |
| 18:13 |
lhofhansl |
tangentially... If someone could look at #10715. It helps a lot with slow map saving (and the server stalls resulting from it) |
| 18:13 |
ShadowBot |
https://github.com/minetest/minetest/issues/10715 -- Allow configuring block disk and net compression. Change default disk level. by lhofhansl |
| 18:13 |
hecks |
all it does is merge plain node faces into strips no longer than 16, along one axis per face |
| 18:14 |
lhofhansl |
hecks: Meaning we should kill fastfaces? |
| 18:14 |
celeron55 |
of course benchmark before removal but i'm fairly certain if removal of it helps adding new optimizations, it can be removed |
| 18:14 |
hecks |
kill it and use the opportunity to make light updates cheaper, and to use lookup tables and blitting more in meshing |
| 18:15 |
lhofhansl |
Someone tried that a while back (numberZero?) and it did hurt performance. |
| 18:15 |
celeron55 |
can you find the numbers |
| 18:15 |
lhofhansl |
#6903 |
| 18:15 |
hecks |
it would be nice to know which part it hurt, time spent meshing, render time, or mesher I/O |
| 18:16 |
ShadowBot |
https://github.com/minetest/minetest/issues/6903 -- [Experimental] Drop fast faces by numberZero |
| 18:16 |
lhofhansl |
Maybe time to try again. |
| 18:16 |
hecks |
note that liquids no longer use this anyway |
| 18:16 |
hecks |
now that they have perlin waves |
| 18:16 |
lhofhansl |
I disabled it, but only when "waves" is enabled. |
| 18:16 |
hecks |
at around 0.4 water still used greedy meshing |
| 18:17 |
lhofhansl |
It still does when "waves" is off. |
| 18:17 |
hecks |
okay, well, I'm just looking at a typical scene and I barely see any faces being merged |
| 18:17 |
hecks |
https://a.uguu.se/EefcXKMdnFTP_scene.jpg |
| 18:17 |
lhofhansl |
As I commented in 6903 I'd love to get rid of all that code. |
| 18:18 |
hecks |
it seems to kill faces pointing at +Y the most |
| 18:18 |
hecks |
because they are the least likely to have a light gradient on them |
| 18:19 |
lhofhansl |
there isn't much flat in that scene |
| 18:19 |
hecks |
and is there a lot of flat in most scenes? |
| 18:19 |
lhofhansl |
I saw of lot of artifacts when I played with the sphere mapping of MT. Ended up just turning fastfaces off. |
| 18:20 |
hecks |
it's true that I use more noise octaves |
| 18:20 |
lhofhansl |
If it makes atlasing/batching easier, let's kill fastfaces. |
| 18:20 |
|
fluxflux joined #minetest-dev |
| 18:21 |
hecks |
I have no idea if it will make that easier |
| 18:21 |
hecks |
it will actually increase the amount of data to copy around |
| 18:21 |
hecks |
it would however kill light-only remeshes |
| 18:21 |
hecks |
I got another idea: hierarchical remesh |
| 18:22 |
hecks |
where the mesher caches the block in a tree structure, like an octree, and only actually remeshes parts that have been touched |
| 18:22 |
hecks |
and only copies the rest |
| 18:22 |
hecks |
pretty much the same idea as merge-batching - but all the way to single node level |
| 18:22 |
hecks |
oh but this conflicts with fastfaces too |
| 18:23 |
celeron55 |
it might not make sense to have a very deep hierarchy |
| 18:23 |
celeron55 |
but maybe splitting to 8x8x8 nodes would make sense |
| 18:23 |
hecks |
who knows? maybe making the map out of huge octrees is just what the doctor ordered |
| 18:24 |
celeron55 |
when you go smaller, the borders require extra processing |
| 18:24 |
celeron55 |
the smaller the batch, the more surface per volume you get |
| 18:24 |
hecks |
ah, square cube |
| 18:24 |
celeron55 |
and in my experience surface is a bit of a problem when meshing |
| 18:24 |
celeron55 |
it needs extra care |
| 18:24 |
celeron55 |
i mean voxel volume surface |
| 18:25 |
celeron55 |
but who knows |
| 18:25 |
celeron55 |
what about the extreme, meshing each node individually? that certainly wouldn't make sense |
| 18:25 |
celeron55 |
it means there's a lower limit |
| 18:25 |
celeron55 |
for what makes sense |
| 18:26 |
hecks |
would it not? on a single node level, you can just crunch out a lookup table for all the ways a node may be used |
| 18:26 |
celeron55 |
well maybe if you can efficiently process nodes with no visible faces |
| 18:27 |
hecks |
6 bit lookup table (64 elements) |
| 18:27 |
hecks |
where the bits are neighbor presence |
| 18:27 |
celeron55 |
so each mapblock would have a list of nodes with visible faces, and for each of those a lookup table index for what the mesh looks like |
| 18:28 |
celeron55 |
or what |
| 18:29 |
hecks |
each mapblock would be swept in the three dimensions to determine neighbor information for each node (that 6 bit number), stashing that into a buffer |
| 18:29 |
celeron55 |
i think that wouldn't be very useful when rendering, maybe as a cached processing step |
| 18:29 |
hecks |
then another pass would do the lookup |
| 18:30 |
celeron55 |
so basically splitting mesh generator into two steps, the first one which can be cached? |
| 18:30 |
celeron55 |
on a per-node basis |
| 18:30 |
hecks |
it's like |
| 18:30 |
hecks |
a nodedef has this [64] lookup for possible meshes generated (for normals, just one shared lut is needed) |
| 18:30 |
hecks |
then, when we mesh, the first pass computes indices into this lookup |
| 18:31 |
hecks |
the second pass does the substitution and actual mesh |
| 18:31 |
hecks |
meshing |
| 18:31 |
hecks |
this is highly, and I mean highly parallelizable |
| 18:31 |
hecks |
but... no greedy meshing |
| 18:31 |
hecks |
also cacheable at any granularity, so if you wanted to stash 8x8x8 results, you could |
| 18:31 |
celeron55 |
the thing about greedy meshing is, on any dedicated GPU you get basically no benfit, but on basically all integrated GPUs you kind of want it |
| 18:31 |
celeron55 |
+e |
| 18:32 |
hecks |
maybe it can be done as a postprocessing step |
| 18:32 |
hecks |
as a pure mesh operation, unaware of voxels |
| 18:32 |
hecks |
just weld vertices that contribute nothing |
| 18:32 |
celeron55 |
altough once people see how much lighter updates can be... maybe it's worth the loss in FPS anyway |
| 18:33 |
hecks |
steady 60 fps is better than stuttery 80 fps |
| 18:33 |
celeron55 |
i'd certainly like to see this |
| 18:33 |
hecks |
it would be a cool experiment |
| 18:34 |
celeron55 |
already forgot what problem we were trying to solve though |
| 18:34 |
hecks |
=] |
| 18:34 |
hecks |
minimizing remeshes to make batching viable |
| 18:35 |
hecks |
the part that really stinks is how 3D textures aren't universally supported |
| 18:35 |
hecks |
that would eliminate the concern about light |
| 18:36 |
celeron55 |
well, you always need to navigate the opengl version jungle |
| 18:36 |
hecks |
but oh right, some people have talked about lightmapping as a solution to this |
| 18:36 |
hecks |
and you know |
| 18:36 |
hecks |
technically slicing a 2D texture can crudely emulate a 3D one |
| 18:36 |
hecks |
for a blocksize 16... |
| 18:37 |
lhofhansl |
Hey... Going to merge #10721 in a few. |
| 18:37 |
ShadowBot |
https://github.com/minetest/minetest/issues/10721 -- Revert "GUIFormSpecMenu: Shift+Click listring workaround for MacOS" by SmallJoker |
| 18:37 |
hecks |
a 64x64 texture will do |
| 18:37 |
hecks |
that can contain the whole 3D "lightmap" of a block |
| 18:38 |
hecks |
at the cost of one lerp and one extra tex2d in the fragment shader to simulate bilinear filtering on the Z axis |
| 18:38 |
celeron55 |
makes sense |
| 18:40 |
celeron55 |
well |
| 18:40 |
celeron55 |
in cases where nodes touch only at edges, it can get nasty |
| 18:41 |
celeron55 |
but with current code it's not very well handled anyway |
| 18:41 |
lhofhansl |
Let |
| 18:41 |
celeron55 |
or was it fixed? eh, i should know |
| 18:42 |
lhofhansl |
Let's start with something simple and not boil the ocean. |
| 18:43 |
celeron55 |
well |
| 18:43 |
celeron55 |
first you remove someone else's complexity, then add your own complexity |
| 18:43 |
celeron55 |
simple |
| 18:44 |
celeron55 |
at this point anyone who considerably improves MT's rendering will be considered a legend |
| 18:45 |
celeron55 |
so there's a lot at stake here! |
| 18:45 |
|
longerstaff13 joined #minetest-dev |
| 18:45 |
hecks |
just kill some drawcalls, what could possibly go wrong.... |
| 18:46 |
celeron55 |
let's just drop 50% of them at random |
| 18:46 |
celeron55 |
who cares if you don't see everything on every frame |
| 18:46 |
hecks |
block_send_optimize_distance and our lousy culling already do that |
| 18:46 |
celeron55 |
:D |
| 18:47 |
celeron55 |
i guess |
| 18:47 |
hecks |
actually, do proper culling and you'll see at least 20% of them gone |
| 18:47 |
hecks |
you can't fly around in wireframe mode without the urge to ask "why is this being drawn" |
| 18:49 |
hecks |
https://a.uguu.se/ENJdOYJCOonN_quality.jpg |
| 18:49 |
sfan5 |
doesn't irrlicht even support occlusion queries |
| 18:49 |
hecks |
occlusion queries suck |
| 18:49 |
hecks |
but we can definitely do better |
| 18:51 |
hecks |
dungeons are always fun https://a.uguu.se/zo6VilCVAO3p_culling.jpg |
| 18:51 |
sfan5 |
you can go and tweak the values of the current occlusion code but it'll fail on your fast because it's very inaccurate |
| 18:51 |
sfan5 |
and the current fix for that is pretty much "just render everything within 48 (or more?) nodes" |
| 18:52 |
hecks |
it has some interesting false positives going on too |
| 18:52 |
hecks |
who hasn't seen blocks just blink in and out of existence for no reason |
| 18:53 |
celeron55 |
there can only be a finite number of rays for occlusion culling |
| 18:53 |
hecks |
which is why I don't want to use rays for this |
| 18:53 |
celeron55 |
so you always get false positives and false negatives |
| 18:53 |
hecks |
I want to straight up software render some cubes |
| 18:53 |
hecks |
do what occlusion queries do but without the lag |
| 18:54 |
hecks |
you don't even have to render cubes, just hexagons that form the outline of those |
| 18:55 |
celeron55 |
i at some point was thinking if it would be possible to precalculate whether a mapblock can be seen through in each direction and stop doing any node-level rays but instead do them at the mapblock level |
| 18:55 |
hecks |
you're thinking of hierarchical culling |
| 18:55 |
hecks |
you can definitely do an early hit/miss on a whole mapblock before considering its contents |
| 18:56 |
hecks |
better yet, use octrees, they're wonderful for this |
| 18:57 |
hecks |
oh wait |
| 18:57 |
hecks |
I know what you mean now |
| 18:57 |
celeron55 |
for most mapblocks that you shouldn't see through you can't even run a pathfind from the front face to back face |
| 18:57 |
hecks |
you can possibly precompute this |
| 18:58 |
hecks |
the planes bounding a box divide space into 27 regions including itself |
| 18:58 |
hecks |
but uh, no, not like that |
| 18:59 |
lhofhansl |
I tried to improve the current occlusion culling a while back - remember that? Didn't go that well. |
| 18:59 |
hecks |
actually I think that sort of precomputation would be too expensive to perform |
| 19:00 |
hecks |
it would take a nontrivial amount of time to determine if a mapblock is tight for all the possible ray combinations |
| 19:02 |
hecks |
here's some very esoteric WIP culling code for anyone interested https://github.com/hecktest/minetest/blob/batching/src/client/culling.cpp |
| 19:02 |
lhofhansl |
I remember reading an article about how minecraft does it. They use a flooding model. |
| 19:07 |
hecks |
flooding wouldn't be too tight, so screw it |
| 19:07 |
celeron55 |
generally mapblocks have 8 corners, one of which you are always the closest to, and you will be generally seeing 1, 2 or 3 mapblock faces that touch the corner. for you to see through the mapblock, there has to be a path through the mapblock from any of the 3 faces to any of the opposing 3 faces. if there is not, you can't see through the mapblock and any mapblock behind it can always be culled |
| 19:07 |
hecks |
celeron55: does this account for perspective? |
| 19:07 |
celeron55 |
there could of course be a path through it that you can't see through |
| 19:08 |
celeron55 |
that's true even with perspective |
| 19:08 |
celeron55 |
of course you'll get only partial culling with this |
| 19:09 |
celeron55 |
it's just a way that came into mind that would give zero false positives |
| 19:09 |
celeron55 |
of course it requires a fast enough pathfinder, i don't know if that exists |
| 19:10 |
hecks |
any thoughts on my rasterizing approach? |
| 19:10 |
celeron55 |
it can (or should) be a ray based pathfinder that requires a straight path |
| 19:10 |
|
proller joined #minetest-dev |
| 19:10 |
celeron55 |
but it has to check all possible paths |
| 19:10 |
hecks |
I basically wanted to rasterize [n] layers of 1-bpp stencils, in 8x8 tiles because each fits into a u64 |
| 19:10 |
hecks |
and then use bitops to do everything |
| 19:11 |
hecks |
https://github.com/hecktest/minetest/blob/15d573d7182abbf1f31b7767d8318e99387342d0/src/client/culling.cpp#L36 |
| 19:12 |
celeron55 |
well, does it work? |
| 19:12 |
hecks |
no idea :DDD I didn't finish it |
| 19:12 |
hecks |
but rasterization using tiles was fast |
| 19:14 |
celeron55 |
it's still a node level raycast, right? |
| 19:15 |
hecks |
no, I was straight up rasterizing boxes to do software occlusion queries |
| 19:16 |
lhofhansl |
https://tomcc.github.io/2014/08/31/visibility-1.html |
| 19:18 |
celeron55 |
i can't really imagine how fast it would be |
| 19:20 |
lhofhansl |
I actually hacked it into MT once and it was very slow :) |
| 19:20 |
lhofhansl |
(But I didn't make a great effort either - and didn't keep the branch) |
| 19:23 |
lhofhansl |
The way that it is described, the caching, etc, I can envision this is being fast... And it is accurate. |
| 19:23 |
hecks |
check out these bleeding edge realtime 3D graphics https://a.uguu.se/4TXBOF0nStIK_raster.jpg |
| 19:25 |
celeron55 |
lhofhansl: that's fairly similar to what i described |
| 19:25 |
lhofhansl |
Yep |
| 19:26 |
|
TLuna joined #minetest-dev |
| 19:28 |
hecks |
let's maybe try to look for obvious things to fix that would make batching easier |
| 19:28 |
hecks |
I nominate cracko, that one is low hanging fruit |
| 19:28 |
hecks |
also #10714 |
| 19:28 |
ShadowBot |
https://github.com/minetest/minetest/issues/10714 -- Keep mapblocks in memory if they're in range by hecktest |
| 19:28 |
celeron55 |
occlusion culling certainly isn't one. we have it, it mostly works in real use |
| 19:28 |
lhofhansl |
(not a fan of 10714 - as you know) |
| 19:29 |
celeron55 |
i think #10714 makes sense |
| 19:29 |
ShadowBot |
https://github.com/minetest/minetest/issues/10714 -- Keep mapblocks in memory if they're in range by hecktest |
| 19:30 |
hecks |
because you still think that those things should be (incorrectly) based on the view frustum? |
| 19:30 |
lhofhansl |
yes |
| 19:30 |
hecks |
and that the server should just immediately send us mapblocks using tachyons if we turn the camera? |
| 19:31 |
lhofhansl |
If you didn't look that way for 10 minutes... Yes. |
| 19:31 |
hecks |
no, because |
| 19:31 |
hecks |
as it is, every time a client unload happens - be it every 10 minutes or 10 seconds (and 10 seconds is MUCH preferrable) |
| 19:31 |
hecks |
all the blocks behind me go poof |
| 19:32 |
hecks |
and just because I didn't look that way for 10 minutes |
| 19:32 |
hecks |
who's to say I won't do it 10 minutes and one second later? |
| 19:32 |
hecks |
it looks broken, it is broken, it ruins a superior memory management strategy |
| 19:32 |
lhofhansl |
As I also said somewhere... If we change the logic of the cache it's fine. As is it sorts all cached blocks by time and then expires the older ones. |
| 19:33 |
hecks |
did you actually test it? |
| 19:33 |
lhofhansl |
Maybe two caches. One that keep the sphere always. No sorting. And some extra cache. |
| 19:33 |
hecks |
that's fine too |
| 19:33 |
hecks |
but as a quick fix, isn't this good enough? |
| 19:33 |
hecks |
it basically does this |
| 19:33 |
hecks |
it always keeps the sphere |
| 19:33 |
hecks |
and the clock only starts ticking for things outside of it |
| 19:34 |
hecks |
also somewhat relevant https://github.com/minetest/minetest/issues/10683#issuecomment-739557347 |
| 19:35 |
hecks |
I encountered similar stutter to this guy and I narrowed it down to client data unloads |
| 19:35 |
hecks |
cranking up the unload rate helps because there's less stuff to dump at once, but to make that viable, 10714 is needed |
| 19:35 |
lhofhansl |
I suppose that we release the HW buffers (#10501) it's more acceptable. |
| 19:35 |
ShadowBot |
https://github.com/minetest/minetest/issues/10501 -- Periodically release all mesh HW buffers to avoid an Irrlicht bottleneck by lhofhansl |
| 19:35 |
lhofhansl |
now that... |
| 19:38 |
lhofhansl |
It's 3x as many blocks to keep in the cache. Relevant for large viewing ranges. |
| 19:38 |
lhofhansl |
(at fov = 72) |
| 19:38 |
hecks |
eeee hold on a second |
| 19:39 |
hecks |
those blocks, we should've been keeping them from the beginning |
| 19:39 |
hecks |
and fov is irrelevant because nobody just stands around staring at one spot |
| 19:39 |
hecks |
those blocks get loaded anyway |
| 19:40 |
hecks |
only they get dropped for a stupid reason |
| 19:40 |
hecks |
and then they get loaded again |
| 19:42 |
hecks |
you're trying to preserve an optimization that does more harm than good, and doesn't even save that much ram |
| 21:52 |
|
TLuna joined #minetest-dev |
| 22:20 |
|
Taoki joined #minetest-dev |
| 22:35 |
sfan5 |
merging #10152 in 10 minutes |
| 22:35 |
ShadowBot |
https://github.com/minetest/minetest/issues/10152 -- Semi-transparent background for nametags by Zughy |
| 22:38 |
MTDiscord |
<Lone_Wolf> sweet |
| 22:46 |
|
Fixer_ joined #minetest-dev |
| 23:06 |
|
lhofhansl joined #minetest-dev |
| 23:38 |
MTDiscord |
<IhrFussel> I just hope this will look good with already transparent name tags too cause that is what I use on my server |
| 23:39 |
MTDiscord |
<IhrFussel> By transparent I mean alpha set to half |
| 23:39 |
sfan5 |
those are entities aren't they? |
| 23:40 |
MTDiscord |
<IhrFussel> No, I use the builtin name tags with alpha set to half plus different colors |
