Time Nick Message 12:36 grorp I've been trying to figure out the rotation stuff for #15562 and things are confusing. To be fair I'm also missing some math knowledge, but still. Here are some questions, I hope somebody is able to answer them: 12:36 ShadowBot https://github.com/minetest/minetest/issues/15562 -- Add player:get_point_dir() which honors touch_use_crosshair = false 12:36 grorp Server-side: Why is the player's yaw stored in `UnitSAO::m_rotation.Y` as a part of normal rotation, but the player's pitch separately as `PlayerSAO::m_pitch`? https://github.com/minetest/minetest/blob/5.10.0/src/server/player_sao.cpp#L402-L410 12:36 grorp Why is yaw applied inverted on the client? https://github.com/minetest/minetest/blob/5.10.0/src/client/camera.cpp#L318 12:36 grorp Why does the CAO/SAO code have its own rotation function `setPitchYawRoll` that's not used anywhere else, instead of Irrlicht rotation functions? and why is rotation also applied inverted here? https://github.com/search?q=repo%3Aminetest%2Fminetest%20setPitchYawRoll&type=code 12:38 sfan5 good luck 12:40 grorp lol 12:41 grorp I was hoping luatic may have some knowledge, since he did some Irrlicht rotation function documentation recently 13:27 MTDiscord Realistically I think the sad answer probably is they looked at the Irrlicht code, didn't know what conventions it used, saw that it used different conventions from what they liked, and wrote their own / inverted as they saw fit, and now we're left with the mess. 15:55 celeron55 the answer probably is: the rotations were added one-by-one without any intention to add a single more rotation, and each made sense on its own given there was no intention to make it fully featured, and it just piled up 15:57 celeron55 sounds like things for the luanti 6.0 to-do list 15:59 celeron55 should CRCSM considerations (and CSM hosted on CDB is the intermediate step to that) be added on the meeting agenda? 15:59 celeron55 SRCSM* 15:59 celeron55 as the intermediate step* 17:19 sfan5 i dont see how relevant progress can be made on it in a meeting 17:19 sfan5 other than an endless discussion 17:21 celeron55 the only thing that has to be made is a decision: whether it will be taken as the path forward, or whether to still explore other options 17:21 celeron55 i don't think enough opinions were heard on #minetest today 17:25 celeron55 well, there are three ways to go about this: 1) we'll have each core team member have a say on it, and then vote on it, 2) i'll make a recommendation and hope people can stomach it, 3) we'll try to first develop the project organization a bit (as people seem interested to do this), and once the new organization is up, then basically as the first thing make a choice on this 18:10 MTDiscord I think there is consensus among core developers that we do want to move forward with a form of S(S|R|P)CSM. Or is there a core developer who disagrees? 18:14 Krock I thought SSCSM was already an established term. If not, nail it down. 18:15 MTDiscord SSCSM is an established term indeed, SRCSM and SPCSM are slightly different terms ("sent" vs "required" vs "provided"), the proposals for how a user gets the CSMs to play on a server differ 18:15 MTDiscord though probably SSCSM is about the same as SPCSM 18:18 MTDiscord Anyways, the question remains, is any core dev against a form of SSCSM, that is, do they think servers must work without game-specific clientside code? From what I have gathered so far only erle seems to hold this opinion. 18:19 MTDiscord On a different note, have we considered putting all I/O in a different process for security reasons? That way it could be made practically impossible to say, mess up a user's home directory from Luanti, even with a SSM sandbox escape and full control over the main server process. 18:22 Krock Luanti/Minetest is fixed-function in terms of protocol for now. The only exception is probably mod channels. This is uncharted territory. Are there any other Open Source games doing that? 18:22 Krock s/protocol/network transmissions/ 18:23 Krock moddable games like Minecraft and Roblox surely need some way of client-side prediction code 18:24 Krock granted, they're not open source, but if the concept is known, we might have gained some hints in which way we should develop a VM/sandbox. 19:43 MTDiscord I love SSCSM as a path forward, solves so many problems in my future personal roadmap. That said, I appreciate the amount of security thought going into the design 20:12 celeron55 the SRCSM concept is such that the server could request the client to go get a CSM from contentdb to provide the server's required client-side functionality. of course user would be free to get the same CSM via other channels, or try to opt out (which the server could allow or disallow). the most important thing that this provides is a security model where all client-side code is publicly audited 20:13 celeron55 and versioned before use 20:13 celeron55 i haven't been a fan of this, but there are two things about this that make it attractive: 20:14 celeron55 1) almost all of this is already implemented. there's almost nothing else to do than take it into use (aside from a few UI things and related protocol improvements, possibly) 20:14 celeron55 2) this would make the current security model on the client sufficient, because there's not that much difference from downloading singleplayer content from contentdb 20:15 celeron55 actually there's also a third one: there are arguments for having CSMs in contentdb anwyay, to support accessibility and debugging related CSMs that are not game or server specific 20:17 celeron55 so: we basically already have it, it gives a lot of bang for the buck in terms of features vs. security, and we probably kind of want it anyway 20:19 celeron55 i would like to see arguments that specifically go against these three 20:40 pgimeno @grorp I can only talk about setPitchYawRoll which IIRC was my creation. There are 6 variants of Euler angles (actually Tait-Bryan angles) for the six permutations of the axes. Minetest needs extrinsic ZXY order IIRC, and I'm pretty sure that's not the one used by Irrlicht. Irrlicht has made the tremendous mistake of using a left-handed coordinate system, 20:41 pgimeno A left-handed system implies that angles twist the wrong way around, and that may explain some inversions. 21:00 sfan5 https://0x0.st/XFDd.png sus 21:04 Krock why sus? Are the buffers supposed to be uploaded very quickly? 21:05 sfan5 10% of drawing is not supposed to be spent on buffer management 21:05 sfan5 all it does is iterate a list and check some reference counts 21:05 sfan5 i guess the pointer chasing is really bad 21:07 sfan5 HWBufferList.size() = 51922 21:07 Krock couldn't it be that .erase() is inlined? 21:08 Krock and thus wouldn't appear on the flamegraph 21:08 sfan5 it's not erasing anything tho 21:08 sfan5 also std::list, not std::vector 21:10 Krock hmm. erase is O(1) with iterators 21:12 Krock you could copy SHWBufferLink to stack. it's not much data. 21:12 sfan5 there's no reason to heap allocate it in the first place 21:12 sfan5 let me see 21:12 Krock never mind. constructor and destructor so some indirection too. 21:13 Krock *do 21:14 Krock the list needs to keep pointer because you'0re casting IIndexBuffer and IVertexBuffer to it 21:17 sfan5 ah yeah SHWBufferLink has child classes 21:23 sfan5 this is tricky 21:25 Krock change the Cost Threshold to 0.00% and see if it's spending the time in the destructor or somewhere else 21:27 Krock maybe it helps if we simply inline deleteHardwareBuffer and use "it" instead of the additional indirection 21:27 sfan5 it's a virtual method 21:28 Krock also hacky: The "IsVertex" check isn't really needed. VertexBuffer and IndexBuffer are at the same memory address 8) 21:29 Krock oh. virtual. so GL.DeleteBuffers could also be an issue. assuming they're really deleted every frame. 21:29 Krock 51922 is a lot of OpenGL calls 21:30 sfan5 i don't think it's actually deleting any buffers 21:31 sfan5 nothing else here https://0x0.st/XFkT.png 21:36 Krock added a stupid simple counter for deleted vs non-deleted calls to COpenGL3DriverBase::deleteHardwareBuffer. 20480 / 20480 deleted. 21:36 Krock although there's only about 1000 per second (rough guess) 21:37 Krock (at 60 FPS) 21:38 sfan5 yeah this is an extreme and static test scene 21:38 Krock actually I'm stupid and I need to sleep. Added the counter to the wrong place 21:38 Krock this only means that all buffers have a vbo_ID 21:38 sfan5 anyway this problem essentially needs a bit smarter of a GC algorithm 21:38 sfan5 and not just "let's iterate all objects and check if they are still referenced" 21:39 sfan5 I wonder if I can make it a bit smarter to improve performance without refactoring everything 21:39 Krock they have an iterator position, so they could remove themselves in the destructor. 21:39 Krock well that's assuming they have access to the container pointer 21:40 Krock the container would then explicitly not hold ownership 21:40 * Krock vanishes 21:44 sfan5 will try rewriting it to std::vector tomorrow 21:48 sfan5 or maybe not 21:48 sfan5 we can just ignore this problem