| Time |
Nick |
Message |
| 00:11 |
|
khonkhortisan joined #minetest-dev |
| 00:25 |
|
Mallot1 joined #minetest-dev |
| 01:15 |
|
diemartin joined #minetest-dev |
| 01:45 |
|
dexter0 joined #minetest-dev |
| 01:53 |
|
ch98 joined #minetest-dev |
| 02:21 |
|
dexter0 joined #minetest-dev |
| 02:23 |
|
dexter0 joined #minetest-dev |
| 02:40 |
|
arsdragonfly joined #minetest-dev |
| 03:01 |
|
kaeza joined #minetest-dev |
| 03:02 |
hmmmmm |
i updated the TODO http://dev.minetest.net/TODO |
| 03:03 |
hmmmmm |
why does it seem like i get more and stuff TODO, never less |
| 03:30 |
|
AllegedlyDead joined #minetest-dev |
| 03:31 |
|
Neological joined #minetest-dev |
| 03:37 |
|
AllegedlyDead joined #minetest-dev |
| 03:44 |
|
D-Man joined #minetest-dev |
| 03:44 |
D-Man |
you guys should add a portion of the game where the user can create a server while using the game, and/or local servers people on the same wifi can play. |
| 03:46 |
kaeza |
? |
| 04:06 |
ShadowNinja |
Isn't there a pull request for mod .confs? I have use for it in three mods now... |
| 04:15 |
ShadowNinja |
Yippe, down to 66 pulls... |
| 04:27 |
ShadowNinja |
https://github.com/minetest/minetest/pull/484 I could try to split that out if you want. |
| 04:31 |
|
neko259 joined #minetest-dev |
| 04:47 |
|
OWNSyouAll_DESKT joined #minetest-dev |
| 05:06 |
|
ssieb joined #minetest-dev |
| 05:14 |
|
Anchakor_ joined #minetest-dev |
| 05:45 |
|
Taoki[mobile] joined #minetest-dev |
| 06:12 |
|
darkrose joined #minetest-dev |
| 06:12 |
|
darkrose joined #minetest-dev |
| 06:24 |
|
salamanderrake joined #minetest-dev |
| 06:33 |
hmmmmm |
ugh |
| 06:52 |
|
salamanderrake joined #minetest-dev |
| 07:30 |
|
Kray joined #minetest-dev |
| 07:33 |
|
arsdragonfly joined #minetest-dev |
| 07:37 |
|
Weedy joined #minetest-dev |
| 07:37 |
|
ch98 joined #minetest-dev |
| 07:37 |
|
khonkhortisan joined #minetest-dev |
| 07:37 |
|
hmmmmm joined #minetest-dev |
| 07:37 |
|
BrandonReese joined #minetest-dev |
| 07:37 |
|
drizz_ joined #minetest-dev |
| 07:38 |
|
mrtux joined #minetest-dev |
| 07:40 |
|
Weedy joined #minetest-dev |
| 07:47 |
|
Calinou joined #minetest-dev |
| 08:04 |
|
Jordach joined #minetest-dev |
| 08:24 |
|
mrtux joined #minetest-dev |
| 08:29 |
|
VanessaE joined #minetest-dev |
| 08:55 |
|
darkrose joined #minetest-dev |
| 08:55 |
|
darkrose joined #minetest-dev |
| 09:02 |
|
darkrose joined #minetest-dev |
| 09:02 |
|
darkrose joined #minetest-dev |
| 09:36 |
|
ImQ009 joined #minetest-dev |
| 10:19 |
Calinou |
http://forum.minetest.net/viewtopic.php?pid=95633#p95633 |
| 10:19 |
Calinou |
why every 5.3 seconds? |
| 10:19 |
Calinou |
would increasing it increase performance? |
| 10:19 |
Calinou |
or decrease it? |
| 10:33 |
Jordach |
i'd set it to 180 seconds |
| 10:40 |
|
Weedy_lappy joined #minetest-dev |
| 10:40 |
|
Weedy_lappy joined #minetest-dev |
| 10:41 |
|
proller joined #minetest-dev |
| 10:58 |
|
Calinou joined #minetest-dev |
| 11:10 |
|
PilzAdam joined #minetest-dev |
| 11:15 |
PilzAdam |
"* Add block tinting (grass, water, sky, etc.) (for biomes)" <- no way, I hate this in Minecraft |
| 11:15 |
Exio |
make it a setting |
| 11:22 |
|
Zeg9 joined #minetest-dev |
| 11:25 |
Jordach |
make it a settting |
| 11:25 |
PilzAdam |
call it "mc = <bool>" |
| 11:28 |
arsdragonfly |
:set compatible |
| 11:28 |
arsdragonfly |
:P |
| 11:28 |
Zeg9 |
there should be a color paramtype2 |
| 11:29 |
Zeg9 |
if only I wasn't lazy |
| 11:48 |
|
PilzAdam joined #minetest-dev |
| 11:49 |
|
proller joined #minetest-dev |
| 11:54 |
|
iqualfragile joined #minetest-dev |
| 12:08 |
|
ImNotQ009 joined #minetest-dev |
| 12:11 |
|
PilzAdam joined #minetest-dev |
| 12:46 |
|
ssieb joined #minetest-dev |
| 13:49 |
|
NakedFury joined #minetest-dev |
| 14:11 |
|
arsdragonfly|pho joined #minetest-dev |
| 14:38 |
|
Tom-s joined #minetest-dev |
| 14:49 |
|
arsdragonfly1 joined #minetest-dev |
| 14:51 |
|
arsdragonfly1 left #minetest-dev |
| 15:21 |
|
OWNSyouAll_DESKT joined #minetest-dev |
| 15:29 |
|
hmmmm joined #minetest-dev |
| 15:33 |
|
Tom-s left #minetest-dev |
| 15:48 |
|
toabi joined #minetest-dev |
| 15:52 |
|
Calinou joined #minetest-dev |
| 15:52 |
|
dexter0 joined #minetest-dev |
| 16:10 |
|
Jordach joined #minetest-dev |
| 16:15 |
|
BrandonReese joined #minetest-dev |
| 16:22 |
|
proller joined #minetest-dev |
| 16:24 |
|
dexter0 joined #minetest-dev |
| 16:40 |
|
neko259 joined #minetest-dev |
| 17:18 |
|
proller joined #minetest-dev |
| 17:23 |
hmmmm |
having a bit of a lighting problem |
| 17:24 |
hmmmm |
doesn't seem like the vmanip's contents get messed with in any way at all after finishBlockMake... can't really figure it out |
| 17:24 |
hmmmm |
and this is with a single thread, so i can only imagine how screwed up multithread generation would be |
| 17:25 |
hmmmm |
in theory, there's absolutely no reason why the on_generate lighting calculation should be different from the one in makechunk |
| 17:26 |
hmmmm |
everything starts off zeroed out, lighting gets calculated, then it's envlocked, the vmanip is written back and some mapblock things are set, but all that is irrelevant because everything happens within the same exact envlock |
| 17:28 |
hmmmm |
if i disable lighting and merely call calc_lighting in on_generate, the entire thing gets lit up; if i zero it out beforehand with setLighting, i get dark shadows at block boundaries |
| 17:28 |
hmmmm |
there is no reason why this should be happening |
| 17:28 |
hmmmm |
freaking toughest bug i've wrestled with in a while |
| 17:30 |
hmmmm |
looking at the games directory just gave me an idea... might be the other mods |
| 17:30 |
hmmmm |
shit |
| 17:31 |
hmmmm |
let's see without the flowers mod |
| 17:33 |
hmmmm |
which isn't the problem |
| 17:33 |
|
ssieb joined #minetest-dev |
| 17:34 |
|
sapier joined #minetest-dev |
| 17:37 |
|
RealBadAngel joined #minetest-dev |
| 17:37 |
RealBadAngel |
hi all |
| 17:39 |
sfan5 |
hi |
| 17:44 |
hmmmm |
oh fuckme |
| 17:44 |
khonkhortisan |
"this shouldn't be happening" one of the well-known phrases programmers say |
| 17:44 |
hmmmm |
:( |
| 17:44 |
hmmmm |
wanna know what the problem is |
| 17:44 |
hmmmm |
i only write data modified in lua to the vm on write_chunk |
| 17:45 |
hmmmm |
so when i call calc_lighting before write_chunk, it calculates it with everything as an air node |
| 17:45 |
hmmmm |
the same principle would affect set_lighting and update_liquids as well |
| 17:45 |
hmmmm |
this was a pretty big showstopping bug |
| 17:47 |
hmmmm |
hmmm, unrelated, but i wonder how to get rid of those dumb "star destroyer" shapes in 3d noise terrain |
| 17:49 |
sapier |
is there any reason for "merge lua main menu" not beeing on todo list? |
| 17:58 |
celeron55 |
is beeing somehow related to bees? 8) |
| 17:58 |
hmmmm |
sapier, what do you mean? http://dev.minetest.net/TODO#Things_to_do_right_away |
| 17:58 |
sapier |
oh sorry |
| 17:58 |
hmmmm |
lol i just added it |
| 17:59 |
sapier |
argh :-) |
| 17:59 |
hmmmm |
alright so here's how i'm going to do it |
| 18:01 |
hmmmm |
i think i'm going to separate some api: there's going to be a emerged_minp, emerged_maxp = vm:emerge(p1, p2); *then* data = vm:read_data(); which is a simple copy of the vm data contents to a lua table, then vm:write_data(data) writes your data back to the vm, but then you have to call vm:commit_data(); in order to vm->blitBackAll(); |
| 18:03 |
hmmmm |
and there's no breakage because i made the wise decision of not pushing any of this to upstream individually |
| 18:04 |
sapier |
sounds reasonable ... I'd prefere if you not called it "write" as nothing is written in this step |
| 18:04 |
sapier |
what about fetch/pull? |
| 18:04 |
hmmmm |
get set |
| 18:04 |
sapier |
yes |
| 18:07 |
RealBadAngel |
guys, when next freeze is planned? |
| 18:08 |
celeron55 |
i guess it's not planned |
| 18:09 |
RealBadAngel |
i would like to pull bumpmapping code this weekend, thats why im askin |
| 18:10 |
RealBadAngel |
ive tested it for over month when i was cut off (played offline and legacy world) so i think its tested enough already :) |
| 18:11 |
RealBadAngel |
one thing i must say i felt a bit weird when i downloaded latest code without bumpmapping and tried it |
| 18:12 |
RealBadAngel |
it really changes the feel |
| 18:12 |
hmmmm |
i wanted an "early" release of the next version, because of the massive performance improvements, but i guess it's not happening |
| 18:13 |
celeron55 |
hmmmm: it's mostly up to you, really |
| 18:13 |
hmmmm |
people expect big things |
| 18:13 |
hmmmm |
but they shouldn't |
| 18:13 |
celeron55 |
no they don't |
| 18:14 |
hmmmm |
there are at least quite a couple who *do*, i know this for a fact |
| 18:14 |
celeron55 |
and even if they do, the only way to make them not is to stop following the imaginative expectations |
| 18:14 |
hmmmm |
then they cry about how nothing changes in minetest and it's all worthless |
| 18:14 |
RealBadAngel |
whinners will always do so |
| 18:14 |
hmmmm |
that one guy pops into my mind in particular..... who was that.. he quit coming around because he was buttravaged |
| 18:14 |
hmmmm |
ragequit |
| 18:15 |
celeron55 |
well ask yourself: even if you work more, will you finish something that looks like a big change in their eyes? |
| 18:15 |
celeron55 |
i guess you'll simply just work more on things that they don't see |
| 18:15 |
hmmmm |
but he was basically saying that engine development is "worthless" because it's "good enough" at this point |
| 18:15 |
hmmmm |
i told him to get fucked basically |
| 18:16 |
RealBadAngel |
he was obviously wrong and we know it |
| 18:16 |
hmmmm |
i have a feeling you guys know who i'm talking about but i forget his name |
| 18:16 |
sapier |
"nothing changed"? imho even if there is not a single feature added but lots of critical bugs removed or performance increased is worth a release |
| 18:17 |
VanessaE |
hmmmm: prestidigitator? |
| 18:17 |
celeron55 |
i've never heard that discussion |
| 18:17 |
hmmmm |
RealBadAngel, yeah of course he was wrong, but the thing is, he's somewhat representative of the way other casuals feel about minetest development who have no idea what's actually going on |
| 18:17 |
hmmmm |
no, not prestidigitator |
| 18:17 |
VanessaE |
hrm, dunno then |
| 18:17 |
hmmmm |
he wasn't a developer type |
| 18:17 |
RealBadAngel |
this one was a really strange one |
| 18:18 |
hmmmm |
it wasn't mauvbic, i'm pretty sure... |
| 18:18 |
RealBadAngel |
produced really weird code, psedo java style |
| 18:18 |
hmmmm |
oh, prestidigitator? yeah |
| 18:18 |
hmmmm |
he's a total java fanboy |
| 18:18 |
celeron55 |
well actually whether MT is good enough completely depends on what one wants to do with it |
| 18:18 |
VanessaE |
can't remember who then |
| 18:18 |
sapier |
it's not important who said what just looking for big changes is a bogus aim |
| 18:18 |
hmmmm |
meh. if i remember i'll say it |
| 18:19 |
RealBadAngel |
not important really |
| 18:19 |
celeron55 |
anyway, releasing about now would be a very nice move towards more frequent releases |
| 18:19 |
RealBadAngel |
what is important, project like this is never finished |
| 18:19 |
celeron55 |
i would approve such highly |
| 18:19 |
hmmmm |
me too |
| 18:19 |
hmmmm |
but i have a boatload of features that i know lots of people would love |
| 18:19 |
hmmmm |
same with RBA as well |
| 18:19 |
RealBadAngel |
could we make it with bumpmapping added? |
| 18:20 |
celeron55 |
why does it matter? you'll be developing them in no time anyway and they won't be really delayed at all |
| 18:20 |
hmmmm |
because he's been waiting since 0.4.6 for this |
| 18:20 |
sapier |
imho if we release now we shouldn't add any big feature not already added yet |
| 18:20 |
celeron55 |
think about it |
| 18:20 |
RealBadAngel |
code is over 1 month old |
| 18:20 |
celeron55 |
it's not the version number that matters |
| 18:20 |
celeron55 |
it's time that matters |
| 18:20 |
RealBadAngel |
no point to keep it away |
| 18:20 |
hmmmm |
and as for me, this is sort of a complement to schematic decorations, and if there were a split in between the two, people would start abusing them too much |
| 18:21 |
hmmmm |
also |
| 18:21 |
sapier |
rba how many ppl have tested it? |
| 18:21 |
hmmmm |
different versions do matter, because a lot of people do lots of stuff for releases |
| 18:21 |
hmmmm |
they have to update distro repositories etc. |
| 18:21 |
celeron55 |
hmmmm: well, a chance of people abusing an incomplete API is a real reason to delay a release |
| 18:21 |
RealBadAngel |
many, code is aviable for download for all this time |
| 18:21 |
celeron55 |
hmmmm: nothing else that you've said is |
| 18:21 |
RealBadAngel |
and more, there are already 3 texture packs that use it |
| 18:22 |
sapier |
beeing available doesn't say anything ;-) |
| 18:22 |
RealBadAngel |
Haven, HDX and Sphax's |
| 18:22 |
sapier |
ok so at least some test |
| 18:23 |
RealBadAngel |
also theres script to produce normal maps for any texture pack out there |
| 18:23 |
VanessaE |
RealBadAngel: that reminds me, I have an update for you for that |
| 18:23 |
RealBadAngel |
the script? |
| 18:23 |
VanessaE |
yeha |
| 18:24 |
VanessaE |
http://digitalaudioconcepts.com/vanessa/hobbies/minetest/generate-texture-normals.sh |
| 18:24 |
sapier |
I guess we should really rethink if "merge window" concept wouldn't be an option |
| 18:24 |
VanessaE |
it's multithreaded now thanks to xargs. |
| 18:25 |
RealBadAngel |
sapier: http://imgur.com/a/Eq09o#0 |
| 18:25 |
RealBadAngel |
take a look |
| 18:26 |
sapier |
I don't have any concerns about it beeing worth added, it's great! just adding big features right before a release .... ;-/ |
| 18:27 |
RealBadAngel |
it was ready before 0.4.7 |
| 18:27 |
khonkhortisan |
that image has more bump mapping than color |
| 18:27 |
RealBadAngel |
i was waitint to test it more |
| 18:27 |
sapier |
if there's no quick release to happen I sugges adding all those features as soon as possible and do bugfixing until release |
| 18:28 |
RealBadAngel |
i just need to check if files i modified were touched lately |
| 18:29 |
khonkhortisan |
Does bump mapping work correctly with facedir? - if I rotate a node 180° on the front face, will the lighting be reversed? |
| 18:29 |
sapier |
you should rebase it ;-) |
| 18:29 |
RealBadAngel |
bump mapping has nothing to do with facedir |
| 18:30 |
VanessaE |
RealBadAngel: maybe he means the current lighting bug where lighting rotates with facedir. |
| 18:30 |
RealBadAngel |
ah ah |
| 18:30 |
RealBadAngel |
i already fixed that, will pull it soon also |
| 18:31 |
RealBadAngel |
sync to current tree is all i need |
| 18:44 |
|
Calinou joined #minetest-dev |
| 19:16 |
PilzAdam |
RealBadAngel, side note: Taoki wants to talk with you about skydome |
| 19:19 |
|
kaeza joined #minetest-dev |
| 19:19 |
|
proller joined #minetest-dev |
| 19:21 |
Taoki |
RealBadAngel: Was mostly curious if you're still working on the skydome. I'm still very unsure of the concept itself, and if it involves a sphere mesh following the player's origin I disagree with the idea (for upstream, of course any optional mod is ok) |
| 19:22 |
Taoki |
If anyone wants a skydome, the only way I'd personally vote for and consider ok is a way in the code to automatically generate the mapping (cubemap or spheremap) and give the sky an infinite distance (simply map it to the "infinite" space) |
| 19:24 |
VanessaE |
I thought the latter was the plan anyway? |
| 19:25 |
Taoki |
But yeah. From my experience at least, the method of having an inside-out textured mesh follow the player is the most hacky and bad way to do a sky. Wouldn't wanna see anyone working hard on doing something in a broken way too |
| 19:25 |
VanessaE |
but there were possible plans to make the ecliptic variable based on the player's Z coordinate also |
| 19:26 |
Taoki |
VanessaE: Not sure how possible it is with Irrlicht. But the right way is ti somply map the texture to the cackground (in a way that considers view angle) and deform it in such a way so it's a sphere / cube map |
| 19:26 |
Taoki |
I'd be tempted to go with a cubemap sky, since that's a lot simpler. But in that case it's harder to animate layers over it, such as the red horrizon color at sunset. |
| 19:27 |
Taoki |
Personally, I'd say the current sky system is good in essence. Just needs improvements |
| 19:27 |
Taoki |
But as RBA did prove, being able to add textures to the sky is very useful |
| 19:27 |
VanessaE |
quite so |
| 19:27 |
celeron55 |
i have a branch that implements a basic per-player skybox lua interface |
| 19:28 |
Taoki |
I think most importantly, the sun and moon should be possible to texture. For a while I thought it already is... I was pretty sad to hear the sun and moon textures are code-generated |
| 19:28 |
Taoki |
celeron55: Does it use the "inside-out mesh following the player" approach? |
| 19:28 |
celeron55 |
https://github.com/celeron55/minetest/tree/set_sky |
| 19:28 |
celeron55 |
Taoki: of course not |
| 19:28 |
celeron55 |
who would do anything like that |
| 19:28 |
Taoki |
Good then :) And that sounds like a good idea (your branch) |
| 19:29 |
Jordach |
what does the set_sky branch do specially? |
| 19:29 |
Taoki |
Any estimation to when that branch will be in? I'd really love to see it |
| 19:29 |
Taoki |
celeron55: Also, don't kill me for even remotely suggesting something that Minecraft also has (and therefore "copying it" :P ). But I think this would be very worth considering: http://forum.minetest.net/viewtopic.php?id=6375 |
| 19:30 |
Taoki |
The screenshot comparison I added in the first post speaks a lot I think |
| 19:30 |
|
Miner_48er joined #minetest-dev |
| 19:30 |
celeron55 |
i implemented it because i wanted to try to make this: http://c55.me/random/2013-05/screenshot_1726656136.png http://c55.me/random/2013-05/screenshot_1726683685.png |
| 19:31 |
celeron55 |
there's no intention from my part for putting that in; it's up to others |
| 19:32 |
Taoki |
ok. And I like that (your screenshots) |
| 19:32 |
celeron55 |
that's partly the reason i wanted to add in the singlenode mapgen too 8) |
| 19:33 |
Taoki |
What I'd really love to see regarding a Lua API for the sky though, in a way to set any planets and lights at any hour. So you can specify a "sky planet" as a texture, and a position + amount / color of light it emits at any hour |
| 19:33 |
VanessaE |
that volumetric colored fog looks beautiful. |
| 19:33 |
Taoki |
Similar to how Second Life has the Windlight editor for its sky |
| 19:34 |
Taoki |
VanessaE: Yes. That's something that would be lovely for MT too |
| 19:34 |
Taoki |
More likely with shaders though |
| 19:34 |
PilzAdam |
https://github.com/PilzAdam/minetest/commit/7af479cba466f801c5cb648c8a449877957cb723 |
| 19:34 |
VanessaE |
I don't think shaders are needed, but what do I know? |
| 19:35 |
VanessaE |
(unless piping the fog through a shader will result in better performance, of course) |
| 19:35 |
celeron55 |
eh what |
| 19:35 |
celeron55 |
so where's the volumetric fog you are talking about |
| 19:35 |
PilzAdam |
celeron55, if you are still interested: it turned out that there is no second leak in VBO, you just have to decrease client_unload_unused_data_timeout |
| 19:35 |
celeron55 |
is this once again some funky technical term that people have started using without any reality |
| 19:35 |
Taoki |
PilzAdam: Looks good to me |
| 19:36 |
Taoki |
celeron55: In Minecraft, fog color depends on sun and moon directionally. If the sun is setting for instance: The fog around the sun is orange, while behind the sun (where the moon is rising) it's a plale white |
| 19:36 |
Taoki |
In other words, fog matches horrizon + sun / moon color in any direction and position |
| 19:36 |
celeron55 |
Taoki: none of your screenshots show the fog being different color at different position |
| 19:36 |
Taoki |
Which looks very beautiful and immersive |
| 19:37 |
celeron55 |
the fog is continuously the same color in each of them |
| 19:37 |
Taoki |
celeron55: They're screenshots so I didn't turn aroun 180*. But trust me, it works that way |
| 19:37 |
Taoki |
I checked |
| 19:37 |
Taoki |
If you look in one direction in Minecraft when the sun is setting, for is orange. If you turn around 180*, it's pale blue |
| 19:37 |
celeron55 |
i still think it just sets the fog color based on what you're mainly looking at |
| 19:37 |
celeron55 |
that's not anything more fancy than just dynamically adjusting the fog color |
| 19:38 |
Taoki |
Not sure. I think I can see the transition, but I never used a field of view wide enough to cover an 180* area |
| 19:38 |
celeron55 |
in any case, it's not volumetric fog |
| 19:38 |
celeron55 |
even if it's actually how you explain it, that's just roughly a simple shader line |
| 19:39 |
* Taoki |
looks closely at the screenshots, trying to figure out if there is a color fading of the fog or it's all based on where you look at and always the same color at one time |
| 19:39 |
celeron55 |
i hate it when people think good-looking stuff requires some fancy technology |
| 19:39 |
celeron55 |
it just doesn't make things go forward at all |
| 19:39 |
VanessaE |
"fancy technology"? |
| 19:40 |
VanessaE |
(shaders are still considered "fancy"?) |
| 19:40 |
Taoki |
http://i43.tinypic.com/fnzq0l.png I think the fog riht around the edges is darker and more blue than in the center (where the moon is). Can't quite tell |
| 19:40 |
Taoki |
There's likely some gradient there. But to see it all at once it would take a big FOV |
| 19:40 |
celeron55 |
VanessaE: yeah sure, thanks for not reading what i said |
| 19:40 |
RealBadAngel |
Taoki: sky sphere is centered always, its a different piece of the scene than world |
| 19:41 |
VanessaE |
Taoki: definitely a different amount of saturation at the moon versus the horizon, but the hue seems to be the same. |
| 19:41 |
Taoki |
RealBadAngel: ok. Does it still require a mesh file though? And does it have unlimited distance? |
| 19:41 |
VanessaE |
celeron55: stop being an asshole. |
| 19:41 |
VanessaE |
If I missed something, next time try saying "actually I meant X". |
| 19:41 |
RealBadAngel |
mesh and unlimited (but for testing purposes i limited it) |
| 19:42 |
celeron55 |
VanessaE: frankly i haven't seen any benefit from not being an asshole towards you |
| 19:42 |
Taoki |
RealBadAngel: ok. The only way I'd personally consider it correct is finding a way to map it in the code. Sky meshes are really bad IMO, especially when there's a way to generate it more easily |
| 19:42 |
Taoki |
It should be possible to generat ea hemisphere and texture it with a simple code. That would also allow it to have a geometry LOD |
| 19:43 |
RealBadAngel |
sky model requires moon, sun, star sky, and blue map for dusk to dawn transitions |
| 19:43 |
VanessaE |
celeron55: your being an asshole is precisely what's turned me off to the idea of even trying to contribute to (as in, writing more code for) the engine or the main game. |
| 19:43 |
Taoki |
RealBadAngel: Yes, the idea is prolly good. But doing it with meshes sounds wrong. It should be possible to do it in code |
| 19:43 |
VanessaE |
whether you see previous contributions as a benefit, I don't know, but at least others do. |
| 19:44 |
Taoki |
RealBadAngel: Personally though, I like the current sky system. Would love some way to improve that instead, so sphere maps won't be needed |
| 19:44 |
celeron55 |
VanessaE: when i try to help you, you just consider it being an asshole too; i've simply stopped trying by now |
| 19:44 |
RealBadAngel |
Taoki, meshes are basic of the engine, whats wrong with them? |
| 19:44 |
RealBadAngel |
also using meshes make it moddable |
| 19:44 |
Taoki |
RealBadAngel: True. It's only for the sky that I find them wrong. I think better formulas for the existing skybox would be bette |
| 19:45 |
Taoki |
I'd love to see it moddable. But if possible, with the current system mostly |
| 19:45 |
RealBadAngel |
existing method is drawing pixels and boxes |
| 19:45 |
RealBadAngel |
which is not moddable at all |
| 19:45 |
VanessaE |
Taoki: you're thinking more of a mathematically-defined sphere then? |
| 19:45 |
Taoki |
I know. That's what I'd like to see changed |
| 19:45 |
Taoki |
VanessaE: Yes, if we really must go for a sphere map |
| 19:45 |
RealBadAngel |
wait a bit for my model |
| 19:45 |
PilzAdam |
RealBadAngel, only the textures should be modable, the sky itself not |
| 19:46 |
RealBadAngel |
you mean meshes |
| 19:46 |
PilzAdam |
yea, whatever |
| 19:46 |
Taoki |
RealBadAngel: My ideal implementation of a moddable sky is a Lua method to define planets, which are textured sprites that have different positions at each time of day (and emit various lights) |
| 19:46 |
RealBadAngel |
and thats the point |
| 19:46 |
celeron55 |
Taoki: skybox/skyspehere/whatever is always an actual mesh AFAIK; altough it isn't usually loaded from a file |
| 19:46 |
VanessaE |
Taoki: I can see the advantage to it, for sure, but I have to wonder what kind of performance you'd get out of it, since you'd have to basically deform everything that's placed onto the surface of that sphere (at least, at init time) |
| 19:46 |
RealBadAngel |
lemme implement real lighting first |
| 19:46 |
celeron55 |
(they are easy to generate on the fly) |
| 19:46 |
RealBadAngel |
then we can go for modding it |
| 19:47 |
Taoki |
RealBadAngel: Yes for real lighting :D |
| 19:47 |
Jordach |
RealBadAngel, thats if you ever finish it |
| 19:47 |
PilzAdam |
RealBadAngel, have you looked at celeron55's branch? |
| 19:47 |
Taoki |
RealBadAngel: But as for the sky, it's the only thing that's worrying me. Since at least / especially for Minetest, I like the current sky system omst. What I don't like about it is that it's currently fixed and un-customizable |
| 19:48 |
Taoki |
Yeah, c55's branch for customizable sky sounds like a great start :) |
| 19:48 |
Taoki |
**omst = best |
| 19:48 |
RealBadAngel |
i havent checked that branch yet |
| 19:49 |
Taoki |
So what I'd wish instead is 1 - De-hardcode the sun and moon pixels (horrid implementation IMO) and replace them with a texture, 2 - Remove sun and moon from the code and att a Lua API to define sky planets (shouldn't be hard) |
| 19:50 |
Taoki |
Each sky object would have an array of tables under the form { daytime, position_at_this_daytime, light_at_this_daytime } |
| 19:50 |
celeron55 |
the sun and moon aren't made of pixels; they're simply untextured polygons |
| 19:51 |
celeron55 |
as well as stars |
| 19:51 |
Taoki |
yeah. IMHO that's the biggest emergency about them... making them textured at least |
| 20:06 |
|
kaeza joined #minetest-dev |
| 20:10 |
|
sapier1 joined #minetest-dev |
| 20:11 |
Taoki |
celeron55: Can you confirm PilzAdam VBO code he linked earlier is fine? Waiting eagerly for it to be in upstream and usable, and he found the solution to all problems with vbo |
| 20:17 |
Taoki |
From what I last tested, it's all good now |
| 20:20 |
celeron55 |
oh i needed to comment on that |
| 20:21 |
celeron55 |
PilzAdam: if that's so, then the Right Way(tm) to do it is to keep the mapblocks in memory equally long as before but delete the meshes earlier |
| 20:21 |
celeron55 |
(that's some work though) |
| 20:22 |
Taoki |
Currently he added a note about setting the client caching limit very low. Till that bigger work can be done, does that work too (considering it's off by default) |
| 20:22 |
celeron55 |
probably no server admin would approve pushing a considerable lower upstream default deletion time |
| 20:22 |
celeron55 |
because it increases traffic for no good reason |
| 20:23 |
Taoki |
No defaults would change upstream. People would manually have to change it in their minetest.conf together with enabling VBO |
| 20:23 |
Taoki |
But current defaults stay the same |
| 20:25 |
celeron55 |
in that case i don't really care, but somebody must promise to finish it sometime if it's put in that way |
| 20:26 |
RealBadAngel |
in my model sky color is a map |
| 20:27 |
RealBadAngel |
very same idea as hmmmm's grass tinting etc |
| 20:28 |
RealBadAngel |
sky is shaded basing on sun position |
| 20:29 |
RealBadAngel |
when touchin the horizon map causes dawn/dusk effect |
| 20:30 |
Taoki |
RealBadAngel: Nice. But if possible, no fixed meshes involved is my suggestion |
| 20:30 |
Taoki |
For the sky that is. Everything else is mesh-based of course |
| 20:31 |
PilzAdam |
celeron55, would be unload time for meshes be configureable too? |
| 20:31 |
PilzAdam |
*the |
| 20:31 |
RealBadAngel |
you have seen the screenshots |
| 20:31 |
RealBadAngel |
effects are really nice |
| 20:31 |
RealBadAngel |
and every piece is moddable |
| 20:32 |
Taoki |
They are. But I couldn't get myself to say the method is good still. I'd go for the branch celeron55 posted earlier, which seems to do what I suggested (customization of the current sky and texturing of sun and moon) |
| 20:32 |
RealBadAngel |
thats why i got sun smiling, death star or milky way photo |
| 20:33 |
celeron55 |
PilzAdam: umm... well i guess so |
| 20:33 |
RealBadAngel |
sun and moon are already textured in my model |
| 20:34 |
RealBadAngel |
i dont get the point |
| 20:34 |
celeron55 |
configuring it will be quite silly though |
| 20:34 |
celeron55 |
it should work so that enabling the vbo setting will also enable a lower mesh unload time |
| 20:34 |
celeron55 |
oh and now that i think of it |
| 20:35 |
RealBadAngel |
celeron55, configuring in a way of putting sun.png into textures/all |
| 20:35 |
celeron55 |
remaking the meshes from the mapblocks in memory is going to be a problem |
| 20:35 |
celeron55 |
RealBadAngel: i'm talking to PilzAdam |
| 20:35 |
Taoki |
RealBadAngel: My point is that IMO doing the sky with meshes is a wrong and hacky way, as a technical concept. And instead I'd rather make the existing sky configurable |
| 20:35 |
Taoki |
Ah, sorry |
| 20:35 |
RealBadAngel |
i think i shall publish my sky code for you to read it first |
| 20:36 |
celeron55 |
because on some GPUs the first time a new mesh is shown creates a small frametime spike, which is diminished currently by mesh generation being spread due to the limited flow of mapblocks from the server |
| 20:36 |
RealBadAngel |
i deleted almost whole old sky code and wrote it from scratch |
| 20:36 |
celeron55 |
so that requires experimenting and finding some way to not make it horrible |
| 20:36 |
|
iqualfragile joined #minetest-dev |
| 20:37 |
|
diemartin joined #minetest-dev |
| 20:38 |
RealBadAngel |
Taoki: meshes allows customization. Hardcoded stars dont. |
| 20:38 |
Taoki |
I think start should be a texture too |
| 20:38 |
Taoki |
**stars |
| 20:39 |
RealBadAngel |
they are |
| 20:39 |
Taoki |
ok |
| 20:39 |
RealBadAngel |
properly mapped in blender ofc |
| 20:39 |
RealBadAngel |
but its a texture |
| 20:40 |
Taoki |
RealBadAngel: Is at least the sky sphere mapped to infinity? And no longer a model attached in any way to the player and centered to the FOV? |
| 20:40 |
RealBadAngel |
sky is another scenenode |
| 20:40 |
Taoki |
Ok |
| 20:40 |
RealBadAngel |
independent from world |
| 20:41 |
Taoki |
That part sounds good at least. If it's mapped to the "background" without having to be attached to anything, the idea might be good |
| 20:41 |
Taoki |
If only the sphere was realtime in code too |
| 20:41 |
RealBadAngel |
it is |
| 20:42 |
RealBadAngel |
i rotate the sphere real time |
| 20:42 |
PilzAdam |
celeron55, yea, the meshes get only regenerated if you are really close to them |
| 20:42 |
Taoki |
Yeah, I mean not a .x or .b3d file :P |
| 20:42 |
RealBadAngel |
so the basic idea is the sphere holds the stars |
| 20:43 |
RealBadAngel |
and it rotates with time |
| 20:43 |
RealBadAngel |
then comes the sky dome |
| 20:43 |
Taoki |
Is the horrizon at sunset + sun & moon also a sphere? And is the sky color itself still a background color? |
| 20:43 |
RealBadAngel |
which is coloured |
| 20:43 |
PilzAdam |
celeron55, how would that be properly fixed? |
| 20:43 |
RealBadAngel |
and covers the sphere |
| 20:43 |
Taoki |
If this model happens to be chosen, sun a& moon should be textured planes |
| 20:44 |
RealBadAngel |
at night dome is not blueish, so you can see stars |
| 20:45 |
RealBadAngel |
at day its blue and covers the stars |
| 20:45 |
Taoki |
Ok. Is all of it defined in Lua? I mean, are there no more sun / moon references in the code, and the sky is completely mode-based now? |
| 20:45 |
RealBadAngel |
its not lua at all atm |
| 20:45 |
* Taoki |
would like to see some screenshots with the default texture set for it |
| 20:45 |
Taoki |
ok |
| 20:45 |
celeron55 |
PilzAdam: don't ask me 8) |
| 20:46 |
RealBadAngel |
Taoki, wait a sec |
| 20:47 |
celeron55 |
PilzAdam: how low the timeout must be set for it to work? |
| 20:49 |
PilzAdam |
120 or so |
| 20:49 |
PilzAdam |
it depends on how many RAM you want to spend for it |
| 20:49 |
celeron55 |
PilzAdam: and do you know why there is so much memory consumption? the reason (i think) is that many meshes get generated up to four times before they are left to stay, as they need to be generated after the neighboring mapblocks are received; as the EHM_STATIC flag is immediately set, the short-time lived meshes are transferred to the GPU too and irrlicht then wants to keep them there for a ridiculously long time |
| 20:49 |
PilzAdam |
120 takes about 900 MiB |
| 20:49 |
celeron55 |
one solution there could be to set EHM_STATIC only after the mesh has existed for certain time |
| 20:50 |
celeron55 |
and lower the mapblock deletion timeout a bit but not so much |
| 20:50 |
kahrl |
the proper solution would be to not generate meshes if they need to be regenerated immediately after :P |
| 20:50 |
celeron55 |
kahrl: of course |
| 20:50 |
kahrl |
but that would mess with TOSERVER_GOTBLOCKS etc |
| 20:50 |
celeron55 |
it's just not quite trivial 8) |
| 20:53 |
celeron55 |
in any case there will be a lot of memory consumption on clients of a busy server |
| 20:53 |
celeron55 |
as stuff is placed and dug, there is a constant regeneration of meshes |
| 20:53 |
celeron55 |
probably filling any amount of RAM if it's up to irrlicht's timeouts |
| 20:54 |
celeron55 |
so really, eh, the proper solution would be to have irrlicht actually delete them when minetest wants to |
| 20:54 |
celeron55 |
as MT already has proper management for them |
| 20:57 |
celeron55 |
maybe we should assign some person to send patches to irrlicht that make it behave sanely |
| 20:57 |
celeron55 |
8) |
| 20:58 |
Calinou |
but people would need an uptodate version of irrlicht |
| 20:58 |
Calinou |
the land would be full of screaming debian and ubuntu users |
| 20:59 |
RealBadAngel |
Taoki, http://i.imgur.com/2xEp8Ow.png |
| 20:59 |
RealBadAngel |
sphere itself |
| 20:59 |
sokomine |
/me screams a bit |
| 20:59 |
Taoki |
RealBadAngel: Sadly that's exactly what I was fearing to see :P |
| 20:59 |
RealBadAngel |
http://i.imgur.com/xngqHYo.png |
| 21:00 |
sokomine |
i think it depends on how difficult irrlicht is to compile. i have no idea about that. generally, linux-users have to compile their own mt |
| 21:00 |
RealBadAngel |
glare effect using map |
| 21:00 |
Calinou |
sokomine: but they do not want to compile their own deps. at all. |
| 21:00 |
Calinou |
I'll never do that |
| 21:00 |
Calinou |
RealBadAngel: looks nice |
| 21:00 |
RealBadAngel |
http://i.imgur.com/wP3g7FK.png |
| 21:00 |
RealBadAngel |
at night |
| 21:01 |
Taoki |
RealBadAngel: No more blocky-llooking sun by default? :P |
| 21:01 |
celeron55 |
Calinou: but at least stuff would be fixed on *some* time |
| 21:01 |
celeron55 |
in |
| 21:01 |
celeron55 |
* |
| 21:01 |
Calinou |
yeah, still |
| 21:01 |
RealBadAngel |
and with textures: http://i.imgur.com/W9vgYNr.jpg |
| 21:01 |
Calinou |
Taoki: fun fact: blocky sun looks terrible without AA |
| 21:01 |
Calinou |
i'm not against using actual skyboxes, like RealBadAngel pointed |
| 21:01 |
RealBadAngel |
blocky? http://i.imgur.com/ETkhTnV.png |
| 21:01 |
Calinou |
lol |
| 21:01 |
Taoki |
Calinou: Not that terrible, but I can tell the edges |
| 21:02 |
Calinou |
Taoki: we can avoid these edges, so why not do it :P |
| 21:02 |
Taoki |
RealBadAngel: So... will the spheres be optional? What happens with the actual sky colors? Do they exist, and become customizable in Lua too when you get to that |
| 21:02 |
Calinou |
customisable fog, sky colors would be nice |
| 21:03 |
RealBadAngel |
you can achieve it with changing the color file |
| 21:03 |
RealBadAngel |
no need for lua stuff |
| 21:04 |
RealBadAngel |
its all texture pack thing |
| 21:04 |
RealBadAngel |
not the code |
| 21:06 |
* Taoki |
is still very skeptic and would prefer the current sky system being made texturable. Hopes RBA isn't discouraged though... the idea isn't bad by itself either I guess |
| 21:06 |
Calinou |
[Taoki tomorrow: replacing the sun image with a pony] |
| 21:06 |
Calinou |
RealBadAngel commits it, gets merged in master |
| 21:07 |
Taoki |
haha, that would be one thing to see :) |
| 21:08 |
Taoki |
But currently, I'm more in favor of celeron55 addition here (the configurable sky). Would like to see that upstream and how it goes. If that's not good enough either a sphere system could be considered |
| 21:09 |
Taoki |
(and if we can't texture the stars some other way) |
| 21:14 |
PilzAdam |
celeron55, I tried setting the EHM_STATIC static flag only if the mesh existed for 10 seconds, but there is no noticeable performance benefit left and the RAM increases too (not so fast, though) |
| 21:20 |
celeron55 |
PilzAdam: maybe it's not so simple then; i don't really know anymore |
| 21:24 |
|
sapier1 left #minetest-dev |
| 21:31 |
arsdragonfly|pho |
PilzAdam : https://github.com/minetest/minetest/pull/790 I put the screenshot here |
| 21:33 |
PilzAdam |
seems good |
| 21:33 |
arsdragonfly|pho |
https://github.com/minetest/minetest/pull/790 and here's another commit |
| 21:34 |
arsdragonfly|pho |
Are there any other core devs around? |
| 21:36 |
arsdragonfly|pho |
https://github.com/minetest/minetest/pull/783 oh wait the second one should be this one |
| 22:45 |
Taoki |
PilzAdam: So... can we still have the VBO setting with manually setting the client data limit, if that system doesn't work? |
| 23:03 |
|
diemartin joined #minetest-dev |
| 23:06 |
|
mrtux joined #minetest-dev |
| 23:19 |
|
NakedFury joined #minetest-dev |
