| Time |
Nick |
Message |
| 00:28 |
|
v-rob joined #minetest-dev |
| 00:42 |
|
Sokomine joined #minetest-dev |
| 00:47 |
|
v-rob joined #minetest-dev |
| 00:58 |
|
AliasAlreadyTake joined #minetest-dev |
| 02:00 |
|
v-rob joined #minetest-dev |
| 02:07 |
|
v-rob joined #minetest-dev |
| 03:29 |
|
queria^clone joined #minetest-dev |
| 03:33 |
|
queria^clone joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:03 |
|
v-rob joined #minetest-dev |
| 05:23 |
|
Pexin joined #minetest-dev |
| 05:48 |
|
Yad joined #minetest-dev |
| 06:27 |
|
Pexin joined #minetest-dev |
| 06:41 |
|
calcul0n joined #minetest-dev |
| 06:42 |
|
v-rob joined #minetest-dev |
| 07:28 |
|
panwolfram joined #minetest-dev |
| 07:41 |
|
panwolfram joined #minetest-dev |
| 09:26 |
|
appguru joined #minetest-dev |
| 10:29 |
|
_Zaizen_[m] joined #minetest-dev |
| 10:40 |
|
appguru joined #minetest-dev |
| 10:48 |
|
Taoki joined #minetest-dev |
| 10:51 |
|
HuguesRoss4 joined #minetest-dev |
| 12:55 |
|
proller joined #minetest-dev |
| 13:30 |
|
appguru joined #minetest-dev |
| 14:25 |
ronoaldo |
makes sense, thanks! so it won't hurt to me if I try OpenGL then. Which OpenGL "version/level" would be ideal? Like OpenGL ES or something else? |
| 14:27 |
|
Fixer joined #minetest-dev |
| 14:49 |
|
appguru joined #minetest-dev |
| 14:57 |
erlehmann |
ronoaldo this depends on your hardware. minimum for minetest is opengl 1.3 right now AFAIK. there is an OGLES2 renderer, but the shaders exceed the amount of instructions given in the OGLES2 spec, so depending on your hardware, it might not work even if it's OGLES2 compliant (look in the github issue tracker for mali GPU, it's compliant, but can't do the OGLES2). |
| 14:58 |
erlehmann |
i mean minetest can't do the OGLES2 thing because shader instruction amount |
| 14:59 |
erlehmann |
ronoaldo to be clear: there is no single “best” version that works for all hardware. it depends on your hardware. i have both hardware where OGLES2 rendering gives more fps (reform2) and hardware where opengl fixed pipeline gives more fps (thinkpad t60). and someone in the issue tracker even reported something where OGLES1 would work best on some hardware. |
| 15:03 |
erlehmann |
ronoaldo the “direction” is OGLES2-like, but it's definitely not OGLES2 … i have read the spec and the limits on shader size are not an optional thing, if you want your stuff to run on conforming hardware, you can't reasonably exceed them. if you are a shader wizard, maybe you can optimize it until it's runs on all conforming hardware? |
| 15:07 |
erlehmann |
ronoaldo also if you want to improve rendering a most frustrating thing for players performance-wise is the amount of drawcalls for particles. |
| 15:59 |
ronoaldo |
I see - so it is not even related to the rendering alone, the algorithm behind the particles in this case, right? |
| 16:00 |
rubenwardy |
no, the problem is the rendering |
| 16:00 |
ronoaldo |
I'm willing to learn more about this stuff so it is nice to get a real issue like that so I can both learn the codebase from Minetest and the required graphics stuff |
| 16:00 |
rubenwardy |
each particle is rendered individually |
| 16:00 |
rubenwardy |
this results in a huge number of drawcalls - calls from the CPU to the GPU |
| 16:00 |
ronoaldo |
I see, so the irrlitch now is the potential bottleneck? or this particles are done via shaders? |
| 16:00 |
rubenwardy |
no, it's not Irrlicht at all |
| 16:00 |
rubenwardy |
it's Minetest |
| 16:00 |
ronoaldo |
got it |
| 16:01 |
rubenwardy |
the solution is to batch the particles. You don't need shaders for this, but you can use shaders to make the particles even more performance |
| 16:02 |
rubenwardy |
Minetest wouldn't have this problem if it used the Irrlicht particle system, as that batches particles |
| 16:02 |
rubenwardy |
but the irrlicht particle system doesn't have a particular rendering feature |
| 16:03 |
ronoaldo |
I see - sounds like a fun problem to dig into :) if noone else is already doing to avoid duplicate effort |
| 16:04 |
|
olliy joined #minetest-dev |
| 16:12 |
erlehmann |
0, |
| 16:27 |
|
v-rob joined #minetest-dev |
| 17:03 |
MTDiscord |
<exe_virus> Go for it. Definitely the particle system needs a revamp |
| 17:04 |
MTDiscord |
<Jonathon> the particle PR seems like it getting closer to being merged anyways |
| 17:05 |
MTDiscord |
<Jonathon> https://github.com/minetest/minetest/pull/11545 |
| 17:05 |
rubenwardy |
that's tangental, adds more features onto a swamp |
| 17:05 |
rubenwardy |
very nice features |
| 17:06 |
MTDiscord |
<Jonathon> yeah, i guess my terribly made point was working on particles means whoever doesnt get merged first will have to fix there pr from conflicts most likely |
| 17:08 |
MTDiscord |
<exe_virus> Gotcha, my money is on neither ;) |
| 17:10 |
ronoaldo |
haha gotta love git merge, right? |
| 17:49 |
|
Pexin joined #minetest-dev |
| 19:08 |
|
erlehmann joined #minetest-dev |
| 19:10 |
erlehmann |
ronoaldo has someone showed you the PR where particle rendering was ported to the irrlicht particle system, but then it turns out that one feature was missing? there may be another way: figure out how to batch the particles so you can minimize the drawcalls. |
| 19:11 |
erlehmann |
ronoaldo from what i can gather from the irrlicht forums, batching is in principle a solved problem, but i haven't figured it out how to apply it. i guess figuring out if the irrlicht particle system can be enhanced to support the missing thing might be a good idea anyway. |
| 19:16 |
ronoaldo |
erlehmann: cool, thanks for the info; the PR is 11545? |
| 19:22 |
appguru |
batching ought to be pretty simple if you're in full control of the rendering pipeline |
| 19:23 |
erlehmann |
#11545 |
| 19:23 |
ShadowBot |
https://github.com/minetest/minetest/issues/11545 -- Animated particlespawners by velartrill |
| 19:23 |
ronoaldo |
cool so that one uses the batches right? |
| 19:23 |
MTDiscord |
<luatic> does it? |
| 19:24 |
ronoaldo |
oh I misunderstood it... it was ported to use irrlitch in that patch, it should batch by default there right? |
| 19:24 |
appguru |
no it wasn't ported to use irrlicht in that PR? |
| 19:25 |
ronoaldo |
oh then I'm confused lol |
| 19:25 |
appguru |
afaik this PR does two things: (1) lots of dope features (yay!) and (2) fix blending (and add multiple blending modes) |
| 19:25 |
ronoaldo |
ok |
| 19:26 |
ronoaldo |
Searching for open PRs with particle in them yelds 8 results to me https://github.com/minetest/minetest/pulls?q=is%3Apr+is%3Aopen+particle |
| 19:27 |
erlehmann |
ronoaldo the animated particlespawners is a different thing |
| 19:27 |
erlehmann |
ronoaldo let me search for the irrlicht particle system thing, so you can maybe fix the feature that is missing |
| 19:28 |
erlehmann |
ronoaldo this one https://github.com/minetest/minetest/pull/8461 |
| 19:29 |
erlehmann |
ronoaldo if you can solve this one, you'll bne fixing a HUGE performance problem. enough things generate particles that it's really a problem. you can basically lag other players out. |
| 19:29 |
erlehmann |
ronoaldo the feature that made this PR a no-go is the “vertical” particle thing. |
| 19:30 |
ronoaldo |
ok - i'll examine the PR and try get my hands dirty from there |
| 19:32 |
appguru |
I feel like I should outline how I believe this might work ideally. Basically sending sizes and positions of particles to the shader pipeline should be enough. You'll want to sort these positions by depth first. Emitting the respective quad (two tris) should be done in the geometry shader. Culling should also be done by the rendering pipeline that way (and not on the CPU in particular). |
| 19:32 |
erlehmann |
two important caveats: first, i suggest to try the rebase before you have possible a solution for “vertical”. sfan5 suggested to maybe keep the old code just for particles with that property. second: the minetest build system is borked, you need to rebuild fully every single time to be sure. for details, see #11749 and weep. |
| 19:32 |
ShadowBot |
https://github.com/minetest/minetest/issues/11749 -- CMake does not capture all dependencies, causing erroneous incremental builds & build failures |
| 19:33 |
ronoaldo |
ok, thanks for the info |
| 19:33 |
ronoaldo |
I'll need some time to study this stuff but I'm earger to try it out |
| 19:35 |
erlehmann |
appguru the CPU load from particles is negligible in irrlicht demos. so why are you suggesting this? |
| 19:40 |
rubenwardy |
appguru: that's the best way, but it does require shaders |
| 19:40 |
erlehmann |
ronoaldo another thing that would be cool to research if you are in research mood: irrlicht has a builtin shadows system that may look better than what minetest does currently and has vastly lower hardware requirements. it might be preferable to use that for shadows of antities. according to celeron55 the major hurdle is that no one knows the black magic of how to integrate it into minetest rendering. if you can make this |
| 19:40 |
erlehmann |
thing work, shadows could look nicer and get a huge performance boost. |
| 19:40 |
rubenwardy |
it's possible to use the builtin pipeline by creating a vertex array / buffer |
| 19:41 |
erlehmann |
entities |
| 19:41 |
rubenwardy |
imo shaders should be required for certain things |
| 19:41 |
rubenwardy |
but that's more a philosophy I'd use on my own projects |
| 19:42 |
erlehmann |
rubenwardy, what things? |
| 19:42 |
rubenwardy |
rendering |
| 19:42 |
rubenwardy |
:D |
| 19:42 |
erlehmann |
lol |
| 19:43 |
rubenwardy |
shaders aren't just for fancy effects, they're also used to make rendering faster. For example, with lighting |
| 19:43 |
rubenwardy |
and particles, as appguru said |
| 19:43 |
ronoaldo |
interesting |
| 19:44 |
ronoaldo |
erlehmann: I'll take a look at that from my personal coding reading black magick book :D |
| 19:44 |
erlehmann |
rubenwardy, but particles are not slow because they do not use shaders. particles are slow because the implementation creates a scene node for every particle or so? |
| 19:46 |
erlehmann |
ronoaldo regarding the drawcall thing, if you can figure out how to batch particles of the same type into one draw call, you'd have already fixed the performance issues i guess |
| 19:47 |
erlehmann |
might not do culling though :/ |
| 19:47 |
erlehmann |
well, good luck! |
| 19:48 |
erlehmann |
ronoaldo, wait, i misspoke, i suggest to NOT try the rebase. LOL. first figure out the solution. |
| 19:48 |
erlehmann |
the rebase will be big jar of conflicts |
| 19:58 |
ronoaldo |
I see , unerstood |
| 19:58 |
ronoaldo |
one question: which metric from the debug game screen I'm focusing to turn down? draw calls ? |
| 19:58 |
ronoaldo |
second question: what mods trigger the bug in a somewhat visible way? |
| 19:59 |
ronoaldo |
this gives me some food for testing/checking if I'm on the right path |
| 20:00 |
erlehmann |
ronoaldo use mcl2, make 23×23×23 cube of obsidian, light it up using flint and steel so you have 23 nether portals. |
| 20:00 |
erlehmann |
you can construct a hollow cube like that using worldedit |
| 20:01 |
erlehmann |
the portals should emit enough particles so that your game grinds to a halt |
| 20:01 |
erlehmann |
incidentally, exactly that is also how griefers use it to make an area laggy |
| 20:01 |
erlehmann |
wait, you'll have 21 nether portals |
| 20:01 |
erlehmann |
sorry! |
| 20:02 |
ronoaldo |
cool, that is a nice reproducible step! thanks!!! |
| 20:03 |
erlehmann |
also, if your game does not grind to a halt here, make more of those cubes and use a worse graphics card for developming performance improvements ;) |
| 20:03 |
erlehmann |
and -> or |
| 20:04 |
erlehmann |
but i manage to get down to 1 or 2 fps using the lag cube |
| 20:04 |
ronoaldo |
i have a beefy machine here, so I could also use a VM with Virtual Box to make the bug more visible right? |
| 20:05 |
erlehmann |
unclear. but even on a beefy machine, fps should take a nosedive. |
| 20:05 |
ronoaldo |
got it |
| 20:05 |
erlehmann |
do you have linux? |
| 20:06 |
ronoaldo |
yes, only linux on my self-built machine |
| 20:06 |
erlehmann |
you can start minetest with the environment variable LIBGL_ALWAYS_SOFTWARE=1 |
| 20:06 |
erlehmann |
this turns on mesa software rendering |
| 20:06 |
ronoaldo |
amazing, perfect |
| 20:06 |
erlehmann |
i think this should always be slower than whatever your GPU manages to do |
| 20:06 |
erlehmann |
but it might be *too* slow again ;) |
| 20:16 |
ronoaldo |
is there a bug report (so I can name the branch with that, just a thing of mine) bout this? |
| 20:18 |
erlehmann |
ronoaldo i have no idea |
| 20:25 |
ronoaldo |
np - I'll create another name |
| 20:52 |
sfan5 |
I think ShadowBot needs a function to auto-kick erlehmann everytime he either mentions mcl2 or #11749 |
| 20:52 |
ShadowBot |
https://github.com/minetest/minetest/issues/11749 -- CMake does not capture all dependencies, causing erroneous incremental builds & build failures |
| 20:56 |
|
proller joined #minetest-dev |
| 20:58 |
Calinou |
if you want more playable performance with software rendering, add "undersampling = 4" to minetest.conf |
| 21:04 |
erlehmann |
Calinou why exactly does that increase performance? |
| 21:04 |
Calinou |
it lowers the resolution |
| 21:04 |
Calinou |
HUD remains at native resolution, so it's still easy to read |
| 21:04 |
erlehmann |
let me check this out real quick |
| 21:05 |
ronoaldo |
what is wrong with mcl2 or that particular PR (asking for a friend) |
| 21:15 |
|
Fixer_ joined #minetest-dev |
| 21:28 |
|
v-rob joined #minetest-dev |
| 22:16 |
|
Alias joined #minetest-dev |
| 22:35 |
MTDiscord |
<Hugues Ross> I'll be merging #9588 tomorrow, in the meantime if anyone wants to give it a last-minute look I'd appreciate it. I'm not sure my review this time was up to my usual standard, so any reassurance is welcome. |
| 22:35 |
ShadowBot |
https://github.com/minetest/minetest/issues/9588 -- Add relative numbers for commands by prepending ~ by Wuzzy2 |
| 22:38 |
erlehmann |
Hugues Ross, could the tonumber parsing approach allow ~-NaN and ~Inf or something? if so, would that be a problem? |
| 22:39 |
MTDiscord |
<Hugues Ross> Excellent question, I'll double-check... I'm not entirely worried since iirc we bounds-check these inputs, but it's worth making sure. |
| 22:41 |
MTDiscord |
<Hugues Ross> ...the answer is no it won't allow those, because the characters aren't matched. Just checked with both /teleport and /time, absolute and relative. Both commands treat these inputs as invalid values |
| 22:42 |
MTDiscord |
<Hugues Ross> Thank you for the reminder though, I don't recall if I'd thought to check that earlier in the week or not |
| 22:47 |
erlehmann |
Hugues ross, the thing is that core.parse_relative_number will parse them though, so if some mod uses that function … possible boom! |
| 22:50 |
|
erlehmann joined #minetest-dev |
| 22:54 |
|
erle joined #minetest-dev |
| 23:08 |
MTDiscord |
<Hugues Ross> hm, good point. I'll see if I can whip up a test case or two and compare with similar existing calls. If the boom is consistent across them, it's probably not something to handle here. If it's not, but it happens in parse_relative_number... that is a real issue to fix. |
| 23:08 |
MTDiscord |
<Hugues Ross> Oh, and in the former case I don't mean we shouldn't fix, just that we should fix that separately |
| 23:09 |
erle |
in what case? |
| 23:32 |
|
panwolfram joined #minetest-dev |
| 23:35 |
|
Desour joined #minetest-dev |
| 23:39 |
MTDiscord |
<Hugues Ross> If it parses NaN/inf, but in a way that's consistent with the existing parsing calls |
| 23:42 |
|
proller joined #minetest-dev |
| 23:59 |
|
proller joined #minetest-dev |
