| Time |
Nick |
Message |
| 01:35 |
|
lhofhansl joined #minetest-dev |
| 01:36 |
lhofhansl |
Hello. Merging #13155 (trivial) |
| 01:36 |
ShadowBot |
https://github.com/minetest/minetest/issues/13155 -- Display whole profiler numbers up to 999999 without scientific notation. by lhofhansl |
| 01:40 |
lhofhansl |
And... Done. :) |
| 03:14 |
|
beanzilla joined #minetest-dev |
| 04:15 |
|
YuGiOhJCJ joined #minetest-dev |
| 04:40 |
|
sugarbeet joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 05:39 |
|
fluxionary joined #minetest-dev |
| 06:35 |
lhofhansl |
Is x2048 around? |
| 06:43 |
|
YuGiOhJCJ joined #minetest-dev |
| 06:44 |
|
YuGiOhJCJ joined #minetest-dev |
| 07:07 |
|
calcul0n joined #minetest-dev |
| 08:09 |
|
YuGiOhJCJ joined #minetest-dev |
| 08:24 |
|
YuGiOhJCJ joined #minetest-dev |
| 09:47 |
|
proller joined #minetest-dev |
| 10:40 |
|
proller joined #minetest-dev |
| 11:54 |
|
vampirefrog joined #minetest-dev |
| 11:55 |
|
kilbith joined #minetest-dev |
| 14:25 |
|
qur joined #minetest-dev |
| 14:33 |
|
Fixer joined #minetest-dev |
| 15:24 |
|
fluxionary joined #minetest-dev |
| 16:14 |
|
fluxionary joined #minetest-dev |
| 16:30 |
|
proller joined #minetest-dev |
| 17:56 |
|
appguru joined #minetest-dev |
| 17:56 |
appguru |
merging game#2965 in 5 min |
| 17:56 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/2965 -- Ensure chests close properly by fluxionary |
| 18:01 |
|
Fixer joined #minetest-dev |
| 18:06 |
MTDiscord |
<x2048> lhofhansl: I am on and off via Discord, usually check chats around this time. |
| 19:01 |
|
qur joined #minetest-dev |
| 19:08 |
|
qur joined #minetest-dev |
| 20:07 |
MTDiscord |
<MisterE> @x2048 what would you think of adding a no_render node drawtype..., you would see no geometry behind it, only the skybox. |
| 20:08 |
MTDiscord |
<MisterE> It would accept textures with transparency |
| 20:08 |
MTDiscord |
<MisterE> For the node, that is |
| 20:10 |
sfan5 |
usecase? |
| 20:18 |
pgimeno |
hm, one I can think of is making sub-worlds at different levels, using a "roof" to prevent them to be rendered |
| 20:21 |
MTDiscord |
<MisterE> That is one particular usecase yes, to avoid the hack of having to space out levels beyond render distance. The other usecase is for portals... imagine a pool in the ground, through which you can see a starfield (the lower part of the skybox). You step into it... |
| 20:21 |
celeron55 |
in a custom built world you might want to hide a piece of the level while already having it loaded (for convenience)? |
| 20:22 |
MTDiscord |
<MisterE> yes |
| 20:23 |
MTDiscord |
<MisterE> For gamejam type games, you could have all the levels near each other inside boxes of this node drawtype, and while inside each box, you would not see the other nearby levels |
| 20:25 |
MTDiscord |
<MisterE> One issue with minigame levels is keeping levels (or minigame arenas on aes for that matter) far enough away that you can't see them from other levels. |
| 20:26 |
MTDiscord |
<luatic> Such a drawtype would require a separate rendering pass or a stencil buffer, wouldn't it? |
| 20:26 |
MTDiscord |
<x2048> Can we achieve the same by having api for render boundaries? |
| 20:27 |
MTDiscord |
<x2048> Right now it's hardcoded at +- view range in all directions |
| 20:29 |
MTDiscord |
<MisterE> Well, that doesn't achieve the portal effect, but maybe thats better done with some other approach, and your idea would be sufficient for the other usecases (if you have per-axis or position-range control) |
| 20:30 |
MTDiscord |
<MisterE> Imo, actually, the position range control would be better than per-axis control |
| 20:30 |
MTDiscord |
<MisterE> But.. what if the area is already loaded? |
| 20:33 |
MTDiscord |
<MisterE> What if, I have two arenas next to each other, bounded by a box for each, and you should see only skybox beyond that box while inside the arena. I go to one arena, load it, the go to the other arena, and load it... we need to make sure that it will stop displaying the old arena that I left as I enter the new one |
| 20:34 |
MTDiscord |
<MisterE> The specific behavior would be lua defined of course, I'm just concerned that the api allow you to say 'the client should see no geometry outside this range' or something like that |
| 20:35 |
MTDiscord |
<x2048> You can have API set_render_limit(aabb3d) that defines absolute boundaries for what's rendered up to a  mapblock. When you enter any arena just set the right bounding box to hide the others |
| 20:36 |
MTDiscord |
<MisterE> Nice |
| 20:36 |
celeron55 |
basically define the rendered volume by absolute node coordinates |
| 20:36 |
MTDiscord |
<MisterE> ^ |
| 20:37 |
celeron55 |
that seems fairly general purpose and very lightweight to implement |
| 20:37 |
MTDiscord |
<x2048> And it would intersect with pos+viewrange |
| 20:37 |
MTDiscord |
<MisterE> Well, that doesn't do portals, but hey, its a step in the right direction. I still might like a way to do special scenes behind a node, but that should be a different feature. |
| 20:38 |
MTDiscord |
<MisterE> Id like minecraft end portals 🙂 |
| 20:38 |
MTDiscord |
<x2048> By portals you mean special node shader? |
| 20:39 |
MTDiscord |
<MisterE> No. A way to not show normal geometry behind a node, but show a special scene behind it... maybe just a skybox, or maybe more complicated geometry |
| 20:39 |
MTDiscord |
<x2048> It's like a world-aligned texture with parallax? |
| 20:40 |
MTDiscord |
<MisterE> Maybe something similar could be done with the camera api and entities, so maybe its already coming |
| 20:40 |
celeron55 |
the definition seemed to be "seeing the sky(box) by looking at special nodes which may have other stuff behind them, which wouldn't then be seen" |
| 20:40 |
MTDiscord |
<MisterE> ^ |
| 20:41 |
MTDiscord |
<x2048> I would not pursue that specific definition |
| 20:41 |
celeron55 |
that doesn't seem as general purpose and not sure what that would take to implement |
| 20:41 |
MTDiscord |
<x2048> MC end portal is just a shader |
| 20:42 |
MTDiscord |
<MisterE> Although, idk that it should be the skybox persay, but some kind of visual effect. Anyhow, lets forget that... the hiding geometry with  lua-defined coordinates is much more general purpose and needed |
| 20:42 |
MTDiscord |
<MisterE> And sane |
| 20:42 |
celeron55 |
shader defined tiles (tile is basically what MT calls a node face) could make sense. could be a compatibility nightmare though, and someone could consider it to be a security nightmare also |
| 20:43 |
MTDiscord |
<x2048> they are |
| 20:44 |
celeron55 |
instead there could be a library of pre-made effects to choose from. not sure how general purpose that could be |
| 20:45 |
MTDiscord |
<x2048> just like textures, shaders can be named and be a part of texture/resource packs |
| 20:47 |
MTDiscord |
<x2048> then it's a different type of compatibility headache |
| 20:49 |
MTDiscord |
<MisterE> Fun |
| 20:55 |
|
Fixer joined #minetest-dev |
| 21:16 |
|
proller joined #minetest-dev |
| 21:27 |
|
appguru joined #minetest-dev |
