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