| Time |
Nick |
Message |
| 00:37 |
|
deezl joined #minetest-dev |
| 01:25 |
|
Cornelia joined #minetest-dev |
| 01:27 |
|
Lone-Star joined #minetest-dev |
| 01:33 |
|
benrob0329 joined #minetest-dev |
| 02:27 |
|
Lord_Vlad joined #minetest-dev |
| 02:37 |
|
ANAND joined #minetest-dev |
| 03:33 |
|
GreenDimond joined #minetest-dev |
| 07:34 |
|
Beton joined #minetest-dev |
| 08:20 |
|
karamel joined #minetest-dev |
| 09:11 |
|
proller joined #minetest-dev |
| 09:48 |
|
Krock joined #minetest-dev |
| 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 |
| 09:56 |
|
ensonic joined #minetest-dev |
| 10:00 |
Krock |
mergign |
| 10:01 |
Krock |
done |
| 10:04 |
|
kaeza joined #minetest-dev |
| 10:08 |
|
ANAND joined #minetest-dev |
| 10:24 |
|
kaeza joined #minetest-dev |
| 10:33 |
|
Fixer joined #minetest-dev |
| 11:42 |
|
kaeza joined #minetest-dev |
| 11:45 |
|
calcul0n_ joined #minetest-dev |
| 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 |
|
Wuzzy joined #minetest-dev |
| 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:56 |
|
proller joined #minetest-dev |
| 12:59 |
p_gimeno |
[0407 14:36:20] <p_gimeno> 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:25 |
|
DI3HARD139 joined #minetest-dev |
| 13:29 |
|
xerox123 joined #minetest-dev |
| 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:18 |
|
Lone-Star joined #minetest-dev |
| 14:35 |
|
JDCodeIt joined #minetest-dev |
| 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 |
| 15:55 |
|
ensonic joined #minetest-dev |
| 16:08 |
|
deezl joined #minetest-dev |
| 16:18 |
|
proller joined #minetest-dev |
| 16:44 |
|
proller joined #minetest-dev |
| 16:45 |
nerzhul |
merging #8435 |
| 16:45 |
ShadowBot |
https://github.com/minetest/minetest/issues/8435 -- Find PostgreSQL correctly by adrido |
| 16:47 |
|
paramat joined #minetest-dev |
| 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 |
| 17:20 |
|
ANAND_ joined #minetest-dev |
| 17:25 |
|
ensonic joined #minetest-dev |
| 17:37 |
|
diemartin joined #minetest-dev |
| 17:48 |
|
srifqi joined #minetest-dev |
| 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 |
| 18:54 |
|
Miner_48er joined #minetest-dev |
| 19:19 |
|
reductum joined #minetest-dev |
| 20:00 |
|
Lord_Vlad joined #minetest-dev |
| 20:38 |
|
proller joined #minetest-dev |
| 20:51 |
diemartin |
? |
| 20:59 |
|
Cornelia joined #minetest-dev |
| 21:24 |
|
proller joined #minetest-dev |
| 22:08 |
|
Fixer_ joined #minetest-dev |
| 22:23 |
|
Fixer joined #minetest-dev |
| 22:44 |
|
srifqi left #minetest-dev |
| 22:54 |
|
Cornelia joined #minetest-dev |
| 23:13 |
|
paramat joined #minetest-dev |
| 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:20 |
|
Lone-Star joined #minetest-dev |
| 23:21 |
|
Cornelia joined #minetest-dev |
| 23:37 |
paramat |
merging |
