| Time |
Nick |
Message |
| 00:19 |
|
imi joined #minetest-dev |
| 00:46 |
|
proller joined #minetest-dev |
| 01:41 |
|
proller__ joined #minetest-dev |
| 01:54 |
|
ShadowBot joined #minetest-dev |
| 02:20 |
|
SFENCE joined #minetest-dev |
| 02:47 |
|
YuGiOhJCJ joined #minetest-dev |
| 02:53 |
|
YuGiOhJCJ joined #minetest-dev |
| 03:50 |
|
SFENCE joined #minetest-dev |
| 04:36 |
|
SFENCE joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 09:22 |
|
Warr1024 joined #minetest-dev |
| 09:47 |
|
Warr1024 joined #minetest-dev |
| 10:00 |
|
cx384 joined #minetest-dev |
| 10:11 |
|
SFENCE joined #minetest-dev |
| 10:13 |
|
proller joined #minetest-dev |
| 10:46 |
|
calculon joined #minetest-dev |
| 10:53 |
|
appguru joined #minetest-dev |
| 11:05 |
|
SFENCE joined #minetest-dev |
| 11:30 |
|
SFENCE joined #minetest-dev |
| 11:46 |
|
SFENCE joined #minetest-dev |
| 12:03 |
|
SFENCE joined #minetest-dev |
| 12:31 |
|
SFENCE joined #minetest-dev |
| 12:47 |
|
SFENCE joined #minetest-dev |
| 13:05 |
|
SFENCE joined #minetest-dev |
| 13:07 |
|
SFENCE joined #minetest-dev |
| 13:16 |
|
MisterE123 joined #minetest-dev |
| 13:16 |
|
wsor4035 joined #minetest-dev |
| 13:16 |
|
thelounge656 joined #minetest-dev |
| 13:41 |
|
Lupercus joined #minetest-dev |
| 13:46 |
|
SFENCE joined #minetest-dev |
| 14:35 |
Krock |
Reminder: Meeting in 25 minutes - https://dev.minetest.net/Meetings#2024-03-03 |
| 14:36 |
Krock |
feel free to have a look at the "One Approval" PRs to go through them this time |
| 14:42 |
Krock |
will merge #14401 and #14384 in 10 minutes |
| 14:42 |
ShadowBot |
https://github.com/minetest/minetest/issues/14401 -- [no squash] Split up tile.cpp/tile.h and just a little refactoring by cx384 |
| 14:42 |
ShadowBot |
https://github.com/minetest/minetest/issues/14384 -- Implement get_node with a get_node_raw by Desour |
| 14:53 |
Krock |
done |
| 14:59 |
Krock |
ping @Zughy appguru @Desour sfan5 myself |
| 15:01 |
MTDiscord |
<luatic> hi |
| 15:01 |
appguru |
oh wait i might as well use my open thunderbird |
| 15:01 |
Krock |
hello there! waiting a few minutes for the others to get active |
| 15:04 |
rubenwardy |
I'm here |
| 15:06 |
Krock |
hello here |
| 15:06 |
Krock |
is @grorp online? |
| 15:06 |
Krock |
because the first topic would be #13020 |
| 15:06 |
ShadowBot |
https://github.com/minetest/minetest/issues/13020 -- 3d line rendering. by Andrey2470T |
| 15:07 |
Krock |
> thoughts on grorp's primitive suggestion |
| 15:08 |
|
Desour joined #minetest-dev |
| 15:09 |
MTDiscord |
<luatic> Discord does not show grorp as online, though perhaps he has just his status to invisible. @andrey2470t is online, though. |
| 15:10 |
Desour |
(I'm here now, hi) |
| 15:11 |
Krock |
I'd definitely support the "type" key to be more future-proof. To be honest I ignored that PR for a while because I didn't see much use for it |
| 15:12 |
Krock |
maybe it would be easiest to first implement a few primitives and the keep the rest for future PRs |
| 15:12 |
Krock |
opinions on grorp's comment? |
| 15:13 |
Krock |
-> https://github.com/minetest/minetest/pull/13020#issuecomment-1944150506 |
| 15:13 |
appguru |
I agree with grorp largely. I'm not exactly sold on a server-controlled primitive API, though. |
| 15:14 |
Desour |
a primitive / 3d draw scene node API would best fit into sscsm. I thought the PR is rather about a more high-level hardcoded API, to connect objects with lines witch good prediction |
| 15:14 |
appguru |
Very long-term I hope that we can extend (SS)CSM to have proper clientside rendering APIs. We *might* want to compromise short or medium-term. |
| 15:14 |
MTDiscord |
<herowl> Desour: agreed |
| 15:16 |
appguru |
An alternative compromise I briefly considered for "connecting objects" would be a bone override API which lets you attach bones to objects or bones of other objects. Basically set_attach but for bones. |
| 15:16 |
appguru |
That way you could at least get the "connecting two points with limited jank" with a relatively cheap compromise; it would of course be much more limited than what this PR suggests. |
| 15:17 |
|
ivanbu joined #minetest-dev |
| 15:17 |
MTDiscord |
<herowl> Long-term I would personally feel MTE would need a C++ dll API so that people could use and package MTE with whatever games, also commercial ones, like a proper engine. |
| 15:18 |
appguru |
To look presentable, it would also need more texturing options (namely world-space repeating textures for entities - unless you want solid color lines, you don't want your rope texture to stretch) |
| 15:18 |
MTDiscord |
<herowl> Wouldn't you need some form of IK to connect bones like that though? |
| 15:18 |
Krock |
appguru: but could bones be stretched? |
| 15:19 |
MTDiscord |
<herowl> Well, from what I know about bones, they work as a tree, and go have two attachment points, you need IK. Unless I'm missing something...? |
| 15:19 |
Krock |
repeating textures already exist for nodes, so it's definitely worth considering to port to entities as well in the future |
| 15:20 |
Krock |
what does IK stand for? |
| 15:20 |
MTDiscord |
<herowl> Inverse kinematics |
| 15:20 |
appguru |
Krock: you would have two bones, attached to two different entities / points, with the vertex weights based on the distance to the bone position along the line, rather than a single bone (but yes bones also support scaling). |
| 15:22 |
Krock |
I see. bone attachments would have a much broader use-case than just using the objectRef base position + some hack offset |
| 15:23 |
appguru |
BTW, there is in fact currently a not too shabby hack: You can get a line-like visual by taking an entity with cube visual and stretching, rotating, and repeating the texture via texmods as appropriate. This is okay-ish for static lines, but of course janky for dynamic lines (like a leash). |
| 15:24 |
Krock |
right |
| 15:25 |
MTDiscord |
<herowl> You can just have a custom mesh as well, or use particles, and some other way I think |
| 15:25 |
MTDiscord |
<herowl> But yeah, jank |
| 15:28 |
Krock |
I'll just state general agreement to grorp's comment. If there's ideas to make the PR more helpful, I'd say to leave a comment there? |
| 15:30 |
appguru |
Personally, the 3d line PR is not a review priority for me, and I think Andrey has deprioritized it as well; I discussed it with him briefly on Discord. Let me make you a copy of the relevant chat history real quick. |
| 15:30 |
MTDiscord |
<herowl> Andrey said he lost interest tbh. |
| 15:30 |
MTDiscord |
<herowl> (in that PR) |
| 15:32 |
Krock |
I do not see any such comment in the PR itself, so if that's the case I'd be grateful if he could clarify whether it needs adoption or not |
| 15:32 |
MTDiscord |
<andrey2470t> Actually yes, I am more interested in other PRs now like Camera API, dual wielding and ambient light. The last one is the most possible feature to be finished and merged, so I will accent on that |
| 15:33 |
Krock |
but the 3d line PR is yet not abandoned, right? |
| 15:35 |
sfan5 |
oh hey |
| 15:36 |
Krock |
hello! |
| 15:37 |
appguru |
hi |
| 15:38 |
MTDiscord |
<andrey2470t> No, but I am stuck into how it should be implemented in the most correct way to be honest. More general API would be better, but up to which degree should it be generalised? Just drawing any primitives like triangles, points, lines or although more types of primitives for objects behaving as lines? |
| 15:38 |
appguru |
here's the relevant #engine discussion: https://gist.github.com/appgurueu/e4962b622f0350a3cc90ab1192027c50 |
| 15:39 |
Krock |
there's always multiple ways to do it. going too much into detail (e.g. vertex/index arrays etc) would be too inefficient |
| 15:40 |
Krock |
thus a connecting line between points (what the PR currently implements) seems to be a good approach. |
| 15:40 |
MTDiscord |
<herowl> Tbh the primitives talked about would be I think line (of a few kinds), cube and icosphere. |
| 15:41 |
MTDiscord |
<herowl> Maybe arbitrary planes too |
| 15:41 |
MTDiscord |
<herowl> Cube defined as AABB and sphere by center and radius |
| 15:42 |
|
grorp joined #minetest-dev |
| 15:43 |
appguru |
hi grorp |
| 15:43 |
[MTMatrix] |
<Zughy> It seems like we should offer a design we agree upon or that PR will remain stuck until it gets closed |
| 15:43 |
Krock |
the four so called "visual types" are IMO the right amount to start with |
| 15:43 |
MTDiscord |
<herowl> Another question is whether to attach the primitives to objects as-is or have option to attach to bones |
| 15:43 |
[MTMatrix] |
<Zughy> (hi) |
| 15:43 |
grorp |
hi, I'm now lurking |
| 15:43 |
MTDiscord |
<andrey2470t> I think this could support setting arbitrary meshes for lines also except of certain primitives |
| 15:43 |
Krock |
@herowl: that's an idea for a later PR to make it more useful. having empty bone names for now might already suffice |
| 15:44 |
MTDiscord |
<herowl> That's my feeling too |
| 15:44 |
appguru |
well, you can always attach an entity to a bone, then attach to that entity as a workaround |
| 15:44 |
MTDiscord |
<herowl> +1 |
| 15:45 |
Krock |
I'd have to do a full code review but as of now it appears that the priorities just aren't high enough |
| 15:45 |
|
SFENCE joined #minetest-dev |
| 15:45 |
MTDiscord |
<andrey2470t> Which difference would be between attaching a line to objects and bones? I've not ever used bones for entities, so I have a bad representation about that |
| 15:45 |
Krock |
however, concept-wise I think it would be a good addition to have. SSCSM are still far away |
| 15:46 |
MTDiscord |
<herowl> Well, maybe name the function "add primitive" though like grorp suggested to prepare for adding more stuff |
| 15:46 |
Krock |
@andrey2470t bones are specific points, such as the player's head. it's what the model uses to render |
| 15:46 |
MTDiscord |
<herowl> Well, you could attach it to a monster mouth or player/mob hand and have it respect animations properly |
| 15:46 |
Krock |
s/render/put the vertices to the place they should be/ |
| 15:47 |
appguru |
andrey2470t: like set_attach, basically. bones are useful when you have animations and want to keep in sync with that. for example players have bones for their arms (which you can use to place items in their hand). think of a dog leash which you want to be attached to the hand of the player without jank. |
| 15:47 |
appguru |
but, as i said, this is not strictly necessary, because as a slightly inefficient but otherwise okay workaround, you can attach an invisible entity to a bone, then attach the line to the invisible entity. |
| 15:48 |
Desour |
bones are not only points. they represent a transformation (i.e. pos, rot, scale) relative to the object. and some vertices of the mesh are bound to it, which makes them be transformed accordingly |
| 15:48 |
MTDiscord |
<herowl> In this case it is just bone position though |
| 15:48 |
MTDiscord |
<jordan4ibanez> And weights |
| 15:48 |
MTDiscord |
<jordan4ibanez> Source: Been trying to find weights again |
| 15:49 |
appguru |
While most people try to lose weight, jordan tries to find it. |
| 15:49 |
MTDiscord |
<jordan4ibanez> At this point I'm about to just go to my gym and call it a day |
| 15:49 |
Desour |
if you can attach a bone of an object to a bone of another object, or to a fixed world pos, that would probably be useful |
| 15:49 |
MTDiscord |
<herowl> But isn't that IK? |
| 15:49 |
MTDiscord |
<herowl> So would be out of scope. |
| 15:50 |
appguru |
herowl: I don't think overriding single bones is IK, or particularly hard to do |
| 15:51 |
appguru |
from wiki: "inverse kinematics is the mathematical process of calculating the variable joint parameters needed to place the end of a kinematic chain [...] in a given position and orientation relative to the start of the chain" |
| 15:51 |
MTDiscord |
<herowl> But if you attach an existing bone to a specific position, and the object is moving...? |
| 15:51 |
MTDiscord |
<andrey2470t> Ah, it works very like as in blender. Attaching some part of mesh to some bone and doing the bone as transformation pivot point |
| 15:52 |
MTDiscord |
<herowl> It is the same thing, not "like" |
| 15:52 |
MTDiscord |
<herowl> We may be missing some features that Blender has, but that's ig |
| 15:52 |
appguru |
herowl: then you might want IK - instead of overriding - for it to look okay |
| 15:53 |
MTDiscord |
<herowl> And what is the thing you were suggesting exactly? Because I feel like I am missing something. |
| 15:53 |
Desour |
@herowl: in IK you'd also move the other bones (in the kinematic chain) so that they fulfill certain constraints (e.g. the arm sticks to the body), no? |
| 15:53 |
MTDiscord |
<herowl> Yes |
| 15:54 |
appguru |
the thing i was suggesting is restricted to a single bone |
| 15:54 |
MTDiscord |
<herowl> So basically orient the bone towards whatever? |
| 15:54 |
appguru |
you fix the (absolute) position of a single bone at a certain world pos, for example, not affecting any other bones |
| 15:54 |
MTDiscord |
<herowl> So that the bone tracks another object, for example? |
| 15:55 |
appguru |
yes |
| 15:55 |
MTDiscord |
<herowl> But not ripping it, just pointing? |
| 15:56 |
appguru |
(you will have to compute the local TRS properties from the wanted global properties by applying the inverse parent transform, but that is pretty doable) |
| 15:56 |
appguru |
herowl: wdym by ripping vs pointing |
| 15:56 |
MTDiscord |
<herowl> Moving the bone to the position vs rotating it towards it. |
| 15:56 |
Krock |
might be already be too deep in this topic? wouldn't attaching to bones already suffice, without any physical impact on the player model? |
| 15:56 |
MTDiscord |
<andrey2470t> Hmm, in the case of the dog leash what appguru mentioned, it can be implemented without bones. Very similar thing I alteady did with the fishing rod. I just set the position offset for the closest rod point and the relative offset is always constant, only the parent's position is changed |
| 15:57 |
Krock |
s/ be / we / |
| 15:57 |
appguru |
herowl: both are doable, i primarily considered positions |
| 15:58 |
appguru |
Krock: let's try to wrap this topic up then to continue with the meeting? |
| 15:58 |
MTDiscord |
<herowl> Krock: I think we don't need any messing with bones for this PR tbh. |
| 15:59 |
appguru |
yes, we were discussing my tangential, slightly alternative suggestion |
| 15:59 |
Krock |
alright then. noted down a quick summary in the meeting points (will save at the end) |
| 15:59 |
Krock |
on to the next: https://github.com/minetest/minetest/pulls?q=is%3Apr+is%3Aopen+label%3A%22One+approval+%E2%9C%85+%E2%97%BB%EF%B8%8F%22 |
| 16:00 |
Krock |
one approval PR's. |
| 16:00 |
Krock |
#11391 |
| 16:00 |
ShadowBot |
https://github.com/minetest/minetest/issues/11391 -- Add support for static boxes in 'leveled' type; add node box types 'leveled_plantlike[_rooted]' by Wuzzy2 |
| 16:00 |
sfan5 |
sounds useful at first glance |
| 16:00 |
sfan5 |
does anyone want to review it? |
| 16:01 |
appguru |
i have a pending review on that, i will finish my review |
| 16:01 |
Krock |
thanks |
| 16:02 |
Krock |
skipping the 3d line rendering PR (already discussed, low priority) |
| 16:02 |
Krock |
#14225 |
| 16:02 |
ShadowBot |
https://github.com/minetest/minetest/issues/14225 -- Add bulk_get_node function by sfence |
| 16:02 |
Krock |
before our meeting I merged DS' optimizations. this PR was however initially not meant to perform well |
| 16:02 |
MTDiscord |
<luatic> Performance-wise, this has been obsoleted by Desour's PR as far as I understand. |
| 16:02 |
Krock |
but rather to be easier to use |
| 16:03 |
sfan5 |
yeah sounds like that should be closed after all |
| 16:03 |
MTDiscord |
<andrey2470t> Ok, so the topic of my PR has finished. Can we discuss about Camera API today also? There are a few questions relating to workarounds due to the static nature of the nodes. |
| 16:03 |
Krock |
@andrey2470t I'll add it after the one approval PRs, if we don't get to it we can discuss it in the next meeting |
| 16:04 |
Krock |
about bulk_get_node: I'd also vote for a close because I don't quite see the need for such specific functions |
| 16:04 |
grorp |
I don't see how it's easier to use tbh |
| 16:04 |
MTDiscord |
<luatic> I think the convenience afforded by bulk_get_node is very limited |
| 16:04 |
Desour |
I'd say let sfence answer first, maybe they still see a reason for the bulk get node, or come up with a faster version |
| 16:05 |
Krock |
(+1'd on rubenwardy's comment) |
| 16:05 |
appguru |
I agree with Desour |
| 16:05 |
Krock |
okay. will await arguments. |
| 16:06 |
Krock |
next: #14243 |
| 16:06 |
ShadowBot |
https://github.com/minetest/minetest/issues/14243 -- Update docs to allow non-liquid nodes to use "liquid" drawtype by ryvnf |
| 16:06 |
Desour |
pure doc change |
| 16:06 |
Krock |
so the background of this change is rather strange |
| 16:06 |
sfan5 |
I'm neutral on that one |
| 16:07 |
appguru |
esp. considering Wuzzy's comments, I think this is just an oversight from the drawtype - liquidtype decoupling left to be addressed in the docs, hence my approval |
| 16:10 |
Krock |
okay. I'll leave a review and see what happens |
| 16:10 |
Krock |
#14319 |
| 16:10 |
ShadowBot |
https://github.com/minetest/minetest/issues/14319 -- Fix object:punch(puncher, ... should allow nil for puncher by sfence |
| 16:10 |
Krock |
I'd like to know why we need "nil" punchers in the first place.. ? |
| 16:11 |
Krock |
I'd somewhat expect an ObjectRef to be provided to callbacks |
| 16:11 |
appguru |
for the same reason some other callbacks allow nil actors, i assume: to let mods invoke them without having to come up with an actor |
| 16:11 |
Krock |
would it require a fake ObjectRef for automation mods? |
| 16:13 |
Krock |
just checked. core.node_dig may also handle nil players |
| 16:14 |
appguru |
a (hopefully rather limited) risk i would like to point out: despite our documentation saying it may be, i wouldn't be surprised if some mods have grown to rely on puncher not being nil |
| 16:15 |
Krock |
3d_armor/3d_armor/init.lua |
| 16:15 |
Krock |
hitter is expected to be an ObjectRef |
| 16:16 |
Desour |
`on_punch` says: "`puncher`: an `ObjectRef` (can be `nil`)" |
| 16:16 |
sfan5 |
acceptable risk, the docs say differently at least |
| 16:16 |
Desour |
but register_on_punchplayer only allows players as hitters |
| 16:16 |
Krock |
register_on_punchplayer doesn't state that yet |
| 16:17 |
appguru |
Desour: I don't think register_on_punchplayer only allows players as hitters. IIRC it allows any object as hitter (but of course only players as victims). |
| 16:17 |
Desour |
kinda inconsistent with on_rightclick where the clicker is not nil, according to doc |
| 16:18 |
Desour |
appguru: that's what the docs say though: "`hitter`: ObjectRef - Player that hit" |
| 16:18 |
appguru |
I wouldn't be surprised if the docs are outdated. Let me check though. |
| 16:20 |
Krock |
who is in favour of this PR, who's against? |
| 16:21 |
appguru |
Desour: PlayerSAO::punch always calls on punchplayer. This is consistent with what I remember. The docs are wrong. |
| 16:21 |
MTDiscord |
<herowl> I personally think that puncher and digger and whatever should be able to be nil. |
| 16:21 |
Krock |
or let's do it differently - await answers of possible use-cases and then proceed on what to do with the other callbacks |
| 16:22 |
MTDiscord |
<herowl> All callbacks should be usable by mods abstractly with any possible side effects. Let me dig up an issue real quick. |
| 16:23 |
Krock |
by the way, @herowl, are you known under another name on GitHub? I cannot recall yours |
| 16:24 |
Krock |
mainly to properly target requests and questions |
| 16:26 |
Krock |
PR reply updated with key points from this discussion |
| 16:27 |
Krock |
next PR: #14347 |
| 16:27 |
ShadowBot |
https://github.com/minetest/minetest/issues/14347 -- Item meta pointing range by cx384 |
| 16:28 |
MTDiscord |
<herowl> #13563 |
| 16:28 |
ShadowBot |
https://github.com/minetest/minetest/issues/13563 -- minetest.dig_node in protected areas will not work (even if you own the area) |
| 16:28 |
MTDiscord |
<herowl> So yeah, it was about protections too. |
| 16:29 |
MTDiscord |
<herowl> nauta-turbidus |
| 16:29 |
MTDiscord |
<herowl> No PRs yet. |
| 16:29 |
Krock |
it seems that's a flaw in core.dig_node |
| 16:29 |
MTDiscord |
<herowl> Well, there are a few things like this. |
| 16:29 |
appguru |
indeed |
| 16:30 |
sfan5 |
14347 seems useful, I will review it |
| 16:30 |
appguru |
thanks |
| 16:30 |
Krock |
sfan5: I agree. it's pretty simple |
| 16:31 |
Krock |
it might trip anticheat though, if newer mods are used on older servers |
| 16:31 |
Krock |
due to f32 getToolRange |
| 16:31 |
Desour |
that's the server owner's fault then |
| 16:32 |
sfan5 |
we want our users to upgrade anyway :) |
| 16:32 |
sfan5 |
could also gate it with a protocol check on the client |
| 16:32 |
Krock |
the error message is not obvious, though. |
| 16:32 |
Desour |
I might also review it if sfan doesn't do before |
| 16:33 |
Krock |
it reports players as cheaters without giving an indicator as for why that happens |
| 16:33 |
Krock |
but I agree that's a server owner problem |
| 16:34 |
Krock |
#14369 |
| 16:34 |
ShadowBot |
https://github.com/minetest/minetest/issues/14369 -- Try to preserve metatable when exchanging data with the async env by y5nw |
| 16:35 |
appguru |
Krock: good catch, sfan5: protocol check sounds like a safe, low effort solution |
| 16:35 |
Krock |
this is only for metatables? |
| 16:35 |
appguru |
yes |
| 16:36 |
appguru |
I took a look, I think I can review it, though I'll have to familiarize myself a bit with sfan's stack-based packer bytecode ;) |
| 16:37 |
Krock |
I don't yet understand why exactly this is needed |
| 16:37 |
appguru |
Krock: when you pass a vector to an async env, the metatable is lost. this is inconvenient. |
| 16:38 |
appguru |
it is not strictly needed, but if we don't have it, we force modders to restore metatables themselves, which is ugly and frustrating. |
| 16:38 |
Krock |
right, but wouldn't it be more efficient to construct the vector "object" again in the async env - assuming it already has vector.lua included? |
| 16:38 |
appguru |
not preserving our own metatables - which we know by name - was considered a bug. this PR also adds a feature to let modders make their own metatables known "by name" to the engine. |
| 16:39 |
Desour |
if performance matters, btw.. please bear in mind that internalizing strings to lua is quite expensive. e.g. get_known_lua_metatables could be called less often. and the metatable table could perhaps be indexed by integers |
| 16:39 |
appguru |
Krock: efficient in what sense? |
| 16:40 |
Krock |
appguru: serialize/deserialize speed vs new metatable construction within the async env |
| 16:40 |
sfan5 |
Krock: when the serialization happens you already have {x=1,y=2,z=3}, just setting the right metatable on it is more efficient than passing it vector.new |
| 16:40 |
ywang |
Desour: I could change the code to use integer indices instead of strings |
| 16:40 |
sfan5 |
it also requires the packer to have specific knowledge of vectors |
| 16:40 |
Krock |
I assume such metatable is only serialized once? |
| 16:41 |
Krock |
since it's the same for all vectors...? |
| 16:41 |
sfan5 |
to be clear: this isn't about serializing the metatable, it's about transporting the information which metatable it was |
| 16:41 |
appguru |
Krock: the metatable is not serialized |
| 16:41 |
ywang |
The metatable is not serialized at all. It is registered separately in the main and async environments |
| 16:41 |
Krock |
ooh |
| 16:41 |
Krock |
I see. that's a much more elegant implementation. Thanks for clarifying |
| 16:41 |
Krock |
after all - 100 LoC is somewhat reasonable for that |
| 16:42 |
appguru |
anyways yeah, Desour is right, integer indices are a good idea performance-wise, esp. considering they wouldn't complicate the code much |
| 16:43 |
appguru |
though names are certainly more user-friendly |
| 16:43 |
Desour |
ywang: if it can be changed to integer indices later, it's fine with strings for now imo. |
| 16:43 |
ywang |
I would assume it is possible to have an API-facing string<->mt mapping and an internal integer<->mt mapping |
| 16:44 |
Krock |
tables would allow string and integer mappings but I don't know whether that's faster |
| 16:44 |
|
cx384 joined #minetest-dev |
| 16:44 |
Desour |
transferring common strings could also be optimized, by doing something like an atomics table: convert the string to a number in lua when sending, and the number back to string in lua when receiving |
| 16:44 |
appguru |
yeah |
| 16:44 |
appguru |
but i think we shouldn't complicate this PR too much for now |
| 16:45 |
appguru |
and we don't want to burden users with picking numbers for metatables |
| 16:45 |
Desour |
+1 |
| 16:46 |
Krock |
moving on. #14406 |
| 16:46 |
ShadowBot |
https://github.com/minetest/minetest/issues/14406 -- [no squash] Fix node callbacks unit test by sfan5 |
| 16:46 |
appguru |
assuming sfan5's implicit approval, that basically has two approvals, doesn't it? |
| 16:46 |
Krock |
this is rather new and simple |
| 16:46 |
sfan5 |
it does, you can skip this |
| 16:46 |
Krock |
right. can be merged as-is. |
| 16:47 |
Krock |
end of one approval PRs |
| 16:47 |
Krock |
andrey2470t would like to discuss #14325 |
| 16:47 |
ShadowBot |
https://github.com/minetest/minetest/issues/14325 -- Camera API (revival) by Andrey2470T |
| 16:47 |
Krock |
> There are a few questions relating to workarounds due to the static nature of the nodes. |
| 16:48 |
MTDiscord |
<luatic> @andrey2470t |
| 16:48 |
Krock |
what exactly would you like to clarity? |
| 16:49 |
MTDiscord |
<andrey2470t> There are questions which I asked on #engine "Question relating to my Camera API pr: should the nodes tile definitions support RTTs at all? I don't feel it would bring a large benefit comparing to the entity render targets textures which are dynamic. The single thing which the nodes textures can support is rendering onto themselves a space only from the only camera, it already means it is impossible e.g. to create mirrors using |
| 16:49 |
MTDiscord |
them. It is necessary to do directly via entities adding them as render surfaces. Another downside is after forced reloading of nodes RTTs textures when a new camera is created or just a texture is set for it that needs adding mesh update tasks for all mapblocks using those textures" |
| 16:50 |
MTDiscord |
<andrey2470t> "(2) There is an other thing requiring clarification: RTTs can't be combined with simple textures like those generated from texture modifiers since they use per-pixel updating. RTTs are always continuously changeable, but texture modifiers are not in the most cases. So it requires a cyclic re-combining simple textures with RTTs through Irrlicht's IImage::set/get_pixel() is what very expensive op. Also one can consider more heavy |
| 16:50 |
MTDiscord |
situation is combining simple texture + RTT + simple_texture + RTT, i.e. combination of infinite count of textures. The solution to that I found is to oblige modders to set RTTs only in textures field and some new overlay_textures with simple textures overlaid on those. A couple of the corresponding textures could be sent to the shader as two uniforms then" |
| 16:51 |
Krock |
what does "RTT" mean in this context? |
| 16:51 |
appguru |
render to texture |
| 16:51 |
Krock |
thanks |
| 16:51 |
MTDiscord |
<andrey2470t> RTT is render target texture |
| 16:53 |
appguru |
I'm presently not invested in the camera API PR, but my opinion is that (1) nodes need not, probably should not, support RTT in a first PR for simplicity; (2) for highly dynamic stuff we usually use entities; (3) if we did really want RTT on nodes, we could consider metadata for that, but I'm not a big fan; (4) nodes complicate matters due to being batched in mapblocks |
| 16:53 |
sfan5 |
note that swapping a texture does not require a mesh update |
| 16:54 |
appguru |
yes |
| 16:54 |
Krock |
the first version of the PR was canvas-like so that's already a good target |
| 16:55 |
Krock |
what would the use-case of rendering to node textures be? |
| 16:55 |
appguru |
btw, i think camera stuff is also generally very clientside in nature, but we probably don't want to wait on SSCSM for this one either |
| 16:57 |
MTDiscord |
<andrey2470t> In the PR I reload certain textures for each tile def having rtt = true flag set through `getTextureForMesh()", but as I found out this doesn't change anything. And adding instant reloading of meshes resolved that problem |
| 16:59 |
MTDiscord |
<andrey2470t> Yes, I think it can be changed later if it is made |
| 16:59 |
appguru |
it is definitely possible to change materials - and hence textures - without reloading/updating meshes (see for example sfence's liquid - glass bugfix PR). |
| 17:00 |
appguru |
btw, do we have any idea of which / how many users rely on shaders disabled? |
| 17:00 |
MTDiscord |
<andrey2470t> Just I know the crack levels of nodes are changed via this mechanism and it does the same thing, however it reloads the only mapblock mesh |
| 17:01 |
appguru |
cracks are different. they're probably not implemented optimally if they reload meshes, though i haven't checked. but the performance impact is limited because at most a single mapblock mesh is concerned. |
| 17:01 |
Krock |
This PR does currently not have priority for me, thus I can only say that I agree to appguru's input (1) above to simplify the PR, hence lowering the bar. |
| 17:02 |
Krock |
I'll be away for a moment and update the wiki to what I currently have. |
| 17:02 |
Desour |
appguru: IIRC, there was consensus that disabled shaders support can be dropped whenever necessary |
| 17:02 |
appguru |
interesting |
| 17:02 |
MTDiscord |
<andrey2470t> How about my second question? This requires usage of new field for entities |
| 17:03 |
appguru |
about overlay textures for entities? |
| 17:03 |
MTDiscord |
<andrey2470t> Yes |
| 17:03 |
appguru |
can't modders achieve a pretty good approximation by just overlaying another surface with a small distance? |
| 17:03 |
MTDiscord |
<andrey2470t> Overlay rtts with simple textures and their various combinations |
| 17:06 |
appguru |
various combinations? |
| 17:06 |
MTDiscord |
<andrey2470t> Sounds hacky too for me. But is embedding a new field of overlay textures not a better solution? |
| 17:07 |
appguru |
it is a bit hacky, but what are the problems with this hack? |
| 17:08 |
MTDiscord |
<andrey2470t> So, the modders should be warned about the limitation according to which textures would accept only rtts or only simple ones, overlay_textures would do only simple |
| 17:08 |
MTDiscord |
<andrey2470t> And those textures would two by two be sent to shaders to be combined |
| 17:09 |
MTDiscord |
<andrey2470t> However, a problem can occur if the object shader is disabled... |
| 17:10 |
MTDiscord |
<andrey2470t> It needs in adding a duplicated mesh whereas my doesn't do it |
| 17:13 |
MTDiscord |
<andrey2470t> And the limitation for that is not critical. It is very low unlikely it would require to combine textures in another sequence |
| 17:14 |
appguru |
not only unlikely: since camera textures are opaque, there is no point in overlaying them over another texture. you can directly set the texture then instead. |
| 17:14 |
MTDiscord |
<andrey2470t> Usually rtt goes first and then atop that some another texture. E.g. I make a camera display from some point, I add rtt and then e.g. texture with date/time info on this |
| 17:15 |
appguru |
more than usually - always, if the modder is sane, because RTT textures are opaque, is what I'm saying :P |
| 17:15 |
appguru |
the RTT textures coming from cameras, that is |
| 17:17 |
appguru |
in other words: your restriction that overlay textures have to be "simple" (non-RTT) is not a restriction at all |
| 17:20 |
appguru |
I'm ultimately not sure whether an overlay_textures feature would be worth the added complexity. |
| 17:20 |
MTDiscord |
<andrey2470t> This is restriction, otherwise if a modder does "camera_rtt^default_glass.png", it will lead to dummy texture. If just "camera_rtt" in textures field, that's all okay |
| 17:21 |
appguru |
yes, the restriction that you can't use RTT in texture modifiers needs to be documented |
| 17:21 |
MTDiscord |
<andrey2470t> It needs to add another textures in other field to be combined in the shader |
| 17:21 |
MTDiscord |
<andrey2470t> Since the shaders work continuously, it is possible |
| 17:22 |
appguru |
it would be possible, but would it be worth it just for overlays, which can be achieved with the hack i described as well? |
| 17:23 |
appguru |
the issues i currently see with my hack would primarily be modder convenience and extreme angles / distances (if you're very far, the two close planes may start z-fighting; if you're very close and observing from an extreme angle, you might notice the hack) |
| 17:24 |
appguru |
I would lean towards keeping the camera API PR simple if there is no significant reduction in functionality. I'm not sure if having to use this hack would qualify as a significant reduction in functionality. |
| 17:26 |
appguru |
btw, i'm not sure whether it'd even be that bad to allow applying texture modifiers to RTTs / how quick one would run into performance problems. CPUs are fast, textures aren't that big. |
| 17:26 |
Desour |
why do you worry about texture modifiers at this point btw.? afaik the PR is very complicated already anyways. just move that feature to a follow up PR |
| 17:27 |
appguru |
also that |
| 17:27 |
MTDiscord |
<andrey2470t> I feel texture modifiers with rtts could be used often, even e.g. do the rtt gray-scale or other tint. You can add some frame around it. There are many things where it would find usage |
| 17:28 |
MTDiscord |
<andrey2470t> If think about that thoroughly |
| 17:28 |
appguru |
mere "tints" via color blending can roughly be achieved with an overlay plane as i have described (gray scale, colorizehsl etc. needs actual processing of the pixels, though) |
| 17:29 |
MTDiscord |
<andrey2470t> Yes, that's a problem |
| 17:29 |
appguru |
but i agree with Desour, this PR is complex as-is, let's worry about texture modifiers when we get there |
| 17:29 |
|
SFENCE joined #minetest-dev |
| 17:30 |
MTDiscord |
<andrey2470t> Well ok |
| 17:30 |
sfan5 |
off-topic but would be nice if someone could review #14419 |
| 17:30 |
ShadowBot |
https://github.com/minetest/minetest/issues/14419 -- [no sq] Fix some common SAO methods to not generate useless update packets by sfan5 |
| 17:31 |
MTDiscord |
<andrey2470t> Then there are still other problems. Punching an entity with rtts cause short-term appearing dummy textures and then disappearing |
| 17:32 |
MTDiscord |
<andrey2470t> I think it is worth to add controlling the main camera in another PR also |
| 17:32 |
MTDiscord |
<andrey2470t> It is targeted mainly for the secondary ones |
| 17:32 |
sfan5 |
sounds like you're not disabling the punch texture modifier |
| 17:32 |
MTDiscord |
<andrey2470t> And the last one is occlusion culling |
| 17:32 |
|
proller joined #minetest-dev |
| 17:33 |
MTDiscord |
<andrey2470t> x2048 suggested some portal algorithm |
| 17:33 |
cx384 |
Sorry if I disrupt your conversation, but regarding texture modifiers, would there be any support if I make a PR to solve #3540 ? |
| 17:33 |
ShadowBot |
https://github.com/minetest/minetest/issues/3540 -- Provide the possibility to provide a crack texture override per node. |
| 17:33 |
cx384 |
(since it is not part on the roadmap and doesn't have a "concept approved" label) |
| 17:33 |
Desour |
controlling the main camera, e.g. setting it to quaternion mode and similar, is a different feature. and it would be much more useful than adding more cameras imo |
| 17:34 |
MTDiscord |
<andrey2470t> How would disable crack modifier if modifiers themselves can't be applied? |
| 17:34 |
|
SFENCE joined #minetest-dev |
| 17:34 |
MTDiscord |
<mistere_123> Desour, IIRC, you can replace the main camera with one of the api's cameras |
| 17:35 |
MTDiscord |
<mistere_123> and then control it however you like |
| 17:36 |
|
SFENCE_ joined #minetest-dev |
| 17:36 |
appguru |
related to main camera control: #14333 |
| 17:36 |
ShadowBot |
https://github.com/minetest/minetest/issues/14333 -- Support setting camera roll via lua by regulus79 |
| 17:37 |
rubenwardy |
#14432 |
| 17:37 |
ShadowBot |
https://github.com/minetest/minetest/issues/14432 -- Assertion `g_menuclouds->getReferenceCount() == 1' failed since VBO optimizations commit |
| 17:37 |
Desour |
@mistere_123: well yes, but you can't control them and how they act that well. i.e. no quaternion mode, no disabling bobbing, no relative transformation I think |
| 17:38 |
appguru |
cx384: sounds like something i'd support conceptually, but i probably can't commit time to it anytime soon :/ |
| 17:39 |
Krock |
cx384: there's quite some reaction/support shown in the issue's reactions so I suppose if this can be implemented rather easily there's not much reason to deny it. It should however not be a workaround for the door issue. In that case, the crack should be centered with the mesh |
| 17:41 |
MTDiscord |
<andrey2470t> You pinged the wrong member lol |
| 17:41 |
MTDiscord |
<mistere_123> You can't disable bobbing on camera api cameras!? why is there bobbing on them at all? |
| 17:41 |
cx384 |
OK thanks, maybe I will make a PR. |
| 17:42 |
|
Desour joined #minetest-dev |
| 17:42 |
MTDiscord |
<andrey2470t> I think no |
| 17:42 |
MTDiscord |
<mistere_123> Cameras were specifically made to break the paradigm of a player == camera. Bobbing is a bug. |
| 17:43 |
MTDiscord |
<mistere_123> If you want bobbing on a camera, attach it to an entity bone with a bobbing animation |
| 17:44 |
Desour |
should've said en/disable bobbing. I'm not assuming the new cameras are doing bobbing |
| 17:44 |
MTDiscord |
<mistere_123> ok I'm thouroghly confused then |
| 17:44 |
Desour |
but the server should be made able to control the bobbing behaviour of the main camera, which the PR doesn't provide, according to its doc |
| 17:45 |
|
vampirefrog joined #minetest-dev |
| 17:45 |
MTDiscord |
<andrey2470t> Yes, there is no amy bobbing, exactly. I think it can be simulated by rotation interpolation which the PR affords |
| 17:45 |
MTDiscord |
<mistere_123> That doesnt matter then... you can use a camera api camera instead of the main camera, and implement bobbing yourself |
| 17:46 |
Desour |
ah yes server side camera bobbing |
| 17:46 |
MTDiscord |
<mistere_123> Yes, if you implemented it yourself it would then be serverside, while still interpolated clientside |
| 17:50 |
MTDiscord |
<andrey2470t> Using interpolation in this PR, bobbing can be already implemented smoothly. However, there may be jerks if do it repeatedly since it needs to track lua-side if camera is rotated at the necessary angle during some time, then inverse the rotation |
| 17:52 |
Desour |
all I wanted to say is that adding more cameras is orthogonal to changing how a camera behaves. and latter is more important to me |
| 17:55 |
appguru |
I don't think it's orthogonal. More like a 45° angle :P the hope/idea with this approach would be that once you have the camera API, you can implement the main camera in terms of that. |
| 17:56 |
appguru |
But I suppose it doesn't matter much which way around you do that. You could either dehardcode the main camera, then generalize that to multiple cameras, or implement support for multiple cameras, then make the main camera a special case of that. |
| 17:58 |
appguru |
The former seems more likely to yield (high-priority) results earlier though. Then again the latter has basically already been implemented... |
| 17:58 |
MTDiscord |
<andrey2470t> I feel tired from the today discussion, it was pretty long for me. It was nice to discuss with all you and I could find conclusions to many problems appeared with my PRs |
| 17:58 |
sfan5 |
rubenwardy: I'll pick that commit and push it master alone |
| 17:59 |
Krock |
reviewing 14419 ... |
| 18:22 |
Krock |
thanks Zughy for the wiki update. The date is yet not correct, though. |
| 18:22 |
[MTMatrix] |
<Zughy> oh, whoops |
| 18:22 |
[MTMatrix] |
<Zughy> on it |
| 18:23 |
[MTMatrix] |
<Zughy> It confuses me that we're using two different formats on internal discussions and the wiki |
| 18:23 |
[MTMatrix] |
<Zughy> never mind, I'm stupid |
| 18:23 |
rubenwardy |
ISO-FREEDOM |
| 18:23 |
[MTMatrix] |
<Zughy> fixed c: |
| 18:26 |
Desour |
btw. @Zughy: I really like the emojis for the PR labels! can we also have some for issue labels? :) |
| 18:26 |
Desour |
or would someone mind if I change them myself? |
| 18:27 |
rubenwardy |
May I suggest 💩 for "Formspec" |
| 18:27 |
Krock |
honestly I dislike the new colors - mostly because I'm used to the old ones |
| 18:27 |
[MTMatrix] |
<Zughy> Desour: thanks! I'd personally avoid more emojis as I fear they're gonna create visual noise; more harm than good |
| 18:27 |
Krock |
note that renaming labels might break links |
| 18:28 |
Krock |
(links outside of github, for issue or PR filtering) |
| 18:28 |
Desour |
@Zughy: oh, ok then |
| 18:29 |
Desour |
haha, right, we now have emojies in the url when searching for topics x) |
| 18:30 |
[MTMatrix] |
<Zughy> right now your brain knows that you're in the PR section with just one rapid glance (emojis = PRs). We could port the same emojis for bug labels (🐛) and feature request labels (✨) but I'm not 100% sure |
| 18:31 |
[MTMatrix] |
<Zughy> also, what Krock said |
| 18:31 |
Desour |
I just noticed, we have a few label:"Feature ✨" issues. should they be converted to "feature request"? |
| 18:34 |
|
appguru joined #minetest-dev |
| 18:34 |
|
SFENCE joined #minetest-dev |
| 18:51 |
|
SFENCE joined #minetest-dev |
| 19:08 |
sfan5 |
merging #14406 in like 5 minutes |
| 19:08 |
ShadowBot |
https://github.com/minetest/minetest/issues/14406 -- [no squash] Fix node callbacks unit test by sfan5 |
| 19:18 |
|
SFENCE joined #minetest-dev |
| 19:26 |
|
SFENCE joined #minetest-dev |
| 19:35 |
[MTMatrix] |
<Zughy> Yes Desour |
| 19:42 |
|
SFENCE joined #minetest-dev |
| 20:04 |
|
Noisytoot joined #minetest-dev |
| 20:08 |
|
SFENCE joined #minetest-dev |
| 20:28 |
|
SFENCE joined #minetest-dev |
| 20:45 |
|
SFENCE joined #minetest-dev |
| 21:02 |
|
SFENCE joined #minetest-dev |
| 21:05 |
MTDiscord |
<redundantcc> Am I needed for something, or can I safely assume pinging me was an accident? |
| 21:08 |
MTDiscord |
<warr1024> Curse of the one-letter nickname. |
| 21:09 |
Desour |
it's "redundantcc" here. it's more than one letter in my used font |
| 21:14 |
ROllerozxa |
discord nickname can be different from their username |
| 21:18 |
MTDiscord |
<warr1024> The IRC bridge is a little weird because it apparently uses the user's username when it quotes them on the IRC side, but seems to also be sensative to their separate nickname on the discord side when it comes to detecting mentions and converting them into Discord pings. |
| 21:19 |
|
SFENCE joined #minetest-dev |
| 21:20 |
MTDiscord |
<redundantcc> Oh this is interesting, so this wasn't just an accident it was a bug! I'm surprising given how often I'm the one to end up finding them. |
| 21:21 |
MTDiscord |
<redundantcc> Can someone send me a link to the IRC Bridge code, I want to see how this works. |
| 21:22 |
MTDiscord |
<warr1024> Ask in meta-discussion on the Discord side; probably a good time to move this out of irc dev, where it's off-topic. |
| 21:41 |
|
Wuzzy joined #minetest-dev |
| 21:44 |
|
SFENCE joined #minetest-dev |
| 22:03 |
|
SFENCE joined #minetest-dev |
| 22:21 |
|
SFENCE joined #minetest-dev |
| 22:38 |
|
SFENCE joined #minetest-dev |
| 22:56 |
|
SFENCE joined #minetest-dev |
| 23:13 |
|
SFENCE joined #minetest-dev |
| 23:32 |
|
panwolfram joined #minetest-dev |
| 23:47 |
|
SFENCE joined #minetest-dev |
