Time  Nick       Message
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: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:12 erlehmann  0,
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?
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: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)
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!
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:39 MTDiscord  <Hugues Ross> If it parses NaN/inf, but in a way that's consistent with the existing parsing calls