Time Nick Message 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 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:09 MTDiscord 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 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 MTDiscord 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 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 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 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 You can just have a custom mesh as well, or use particles, and some other way I think 15:25 MTDiscord 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 Andrey said he lost interest tbh. 15:30 MTDiscord (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 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 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 Tbh the primitives talked about would be I think line (of a few kinds), cube and icosphere. 15:41 MTDiscord Maybe arbitrary planes too 15:41 MTDiscord Cube defined as AABB and sphere by center and radius 15:43 appguru hi grorp 15:43 [MTMatrix] 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 Another question is whether to attach the primitives to objects as-is or have option to attach to bones 15:43 [MTMatrix] (hi) 15:43 grorp hi, I'm now lurking 15:43 MTDiscord 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 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 +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 MTDiscord 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 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 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 In this case it is just bone position though 15:48 MTDiscord And weights 15:48 MTDiscord 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 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 But isn't that IK? 15:49 MTDiscord 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 But if you attach an existing bone to a specific position, and the object is moving...? 15:51 MTDiscord 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 It is the same thing, not "like" 15:52 MTDiscord 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 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 Yes 15:54 appguru the thing i was suggesting is restricted to a single bone 15:54 MTDiscord 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 So that the bone tracks another object, for example? 15:55 appguru yes 15:55 MTDiscord 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 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 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 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 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 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 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 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 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 #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 So yeah, it was about protections too. 16:29 MTDiscord nauta-turbidus 16:29 MTDiscord No PRs yet. 16:29 Krock it seems that's a flaw in core.dig_node 16:29 MTDiscord 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 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 @andrey2470t 16:48 Krock what exactly would you like to clarity? 16:49 MTDiscord 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 "(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 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 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 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 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 How about my second question? This requires usage of new field for entities 17:03 appguru about overlay textures for entities? 17:03 MTDiscord Yes 17:03 appguru can't modders achieve a pretty good approximation by just overlaying another surface with a small distance? 17:03 MTDiscord Overlay rtts with simple textures and their various combinations 17:06 appguru various combinations? 17:06 MTDiscord 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 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 And those textures would two by two be sent to shaders to be combined 17:09 MTDiscord However, a problem can occur if the object shader is disabled... 17:10 MTDiscord It needs in adding a duplicated mesh whereas my doesn't do it 17:13 MTDiscord 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 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 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 It needs to add another textures in other field to be combined in the shader 17:21 MTDiscord 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 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 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 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:30 MTDiscord 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 Then there are still other problems. Punching an entity with rtts cause short-term appearing dummy textures and then disappearing 17:32 MTDiscord I think it is worth to add controlling the main camera in another PR also 17:32 MTDiscord It is targeted mainly for the secondary ones 17:32 sfan5 sounds like you're not disabling the punch texture modifier 17:32 MTDiscord And the last one is occlusion culling 17:33 MTDiscord 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 How would disable crack modifier if modifiers themselves can't be applied? 17:34 MTDiscord Desour, IIRC, you can replace the main camera with one of the api's cameras 17:35 MTDiscord and then control it however you like 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 You pinged the wrong member lol 17:41 MTDiscord 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 MTDiscord I think no 17:42 MTDiscord Cameras were specifically made to break the paradigm of a player == camera. Bobbing is a bug. 17:43 MTDiscord 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 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 MTDiscord Yes, there is no amy bobbing, exactly. I think it can be simulated by rotation interpolation which the PR affords 17:45 MTDiscord 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 Yes, if you implemented it yourself it would then be serverside, while still interpolated clientside 17:50 MTDiscord 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 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] oh, whoops 18:22 [MTMatrix] on it 18:23 [MTMatrix] It confuses me that we're using two different formats on internal discussions and the wiki 18:23 [MTMatrix] never mind, I'm stupid 18:23 rubenwardy ISO-FREEDOM 18:23 [MTMatrix] 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] 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] 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] also, what Krock said 18:31 Desour I just noticed, we have a few label:"Feature ✨" issues. should they be converted to "feature request"? 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:35 [MTMatrix] Yes Desour 21:05 MTDiscord Am I needed for something, or can I safely assume pinging me was an accident? 21:08 MTDiscord 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 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:20 MTDiscord 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 Can someone send me a link to the IRC Bridge code, I want to see how this works. 21:22 MTDiscord Ask in meta-discussion on the Discord side; probably a good time to move this out of irc dev, where it's off-topic.