| Time |
Nick |
Message |
| 00:19 |
|
fluxionary joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:30 |
|
YuGiOhJCJ joined #minetest-dev |
| 07:03 |
MTDiscord |
<kimapr> of course, the API won't evolve past its initial state, so this will remain the only quality level available |
| 07:03 |
MTDiscord |
<kimapr> why not minetest.tts(options)? |
| 07:04 |
MTDiscord |
<kimapr> also a way to query what is actually available |
| 07:04 |
MTDiscord |
<kimapr> so we don't have to do cursed heuristics to find out unreliably |
| 07:44 |
celeron55 |
i think we're going to have to see more demand for TTS before it'll be considered |
| 07:45 |
celeron55 |
but it never hurts to have a proof of concept implementation |
| 07:46 |
sfan5 |
would it be server-side or client-side? |
| 07:49 |
celeron55 |
stream audio from the server? that'd probably be too laggy in general |
| 07:50 |
celeron55 |
whatever that needs could be added of course. TTS can be external to the engine in that case |
| 07:52 |
nrz |
if we want to stream some audio better to have a n external RTMP server to read |
| 08:25 |
Mantar |
nah, just give us tracker music support. send the audio samples, then it's just a coded arrangement |
| 08:28 |
celeron55 |
i don't think that would solve all use cases but it would work for some |
| 08:29 |
celeron55 |
it's actually a good argument for some kind of tracker music support, it would allow you to speak out some simple things |
| 08:30 |
celeron55 |
the other use case is probably long background music tracks, which don't need to sound fancy but have to have lots of variation |
| 08:33 |
celeron55 |
i don't know how many here have seen me turn down the tracker music idea in multiple occasions many years ago, but every time it has been sold roughly as "i want to play old demoscene music on my server" which is... basically the most unfitting, marginal thing you can think of |
| 08:35 |
celeron55 |
if people are able to pick one simple format with a compact implementation and give varied examples of what it can be used for, i think you have a good chance of getting it in |
| 08:42 |
celeron55 |
(i like tracker music in principle, because it's basically open source music. but it's a bad excuse for reusing demoscene music. to gain my respect, you need to make your own, and the system needs to be ergonomic enough to use to encourage that) |
| 08:42 |
celeron55 |
own music, i mean |
| 08:43 |
celeron55 |
there's probably a tracker format and implementation that can fit the bill |
| 09:03 |
Mantar |
tracker music means I can add some instruments to the world, and players can make their own songs |
| 09:04 |
sfan5 |
no, you can already do that now |
| 09:04 |
sfan5 |
there's "just" no way to get consistent timing with our audio api |
| 09:05 |
celeron55 |
an integral thing in tracker music is also being able to filter the samples, so that you get more use out of each sample |
| 09:06 |
sfan5 |
a rather seamless way to implement tts is to have a server-side component that spits out ogg's and you can use dynamic media to shove that to players |
| 09:06 |
celeron55 |
lowpass, highpass, attack, decay, maybe even add noise |
| 09:06 |
Mantar |
a tracker song is basically sheet music, it avoids the problem of timing |
| 09:06 |
celeron55 |
and of course, as much as i don't like reusing demoscene music, being able to read in a common tracker file format is also a useful feature. that way you can externally compose songs |
| 09:07 |
Mantar |
rather than punching a GUI button to play a note, you create sequences and queue them up |
| 09:10 |
MTDiscord |
<jordan4ibanez> Midi for all |
| 09:11 |
celeron55 |
midi isn't a very integrated approach. and general midi is... well, it is what it is |
| 09:11 |
celeron55 |
but yes, midi is truly solely a digital notation format |
| 09:12 |
celeron55 |
(and a protocol for streaming the format) |
| 09:12 |
celeron55 |
(all the way down to hardware level) |
| 09:13 |
celeron55 |
i don't really like it. music is more than notation |
| 09:13 |
celeron55 |
it's important to have the right sound |
| 09:13 |
celeron55 |
trackers make sure you get the exact sound you made, every time |
| 09:15 |
celeron55 |
due to the integrated linking of the samples with the notation |
| 09:16 |
MTDiscord |
<kimapr> Midi is tracker music if it was bad |
| 09:17 |
celeron55 |
midi is like "here's the sheet music" "ah do you want to know what the instruments are? well here's the list of the names of the instruments" "ah you don't have these exact instruments and don't even know where to get them? tough luck" |
| 09:19 |
celeron55 |
tracker music is like "here are the samples. now play them in this sequence, with these pitches and effects. you don't need to know what they sound like, just follow the strict process and you're good" |
| 09:22 |
MTDiscord |
<jordan4ibanez> Minetest will ship it's own instrument set of highly compressed noises that vaguely sound like what they're supposed to represent to save space |
| 09:22 |
MTDiscord |
<jordan4ibanez> See I can't even think of a good idea for this |
| 09:28 |
MTDiscord |
<jordan4ibanez> So we're going to add client side tracker music that's sent to the client from the server? |
| 09:40 |
celeron55 |
i would support that, given that it's neatly made |
| 09:40 |
celeron55 |
it probably needs to have a feature where a sample set can be reused between many tracks |
| 09:42 |
celeron55 |
like, if you're doing something like train announcements, you have a large sample library, where you use only a few per track |
| 09:42 |
celeron55 |
and dynamically generated tracks need to be neatly supported |
| 09:44 |
celeron55 |
the traditional use case also has to work well, which is to have a sample set for music instruments, and the track that uses those samples, which as a combined unit make one playable song. and the song needs to be easily composable in existing external tools |
| 09:45 |
celeron55 |
if suitable tools don't exist due to whatever reason, then of course somehow deal with that |
| 09:46 |
MTDiscord |
<jordan4ibanez> How many channels would we limit the music to? |
| 09:47 |
celeron55 |
idk, a modern standard is probably 16, but maybe 8 is fine if the effects capability is substantial. that will depend on if an existing standard is able to be adopted |
| 09:48 |
celeron55 |
i strongly suggest trying to use something that's already out there |
| 11:43 |
MTDiscord |
<mistere_123> let me guess - it will be defined using "strings with a somewhat unusual syntax" |
| 11:46 |
MTDiscord |
<et086> can we not do that |
| 11:46 |
MTDiscord |
<mistere_123> well yes but actually no |
| 11:49 |
MTDiscord |
<jordan4ibanez> wow that's truly a horrible idea, someone implement it |
| 12:29 |
|
Desour joined #minetest-dev |
| 12:32 |
celeron55 |
ah yes, the trackerspec |
| 12:46 |
Desour |
I planned to add tracker music using libopenmpt, but didn't come to do it yet. there's also an issue, for completeness: #3878 |
| 12:46 |
ShadowBot |
https://github.com/minetest/minetest/issues/3878 -- Tracker music support |
| 12:47 |
Desour |
for tts, one could take moonbase alpha as an inspiration: https://www.youtube.com/watch?v=CNPKXfb3rws |
| 12:48 |
MTDiscord |
<mistere_123> There's no way to make texture-modifiers-created textures not eat ram permanently, is there? I have a fairly detailed HUD that get's created with texture modifiers (its a custom minimap) and then updated every globalstep. I could reduce the updates to every second, but that is jank and only mitigates the problem |
| 12:49 |
MTDiscord |
<mistere_123> https://cdn.discordapp.com/attachments/747163566800633906/1266376831662161951/image.png?ex=66a4ecd4&is=66a39b54&hm=a39ac30f59c10ef39d14a6d6113f9b9733825aaeebb6ddee441da9f00a6d5745& |
| 12:49 |
Desour |
correct, there is no way. textures are never unloaded, afaik |
| 12:51 |
MTDiscord |
<mistere_123> is there any solution to avoid eating ram other than to just give up on the minimap? |
| 12:51 |
Desour |
you could use multiple hud elements. (discussion might be better suited in #minetest, btw) |
| 12:55 |
celeron55 |
it would be nice to be able to unload textures or rewrite existing textures but i'm pretty sure that's going to take a lot of work (prove me wrong if you'd like, of course) |
| 12:58 |
MTDiscord |
<mistere_123> discussion moved to #minetest |
| 13:05 |
Desour |
!tell Mantar https://irc.minetest.net/minetest-dev/2024-07-22#i_6186833 <-- I hope there was something really screwy to you compile. if you can reproduce with a debug build, it would be a new regression |
| 13:05 |
ShadowBot |
Desour: An error has occurred and has been logged. Please contact this bot's administrator for more information. |
| 13:16 |
MTDiscord |
<mistere_123> Idea: a texture buffer that is named at startup and references a named texture modifier string Example api: on server startup minetest.register_dynamic_texture_buffer("mymod:minimap_buffer", "blank.png") On minigame start, -- regular HUD definition { ... text = "mymod:minimap_buffer", ... } when I want to update the HUD: build my minimap texture string using texture modifiers and save it in a variable |
| 13:16 |
MTDiscord |
minimap_texture minimap_texture = "<texture modifiers here>" minetest.update_dynamic_texture_buffer(player, "mymod:minimap_buffer", minimap_texture) |
| 13:45 |
MTDiscord |
<mistere_123> https://github.com/minetest/minetest/issues/3528 |
| 13:45 |
MTDiscord |
<mistere_123> since 2016 |
| 16:22 |
|
clavi joined #minetest-dev |
| 16:22 |
|
clavi joined #minetest-dev |
| 17:45 |
celeron55 |
your minimap is probably one of the first documented sane use cases for such a feature |
| 17:45 |
celeron55 |
and doesn't totally match that issue |
| 17:46 |
celeron55 |
the issue is about replacing the image contents, while what you are doing is basically a runtime-modifiable image alias |
| 17:46 |
celeron55 |
or, i mean, texture alias |
| 17:46 |
celeron55 |
remember: texture modifiers are part of the texture name |
| 17:47 |
celeron55 |
or, not really doing, but suggesting or needing |
| 17:48 |
celeron55 |
you could make a new issue for it |
| 17:49 |
celeron55 |
i think what that issue is requesting probably wouldn't even be useful to you as you aren't generating the textures server-side, nor have any need to |
| 17:50 |
celeron55 |
maybe this does the ping on the discord side: @mistere_123 |
| 17:51 |
MTDiscord |
<wsor4035> (yes) |
| 17:56 |
|
Noisytoot joined #minetest-dev |
| 17:57 |
MTDiscord |
<mistere_123> I'm not sure what you mean by "not generating the textures server-side" celeron55 I do a lot of complex concatenation of texture modifier strings, on the server (ideally on the globalstep but now every second to mitigate the issue) to get the final minimap image. |
| 17:58 |
celeron55 |
yes, but that's not actually doing anything to any textures on the server, you are not generating texture data on the server |
| 17:59 |
celeron55 |
the client already has all the data |
| 17:59 |
celeron55 |
there is nothing to send, in terms of texture data |
| 17:59 |
MTDiscord |
<mistere_123> ah, i.e. all the parts are already on the client |
| 17:59 |
celeron55 |
thus, you cannot update a texture to do what you want |
| 17:59 |
celeron55 |
you are only updating the texture name |
| 18:00 |
celeron55 |
or, essentially the recipe for how to come up with the final texture data by combining existing textures, which is done by the client, without transfer of texture data itself |
| 18:00 |
MTDiscord |
<mistere_123> Well, if an updatable texture accepted texture modifiers that would solve my issue. But all I really need is for the client to not store the texture modifier result in ram after it's been shown once |
| 18:00 |
MTDiscord |
<mistere_123> So, what should the new issue look like/say? |
| 18:03 |
celeron55 |
shown once? i'm sure it's shown on the screen continuously, which means irrlicht has to have the data available. but yes, it is true that textres generated by texture modifiers are a special case that could be automatically deleted when they haven't been used for a while, because the client can re-generate them immediately, synchronously, on the next use |
| 18:03 |
celeron55 |
this is very different to the textures sent by the server as texture data. the client can't drop those, because it may need the data at any time |
| 18:04 |
celeron55 |
either to be shown directly or as part of generating a final texture based on texture modifiers |
| 18:04 |
celeron55 |
i think creating an issue that requests this feature is your best bet |
| 18:04 |
MTDiscord |
<mistere_123> I feel like this is sorta a bug report as well as a feature request |
| 18:04 |
celeron55 |
you have other options too, but i think more people will agree with this |
| 18:08 |
MTDiscord |
<warr1024> I'm pretty sure we've already got at least one issue in for "we should be disposing of textures to free RAM once they're no longer used". There are now multiple ways of creating single-use media, including texture modifiers and dynamic media, at least. Whether or not any of those is good for any particular use-case, the fact that all of them eventually lead to client OOM is a serious problem. |
| 18:11 |
celeron55 |
my point here is, texture modifiers provide a unique and basically trivial opportunity to do it |
| 18:11 |
celeron55 |
for anything else, you don't know when it can be disposed |
| 18:11 |
celeron55 |
for modified textures, you can dispose it safely at any time (but in practice shouldn't drop things that are being rendered every frame) |
| 18:12 |
celeron55 |
it's very different and doesn't have the profound challenge of trying to do it to anything else |
| 18:12 |
MTDiscord |
<mistere_123> for when it can be disposed: You can have an api call that purposefully says to dispose of a specific texture |
| 18:13 |
MTDiscord |
<warr1024> it's not necessarily a profound challenge to require the modder to make the decision. In fact, it would be perfectly tolerable to do that even in the case of texture mods. |
| 18:13 |
celeron55 |
mistere_123: yeah, and what if the call is made for a texture that nevertheless ends up being pointed to by data that irrlicht is using to render the scene? yay, that's a segfault or something |
| 18:13 |
MTDiscord |
<mistere_123> This, but I need a solution not an ideal solution |
| 18:14 |
MTDiscord |
<mistere_123> C55: point all dropped textures to no_texture.png? |
| 18:14 |
celeron55 |
well i suppose irrlicht's refcounting will handle it in some way somewhere on the line and us dropping it from the texture source (the client's texture database) won't hurt |
| 18:14 |
MTDiscord |
<warr1024> Texture modifiers are not "instant", it just depends a ton on the actual texture and actual modifiers. The synchronous nature of them can make them actually quite a pain to display suddenly in the middle of gameplay, and I've employed some hacks (e.g. make them node textures) to try to avoid this in certain cases. It might really make sense to have the modder be able to register textures to pre-generate that aren't tied to nodes, |
| 18:14 |
MTDiscord |
and allow them to request e.g. background generation manually. |
| 18:14 |
MTDiscord |
<mistere_123> At this point I'm out of my league |
| 18:15 |
MTDiscord |
<warr1024> I'm just saying that rather than dealing with the complication of figuring out what we can/should load/unload and when, it's perfectly acceptable to punt it to the modders, as right now, as it would allow us to solve a problem that currently we have NO way to solve. |
| 18:16 |
celeron55 |
warr1024: yes, as a technique it does have some inherent issues like that, while safety not being one of them |
| 18:17 |
celeron55 |
anyway, don't forget mistere_123's use case |
| 18:17 |
MTDiscord |
<warr1024> It's good, at least, that texture generation lag generally only affects people at the extreme low end of system performance right now. The only place I see it consistently is when people use ^[opacity: to fade in a full-screen HUD overlay; those tend to have fairly large image sizes. |
| 18:17 |
celeron55 |
when thinking about it like that, you may end up not solving the use case at all, but rather some other use cases |
| 18:18 |
celeron55 |
asking the client to drop a dynamic texture is completely useless if what you want is the client to drop the cached version of a modified texture |
| 18:18 |
MTDiscord |
<warr1024> If we had the ability to manually ask the client to dispose an image, MisterE's use-case would be handled by just having the server-side mod keep track of which textures it's asked the client to load/generate, and then "releasing" them from the back end of the queue. |
| 18:18 |
MTDiscord |
<mistere_123> https://github.com/minetest/minetest/issues/14884 |
| 18:19 |
celeron55 |
warr1024: personally, i'd first want to just have the automatic dropping of modified textures and see how it does. but if you predict it will cause lag spikes, that's a reason to not go that route |
| 18:20 |
celeron55 |
in any case it probably should be implemented anyway |
| 18:21 |
celeron55 |
and the mod should more like provide a list of texture names to NOT drop |
| 18:21 |
MTDiscord |
<warr1024> The main reason I'd rather go with manual than automatic is that automatic tends to instigate a lot of bikeshedding from people trying to decide WHEN it's the right time to drop a texture automatically, and then there's the potential of modders complaining that it's too aggressive, or not aggressive enough. On the other hand, if you do it manually, then modders can figure it out themselves, and you can avoid a lot of the engine-level |
| 18:21 |
MTDiscord |
bikeshedding. |
| 18:21 |
MTDiscord |
<warr1024> If you're confident that automatic will work without a bunch of political fallout, then that's fine for me too. |
| 18:21 |
MTDiscord |
<mistere_123> Warr1024: yes, if the texture to drop is identified by the complete generated texture modifier string, then I can save a queue of generated and sent strings and request the client to drop them after I have sent the next one. |
| 18:22 |
MTDiscord |
<jordan4ibanez> What about both |
| 18:22 |
celeron55 |
in the end i'm fine with any solution that makes mistere_123 happy for now. the explicit drop requests are probably the simplest to implement |
| 18:23 |
MTDiscord |
<warr1024> both would just be more work ... I'd do one or the other first, at least, and then we can add the other one later if we think we need it. |
| 18:23 |
MTDiscord |
<jordan4ibanez> What if you can tell the engine to drop manually, let's say if you're rendering a doom clone to 6 textures, you want to revert then clear, or you can just let the engine time out the texture |
| 18:23 |
MTDiscord |
<mistere_123> Warr1024: to your point about when to drop a texture, C55's point is that it is always safe to drop a texture modifier generated texture since it can just be regenerated ... so a good rule of thumb is to wait a bit until the texture has not been used for a while and then drop it |
| 18:23 |
MTDiscord |
<jordan4ibanez> Render, not revert |
| 18:24 |
MTDiscord |
<mistere_123> As for what makes me happy: A solution, within a year |
| 18:25 |
MTDiscord |
<mistere_123> any solution that I can twist into working that doesnt fill ram |
| 18:25 |
MTDiscord |
<mistere_123> and doesnt look ugly |
| 18:25 |
MTDiscord |
<warr1024> MisterE: we CAN drop a texture then, but SHOULD we? Keeping them around a little longer, if we have the RAM, could be a reasonable time/speed tradeoff to avoid regenerating them all the time. Then you get into questions about MRU vs MFU strategies and such. Even with a simple "if it hasn't been used in 60 seconds" strategy, we'll have to argue about how long of a timeout, and then we'll end up adding a setting for it, and then |
| 18:25 |
MTDiscord |
we'll argue about what the default value should be 😆 |
| 18:25 |
MTDiscord |
<jordan4ibanez> free_texture(blah) |
| 18:26 |
MTDiscord |
<warr1024> In any event, I've had this problem for at least a couple of years now, and it's held me back from doing certain things with my skyboxes. |
| 18:26 |
MTDiscord |
<warr1024> I've got a mitigation in place but it has pretty seriously shitty effects on gameplay |
| 18:26 |
MTDiscord |
<mistere_123> Arguement should be postponed until future setting-default-optimization PRs |
| 18:27 |
MTDiscord |
<jordan4ibanez> You also have to keep in mind the server is generating the texture and the client is now storing it, and it's getting puppeted. unless it's not and I have no idea how it works anymore |
| 18:27 |
MTDiscord |
<jordan4ibanez> So the server will tell the client to free or something |
| 18:27 |
MTDiscord |
<warr1024> "Just do it in some okay way, and then leave the arguments about how to do it perfectly for later" has not historically been the Minetest Way. |
| 18:28 |
MTDiscord |
<jordan4ibanez> That's how the entire engine was built though |
| 18:28 |
MTDiscord |
<warr1024> jordan4ibanez: in this case, the server isn't necessarily generating any textures, it's just generating a name that the client will use to generate the textures. |
| 18:28 |
MTDiscord |
<mistere_123> Having the feature at all is better than not. Choose a default timeout of 5 mins and call it a day. Better to consume some memory but not have a leak than to have a leak or be constricted to not using the power of texture mods |
| 18:29 |
MTDiscord |
<warr1024> I don't know why you're continuing to argue for simplifying the complicated version instead of just starting with the simple version from the start 😆 |
| 18:30 |
MTDiscord |
<warr1024> If you're gonna DO it, then I guess you can do either version |
| 18:31 |
MTDiscord |
<warr1024> If it's doing to be done by somebody who's not already married to a particular approach, I'd just tell them that we, as modders, would be glad to tell the engine when it can release a texture, and they can rely on that information if they want. |
| 18:31 |
MTDiscord |
<mistere_123> I don't have the skill or time to do it. I'm argueing for a way, and I really don't care whether it's a simplified complicated version, a complicated simple version of a fix, as long as it works |
| 18:31 |
MTDiscord |
<jordan4ibanez> I now pronounce you, pr and programmer, you may now seg the fault |
| 18:32 |
MTDiscord |
<warr1024> The fact that we're right here bikeshedding about whether to use the bikesheddable approach or not is some evidence that there's a significant risk of bikeshedding. |
| 18:32 |
MTDiscord |
<mistere_123> XD |
| 18:34 |
|
SingleDigitIq joined #minetest-dev |
| 18:35 |
MTDiscord |
<mistere_123> Fun, now there's a possible close on my issue |
| 18:35 |
|
SingleDigitIq joined #minetest-dev |
| 18:36 |
MTDiscord |
<mistere_123> alright, I guess it's mitigated memory-leak for now until the politics settle |
| 18:38 |
MTDiscord |
<mistere_123> Lars is not wrong that its a duplicate, though the issue could be named better |
| 18:39 |
MTDiscord |
<josiah_wi> I feel like if contributors came with a "I'm here to help what can I do to give back" attitude instead of a "hey I want to code this cool thing for myself please merge my PR" development would move faster and there'd be less bugs. |
| 18:40 |
MTDiscord |
<warr1024> I kind of hate when a newer, better version of an issue gets closed as a "duplicate" of an older one that doesn't cover the issue properly ... and then at best the newer info is just dumped into the comments of the old issue, so you have to read some huge thread to find out what the actual issue is anymore. |
| 18:41 |
MTDiscord |
<mistere_123> yep, but other than that what do we do about the 5 similar issues that describe the same issue :shr |
| 18:41 |
MTDiscord |
<josiah_wi> To be clear, I'm not talking about you here, MisterE. You're bringing up a real issue that needs a solution. I just feel that everybody's excitement to do their own thing results in issues like yours never getting fixed. |
| 18:41 |
MTDiscord |
<warr1024> Josiah: FOSS is mostly about "scratch your own itch" though, and mostly it works because people share common itches. If we had to have a spirit of charity to be able to contribute, there would be a lot less opportunity for ordinary people to do so. |
| 18:43 |
MTDiscord |
<josiah_wi> I'm just suggesting finding those unordinary people so we can have something we can be proud of. |
| 18:43 |
MTDiscord |
<mistere_123> Well that's what you get when you aren't paid. I guess the commercial client who I am working for could choose to place a bounty, or even develop a PR, to fix the issue |
| 18:44 |
MTDiscord |
<warr1024> The pool of people who can and would contribute significantly is small enough that it's very hard to predict what kind of approach would actually motivate people. |
| 18:44 |
MTDiscord |
<warr1024> Lars, at least, had expressed interest in this problem at one point, maybe the thing to do is just ask them 😄 |
| 18:44 |
MTDiscord |
<mistere_123> sfan5 seems to be the type you are referring to josiah, thank God for him, we would be in a lot worse shape now without the backend contributions that don't seem very fun. |
| 18:45 |
MTDiscord |
<mistere_123> but adding new features is important as well |
| 18:45 |
MTDiscord |
<josiah_wi> Yeah, it seems like sfan5 kind of carries the whole project on his back. |
| 18:45 |
MTDiscord |
<josiah_wi> Lars is new, but he's doing quite a bit now as well. |
| 18:48 |
MTDiscord |
<mistere_123> ok. |
| 18:48 |
MTDiscord |
<mistere_123> https://cdn.discordapp.com/attachments/747163566800633906/1266467281454502081/image.png?ex=66a54111&is=66a3ef91&hm=c96a9ce8b8a01ae4fba220634ee3929ab48e3df4dbf8497df25d9f28ee9302b3& |
| 18:51 |
MTDiscord |
<warr1024> 😼 |
| 19:07 |
|
v-rob joined #minetest-dev |
| 19:10 |
v-rob |
I feel like the far better option than allowing modders to drop textures is to use render textures. Rather than making dynamic textures by creating a new image for each texture modifier, you could create a single image with `minetest.create_dynamic_texture("name", width, height)` and send commands to modify this texture in place. No memory leaks, no messing about with dropping textures. |
| 19:11 |
v-rob |
I'll bet that would solve 90% of issues with modders who need to use insane amounts of ^[combine to create dynamic textures like signs or minimaps. |
| 19:13 |
MTDiscord |
<warr1024> So, like, making textures mutable and modifying them in-place? That could be kind of cool, but it sounds more like a "further down the road" kind of thing. Even if we added it now, we'd still have the broken old feature in there to deal with... |
| 19:15 |
v-rob |
I dunno if texture modifiers are "broken"--I use them a lot in node definitions, where I never want them to be unloaded. They seem to be a reasonable solution for certain types of usages. I wouldn't want to have to use a dynamic texture for many simple texture modifier use-cases. |
| 19:15 |
Mantar |
that approach would work for Exile's seasonal changes, currently we have to swap out grassy nodes with dead grassy nodes for winter, but if we could just instruct the client to update the texture on the regular grassy nodes, then that'd save a ton of map updating |
| 19:17 |
v-rob |
Explicitly dropping texture modifiers, incidentally, would stink as a modder. To drop `a^[transformFX^[mask:mask.png`, you'd have to drop `a^[transformFX` as well since all intermediate texture modifiers are cached. |
| 19:18 |
v-rob |
I came up with a proof-of-concept API that allowed in-place texture modification from Lua once upon a time, but it was client-side only. It could easily be done server-side with a network layer. |
| 19:29 |
celeron55 |
v-rob: the "live updateable named texture" would probably allow a lot of things |
| 19:30 |
MTDiscord |
<warr1024> Intermediate modifiers ARE cached? That's new to me. Last time I heard they weren't. |
| 19:44 |
celeron55 |
uhm, does minetest.dynamic_add_media() allow updating the content of the file? |
| 19:44 |
MTDiscord |
<mistere_123> v-rob: I would be satisfied with that approach as well, as long as all the modifiers I need are available to it one way or another (I make heavy use of combine, resize, etc) |
| 19:45 |
MTDiscord |
<mistere_123> All intermediate textures are cached? That's is awful |
| 19:46 |
celeron55 |
because if it (minetest.dynamic_add_media()) allows, or would be made to allow updating the content, then doesn't/wouldn't it allow doing some of this stuff? |
| 19:46 |
MTDiscord |
<mistere_123> the ram leak is worse than I thought |
| 19:46 |
MTDiscord |
<mistere_123> celeron55, no, that has been the next major feature request for the dynamic_add_media saga |
| 19:47 |
MTDiscord |
<mistere_123> for just this sort of thing |
| 19:47 |
celeron55 |
is there something that makes it hard |
| 19:47 |
celeron55 |
it seems like potentially a very small change |
| 19:47 |
MTDiscord |
<mistere_123> Yet one which has not been done 😦 |
| 19:47 |
celeron55 |
well i don't know whether it is |
| 19:48 |
celeron55 |
https://github.com/minetest/minetest/issues/11640 |
| 19:49 |
celeron55 |
at least there's an issue about it |
| 19:50 |
MTDiscord |
<mistere_123> meanwhile, added visible and off-screen waypoints to the minimap, RIP ram |
| 19:50 |
MTDiscord |
<mistere_123> https://cdn.discordapp.com/attachments/747163566800633906/1266482677528137788/image.png?ex=66a54f68&is=66a3fde8&hm=40eef9169fea3f043e4e74d759b60344e092efa91b95b7d19ae3952b51811a4b& |
| 19:51 |
celeron55 |
i think 11640 is probably the low hanging fruit here |
| 19:52 |
celeron55 |
what even happens if you try to update previously added dynamic media? |
| 19:53 |
celeron55 |
errorstream << "Server::dynamicAddMedia(): file \"" << filename |
| 19:53 |
celeron55 |
<< "\" already exists in media cache" << std::endl; |
| 19:53 |
celeron55 |
apparently, this |
| 19:53 |
celeron55 |
an explicit conditional and error message |
| 19:54 |
MTDiscord |
<mistere_123> And what happens if that is removed? |
| 19:57 |
MTDiscord |
<mistere_123> Wait A Minute: |
| 19:57 |
MTDiscord |
<mistere_123> https://cdn.discordapp.com/attachments/747163566800633906/1266484466453450943/image.png?ex=66a55112&is=66a3ff92&hm=1d102287c441d25ec1d9eee2a436cc60181d172c198e748a0fc33aa649014cc6& |
| 19:57 |
MTDiscord |
<mistere_123> if I used ephemeral ... for an image ... is that a solution of some sort? |
| 19:57 |
celeron55 |
well that's the start |
| 19:58 |
MTDiscord |
<mistere_123> "it will not be cached on the client" what does that mean exactly? |
| 19:58 |
celeron55 |
that refers to the disk cache |
| 19:58 |
MTDiscord |
<mistere_123> ah, not ram 😦 |
| 19:58 |
celeron55 |
modified textures don't go there to begin with |
| 19:58 |
celeron55 |
they are quite similar to the ephemeral dynamic ones, i suppose |
| 19:59 |
MTDiscord |
<mistere_123> Well, even if I used other / custom image manipulation software to get the image data, and then send it via dynamic media, that would be better than a ram leak ... but in this case, it is still stored in ram like all the other media resulting in a mem leak, right? |
| 20:00 |
MTDiscord |
<mistere_123> just not cached for future connections |
| 20:00 |
sfan5 |
"And what happens if that is removed?" the client rejects the duplicate file |
| 20:01 |
sfan5 |
if you remove the check on the client it probably doesn't work either |
| 20:01 |
celeron55 |
i'm trying to follow the code path there and i haven't yet stumbled upon where it's rejected |
| 20:02 |
sfan5 |
for replacing textures there's an easy and seamless way that only works if the dimensions stay the same, so you can just overwrite the data of the existing texture. |
| 20:03 |
sfan5 |
otherwise you get into a game of keeping track of and chasing down the pointers in use to the texture of this particular name so you can swap them out |
| 20:04 |
celeron55 |
it seems like it might go through all the way into being loaded to the client's image cache |
| 20:04 |
sfan5 |
hm, yeah could be |
| 20:04 |
celeron55 |
but any tilespecs or meshes or such will contain a reference to the old texture, i suppose |
| 20:04 |
celeron55 |
however, MisterE is using it in the HUD |
| 20:04 |
celeron55 |
it might update |
| 20:05 |
MTDiscord |
<luatic> iirc the tile image cache caches everything infinitely unconditionally |
| 20:05 |
sfan5 |
but a texture is only built from the image cache once, is it? |
| 20:05 |
celeron55 |
that's likely |
| 20:06 |
MTDiscord |
<mistere_123> The final minimap image is always the same size on the HUD |
| 20:06 |
celeron55 |
it won't be impossible to make a propagation system that just goes through everything and updates it, i guess, but that will take some work |
| 20:06 |
celeron55 |
and it might be slow |
| 20:07 |
celeron55 |
how slow? well, like "invalidate all meshes" slow |
| 20:07 |
MTDiscord |
<mistere_123> I mentioned on the 11640 issue, but I'll put a $100 bounty on this |
| 20:07 |
MTDiscord |
<luatic> well. as for the theoretical long-term goal, that would be to implement a texture api, but that belongs to the client, imo. |
| 20:07 |
MTDiscord |
<luatic> short-term it seems like either some form of GC for unused textures or the ability to swap out textures will do the job |
| 20:10 |
MTDiscord |
<luatic> the texture swapping feature is also wanted in the context of artists wanting to hot reload changes in game |
| 20:10 |
celeron55 |
if the source image on the client would be accompanied by a reference to the texture that was generated from it, the texture could definitely be updated if the image stays the same size, but i don't really see why resizing the existing texture wouldn't also be possible |
| 20:11 |
celeron55 |
might take quite some digging |
| 20:11 |
sfan5 |
if it doesn't resize you can skip propgatation. just upload new data to the GPU, the ITexture* stays the same |
| 20:11 |
celeron55 |
or just trying it out and see what sticks |
| 20:11 |
MTDiscord |
<luatic> celeron55: as for slowness, swapping a texture should just invalidate all textures that depend on it. with a proper index this should be efficient. |
| 20:26 |
MTDiscord |
<warr1024> Making dynamic media required for memory management would be quite a hurdle for modders. We'd need a way to run texture modifiers server-side, and then we'd have to suffer the cost of transferring the resultant image over the network. |
| 20:27 |
MTDiscord |
<mistere_123> It would be possible to have server-side image manipulation libs |
| 20:27 |
MTDiscord |
<warr1024> It would be possible, but it would make a lot of existing stuff way harder |
| 20:27 |
MTDiscord |
<mistere_123> without the hassle of "strings with a somewhat unusual syntax" ... might be worth it |
| 20:28 |
MTDiscord |
<mistere_123> I really love that quote from the api, it describes the problem perfectly while ignoring it completely |
| 20:29 |
sfan5 |
if you don't want to generate textures server-side it sounds like you want the API v-rob mentioned yesterday |
| 20:29 |
MTDiscord |
<warr1024> while texturemod strings may be weird, they're a far more efficient way to adjust the position of layers in a skybox than sending a fresh png each time |
| 20:30 |
MTDiscord |
<warr1024> v-rob's API would be fine, but we already have texture modifiers that do what I need in that regard. |
| 20:30 |
MTDiscord |
<mistere_123> My point is that I don't really care how I have to generate the textures, as long as I have complete control in some manner and can avoid a memory leak |
| 20:30 |
sfan5 |
v-rob's API *is* existing textures modifiers |
| 20:31 |
sfan5 |
or at least that's how I understood it |
| 20:32 |
MTDiscord |
<warr1024> It was pretty nebulous |
| 20:33 |
MTDiscord |
<warr1024> like it sounded like maybe you could draw over top of an existing texture, but then there'd be no reason why you couldn't replace it entirely that way from external sources, so it could work |
| 20:33 |
MTDiscord |
<warr1024> but I suppose a lot of it would depend on what the actual protocol for texture construction looked like and how easy it would be to port the existing features we're using texture mods for. |
| 20:34 |
sfan5 |
I was thinking more you specify an existing texture and can seamlessly swap out the modifiers on-top ideally without leaving junk in the cache |
| 20:43 |
|
v-rob joined #minetest-dev |
| 20:46 |
MTDiscord |
<warr1024> I guess we'd have to give constructed textures aliases, so we'd have a sane way to address them. We could continue to use the "implicit name" of the first texture string used to initially construct it, but that could feel weird after we'd changed it. |
| 20:48 |
|
v-rob_ joined #minetest-dev |
| 20:49 |
|
v-rob joined #minetest-dev |
| 20:53 |
|
v-rob__ joined #minetest-dev |
| 20:54 |
|
v-rob joined #minetest-dev |
| 20:54 |
v-rob |
> v-rob's API *is* existing textures modifiers |
| 20:54 |
v-rob |
Well no. Texture modifiers create new static textures. My proposal is to use render target textures. No new textures are created, although Irrlicht doesn't currently provide any way to resize the texture (you can draw textures of any size onto this texture, however) |
| 20:58 |
MTDiscord |
<warr1024> So, say, I could define a skybox with something like "blank.png^skybox_top.png", and then later I could say modify_texture("blank.png^skybox_top.png", "^skybox_top_glow.png") to add a glowing effect texture over it, and then maybe later modify_texture(""blank.png^skybox_top.png", "^skybox_top.png") to redraw the original and remove the glow? |
| 20:58 |
MTDiscord |
<warr1024> or would it be like a "replacement" protocol unless I explicitly included the original texture in the name? |
| 20:58 |
|
v-rob_ joined #minetest-dev |
| 20:59 |
v-rob_ |
Here's a very bad video illustrating the earlier proof-of-concept. The textures are dynamic and modified in-place. https://www.youtube.com/watch?v=87iyesNooFI |
| 21:02 |
v-rob_ |
The API would be something like `local x = minetest.create_texture("name", 64, 64); x:draw_rect(0, 0, 32, 32, "blue"); x:draw_image(16, 16, 32, 32, "air.png")`, and the `:draw()` calls would be batched up and sent to the client. |
| 21:02 |
v-rob_ |
Or maybe a single `:draw()` call that takes a table of actions to perform. Something like this anyway |
| 21:03 |
v-rob_ |
Actually, probably more like `minetest.draw("name", ...)` rather than returning an object. |
| 21:04 |
v-rob_ |
I'm just riffing off the CSM API that I had earlier. Obviously I'd need to think about how best to design the API, but I'm quite certain it's feasible. |
| 21:04 |
sfan5 |
that's basically inventing a new api for texture modifiers |
| 21:04 |
v-rob_ |
No it's not. Look at the video--it's a render texture. |
| 21:05 |
v-rob_ |
Texture modifiers can't do that, because they're a static image created by a static string. |
| 21:05 |
v-rob_ |
In the code, you set the texture of the item to the name of your custom image, and the texture itself changes, not the texture string. |
| 21:06 |
sfan5 |
I get that part |
| 21:06 |
sfan5 |
but conceptually `x:draw_image(16, 16, 32, 32, "air.png")` is just a different way of invoking some semi-complicated `^[combine` string |
| 21:07 |
sfan5 |
so we end up with two different APIs to assemble textures. one for dynamic ones and one for static ones |
| 21:08 |
v-rob_ |
Definitely, except that "^[combine" is part of the texture name, so you can't update it on-the-fly. You can call `draw_image()` as many times as you like at any point. You can't retroactively add "^[combine" to an existing texture, only create a new texture. |
| 21:08 |
MTDiscord |
<warr1024> We could just use texture modifiers as the protocol for specifying how to construct things, but the "create_texture("name", "spec")" aspect would still be pretty new. |
| 21:08 |
v-rob_ |
I don't particularly like the fact that there are two APIs either. Ideally we'd have single APi |
| 21:09 |
v-rob_ |
Problem is, I don't know of any way to resize a texture in place. Maybe you can do it in ITexture, but that'd take some investigating. So the APIs would have different capabilities if only for that single reason. |
| 21:10 |
MTDiscord |
<warr1024> oh tricky |
| 21:10 |
v-rob_ |
That is, since ITexture wraps the OpenGL texture, it might be possible to swap out the texture internally. I have zero idea if that's possible because I don't know the internals of Irrlicht very well at all. |
| 21:10 |
MTDiscord |
<warr1024> tbf texture modifiers are not "good" with texture sizing either. Like if you have a texturepack that overrides a texture with one of a different size, you can end up with a very different result when textures are combined by modifiers. |
| 21:12 |
v-rob_ |
If we didn't have texture modifiers already, I don't think the lack of resizing would be a problem. The example I had above drew a 32x32 version of the 16x16 "air.png" image. If you make your render texture big enough from the start, then you have full control of the size of anything you draw onto it. |
| 21:18 |
v-rob_ |
There would be other texture modifiers would be problematic, like [invert or [hsl. You'd need to do things with shaders, or access the texture via software (a slow method). However, I think the majority of use-cases would still be solved if you had an API with only the abilities of `draw_texture()`. |
| 21:25 |
v-rob_ |
On the other hand, you could render arbitrary 3D stuff to a render texture. I can't think of many use-cases of that for modders though. |
| 21:29 |
v-rob_ |
"Hi, I need a dynamic image that I can draw other images on" "OK, here's a full 3D pipeline" |
| 21:36 |
|
v-rob_ joined #minetest-dev |
| 22:32 |
|
panwolfram joined #minetest-dev |
| 23:05 |
|
Eragon joined #minetest-dev |
