| Time |
Nick |
Message |
| 01:08 |
|
shadowzone joined #minetest-dev |
| 01:18 |
|
Wayward_One joined #minetest-dev |
| 01:29 |
|
IAmRasputin joined #minetest-dev |
| 01:33 |
|
prozacgod joined #minetest-dev |
| 01:34 |
est31 |
network protocol only resends parts of the map if the map actually changed? |
| 01:47 |
|
OldCoder joined #minetest-dev |
| 02:13 |
|
T4im joined #minetest-dev |
| 02:15 |
|
Zeno` joined #minetest-dev |
| 02:15 |
Zeno` |
Wayward_One, that's interesting then isn't it. The question is why? |
| 02:16 |
Zeno` |
I love continuing conversations after a 12 hour break |
| 02:16 |
acerspyro |
lol |
| 02:16 |
acerspyro |
Someone lost track of time here |
| 02:16 |
Zeno` |
hmmmm, Wayward_One's "issue" is fixed |
| 02:27 |
Zeno` |
Must get feature freeze thawed |
| 02:29 |
* Tesseract |
would like SQLite3 and translations to be fixed first (PRs already made). |
| 02:30 |
Tesseract |
Also, now that Lua 5.3's been out for a while is 5.2 old enough to use? |
| 02:30 |
Tesseract |
5.1 is only, like 9 years old now. |
| 02:31 |
acerspyro |
Tesseract: You do know there's a game with your name, right? |
| 02:32 |
Tesseract |
acerspyro: I've only been told 256 times, please, tell me again. ;-P |
| 02:32 |
acerspyro |
Tesseract: You do know there's a game with your name, right? |
| 02:33 |
acerspyro |
That NEEDS to be 512 times now |
| 02:34 |
|
shadowzone joined #minetest-dev |
| 02:34 |
Brains |
Wonder if he used signed storage for that... And what being told something -<some large number> means. |
| 02:36 |
Zeno` |
? |
| 02:37 |
Brains |
Zeno`: Lame joke about Tesseract storing the number of times he's been told about the game of the same name. Lame and OT to boot. |
| 02:38 |
Zeno` |
:) |
| 02:47 |
T4im |
Tesseract: luajit is at 5.2. right? wouldn't it be right to assume that a more recent luajit can do a lot more runtime optimizations and thus run faster? :D |
| 02:49 |
Tesseract |
T4im: No, luajit is at 2.0.3 or so. It's compatible with 5.1, supports most 5.2 features, and has one or two 5.3 features though. |
| 02:49 |
T4im |
ah, yes I meant compatible with 5.2 :) |
| 03:13 |
hmmmm |
Zeno`: Saw that, holy crap |
| 03:13 |
hmmmm |
Zeno`: What was taking up more cpu time in clientmap though?? |
| 03:13 |
hmmmm |
my guess is that my change somewhere caused a flood of exceptions |
| 03:14 |
Zeno` |
hmmmm, I'm just spent another 30 minutes looking at it and I really don't know. It's baffling |
| 03:14 |
hmmmm |
i'll try to figure it out so it never happens again |
| 03:16 |
Zeno` |
If you figure it out before I do be sure to let me know because I really want to know. I can't see anything that jumps out. Even looking through these valgrind logs... it's odd. |
| 03:17 |
hmmmm |
Zeno`: So reverting the changes in clientmap.cpp in that commit specifically fixes it? |
| 03:17 |
Zeno` |
It increases performance, yes |
| 03:18 |
Zeno` |
Oh. I reverted the whole commit |
| 03:18 |
Zeno` |
so it could be any of those changes |
| 03:18 |
hmmmm |
why'd you say clientmap.cpp then |
| 03:18 |
|
Miner_48er joined #minetest-dev |
| 03:18 |
Zeno` |
the order of ::render() and ::renderMap() is reversed |
| 03:19 |
hmmmm |
oh dear |
| 03:19 |
Zeno` |
hmmmm, not sure. It was late. Let me profile with just reverting clientmap.cpp |
| 03:20 |
Zeno` |
By the time I came across this innocent looking commit I'd been profiling for 8 hours; I was going cross-eyed heh. But reverting it definately changes things. Trying to narrow down even more now |
| 03:21 |
Zeno` |
https://github.com/Zeno-/minetest/tree/experiment is what I got Wayward_One to try before I passed out from lack of sleep |
| 03:21 |
Zeno` |
ok, back to looking |
| 03:26 |
Zeno` |
Whatever it turns out to be (*root* cause) it's likely to be somewhere else... because I can't see anything in that entire commit that should cause such a difference (suggesting something somewhere else is flaky) |
| 03:53 |
|
cheapie joined #minetest-dev |
| 03:59 |
Zeno` |
I'm getting frustrated now |
| 04:24 |
Zeno` |
ok, it's more than 1 commit |
| 04:24 |
Zeno` |
arrgh |
| 04:37 |
Zeno` |
I don't know what to do now :/ |
| 04:40 |
Zeno` |
and what is #2252? |
| 04:40 |
ShadowBot |
https://github.com/minetest/minetest/issues/2252 -- Framerate cut in half, HUD problem ? |
| 04:43 |
|
Hunterz1 joined #minetest-dev |
| 05:19 |
Zeno` |
time to clutch at straws again :( |
| 05:24 |
|
OldCoder joined #minetest-dev |
| 05:31 |
Zeno` |
I've worked out what the problem is: client rendering is now too fast. Might have to add a sleep() |
| 05:32 |
Zeno` |
</joke> for those who do not understand my sense of humour (the sleep() bit anyway) |
| 06:19 |
|
chchjesus joined #minetest-dev |
| 06:44 |
|
Hunterz joined #minetest-dev |
| 07:00 |
Zeno` |
ok, I found the real problem |
| 07:01 |
Zeno` |
Client::ProcessData() is now being called too often (and therefore mesh update thread) |
| 07:02 |
T4im |
that thread is quite visible in (h)top, spiking cpu quite drasticly.. kudos for fixing another noticeable performance hit :D |
| 07:03 |
Zeno` |
The faster everything else gets the more processData() gets called |
| 07:03 |
Zeno` |
T4im, well I haven't fixed it yet |
| 07:03 |
Zeno` |
:) |
| 07:03 |
T4im |
ah, finding the problem is half the job ;) |
| 07:03 |
T4im |
if not more :) |
| 07:04 |
Zeno` |
I just know it's the problem because changing sleep_ms(3); to sleep_ms(25); in the mesh update thread "fixes" the problem (changing to 25 is not a solution; I did it to prove to myself that this was the real issue) |
| 07:05 |
Zeno` |
I really don't know how to fix it |
| 07:05 |
Zeno` |
need to work out some reasonable interval on which to base the sleep time on |
| 07:28 |
|
kahrl joined #minetest-dev |
| 07:29 |
kahrl |
Zeno`: do you have an idea why that would cause general slowness? |
| 07:29 |
kahrl |
I mean it's a thread, so in theory it should run in parallel |
| 07:29 |
kahrl |
is there contention on some lock? |
| 07:32 |
Zeno` |
I think that's part of the issue yes (lock contention) |
| 07:32 |
Zeno` |
haven't worked out all the "why's" yet |
| 07:32 |
Zeno` |
But also clientmap::render seems to be doing more work than it should (for some reason) |
| 07:33 |
Zeno` |
I'm finding it quite difficult to debug (with the threads) |
| 07:34 |
kahrl |
I can imagine |
| 07:35 |
Zeno` |
What I've been thinking about is that sleep(3) in the thread... |
| 07:35 |
Zeno` |
should that 3 be based on "something" |
| 07:35 |
Zeno` |
like some kind of "aimed for interval" |
| 07:35 |
kahrl |
I don't like that it is polling at all |
| 07:35 |
kahrl |
it should condition variables or something like that |
| 07:35 |
kahrl |
should use* |
| 07:35 |
Zeno` |
correct |
| 07:35 |
Zeno` |
I was saying that to someone else earlier |
| 07:36 |
Zeno` |
some kind of signal to say "hey go process data" |
| 07:36 |
Zeno` |
maybe after map update is complete (I think that was the potential solution) |
| 07:36 |
Zeno` |
soltuion/suggestion |
| 07:37 |
kahrl |
the threadsafe stuff in util/container.h used to sleep too to wait on new data, now they use semaphores |
| 07:37 |
Zeno` |
should semaphores be used here then? |
| 07:37 |
kahrl |
probably |
| 07:38 |
kahrl |
personally I prefer condition variables (semaphores feel too low level and error prone) but we don't have that in jthread |
| 07:39 |
kahrl |
actually I guess since this is a simple producer-consumer thing, semaphores would be fine |
| 07:40 |
Zeno` |
hmm |
| 07:42 |
|
Krock joined #minetest-dev |
| 07:44 |
Zeno` |
it's (probably) /really/ ProcessData being called more often and therefore adding more "mesh update tasks" |
| 07:45 |
Zeno` |
I'm not sure... I've been looking at this too long now |
| 07:46 |
T4im |
kahrl: that thread also spikes heavily in cpu and memory, which might easily overpower a slower pc if it gets more time than the main thread |
| 07:47 |
kahrl |
should its priority be reduced then? |
| 07:47 |
T4im |
maybe.. would there be any drawbacks? |
| 07:48 |
kahrl |
well if the main thread is running all the time and the mesh update thread has low priority, mesh updated might not happen at all |
| 07:48 |
kahrl |
that would be the only danger I can think of |
| 07:48 |
kahrl |
mesh updates* |
| 07:51 |
Zeno` |
I need a break. I expect kahrl and/or T4im to have fixed this once I get back (lol) |
| 07:51 |
* kahrl |
hands the responsibility to T4im |
| 07:51 |
* T4im |
quickly flees |
| 07:52 |
* VanessaE |
hides too just to be safe |
| 07:52 |
* Zeno` |
hides as well then |
| 07:53 |
Zeno` |
ok, something easier? |
| 07:54 |
Zeno` |
T4im, can you change the sleep time in that thread just to confirm things? |
| 07:54 |
Zeno` |
and anyone else as well |
| 07:54 |
kahrl |
Zeno`: #2255 |
| 07:54 |
ShadowBot |
https://github.com/minetest/minetest/issues/2255 -- Fix download URL by blha303 |
| 07:55 |
|
nrzkt joined #minetest-dev |
| 07:55 |
Zeno` |
I think that's safe to merge |
| 07:55 |
kahrl |
yep |
| 07:55 |
kahrl |
easy enough? :P |
| 07:55 |
Zeno` |
hopefully there are no side effects |
| 07:55 |
Zeno` |
lol |
| 07:56 |
Zeno` |
you'd better profile the game after you merge it though, rofl |
| 07:56 |
* Zeno` |
is certainly tired |
| 08:06 |
Krock |
tested #2256 , compiles without fails |
| 08:06 |
ShadowBot |
https://github.com/minetest/minetest/issues/2256 -- Give full breath after death by SmallJoker |
| 08:06 |
Krock |
ShadowBot, it's not an issue. it's a pull |
| 08:17 |
|
jin_xi joined #minetest-dev |
| 08:35 |
|
kilbith joined #minetest-dev |
| 08:40 |
kilbith |
hmm, the releasing is constipated and may need a laxative... |
| 08:42 |
VanessaE |
there is currently a polyp or two to be excised. |
| 09:20 |
|
crazyR joined #minetest-dev |
| 09:30 |
|
FR^2 joined #minetest-dev |
| 09:36 |
|
nrzkt left #minetest-dev |
| 10:24 |
|
ImQ009 joined #minetest-dev |
| 10:24 |
|
rubenwardy joined #minetest-dev |
| 10:24 |
rubenwardy |
#2257 |
| 10:24 |
ShadowBot |
https://github.com/minetest/minetest/issues/2257 -- Change assignment to global to warning by rubenwardy |
| 10:24 |
Krock |
rubenwardy, why not "info" log level? |
| 10:25 |
Krock |
or yeah. warning level |
| 10:25 |
rubenwardy |
The reading from global uses the warn() function |
| 10:49 |
|
est31 joined #minetest-dev |
| 11:22 |
|
Zeno` joined #minetest-dev |
| 11:36 |
|
Player_2 joined #minetest-dev |
| 11:48 |
|
ninnghazad joined #minetest-dev |
| 11:48 |
|
Krock joined #minetest-dev |
| 11:48 |
|
ninnghazad left #minetest-dev |
| 11:52 |
|
DFeniks joined #minetest-dev |
| 11:58 |
|
Kalabasa joined #minetest-dev |
| 12:05 |
Zeno` |
merging #2255 (get it out of the way) |
| 12:05 |
ShadowBot |
https://github.com/minetest/minetest/issues/2255 -- Fix download URL by blha303 |
| 12:06 |
Zeno` |
(karhl agreed to this and additionally it's a trivial doc change) |
| 12:16 |
|
kahrl_ joined #minetest-dev |
| 13:04 |
Zeno` |
What's going on with this feature freeze? |
| 13:10 |
Zeno` |
no blockers? |
| 13:10 |
Zeno` |
so... |
| 13:14 |
Zeno` |
ok, to put it more clearly: what is holding up the release of 0.4.12? |
| 13:25 |
Krock |
ping some devs |
| 13:28 |
Zeno` |
ping |
| 13:35 |
Zeno` |
bool threadSetPriority(threadid_t tid, int prio); |
| 13:35 |
Zeno` |
is prio a precentage? |
| 13:40 |
|
iqualfragile joined #minetest-dev |
| 13:49 |
|
shadowzone joined #minetest-dev |
| 13:52 |
Zeno` |
is there any way to get the thread ID? |
| 13:54 |
Zeno` |
nvm |
| 14:13 |
Krock |
Zeno`, is #2256 acceptable for you? |
| 14:13 |
ShadowBot |
https://github.com/minetest/minetest/issues/2256 -- Give full breath after death by SmallJoker |
| 14:15 |
Zeno` |
yes |
| 14:17 |
Zeno` |
I was looking at that earlier |
| 14:22 |
|
iqualfragile_ joined #minetest-dev |
| 14:40 |
|
younishd joined #minetest-dev |
| 14:56 |
|
SudoAptGetPlay joined #minetest-dev |
| 15:03 |
|
IAmRasputin joined #minetest-dev |
| 15:04 |
|
SopaXorzTaker joined #minetest-dev |
| 15:09 |
|
shadowzone joined #minetest-dev |
| 15:16 |
|
hmmmm joined #minetest-dev |
| 15:26 |
|
kilbith joined #minetest-dev |
| 16:00 |
|
nrzkt joined #minetest-dev |
| 16:01 |
|
CraigyDavi joined #minetest-dev |
| 16:15 |
|
shadowzone joined #minetest-dev |
| 16:17 |
|
PilzAdam joined #minetest-dev |
| 16:38 |
|
Zeno` joined #minetest-dev |
| 16:38 |
Zeno` |
preparing to merge #2218 |
| 16:38 |
ShadowBot |
https://github.com/minetest/minetest/issues/2218 -- Suppress 4 gcc 4.9.2 warnings in CGUITTFont.cpp by ngosang |
| 16:38 |
Zeno` |
not a bug fix, but it's trivial and fixes warnings |
| 16:45 |
|
Calinou joined #minetest-dev |
| 16:50 |
Zeno` |
hmmmm, what will it take to get 0.4.12 released? |
| 17:05 |
|
roniz joined #minetest-dev |
| 17:09 |
|
Hunterz joined #minetest-dev |
| 17:15 |
|
shadowzone joined #minetest-dev |
| 17:15 |
|
ImQ009 joined #minetest-dev |
| 17:17 |
|
rubenwardy joined #minetest-dev |
| 17:19 |
rubenwardy |
#2257 |
| 17:19 |
ShadowBot |
https://github.com/minetest/minetest/issues/2257 -- Change assignment to global to warning by rubenwardy |
| 17:22 |
Zeno` |
I think that should be merged |
| 17:24 |
|
acerspyro joined #minetest-dev |
| 17:24 |
Zeno` |
It's not an "error"... it's a warning that something might be wrong. So it should, IMO, be a warning |
| 17:24 |
rubenwardy |
These sound like a blocker: https://forum.minetest.net/viewtopic.php?f=6&t=11145 |
| 17:24 |
rubenwardy |
And yes, I agree. |
| 17:25 |
rubenwardy |
Most importantly, it shouldn't spam the chat console. |
| 17:29 |
Zeno` |
you'll probably have to debate with Tesseract ;) |
| 17:30 |
Zeno` |
I can't remember the reasoning behind making it an error in the first place |
| 17:32 |
Zeno` |
It's obviously not an error. If it was an error then it should abort |
| 17:37 |
Tesseract |
Zeno`: I made one of the warnings print to errorstream because it was espacially bad. It's a bug in all or almost all cases and easy to silence in the other ones. |
| 17:37 |
T4im |
I've seen false error reports about that already |
| 17:38 |
Zeno` |
shadowing parameters in C or C++ is almost always an error as well |
| 17:38 |
T4im |
from what I've seen you prepared a way for silencing them, but so far its not silenceable is it? |
| 17:39 |
Zeno` |
But, it's (in C or C++) a warning |
| 17:41 |
Tesseract |
T4im: No, the error that produces a error just needs a `varname = nil` line somewhere to declare that you're going o be using that global later inside a function. |
| 17:42 |
Tesseract |
T4im: There's a warning that's a little harder to silence though. It's still silencable by using rawget directly though. |
| 17:42 |
T4im |
but then testing it for nilness is kinda pointless because you know its nil |
| 17:42 |
Tesseract |
T4im: The error is for code like this: ... |
| 17:43 |
T4im |
I mean something like `if not declared then fallback() end` |
| 17:44 |
T4im |
or something like https://github.com/minetest-technic/technic/blob/master/technic/init.lua#L5 |
| 17:44 |
Zeno` |
hold the horses. If there is a way to silence them then that's further support indicating that it should be a warning and not an error |
| 17:44 |
Tesseract |
http://pastebin.ubuntu.com/10057154/ |
| 17:44 |
Tesseract |
T4im: ^ That's the only thing that's printed to errorstream and therefore the chat. |
| 17:45 |
Zeno` |
also the word "probably" |
| 17:45 |
Tesseract |
The `if not foo then` thing can be silenced by `if not rawget(_G, "thing") then`. |
| 17:46 |
Krock |
I don't like magical variables, like that _G and rawget |
| 17:46 |
Tesseract |
Zeno`: I used errorstream to indicate that it's a serious problem. It could not be a bug, but even if it isn't a bug it should be declared. |
| 17:46 |
T4im |
ah, nice.. I tried a few _G tricks, but rawget did the trick |
| 17:46 |
T4im |
krock: nothing magical about that |
| 17:47 |
Tesseract |
Really, you shouldn't use globals at all, except for the functions from the Lua libs, but we have a bit to do before that will work well. |
| 17:47 |
Zeno` |
yeah you shouldn't. But is that advice (a warning) or an error? |
| 17:47 |
T4im |
well… the fact that there is a way to "intentionally" test, while finding all accidents… lets say you can call me satisfied :) |
| 17:49 |
Tesseract |
Krock: rawget and _G aren't magical, they're just a metatable bypass function and the globals table, respectively. I'd prefer a name like "glogals", but they had to maintain compatability whe they added it and probably wanted to minimize collisions. |
| 17:49 |
|
SopaXorzTaker joined #minetest-dev |
| 17:49 |
Krock |
okay :/ |
| 17:50 |
|
shadowzone joined #minetest-dev |
| 17:51 |
Tesseract |
Zeno`: It's closer to an error than a warning since it's at least very bad style if not a bug. |
| 17:51 |
Zeno` |
it's terrible style |
| 17:54 |
Zeno` |
int main(void) { callFunction(); } (C) is probably bad style as well but it's not an error and it's not even undefined- or implementation- behaviour |
| 17:55 |
rubenwardy |
The point is that is confuses users. It's only good for new mods being created. |
| 17:56 |
|
DFeniks joined #minetest-dev |
| 17:56 |
rubenwardy |
The point is that it shouldn't spam the console. |
| 17:56 |
est31 |
^ |
| 17:56 |
rubenwardy |
It isn't an error, although it could cause errors. |
| 18:01 |
Zeno` |
"could cause errors" |
| 18:01 |
Zeno` |
that's a warning |
| 18:01 |
rubenwardy |
Exactly |
| 18:09 |
Zeno` |
we should add -Wextra -Werror to the compile options :) |
| 18:13 |
Zeno` |
sigh |
| 18:25 |
|
SopaXorzTaker joined #minetest-dev |
| 18:25 |
|
MinetestForFun joined #minetest-dev |
| 18:27 |
|
shadowzone joined #minetest-dev |
| 18:29 |
|
Robert_Zenz joined #minetest-dev |
| 18:35 |
|
ImQ009 joined #minetest-dev |
| 18:45 |
|
nrzkt joined #minetest-dev |
| 18:54 |
puhfa |
hey guys, is max_hear_distance in minetest.sound_play supposed to work? |
| 18:55 |
puhfa |
i used 256 as max_hear_distance and 64 for gain, the sound plays globally for everyone at maximum volume |
| 18:55 |
Calinou |
64 gain?! |
| 18:55 |
puhfa |
well it was a loud noise |
| 18:55 |
Calinou |
gain should usually not be above 1, and certainly not above 2 |
| 18:56 |
puhfa |
documentation was not too verbose on that aspect :| |
| 18:56 |
puhfa |
but thanks, thats probably messing it up then |
| 19:03 |
|
Calinou joined #minetest-dev |
| 19:47 |
|
Robert_Zenz joined #minetest-dev |
| 19:50 |
Krock |
Tesseract, what do you think about #2256? I guess that's a bugfix and should be merged soon ;) |
| 19:50 |
ShadowBot |
https://github.com/minetest/minetest/issues/2256 -- Give full breath after death by SmallJoker |
| 19:54 |
|
Miner_48er joined #minetest-dev |
| 20:09 |
|
AnotherBrick joined #minetest-dev |
| 20:09 |
Tesseract |
Others: #2245 and ^ O.K? |
| 20:09 |
ShadowBot |
https://github.com/minetest/minetest/issues/2245 -- Fix dying of lava causes repeated death by gregorycu |
| 20:17 |
|
DFeniks joined #minetest-dev |
| 20:19 |
VanessaE |
maybe "dieing in lava" ? |
| 20:19 |
VanessaE |
I'm pretty sure no one's applying a color to lava. :P |
| 20:20 |
crazyR |
does anyone have a rough idea how long it will be till the lighting issues are fixed with mesh nodes? |
| 20:21 |
VanessaE |
^^^^ especially wield/in-hand mesges |
| 20:21 |
VanessaE |
meshes* |
| 20:22 |
est31 |
why, when I have a pick in my hand, I dont see it when its dark |
| 20:22 |
est31 |
and when there is light, I see the pick |
| 20:23 |
est31 |
its weird though |
| 20:23 |
est31 |
lights in MT are bad |
| 20:24 |
est31 |
eg when I build the whole ceiling full with homedecor glowlights, its still worse than placing the glowlight next to the node |
| 20:25 |
est31 |
in RL, there is no "maximum light" |
| 20:26 |
est31 |
crazyR: what are the other issues? |
| 20:26 |
|
Calinou joined #minetest-dev |
| 20:28 |
crazyR |
other issues? |
| 20:29 |
VanessaE |
#2150 |
| 20:29 |
ShadowBot |
https://github.com/minetest/minetest/issues/2150 -- Meshnode ligthing issues create unwanted patterns |
| 20:29 |
VanessaE |
may as well properly reference it |
| 20:30 |
est31 |
do you know which commit introduced this |
| 20:30 |
est31 |
if not I gonna bisect |
| 20:30 |
VanessaE |
no, I haven't had a chance to bisect it |
| 20:30 |
VanessaE |
but it's probably been there since mesh nodes were available |
| 20:30 |
est31 |
ok then /me does |
| 20:30 |
VanessaE |
seems to me the solution is simple though: |
| 20:30 |
est31 |
there are before/ after images |
| 20:30 |
VanessaE |
just give each vertex on a poly the same lighting value |
| 20:30 |
est31 |
so there should be some before? |
| 20:31 |
|
T4im joined #minetest-dev |
| 20:31 |
VanessaE |
whatever value that is, give them all the same one |
| 20:31 |
est31 |
T4im might be interested in discussion bout #2150 |
| 20:31 |
ShadowBot |
https://github.com/minetest/minetest/issues/2150 -- Meshnode ligthing issues create unwanted patterns |
| 20:31 |
VanessaE |
you'll get flat lighting, but it'll look far better than a gradient across a node, then another across its neighbor, repeat ad nauseum. |
| 20:31 |
T4im |
yea :) |
| 20:31 |
VanessaE |
est31: the "before" images are nodebox-based objects |
| 20:32 |
VanessaE |
so invalid as far as lighting on meshes is concerned. |
| 20:32 |
est31 |
ah ok |
| 20:32 |
est31 |
any source to read about the difference between nodebox and mesh? |
| 20:33 |
VanessaE |
idk exactly - there were a couple commits back around the middle of last year that convert all nodeboxes into irrlicht meshes internally |
| 20:33 |
VanessaE |
but that's not the same thing |
| 20:38 |
VanessaE |
and then after that, if I remember right, there was a fix to the lighting of nodeboxes to at least get the side-shading right |
| 20:38 |
VanessaE |
but that won't apply to a mesh node |
| 20:43 |
kahrl_ |
can #2150 be reproduced with slope_test? |
| 20:43 |
ShadowBot |
https://github.com/minetest/minetest/issues/2150 -- Meshnode ligthing issues create unwanted patterns |
| 20:43 |
kahrl |
I tried it and it doesn't happen |
| 20:44 |
VanessaE |
kahrl: try rotating some nodes |
| 20:44 |
VanessaE |
I think that's what triggers the lighting bugs |
| 20:44 |
kahrl |
well they are rotated when I place them |
| 20:44 |
kahrl |
but I'll try the screwdriver |
| 20:45 |
VanessaE |
the lighting is rotated with the nodes instead of being applied after |
| 20:46 |
kahrl |
ok yeah, I see it now |
| 20:46 |
VanessaE |
might be a lighting glitch in the models, but in blender they look right |
| 20:46 |
kahrl |
perhaps the issue is, once again, normals? |
| 20:46 |
VanessaE |
could be |
| 20:46 |
kahrl |
in particular that they aren't rotated with the mesh? |
| 20:47 |
VanessaE |
that's what I was thinking |
| 20:49 |
VanessaE |
a really bad one is pipeworks' spigot mesh |
| 20:49 |
VanessaE |
for lighting I mean |
| 20:49 |
VanessaE |
flip that one upside down, and what now faces upward will have the worst shadow on it you ever saw :) |
| 20:50 |
VanessaE |
(or it did when I last checked) |
| 20:51 |
VanessaE |
mm, not so much anymore |
| 20:55 |
kahrl |
how many vertices are there per "corner" of the mesh? |
| 20:56 |
kahrl |
one (aka one arbitrary-ish normal) or one per incident face (with a different normal for each face)? |
| 20:56 |
VanessaE |
well for a basic slope there should only be one |
| 20:56 |
VanessaE |
(I started with the standard Blender cube, moved one edge, removed doubles, leaving me with a prism) |
| 20:58 |
kahrl |
if you want different normals you need different vertices |
| 20:59 |
VanessaE |
hm. well I'm only familiar with how to make the model :) |
| 20:59 |
kahrl |
I think if you use just one vertex, blender calculates a "mean" normal from the normals of the incident faces, which isn't really helpful in any way |
| 21:00 |
kahrl |
not at sharp corners, at least |
| 21:01 |
VanessaE |
maybe my models are just broken then? |
| 21:03 |
kahrl |
could be |
| 21:03 |
kahrl |
I don't know enough blender to tell you how to fix them :/ |
| 21:03 |
|
shadowzone joined #minetest-dev |
| 21:03 |
VanessaE |
well no, that can't be it |
| 21:03 |
VanessaE |
I jsut now checked |
| 21:03 |
VanessaE |
just* |
| 21:04 |
VanessaE |
in my original slope_test models where the UV-maps call for custom textures, the tiling/lighting is perfect. |
| 21:04 |
VanessaE |
in the versions where the only thing I did was change the UV maps so that default textures could be wrapped around them, the lighting is bugged |
| 21:05 |
VanessaE |
technic's models are 1:1 copies of slope_test's "_onetexture" models (the ones UV-mapped to use default textures) |
| 21:05 |
kahrl |
perhaps you removed doubles in the process of changing the UV coordinates? |
| 21:05 |
VanessaE |
with some new ones where I just loaded the model and did a scale-Z "-1" to flip it over, or similar, and rotated the UVs |
| 21:06 |
VanessaE |
nope, pretty sure I didn't change the models themselves at all |
| 21:06 |
kahrl |
hmm, ok |
| 21:06 |
VanessaE |
I would have avoided that, for fear of creating models that didn't tile next to each other perfectly. |
| 21:06 |
kahrl |
it's of course also possible that irrlicht's recalculateNormals is bugged |
| 21:08 |
VanessaE |
http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/Screenshot%20-%2002042015%20-%2004%3a10%3a24%20PM.png |
| 21:08 |
VanessaE |
the standard ones are wood, _onetexture (same as technic) is the stone version |
| 21:12 |
kilbith |
https://lut.im/SKNSikyb/fmyJIj9t |
| 21:18 |
kahrl |
perhaps instead of calling recalculateNormals, the existing normals should simply be multiplied by the inverse transpose of the transformation matrix |
| 21:18 |
kahrl |
(since the transformation is just a rotation, the inverse transpose is just the matrix itself) |
| 21:45 |
VanessaE |
kahrl: ok, can you clear something up for me? |
| 21:45 |
VanessaE |
UVs are supposed to ONLY be for position/size/rotation of the textures on a poly, right? they're not supposed to affect lighting et al? |
| 21:46 |
VanessaE |
(that's where normals come into play?) |
| 21:46 |
kahrl |
that is correct, afaik |
| 21:46 |
VanessaE |
ok |
| 21:46 |
VanessaE |
I'm sitting here busting my brain trying to figure out how my models could be screwed up, if they in fact are. |
| 21:46 |
kahrl |
(unless you also use a bump map or similar, mapped by uv coordinates, of course) |
| 21:46 |
VanessaE |
right, which isn't the case here. |
| 21:48 |
kahrl |
I would try to figure it out if I knew how to use blender :/ |
| 21:48 |
kahrl |
RBA would probably know |
| 21:48 |
VanessaE |
yeah |
| 21:48 |
VanessaE |
he'll probably just point to lighting being "faked" in some manner |
| 21:49 |
kahrl |
ugh, I can't even install blender because the specific deps it wants conflict with all the other things I've installed |
| 21:49 |
VanessaE |
heh |
| 21:50 |
kahrl |
I used to have it installed, then this deps problem appeared and since then I don't have it anymore |
| 21:50 |
kahrl |
though it might be fixed by now, no dice |
| 21:50 |
kahrl |
thought* |
| 21:52 |
|
shadowzone joined #minetest-dev |
| 21:54 |
|
shadowzone joined #minetest-dev |
| 21:59 |
|
acerspyro joined #minetest-dev |
| 22:13 |
|
FR^2 joined #minetest-dev |
| 22:40 |
|
kilbith joined #minetest-dev |
| 22:46 |
|
shadowzone joined #minetest-dev |
| 22:52 |
|
Megaf joined #minetest-dev |
| 23:02 |
VanessaE |
kahrl: you see that conversation in #minetest ? |
| 23:03 |
|
OldCoder joined #minetest-dev |
| 23:04 |
kahrl |
VanessaE: yes |
| 23:04 |
kahrl |
were there any conclusions yet? it was a bit chaotic |
| 23:06 |
VanessaE |
checking now. |
| 23:06 |
acerspyro |
Maybe splitting edges won't do it, or maybe it will, since it's not the same UV island |
| 23:07 |
VanessaE |
nope, no good. |
| 23:25 |
|
roniz joined #minetest-dev |
