Time Nick Message 07:03 MTDiscord of course, the API won't evolve past its initial state, so this will remain the only quality level available 07:03 MTDiscord why not minetest.tts(options)? 07:04 MTDiscord also a way to query what is actually available 07:04 MTDiscord 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 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 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 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 See I can't even think of a good idea for this 09:28 MTDiscord 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 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 let me guess - it will be defined using "strings with a somewhat unusual syntax" 11:46 MTDiscord can we not do that 11:46 MTDiscord well yes but actually no 11:49 MTDiscord wow that's truly a horrible idea, someone implement it 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 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 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 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 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 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 = "" minetest.update_dynamic_texture_buffer(player, "mymod:minimap_buffer", minimap_texture) 13:45 MTDiscord https://github.com/minetest/minetest/issues/3528 13:45 MTDiscord since 2016 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 (yes) 17:57 MTDiscord 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 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 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 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 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 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 for when it can be disposed: You can have an api call that purposefully says to dispose of a specific texture 18:13 MTDiscord 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 This, but I need a solution not an ideal solution 18:14 MTDiscord 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 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 At this point I'm out of my league 18:15 MTDiscord 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 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 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 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 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 If you're confident that automatic will work without a bunch of political fallout, then that's fine for me too. 18:21 MTDiscord 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 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 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 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 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 Render, not revert 18:24 MTDiscord As for what makes me happy: A solution, within a year 18:25 MTDiscord any solution that I can twist into working that doesnt fill ram 18:25 MTDiscord and doesnt look ugly 18:25 MTDiscord 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 free_texture(blah) 18:26 MTDiscord 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 I've got a mitigation in place but it has pretty seriously shitty effects on gameplay 18:26 MTDiscord Arguement should be postponed until future setting-default-optimization PRs 18:27 MTDiscord 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 So the server will tell the client to free or something 18:27 MTDiscord "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 That's how the entire engine was built though 18:28 MTDiscord 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 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 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 If you're gonna DO it, then I guess you can do either version 18:31 MTDiscord 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 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 I now pronounce you, pr and programmer, you may now seg the fault 18:32 MTDiscord 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 XD 18:35 MTDiscord Fun, now there's a possible close on my issue 18:36 MTDiscord alright, I guess it's mitigated memory-leak for now until the politics settle 18:38 MTDiscord Lars is not wrong that its a duplicate, though the issue could be named better 18:39 MTDiscord 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 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 yep, but other than that what do we do about the 5 similar issues that describe the same issue :shr 18:41 MTDiscord 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 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 I'm just suggesting finding those unordinary people so we can have something we can be proud of. 18:43 MTDiscord 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 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 Lars, at least, had expressed interest in this problem at one point, maybe the thing to do is just ask them 😄 18:44 MTDiscord 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 but adding new features is important as well 18:45 MTDiscord Yeah, it seems like sfan5 kind of carries the whole project on his back. 18:45 MTDiscord Lars is new, but he's doing quite a bit now as well. 18:48 MTDiscord ok. 18:48 MTDiscord https://cdn.discordapp.com/attachments/747163566800633906/1266467281454502081/image.png?ex=66a54111&is=66a3ef91&hm=c96a9ce8b8a01ae4fba220634ee3929ab48e3df4dbf8497df25d9f28ee9302b3& 18:51 MTDiscord 😼 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 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 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 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 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 the ram leak is worse than I thought 19:46 MTDiscord celeron55, no, that has been the next major feature request for the dynamic_add_media saga 19:47 MTDiscord 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 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 meanwhile, added visible and off-screen waypoints to the minimap, RIP ram 19:50 MTDiscord 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 And what happens if that is removed? 19:57 MTDiscord Wait A Minute: 19:57 MTDiscord https://cdn.discordapp.com/attachments/747163566800633906/1266484466453450943/image.png?ex=66a55112&is=66a3ff92&hm=1d102287c441d25ec1d9eee2a436cc60181d172c198e748a0fc33aa649014cc6& 19:57 MTDiscord 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 "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 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 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 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 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 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 I mentioned on the 11640 issue, but I'll put a $100 bounty on this 20:07 MTDiscord 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 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 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 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 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 It would be possible to have server-side image manipulation libs 20:27 MTDiscord It would be possible, but it would make a lot of existing stuff way harder 20:27 MTDiscord without the hassle of "strings with a somewhat unusual syntax" ... might be worth it 20:28 MTDiscord 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 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 v-rob's API would be fine, but we already have texture modifiers that do what I need in that regard. 20:30 MTDiscord 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 It was pretty nebulous 20:33 MTDiscord 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 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:46 MTDiscord 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: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 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 or would it be like a "replacement" protocol unless I explicitly included the original texture in the name? 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 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 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 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"