| Time |
Nick |
Message |
| 00:05 |
|
Eragon joined #minetest-dev |
| 01:38 |
|
MTDiscord joined #minetest-dev |
| 02:50 |
|
clavi joined #minetest-dev |
| 02:50 |
|
clavi joined #minetest-dev |
| 04:59 |
|
tzenfore joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 12:16 |
|
grorp joined #minetest-dev |
| 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 |
<luatic> 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. |
| 13:49 |
|
jordan4ibanez joined #minetest-dev |
| 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 |
| 17:43 |
|
MTDiscord1 joined #minetest-dev |
| 17:46 |
|
Eragon_ joined #minetest-dev |
| 18:10 |
MTDiscord |
<luatic> 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 |
<luatic> 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 |
<luatic> though probably SSCSM is about the same as SPCSM |
| 18:18 |
MTDiscord |
<luatic> 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 |
<luatic> 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. |
| 18:25 |
|
fluxionary joined #minetest-dev |
| 19:27 |
|
SFENCE joined #minetest-dev |
| 19:38 |
|
SFENCE joined #minetest-dev |
| 19:43 |
MTDiscord |
<exe_virus> 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:02 |
|
SFENCE joined #minetest-dev |
| 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:29 |
|
SFENCE joined #minetest-dev |
| 20:34 |
|
SFENCE joined #minetest-dev |
| 20:37 |
|
SFENCE joined #minetest-dev |
| 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:40 |
|
SFENCE joined #minetest-dev |
| 20:41 |
pgimeno |
A left-handed system implies that angles twist the wrong way around, and that may explain some inversions. |
| 20:55 |
|
SFENCE joined #minetest-dev |
| 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:09 |
|
SFENCE joined #minetest-dev |
| 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 |
| 23:33 |
|
panwolfram joined #minetest-dev |
