Time Nick Message 09:50 Krock merging #8450 and #8443 in ~10 minutes 09:50 ShadowBot https://github.com/minetest/minetest/issues/8450 -- Update hex.h by starling13 09:50 ShadowBot https://github.com/minetest/minetest/issues/8443 -- Add deprecation warnings for ObjectRef:get/set_attribute by ClobberXD 10:00 Krock mergign 10:01 Krock done 11:48 Krock ANAND: regarding the FOV PR: it would probably be a better idea to make the FOV value a multiplier so that it will still look about right for different screen formats 11:50 ANAND Thanks, paramat suggested the same 11:51 ANAND A multiplier is a great compromise between fixed values and modifiers 11:51 Krock according to the first few posts, paramat is against that idea 11:52 ANAND Yeah 11:52 Krock unchanged opinion. he disagrees with relative values (multipliers) entirely 11:59 ANAND He says he misunderstood and indicates that he's fine with non-combinable multipliers in his last post 11:59 ANAND https://github.com/minetest/minetest/pull/7557#issuecomment-480467677 11:59 p_gimeno what units are used for FOV? is it an angle? 11:59 ANAND degrees 12:00 p_gimeno in that case, direct multiplication is not the best idea 12:01 ANAND What problems do you foresee, and what do you suggest as a solution? 12:01 p_gimeno atan(tan(FOV)*factor) may work 12:02 ANAND Ok, I'll try that out 12:02 ANAND What would be the issue with direct multiplication, though? 12:03 p_gimeno imagine you have a FOV of 120° (pretty wide) - half that is 60°, it's not really double the zoom, it's more than that 12:04 ANAND How so? Isn't that exactly double the zoom? 12:04 p_gimeno I assume you want the applied zoom factor to be the same at any FOV 12:04 p_gimeno no... 12:05 ANAND Correct 12:05 p_gimeno ok, imagine the ZOOMED view is 100°. What should the NON-ZOOMED view be? 12:05 ANAND Erm... the player's default FOV? 12:05 p_gimeno (I mean, walking backwards) 12:06 p_gimeno basically, the problem is that the actual zoom factor applies to the projected image, not to the angle 12:06 p_gimeno I can try to draw diagrams to explain 12:06 ANAND I see 12:06 ANAND That'd be really helpful 12:35 p_gimeno http://www.formauri.es/personal/pgimeno/temp/FOV-Diagram-2X-zoom-is-not-0.5X-angle.png 12:36 p_gimeno that's what you expect from a 2X zoom: the small rectangle will be zoomed to occupy the full screen 12:36 p_gimeno however, note the angles are not half of each other 12:38 p_gimeno they approximate half of each other as the initial angle decreases, though; if the initial FOV is e.g. 30° you're not going to note a difference. But if it's wider, you might. 12:40 rubenwardy we're now at 360 contributors according to Github ? 12:40 ANAND ? 12:41 ANAND p_gimeno: I'll try out the atan(tan()) method then 12:41 ANAND It's still somewhat strange that 60 isn't the half of 120 :P 12:41 ANAND Thanks for your efforts :) 12:42 p_gimeno the problem is thinking that a FOV expressed as an angle is reasonable, it is not 12:43 p_gimeno FOV has always been expressed in length units with respect to a certain size film, typically in mm with respect to a 35mm film 12:44 p_gimeno then a 64mm FOV is really double a 32mm FOV 12:45 ANAND Hmmmm... 12:46 p_gimeno a similar problem happens in some raycasting tutorials where they use angles to raycast successive pixel columns, and they get deformation and don't understand why - https://love2d.org/forums/viewtopic.php?f=4&t=85624 12:49 p_gimeno there's sooo many wrong design decisions in minetest, I've lost count of them. That's just another one. 12:50 sfan5 isn't that every software 12:51 p_gimeno yeah but rarely so prominent and with so many implications as in minetest 12:59 p_gimeno [0407 14:36:20] however, note the angles are not half of each other <--- wait, I should have said "note the angles are not equal" 13:04 p_gimeno THESE angles are not half of each other: http://www.formauri.es/personal/pgimeno/temp/FOV-Diagram-2X-zoom-is-not-0.5X-angle-fixed.png 13:05 Krock nice visualisation :) 13:05 p_gimeno heh thanks 13:52 p_gimeno ANAND: I think I made a mistake. I think that FOV angle is double what should be used in calculations. The calculation should be 2*atan(tan(FOV/2)*factor) 13:59 ANAND p_gimeno: Alright. Thanks again :) 14:52 ANAND https://github.com/minetest/minetest/blob/master/src/constants.h#L40 14:52 ANAND lol :P 14:52 ANAND I guess that's quite handy 16:45 nerzhul merging #8435 16:45 ShadowBot https://github.com/minetest/minetest/issues/8435 -- Find PostgreSQL correctly by adrido 16:54 paramat simple PR any support? #8440 16:54 ShadowBot https://github.com/minetest/minetest/issues/8440 -- Android settings: Use opaque leaves instead of fancy by paramat 16:57 Krock simple leaves would look way better 16:57 Krock opaque may generate ugly black or white fillers for the alpha channel 17:02 p_gimeno Krock: About this: https://github.com/minetest/minetest/issues/8451#issuecomment-480522773 I moved the calculation of max_rotation_delta inside the 'if' so that it doesn't need to be evaluated in the other 'if' branch where it's not needed 17:02 paramat only if the textures are badly made, we shouldn't be concerned about that 17:03 Krock p_gimeno: oh right, I see 17:04 Krock the impact on performance is very tiny so having the multiplication outside wouldn't hurt either. However, I think the inner variable should be inlined since it's only used once 17:05 p_gimeno fine with me 17:05 paramat hm well, if i change it to 'simple' will you +1? :) 17:05 p_gimeno also the new variable is just a shortened version of the other setting, which could be used in its place 17:06 Krock paramat: yes sure 17:06 paramat ok will do and merge 17:06 paramat thanks 17:06 Krock nice, thanks too 17:07 Krock merging #8129 in a minute 17:07 ShadowBot https://github.com/minetest/minetest/issues/8129 -- Optimize random turns in dungeongen by osjc 17:07 paramat good 17:08 Krock merging 17:08 paramat another very simple one #8410 17:08 ShadowBot https://github.com/minetest/minetest/issues/8410 -- World start time: Move to first full light (day night ratio = 1000) by paramat 17:09 Krock that was already discussed in a previous PR 17:11 Krock #6220 17:11 ShadowBot https://github.com/minetest/minetest/issues/6220 -- New world start time: Make this 5751, time of earliest full brightness by paramat 17:12 Krock there it was 5751 and now 6125 seems to be a better choice? huh 17:12 paramat no, different argument, this should be decided by MTG not the engine 17:13 paramat we can move it to MTG 17:13 paramat see the argument, considering all possible games, first full light is the obvious optimum choice 18:19 paramat merging #8440 18:19 ShadowBot https://github.com/minetest/minetest/issues/8440 -- Android settings: Use 'simple' leaves instead of 'fancy' by paramat 20:51 diemartin ? 23:15 paramat #8453 is codestyle improvements, carefuly tested, so will merge as trivial in 15 mins 23:15 ShadowBot https://github.com/minetest/minetest/issues/8453 -- daynightratio.h: Improve codestyle, some optimisation by paramat 23:37 paramat merging