| Time |
Nick |
Message |
| 00:18 |
|
Thermoriax joined #minetest |
| 00:26 |
|
YuGiOhJCJ joined #minetest |
| 00:44 |
MTDiscord |
<warr1024> What bugs you don't know about? |
| 00:44 |
MTDiscord |
<luatic> Warr1024: I assume this refers to "shaders (per se) cutting framerate in half". |
| 00:45 |
MTDiscord |
<warr1024> Is that not common knowledge? Turning on any fancy graphical option has a non-zero cost. When you've got pretty much everything else turned to the minimum, something like shaders is going to have a big marginal impact. |
| 00:45 |
MTDiscord |
<luatic> Shaders per se do not imply fancy graphical options |
| 00:47 |
|
filex joined #minetest |
| 00:48 |
MTDiscord |
<luatic> They are just a rendering implementation "detail" if you will and hence really shouldn't be an option; the only reasons they are one is (1) a while ago it was important to support much older OpenGL (ES) versions; (2) there might be actual performance hits caused by shaders per se - if there are, please report them. |
| 01:08 |
|
v-rob joined #minetest |
| 02:44 |
mdhughes |
Also I find most shaders hideous and annoying to gameplay. So I don't turn them on. |
| 02:45 |
mdhughes |
Yeah, it's real funny to have the "sun" blast the center of the screen yellow/white, and the outer areas waving blacks with a little brown, but I'm there to build. |
| 02:45 |
MTDiscord |
<warr1024> Fair, but I don't think we're talking about turning on individual shader options. We're just talking about the main "base" shaders. |
| 02:45 |
MTDiscord |
<warr1024> I don't remember what they do, other than have completely independent lighting bugs from non-shader-based lighting. |
| 02:46 |
MTDiscord |
<warr1024> I think something to do with entity lighting. Lighting is baked into node meshes, but I guess because entities can change orientation on a per-frame basis, we did them using shaders. |
| 03:43 |
|
Mantar joined #minetest |
| 04:00 |
|
MTDiscord joined #minetest |
| 04:22 |
|
Pexin joined #minetest |
| 04:36 |
|
filex joined #minetest |
| 05:14 |
|
v-rob joined #minetest |
| 06:05 |
|
gregon joined #minetest |
| 06:38 |
|
TomTom joined #minetest |
| 07:25 |
|
Lunatrius joined #minetest |
| 07:50 |
|
bdju joined #minetest |
| 07:54 |
|
tarsovbak joined #minetest |
| 07:58 |
|
bdju joined #minetest |
| 08:08 |
|
illwieckz joined #minetest |
| 08:23 |
|
illwieckz joined #minetest |
| 08:26 |
|
Evergreen9 joined #minetest |
| 08:27 |
|
Road_Killer joined #minetest |
| 08:30 |
|
down200 joined #minetest |
| 08:31 |
|
illwieckz joined #minetest |
| 09:01 |
|
Sokomine joined #minetest |
| 09:09 |
|
illwieckz joined #minetest |
| 09:11 |
|
gregon joined #minetest |
| 10:14 |
|
tarsovbak joined #minetest |
| 10:15 |
|
gregon joined #minetest |
| 10:21 |
sfan5 |
lighting is not entirely baked into node meshes either, shaders are also involved |
| 10:59 |
|
filex joined #minetest |
| 11:06 |
rubenwardy |
Shaders are a required part of the modern graphics pipeline. When you're disabling shaders you're just reverting to fixed shaders provided by irrlicht (well, maybe the fixed pipeline is still supported on some configurations idk) |
| 11:54 |
|
Road_Killer joined #minetest |
| 12:12 |
|
hifi left #minetest |
| 12:15 |
|
ireallyhateirc joined #minetest |
| 13:01 |
|
filex joined #minetest |
| 13:02 |
|
Noisytoot joined #minetest |
| 14:10 |
MTDiscord |
<warr1024> When I'm disabling shaders I'm squeezing every drop of performance out of the system I can, and have the best possible shot at double digit frame rates. I'm well aware of what that causes to happen on modern hardware, but the only thing that's relevant to me is whether the final output is usable. |
| 14:15 |
MTDiscord |
<warr1024> I assume that eventually we will just have to get our base shaders up to spec with whatever is being done in the fixed pipeline. Right now there are features behind the "shader" checkbox that we can't control. Rather than the shader checkbox just going away as it is now, it probably makes more sense to just turn it into an option to toggle features without changing the basic pipeline. |
| 14:17 |
MTDiscord |
<warr1024> As I understand it, enabling shaders in MT doesn't make our rendering pipeline NOT fixed though, we just add shaders at certain points along the otherwise hardware-defined legacy pipeline. Even if the goal is to modernize the pipeline, it seems like we're some way away from that. |
| 14:23 |
celeron55 |
well, that checkbox puts the vertex and the fragment shader in place for a number of materials, and that replaces the fixed pipeline function at that point in the pipeline |
| 14:25 |
celeron55 |
however much that differs from a "modern-modern" approach, i don't know. that's as modern as i've ever needed to go |
| 14:29 |
MTDiscord |
<warr1024> Yeah, I guess I'm also skeptical that "more modern" is actually a useful direction to go here. As long as newer hardware or drivers continue to support emulating the fixed pipeline, the only drawback to it seems to be that if you want some of the fancy options you have to literally smear petroleum jelly all over your display. |
| 14:38 |
ireallyhateirc |
you mean the blur? |
| 14:42 |
ireallyhateirc |
blur pretty much attempts to simulate how the human eye scatters light. However the last time I tried it, it was literally petroleum jelly. |
| 14:42 |
ireallyhateirc |
human eyes are bad enough irl so I'm not sure why would anyone want to simulate that in the game ¯\_(ツ)_/¯ |
| 14:43 |
MTDiscord |
<damotrix> Haha agreed |
| 14:43 |
MTDiscord |
<damotrix> It's always annoying as heck for blur to be included in games |
| 14:44 |
MTDiscord |
<damotrix> Only thing blur is good for, is if you're using it to show speed, maybe. Like in a fast car or spaceship, only place I see it as a net positive |
| 15:11 |
MTDiscord |
<warr1024> Yeah, the idea of simulating natural light scattering to produce an image which will then be subject to natural light scattering is pretty redundant. I don't really get why people are so impressed by filters that reduce image quality by blurring the entire screen, while at the same time complain about linear texture filters. Maybe it's just my bias as a glasses-wearer, since I could just take my glasses off if I wanted blur. |
| 15:12 |
MTDiscord |
<warr1024> Some of the filters we have right now suffer a bit from the fact that the people developing them are, I think, learning the process, rather than being already honed professionals at it. In a way, the final product isn't necessarily the point of the exercise, but just some combination of proving the person and the engine capable. |
| 15:13 |
MTDiscord |
<warr1024> Some of them also suffer significantly from the fact that we can't deliver a lot of information to the shaders because that information just doesn't exist, like HDR lighting info, normal maps, etc. Attempts to get that information have not gone well either. Mod devs will be very slow to provide extra texture information, and attempts to automatically infer it from the RGBA texture info have gone badly. |
| 15:17 |
|
___nick___ joined #minetest |
| 15:20 |
|
___nick___ joined #minetest |
| 15:21 |
MinetestBot |
[git] grorp -> minetest/minetest: Expose analog joystick input to the Lua API (#14348) 22ef4c8 https://github.com/minetest/minetest/commit/22ef4c8be17528d7fa23c7a0557d49aeda6f2e3a (2024-10-01T15:21:42Z) |
| 15:31 |
MinetestBot |
[git] grorp -> minetest/minetest_game: Set volumetric lighting strength df81594 https://github.com/minetest/minetest_game/commit/df8159436c65db7940077dda28f4d1ad5a9c0811 (2024-10-01T15:29:41Z) |
| 15:44 |
|
v-rob joined #minetest |
| 16:30 |
|
Lunatrius joined #minetest |
| 16:50 |
|
Boingo joined #minetest |
| 16:53 |
|
ireallyhateirc joined #minetest |
| 17:06 |
|
___nick___ joined #minetest |
| 17:21 |
|
___nick___ joined #minetest |
| 17:27 |
|
Talkless joined #minetest |
| 17:57 |
|
fluxionary joined #minetest |
| 18:09 |
|
shaft joined #minetest |
| 18:17 |
shaft |
Apparently minetest supports normalmaps and such. Can texturepacks make use of it? |
| 18:18 |
Krock |
_normal.png textures AFAIK |
| 18:19 |
Krock |
it's mentioned here. once. https://github.com/minetest/minetest/blob/master/doc/lua_api.md?plain=1#L187 |
| 18:20 |
Krock |
https://github.com/minetest/minetest/blob/22ef4c8be17528d7fa23c7a0557d49aeda6f2e3a/src/client/texturesource.cpp#L510-L524 |
| 18:21 |
Krock |
see games/devtest/mods/testnodes/drawtypes.lua for an example |
| 18:21 |
Krock |
^ nvm ignore that line. it's a false-positive match. |
| 18:36 |
shaft |
I'm not sure if I see anything. |
| 18:36 |
shaft |
I don't think its working |
| 18:52 |
sfan5 |
normal map support was dropped a while ago |
| 18:54 |
shaft |
Why if I may ask? |
| 18:54 |
sfan5 |
it was broken |
| 18:57 |
shaft |
Well whatever. I just came across it because I was thinking maybe there's a metallic filter too or something. It's such a pain trying to find a drawn style texture for non-dirty metall. |
| 18:59 |
MTDiscord |
<warr1024> "normal map support was dropped" ... for a moment I read this as "sorry, only strange maps are supported now." |
| 19:00 |
MTDiscord |
<warr1024> IIRC we used to try to generate normals from textures by applying filters but it just kind of looked awful. It was one of those effects that you see and at first think "ooh, that's fancy, really attention-getting" but then after you see it in every youtube video for a while it's much more like a distraction than an enhancement. |
| 19:03 |
shaft |
Well of course it looks like shit if you're generating it from the textures. |
| 19:05 |
Krock |
so dropping them wasn't done properly |
| 19:05 |
sfan5 |
IIRC it was broken beyond the auto-generation feature |
| 19:11 |
|
jaca122 joined #minetest |
| 19:12 |
sfan5 |
Juri: can you reach your server from outside? |
| 19:12 |
MTDiscord |
<warr1024> Fair, I only know that it was broken up to and including auto-generation, and that felt like plenty broken for me 😄 |
| 19:12 |
sfan5 |
ip or port? |
| 19:13 |
Juri |
sfan5: yes and there are currently 5 people online |
| 19:13 |
Juri |
ip: 23.88.77.225 domain: wunderwelt.one port: 30000 |
| 19:13 |
sfan5 |
!up wunderwelt.one |
| 19:13 |
MinetestBot |
wunderwelt.one:30000 seems to be down (IPv6) |
| 19:13 |
sfan5 |
!up 23.88.77.225 |
| 19:13 |
MinetestBot |
23.88.77.225:30000 is up (12ms) |
| 19:13 |
MTDiscord |
<warr1024> It'd be nice if the serverlist replied with, and MT then displayed, an error message confirming what the serverlist was actually trying, and what result it got (e.g. did it get ICMP unreachable, or just time out, or what). Nice to have, but probably not critical. |
| 19:14 |
sfan5 |
do you advertise to the serverlist with the domain too? |
| 19:14 |
Juri |
oh well, seems i messed up my dns |
| 19:14 |
MTDiscord |
<warr1024> (like being able to verify that DNS lookups worked right on the serverlist side to rule out DNS caching issues) |
| 19:14 |
sfan5 |
if yes then the problem is that dns specifies an ipv6 and mt isn't reachable there |
| 19:15 |
Juri |
a few hours ago i added AAAA values to my record |
| 19:17 |
Juri |
minetest is only bound to the v4 interface |
| 19:17 |
sfan5 |
try ipv6_server = true |
| 19:18 |
sfan5 |
and don't forget the firewall rule if you have one |
| 19:18 |
Juri |
will that setting prevent people without IPv6 from playing? |
| 19:19 |
sfan5 |
no |
| 19:19 |
|
InFerNo__ joined #minetest |
| 19:19 |
Juri |
honestly i would like to keep minetest ipv4 due to xban |
| 19:20 |
sfan5 |
you can but then your domain can't also have ipv6 |
| 19:20 |
Juri |
oh well |
| 19:20 |
Juri |
thanks for the quick help |
| 19:24 |
MTDiscord |
<warr1024> You might consider creating a separate host within the domain, like mt.wunderwelt.one, so that you can have only an A record for that... |
| 19:24 |
shaft |
That's stupid ipv6 is the future. |
| 19:24 |
MTDiscord |
<warr1024> Yeah, that's one of the drawbacks of living in the present. |
| 19:25 |
Juri |
that is a good idea, but slightly annoying since it will break peoples favorite lists |
| 19:25 |
Juri |
well not break, but it will show my server offline |
| 19:26 |
Juri |
i think i somehow will force minetest to do the announcement over ipv4 |
| 19:26 |
shaft |
IPv4 isn't going to help you ban banevaders. There's plenty of IPs even on IPv4 |
| 19:26 |
Juri |
that should solve the issue as well |
| 19:27 |
sfan5 |
it won't |
| 19:27 |
sfan5 |
the serverlist verifies that the domain you provide can be connected to. if it has an ipv6 address it picks that and expects it to work |
| 19:27 |
Juri |
oh really? i just looked at the checkRequestAddress() function and thought my request comes from my ipv6 |
| 19:28 |
Juri |
if my request comes via v4 then the probe should work out, or am i missing something? |
| 19:29 |
|
Thermoriax joined #minetest |
| 19:30 |
sfan5 |
you're looking for asyncFinishThread(). it resolves the domain (or ip) and uses that. the request IP is not used. |
| 19:31 |
MTDiscord |
<warr1024> It makes sense to me that the serverlist should probe the configured address and not the sender of the request. |
| 19:31 |
MTDiscord |
<warr1024> but on some level it seems weird it should prefer the broken future-only version of IP and not the works-today one 😆 |
| 19:47 |
Juri |
Well I removed the AAAA record for now, TTL is 2 hours :/ |
| 20:58 |
|
v-rob joined #minetest |
| 21:13 |
|
kamdard joined #minetest |
| 21:18 |
Juri |
We're back on the server list, thanks for the help |
| 21:19 |
ireallyhateirc |
If I do animation in blender that swaps textures of the character, will that get displayed correctly in Minetest? Provided that I only use one texture. |
| 21:20 |
MTDiscord |
<greenxenith> If you mean keyframing materials, no |
| 21:20 |
ireallyhateirc |
I'm making a character that will have facial expressions and for that I'm going to swap textures instead of rigging and animating. |
| 21:21 |
ireallyhateirc |
hmmm so I will be forced to implement a custom system in Minetest for swapping textures? |
| 21:21 |
MTDiscord |
<greenxenith> You could just swap textures using a separate material on the mesh and set_properties? |
| 21:22 |
ireallyhateirc |
well I'm new to animation and blender so I don't really know what you mean. So I need to make a separate material for the face? |
| 21:23 |
MTDiscord |
<greenxenith> You can apply separate materials to different sets of faces, yes. Minetest will assign your defined textures to those slots in order. |
| 21:23 |
MTDiscord |
<greenxenith> So you could have a separate face layer that gets used for facial expressions |
| 21:24 |
ireallyhateirc |
sounds good. Where can I find this in the lua API doc? |
| 21:24 |
MTDiscord |
<greenxenith> Good question |
| 21:25 |
MTDiscord |
<greenxenith> https://github.com/minetest/minetest/blob/master/doc/lua_api.md#object-properties under textures = {} |
| 21:28 |
ireallyhateirc |
>Minetest will assign your defined textures to those slots in order. |
| 21:28 |
ireallyhateirc |
how do I know the material order? |
| 21:29 |
MTDiscord |
<greenxenith> That is defined in the model (you decide the slot order in blender) |
| 21:31 |
ireallyhateirc |
I have my model divided into the head, hair, body and probably also clothes. This will normally work in MT if exported? |
| 21:32 |
|
v-rob joined #minetest |
| 21:33 |
ireallyhateirc |
well I guess I'll watch a tutorial about exporting models lol |
| 21:33 |
MTDiscord |
<greenxenith> I wont outright say it wont because it could if you are lucky, but usually Minetest only works with one object per model. You should use vertex groups for armature linking and group separation |
| 21:35 |
ireallyhateirc |
so before exporting I should merge it all into one object and then it should be safe? |
| 21:36 |
MTDiscord |
<greenxenith> It should really be one object while you are working on it too but yeah |
| 21:36 |
sparky4 |
hey guys |
| 21:37 |
sparky4 |
i got locked out of my fourm account because of a typo... |
| 21:37 |
ireallyhateirc |
some tutorials show monolithic modelling, other tutorials separate pieces like hair, head, etc. into separate objects |
| 21:38 |
sparky4 |
celeron55: poke i need assistance with my account |
| 21:38 |
sparky4 |
the fourm one |
| 21:39 |
MTDiscord |
<greenxenith> Generic blender stuff is whatever. For Minetest in particular it is better to just work in one object |
| 21:41 |
ireallyhateirc |
I see, well looks like there's no other way around but to export it to MT and try ¯\_(ツ)_/¯ |
| 21:42 |
ireallyhateirc |
I'm just worried about getting face textures changes in synch with animations |
| 21:42 |
MTDiscord |
<greenxenith> Yeah that's tough |
| 21:42 |
ireallyhateirc |
unless I do some sort of hack with bones like hidding multiple faces in the head and scalling them up/down |
| 21:43 |
MTDiscord |
<greenxenith> You could do some sort of swap system where you have one hidden and one shown, set the hidden before starting the animation, then use the hidden face during the animation to swap in |
| 21:44 |
ireallyhateirc |
this is probably too ambitious for minetest lol: https://p.mort.coffee/l9d.png |
| 21:44 |
MTDiscord |
<greenxenith> Been done before |
| 22:35 |
MTDiscord |
<luatic> sparky4: what do you need? |
| 22:35 |
|
v-rob joined #minetest |
| 22:35 |
|
panwolfram joined #minetest |
| 22:43 |
MTDiscord |
<jordan4ibanez> I have read the source code of your irc client |
| 22:43 |
MTDiscord |
<jordan4ibanez> There is a buffer overflow exploit on line 471 in main.cpp |
| 23:03 |
sparky4 |
! |
| 23:04 |
sparky4 |
luatic my mary4 account i cannot get into it i locked myself out iwth an email typo xD |
| 23:04 |
MTDiscord |
<greenxenith> Since you are on Discord, you can probably shoot him a DM with your correct email |
| 23:05 |
ireallyhateirc |
jordan4ibanez, hexchat? lol |
| 23:05 |
|
Eragon joined #minetest |
| 23:11 |
|
GreenXenith joined #minetest |
| 23:12 |
|
GreenXenith left #minetest |
