| Time |
Nick |
Message |
| 00:35 |
|
Hijiri joined #minetest-dev |
| 01:04 |
|
ANAND joined #minetest-dev |
| 02:04 |
|
Tmanyo joined #minetest-dev |
| 02:27 |
|
paramat joined #minetest-dev |
| 03:51 |
|
Cornelia joined #minetest-dev |
| 07:49 |
|
bigfoot547 joined #minetest-dev |
| 08:00 |
|
Lymkwi joined #minetest-dev |
| 08:35 |
|
Lymkwi joined #minetest-dev |
| 10:04 |
|
Fixer joined #minetest-dev |
| 10:26 |
|
Fixer joined #minetest-dev |
| 10:36 |
|
Ruslan1 joined #minetest-dev |
| 12:57 |
|
Darcidride joined #minetest-dev |
| 13:10 |
|
Darcidride joined #minetest-dev |
| 13:20 |
|
Darcidride joined #minetest-dev |
| 13:37 |
|
Ruslan1 joined #minetest-dev |
| 13:53 |
|
ANAND joined #minetest-dev |
| 13:58 |
|
Fixer joined #minetest-dev |
| 14:49 |
|
Darcidride joined #minetest-dev |
| 14:57 |
|
Fixer joined #minetest-dev |
| 15:08 |
|
hecks joined #minetest-dev |
| 15:15 |
|
Fixer joined #minetest-dev |
| 15:20 |
|
ANAND joined #minetest-dev |
| 15:45 |
|
YuGiOhJCJ joined #minetest-dev |
| 15:47 |
|
calcul0n joined #minetest-dev |
| 16:16 |
|
Fixer joined #minetest-dev |
| 16:25 |
|
Krock joined #minetest-dev |
| 16:30 |
Krock |
merging web#142 in 5 mins |
| 16:30 |
ShadowBot |
https://github.com/minetest/minetest.github.io/issues/142 -- Title section as 'New user?' by paramat |
| 16:38 |
hecks |
regarding my light anchor PR |
| 16:38 |
hecks |
what's the "correct" way of having a different default property for players? |
| 16:42 |
Krock |
merging with 7 minutes delay... |
| 16:44 |
Krock |
Closing #7746 and #7747 in favour of #4501 since they both result in the same request again. Waiting 5 mins for objects |
| 16:44 |
ShadowBot |
https://github.com/minetest/minetest/issues/7746 -- Allow spawning particles in a circle around the player |
| 16:44 |
ShadowBot |
https://github.com/minetest/minetest/issues/7747 -- Allow particle velocities to be correlated with particle positions |
| 16:44 |
ShadowBot |
https://github.com/minetest/minetest/issues/4501 -- More general particle spawners |
| 16:44 |
Krock |
s/objects/objections/ |
| 16:47 |
Krock |
hecks: https://github.com/minetest/minetest/blob/master/src/content_sao.cpp#L865 |
| 16:49 |
|
paramat joined #minetest-dev |
| 16:51 |
hecks |
oh |
| 16:51 |
paramat |
Krock hang on :) |
| 16:51 |
|
Gael-de-Sailly joined #minetest-dev |
| 16:52 |
Krock |
was about to mention that I would begin closing/reopening them |
| 16:52 |
Krock |
do you think we should keep the issues as-is? |
| 16:52 |
paramat |
those issues were opened because i requested specific behaviour issues, hmm |
| 16:53 |
paramat |
not sure |
| 16:53 |
paramat |
i would prefer 4501 to be closed |
| 16:54 |
paramat |
but that depends on other's opinion about the methods suggested in 4501 |
| 16:54 |
paramat |
*opinions |
| 16:54 |
Krock |
well, the two issues just result in the only nice solution - running some kind of shader code on particles |
| 16:54 |
Krock |
where the PR already exists, but wow is it big |
| 16:55 |
paramat |
i'm very -1 for that PR |
| 16:55 |
paramat |
i'll look at the issues over the next hour or so .. |
| 16:59 |
Krock |
okay |
| 17:09 |
paramat |
complex programmable particle spawners should be done using SSCSM anyway, obviously. using existing lua and resulting in complete flexibility |
| 17:10 |
VanessaE |
SSCSM? hah. :P |
| 17:12 |
paramat |
i think these issues should be left open, as they are for specific additional spawner parameters instead script-programmable spawners. different requests |
| 17:16 |
hecks |
the whole point of particle systems is that they are faster than individual objects; some tradeoff between performance and flexibility is needed |
| 17:20 |
hecks |
as for "allow spawning particles in -foo- shape; in addition to basic shapes like box, sphere, cone |
| 17:20 |
hecks |
allow using the lines and vertices of a mesh, that will cover all cases |
| 17:21 |
Cornelia |
Yea.. but that can be heavier than using an equation to calculate positions |
| 17:21 |
Cornelia |
Like with an ellipse or quad |
| 17:21 |
paramat |
i think all 3 issues just have the wrong approach to particles, complexity for very limited results |
| 17:22 |
hecks |
circle and line are the only other primitives I'd consider supporting |
| 17:22 |
hecks |
plane, that's no different and probably no faster than a flattened box |
| 17:23 |
hecks |
other things can be made programmable, but the shape is something the engine needs to handle I'm afraid |
| 17:23 |
hecks |
mostly because there's no way to precompute something like that, as opposed to "x over time" curves which you can do that with |
| 17:24 |
hecks |
so uh, I don't know, "velocity over time" or "velocity over distance" can be lua functions that the system precomputes into a LUT |
| 17:25 |
hecks |
but spawner positions need some presets |
| 17:26 |
sofar |
the problems with shapes is that someone else will want yet a different shape |
| 17:26 |
hecks |
which is why, besides the primitives, there's always a "spline" or "mesh" option |
| 17:26 |
hecks |
understandably slower, but providing the most control |
| 17:27 |
hecks |
note that I can't remember the last time I used a mesh particle spawner in a commercial engine, primitives are usually good enough |
| 17:29 |
hecks |
and that's about all the features a particle system needs; spawner shapes, "y over x" functions, and a particle's render settings |
| 17:51 |
paramat |
sfan5 to clarify you got exactly this kind of fuzziness? https://github.com/minetest/minetest/pull/7651#issuecomment-414044106 |
| 17:52 |
paramat |
i got 'clear but slightly distorted' which i think is fine |
| 17:53 |
paramat |
distortion just caused by change of image size |
| 17:59 |
sfan5 |
paramat: yes |
| 18:01 |
paramat |
ok thanks |
| 18:01 |
paramat |
can we close #7745 ? it's ridiculous |
| 18:01 |
ShadowBot |
https://github.com/minetest/minetest/issues/7745 -- replace lua api with a wasm api |
| 18:04 |
VanessaE |
that gets a :-2: from me. |
| 18:08 |
sofar |
if I was signed into github I'd close it |
| 18:08 |
sofar |
lol |
| 18:11 |
Krock |
Let Me Do That For You (TM) |
| 18:11 |
Krock |
issue solved |
| 18:24 |
paramat |
will merge #2222 in 15 mins, trivial/pre-approved |
| 18:24 |
ShadowBot |
https://github.com/minetest/minetest/issues/2222 -- minetest.get_craft_recipe occasionally returns wrong recipes |
| 18:24 |
paramat |
ugh |
| 18:24 |
paramat |
game#2222 |
| 18:24 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/2222 -- Fence rail only connect to fences. Update map mod README recipe by paramat |
| 18:33 |
Shara |
"seems to be approved" |
| 18:33 |
Shara |
you don't sound very sure of yourself there :P |
| 18:35 |
paramat |
just being careful with my language, my comment is thumbed-up :) |
| 18:35 |
Shara |
That's not the same thing |
| 18:37 |
Shara |
But looks fine anyway |
| 18:38 |
paramat |
hm ok, it *is* approved |
| 18:38 |
Shara |
Well, now it is :D |
| 18:40 |
paramat |
heh, merging |
| 18:41 |
Shara |
paramat: what if anything was still needed for game#2180? |
| 18:41 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/2180 -- Add huckleberry bushes by random-geek |
| 18:42 |
paramat |
merged |
| 18:42 |
paramat |
yeah hmm |
| 18:43 |
paramat |
i need to think on what biomes to put them in |
| 18:43 |
Shara |
I still disagree with your approach for the textures, but certainly not enough to not want it merged |
| 18:46 |
paramat |
actually i'm fine with your suggestion |
| 18:47 |
paramat |
will edit my comment |
| 18:47 |
Shara |
Well, I'd also like to not bother him for more changes after so long a gap in the discussion |
| 18:52 |
paramat |
these bushes bother me a little because they seem rather unnecessary, but i don't have enough reason to object, so won't |
| 18:53 |
VanessaE |
paramat: tell him to PR against plantlife modpack/bushes_classic |
| 18:53 |
VanessaE |
there are several fruit bushes there |
| 18:54 |
VanessaE |
won't have the same spawning pattern, but that ^ is a good place for such a think imho |
| 18:54 |
VanessaE |
thing* |
| 18:56 |
Shara |
I would really like to see these in MTG myself. |
| 18:57 |
Shara |
paramat: I don't really understand your comment on github at all. How will the berries "appear on top of the leaves not in them"? |
| 18:57 |
paramat |
oh, the berry layer can be underneath, duh |
| 18:58 |
Shara |
This is literally the nomberry approach (sorry to those who have no clue what I'm talking about). It's been done. It works fine. |
| 18:58 |
paramat |
it seems they will have to be alongside other bushes, as pine bushes were just added and we have bushes for everywhere now |
| 18:58 |
paramat |
ok |
| 18:59 |
Shara |
There's no issues with a biome having two kinds of bush. MTG needs more interesting things in it :) |
| 19:00 |
hecks |
git push wrong branch, git revert 6e54a8, git cannot do, git please kill me |
| 19:00 |
paramat |
is huckleberry a common food berry? maybe i'm being UK-centric |
| 19:00 |
VanessaE |
lol |
| 19:01 |
VanessaE |
paramat: used to be common in the US to make pies out of, don't hear much about it anymore though |
| 19:02 |
|
Andrey01 joined #minetest-dev |
| 19:03 |
paramat |
hm it's an american name |
| 19:03 |
paramat |
it just seems an odd and uncommon choice for a food berry |
| 19:04 |
paramat |
"In North America the name was applied to numerous plant variations all bearing small berries with colors that may be red, blue or black" it's an unspecific species too |
| 19:04 |
paramat |
i don't like this berry choice |
| 19:05 |
paramat |
but then apple is too i guess |
| 19:05 |
VanessaE |
fwiw, we use elderberries and gooseberries as food too (my mom used to make a great elderberry pie) |
| 19:06 |
VanessaE |
so I don't suppose huckleberry is any more strange than anything else |
| 19:06 |
Shara |
I'm fine with it. |
| 19:10 |
paramat |
yeah, it's ok |
| 19:12 |
sfan5 |
paramat: it could just be called "blueberry" without specificing whether it's the american or european variant |
| 19:12 |
sfan5 |
the european variant are these -> https://en.wikipedia.org/wiki/Vaccinium_myrtillus |
| 19:15 |
|
Xio joined #minetest-dev |
| 19:16 |
VanessaE |
fyi bushes classic already has blueberries |
| 19:17 |
hecks |
anything else missing in pr 7626? |
| 19:17 |
|
Xio joined #minetest-dev |
| 19:19 |
paramat |
yes i'd prefer blueberry |
| 19:19 |
* VanessaE |
growls |
| 19:20 |
|
Xio joined #minetest-dev |
| 19:23 |
|
Xio joined #minetest-dev |
| 19:25 |
paramat |
#7626 |
| 19:25 |
ShadowBot |
https://github.com/minetest/minetest/issues/7626 -- Entity lighting fix by hecktest |
| 19:25 |
VanessaE |
come on, just pick a different name that's already in use by some mod. |
| 19:25 |
VanessaE |
that's NOT already in use( |
| 19:26 |
hecks |
garbleshmoofoomplecricklebloopbloopberry |
| 19:26 |
VanessaE |
haha |
| 19:29 |
paramat |
yes 7626 still has issues, the transform needs to be avoided when not needed, and possibly optional |
| 19:32 |
hecks |
having a separate path to apply it without rotation would be quite messy, but not using the transform if the offset is 0 0 0 is trivial |
| 19:33 |
hecks |
remind me though, if (offset == v3f(0,0,0)) is not a leak in c++ is it |
| 19:36 |
sfan5 |
it's not |
| 19:37 |
paramat |
it's very useful to have a fixed vertical offset of the light anchor, without transforming |
| 19:47 |
hecks |
how bout https://pastebin.com/pwt2dQRU |
| 19:47 |
hecks |
shit, make that offset.z |
| 19:48 |
hecks |
actually, no, this will break with arbitrary rotations |
| 19:49 |
sfan5 |
what's the problem with always applying the transform anyway? |
| 19:49 |
hecks |
so you need another damn property just to control if the offset is local or world space |
| 19:49 |
hecks |
paramat says it's too slow, I say it's almost 2020 and he's complaining about a 3x3 mul in a lighting calculation |
| 19:51 |
hecks |
I don't think even "think about the raspi servers" would have much merit here; minetest could use a "get point relative to entity" api function anyway, and you'd have to compute the matrix for that too |
| 19:51 |
sfan5 |
matrix multiplication is too slow? |
| 19:52 |
hecks |
¯\_(ツ)_/¯ |
| 19:52 |
sfan5 |
i suggest we don't worry about premature optimization at this level |
| 19:53 |
hecks |
and I suggest the same, especially in something this basic, but uhh, something something it adds up I guess? |
| 19:53 |
hecks |
to clarify, I do support not doing boneheaded things to avoid the code from becoming uniformly slow |
| 19:54 |
hecks |
but being stingy with vector math is where I draw the line |
| 19:54 |
hecks |
in a 3D game engine of all things |
| 19:54 |
hecks |
also, most people will expect local offsets like this to work in object space |
| 19:56 |
hecks |
a condition of "if offset is 0, don't transform" eliminates most unnecessary transformations anyway, and I'll add that |
| 19:57 |
|
Fixer joined #minetest-dev |
| 20:00 |
hecks |
paramat: could you give me an example of a global Y offset being a very useful ability? |
| 20:01 |
paramat |
a 3D vector transform is quite a lot of calculation, it needs to be avoided when not needed |
| 20:01 |
paramat |
almost all models won't need the transform, so always using it is very wasteful |
| 20:01 |
sfan5 |
okay how many seconds does this calculation take? |
| 20:02 |
hecks |
any CPU these days will choke more on the special case if()s than on a round of MADs |
| 20:02 |
sofar |
^^ |
| 20:02 |
hecks |
I haven't profiled it but I can give you some instruction counts, hold on |
| 20:02 |
sofar |
numbers talk |
| 20:02 |
paramat |
but anyway, if it's avoided when the vector is 0, 0, 0 that's very welcome |
| 20:03 |
sofar |
don't guess. measure |
| 20:03 |
sfan5 |
hecks: doesn't SSE/AVX have vector math? |
| 20:03 |
hecks |
maybe |
| 20:03 |
sfan5 |
not sure if irrlicht uses those, but gcc can do some magic |
| 20:03 |
sofar |
avx IS vector extensions |
| 20:03 |
sfan5 |
well yes, i was wondering whether it applies in this particular case |
| 20:04 |
sfan5 |
(and it probably does) |
| 20:04 |
sofar |
the v in avx stands for vector :D |
| 20:04 |
hecks |
alright, give me a minute |
| 20:05 |
paramat |
hm well, i must admit i'm not sure if a global y offset is essential. however i'm not convinced transform is needed at all |
| 20:05 |
hecks |
so first of all, this function is only using CMatrix4::rotateVect |
| 20:05 |
hecks |
in other words, a mul3x3 |
| 20:06 |
hecks |
http://irrlicht.sourceforge.net/docu/matrix4_8h_source.html#l01101 |
| 20:06 |
hecks |
the code just does multiplies and adds |
| 20:06 |
paramat |
the exact time doesn't matter, i know it's going to be small and you'll tease me for it :) what matters is avoiding unnecessary calculation |
| 20:07 |
paramat |
i think we need an explained need to do transform at all, i don't see it, but i'm happy to be convinced |
| 20:07 |
hecks |
to which I respond, branching hurts more than arithmetic |
| 20:08 |
hecks |
and it's probably not worth it to avoid anything less complex than a sqrt |
| 20:09 |
hecks |
bloating api and documentation is also a thing one should avoid |
| 20:09 |
paramat |
checking if a vector is (0,0,0) is less intensive than a 3D vector rotation |
| 20:09 |
hecks |
which is why I'm for doing that |
| 20:10 |
hecks |
but not for having a world space option, that's overkill and I can't think of a use for it |
| 20:10 |
paramat |
anyway, i'm ok with skipping transform on the condition of the vector being (0,0,0), to be clear |
| 20:10 |
hecks |
while I can think of thousands of cases where it might not behave as the modder expects |
| 20:11 |
paramat |
see the end of smalljoker's comment here https://github.com/minetest/minetest/pull/7626#issuecomment-417095741 i'm ok with that |
| 20:11 |
paramat |
"Skip the transform part when light_anchor has a zero length" |
| 20:12 |
sfan5 |
a length calculation might be more wasteful than (v.x == 0 && v.y == 0 && v.z == 0) |
| 20:12 |
hecks |
that is correct |
| 20:12 |
paramat |
agreed |
| 20:12 |
hecks |
I'm just ==ing it with v3f(0,0,0) |
| 20:13 |
paramat |
but, please convince me in the thread a transform is needed at all. i can't see why, since any pitching rolling model needs to rotate around it's centre of mass, whichis naturally also the optimum position for the light anchor |
| 20:14 |
hecks |
a floor-origin model can board a rotating vehicle |
| 20:15 |
hecks |
attachments in general are a candidate for "odd offset with 6DOF" |
| 20:16 |
hecks |
an Y-rotating model might need to have its anchor a little forward or backwards, depending on how the model is used |
| 20:17 |
hecks |
the anchor is something you set when the lighting breaks, and having it transform is more bulletproof than only applying an Y offset |
| 20:17 |
hecks |
while having both of these at once is ridiculous |
| 20:18 |
paramat |
hm ok best i stay neutral on the need then :) |
| 20:18 |
paramat |
thanks |
| 20:18 |
hecks |
at least you didn't suggest sincosing XZ while applying Y affinely |
| 20:18 |
hecks |
I think I'd blow a fuse |
| 21:02 |
paramat |
anyone like #7019 ? i support the concept but not good with this type of code. only needs 1 more +1 |
| 21:02 |
ShadowBot |
https://github.com/minetest/minetest/issues/7019 -- Colorize command parameters and privilege names by Wuzzy2 |
| 21:08 |
hecks |
git commit -am "have mercy" |
| 21:25 |
paramat |
:) |
| 21:27 |
hecks |
free software has worse bureaucracy than actual communism |
| 22:13 |
Hijiri |
It depends on the project |
| 22:15 |
Hijiri |
obvious case is a project with one primary active developer and they can just sling code to match their personal vision of the project |
| 22:16 |
Hijiri |
also it helps if a project is more active, like terasology |
| 22:16 |
Hijiri |
I haven't played terasology so I can't say anything about the quality of their actual project |
| 22:16 |
Hijiri |
but it looks like they are getting things done, at least by the number of google summer of code projects they had this year |
| 22:17 |
Hijiri |
Notably though they didn't finish implementing dimensions, so maybe that suggests it would be a difficult feature to add, if terasology is similar to MT |
| 23:19 |
|
paramat joined #minetest-dev |
