Minetest logo

IRC log for #minetest-dev, 2024-07-26

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

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&amp;is=66a39b54&amp;hm=a39ac30f59c10ef39d14a6d6113f9b9733825aaeebb6ddee441da9f00a6d5745&amp;
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&amp;is=66a3ef91&amp;hm=c96a9ce8b8a01ae4fba220634ee3929ab48e3df4dbf8497df25d9f28ee9302b3&amp;
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&amp;is=66a3fde8&amp;hm=40eef9169fea3f043e4e74d759b60344e092efa91b95b7d19ae3952b51811a4b&amp;
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&amp;is=66a3ff92&amp;hm=1d102287c441d25ec1d9eee2a436cc60181d172c198e748a0fc33aa649014cc6&amp;
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

| Channels | #minetest-dev index | Today | | Google Search | Plaintext