Time Nick Message 13:25 [MatrxMT] pgimeno: thank you for the reply. it would be quite useful if the conventions used by setPitchYawRoll were documented in the code. 13:27 [MatrxMT] why did minetest / entity rotations need to use this specific convention? 13:33 [MatrxMT] I encountered a random testBiomeGen CI failure: https://github.com/minetest/minetest/actions/runs/12373489833/job/34533924411 14:27 pgimeno @grorp The first axis is the roll axis, the second axis is the pitch axis, and the last axis is the yaw axis. If you want them to work as you expect in Minetest, you need them to be done that way. You can swap X and Z but Minetest considers yaw angles with Z as the reference axis, not X, so that's how you end up with that convention. 21:02 [MatrxMT] does any core dev know why this happens? 5.10, both with .obj and .glb. Normals are correct 21:02 [MatrxMT] https://i.imgur.com/53B0tJF.png 21:09 sfan5 yes: #15401 21:09 ShadowBot https://github.com/minetest/minetest/issues/15401 -- Color problems with semitransparency & mipmapping enabled since ~5.4.0 22:30 [MatrxMT] is it normal that collisionboxes don't rotate with entities? https://imgur.com/dZWllBj 22:33 MTDiscord Yes 22:34 MTDiscord They have never been able to rotate 22:35 [MatrxMT] great, another idea thrown into the bin. I'll open an issue, it's absurd we expect from people to use somehow-cubic entities all the time 22:37 MTDiscord Coming from the guy that said Luanti games will only ever be blocky? :^) 22:38 [MatrxMT] The wall in my video is blocky :P 22:38 MTDiscord Something for AES? 22:38 [MatrxMT] yep 22:39 MTDiscord I would be surprised if there wasnt already an issue for rotating collision boxes 22:40 [MatrxMT] There was #2721, which had basically no discussion except for Paramat closing it 22:40 ShadowBot https://github.com/minetest/minetest/issues/2721 -- Possibility to rotate entity's collision box 22:40 MTDiscord proper rotating collision boxes are unfortunately very much nontrivial 22:41 [MatrxMT] https://github.com/minetest/minetest/issues/2721#issuecomment-127774508 22:41 [MatrxMT] - "This was asked years ago, not months ;)" 22:41 [MatrxMT] - 2015 22:41 [MatrxMT] Fuck me 22:41 MTDiscord they require you to introduce angular velocity into the equations 22:42 MTDiscord though, if all you need are static rotated collision boxes, that could be more realistic 22:42 [MatrxMT] yeah, I don't need to animate it 22:44 MTDiscord Are you wanting it player-aligned? 22:44 [MatrxMT] yep. Well, in my code I spawn the entity first and then I rotate it through staticdata (passing player pos) 22:45 MTDiscord what i'm calling "static" basically means you call set_rotation and then the collision box is rotated by that, no matter whether that is "possible" or not, that's still your problem 22:46 MTDiscord in particular this is somewhat unsuitable for things like boats where you instead want angular velocity (say, boat turning left) and then want to see how far it can turn until it hits something 22:47 MTDiscord another problem with rotated boxes is that suddenly normals aren't the 6 cardinal directions anymore, they can be anything 22:48 MTDiscord this can be dealt with relatively straightforwardly (zero the orthogonal component, keep only the parallel component) for some purposes i suppose but in general we will really want better physics there 22:50 [MatrxMT] #15569 22:50 ShadowBot https://github.com/minetest/minetest/issues/15569 -- Collisionbox should be able to rotate with the entity 23:04 sfan5 do you want 90° or arbitrary rotations? 23:06 MTDiscord I mean 90° rotations don't need an engine feature though it could be neat for convenience 23:12 [MatrxMT] arbitrary. If player is rotated by 140°, I need that wall to share the same rotation (and collisionbox)