Texture animation

[xDarkDelux]

Hello, I've been studying your project for a long time, but it's not clear to me how I can make a simple animation using several textures. For example, there is a button, we set the texture to it with a decorator using ninepatch. But let's say I have 10 textures of this button (frames) and I would like them to change in turn at some interval, thus creating an animation. How can this be done using the available features in RmlUi? Maybe with keyframes? I'm not very versed in html / css, I will be glad to any advice.

[mikke89]

Hi, and welcome.

It's a good question, we don't really have any built-in support for animated sprites. Generally, I can think of two approaches to deal with this:

• Use a designated texture name and use that to manually handle rendering of the animation in your render interface.
• Create a custom decorator and handle the animation during rendering there-in.

Good luck :) Let us know how it goes. I'm sure it would be very valuable to others if you could share some details and learnings on the solution you end up with.

[xDarkDelux]

Thanks for the tips, I like the custom decorator option, worth a try. I will definitely let you know the results.

[xDarkDelux]

After studying your options and comparing them with my requirements, I realized that implementing your own decorator does not solve the problem of texture animations. I made an animation for all textures in the render interface, the result is good, now it is possible to animate the texture with frames for any decorator or tag. I'm concerned about only 1 issue - performance. Considering that RmluiCore uses TextureHandle as a pointer to the texture, I need to adapt to this in order to be able to update painlessly when the next release comes out. It turns out that I need to store pointers to the texture with animation in some container and look for the texture in this container when compiling the geometry to understand if it is an animation or a regular texture. Question - do you have any plans to make a full-fledged class instead of TextureHandle, which will already have a pointer to the texture itself inside and which will make it possible to make your own class and inherit from it, supplementing it with your own parameters?

[mikke89]

The TextureHandle is a user handle, you can assign it whatever you'd like, including pointers to your own classes, or indices into an array. It can reference any resource on your machine really. Make your own class or a struct with the data you need, and e.g. return a pointer to that. With this in mind, there are no good reasons to make the handle into a class on the library side, as a user handle covers every use case.

[xDarkDelux]

Well, I thought if you return a pointer to your class or structure to it, there will be problems in RmluiCore, but apparently I'm wrong. Thanks for the tips, I'll try.

[mikke89]

No problem, hope everything works out.
The handle is a completely opaque type that is only used to pass it back to the user for their own book-keeping, the same goes for all the other handles. The only reserved value is zero, otherwise you are free to give it any value you'd like.

[Paril]

Hey, so I'm coming up against this same issue and I was reading the stuff above to figure out a good solution. @mikke89 essentially what we need is a solution that can be changed by artists without needing programmer intervention. I liked the idea of having essentially a virtual texture name that is replaced at runtime with the updated animation, but I realized when thinking more about it that that would mean you couldn't easily re-use the same animation at different speeds.

I think a custom decorator ends up being the best solution; considering they may have spaces in them, I think a string parser would work?

decorator: animated-image(2s "menu/cursor1.tga menu/cursor2.tga menu/cursor3.tga \"menu/cursor end4.tga\"");

Do you foresee any issues popping up regarding this approach?

[Paril]

I've mostly got this working, but I'm confused about this:

https://mikke89.github.io/RmlUiDoc/pages/cpp_manual/decorators.html#updating-decorators

It mentions a potential approach to dirtying the decorators but doesn't tell us how to actually do this. Do we have to destroy all of the decorators and re-initialize them? That seems very inefficient; I don't see any "dirty" members or methods on decorators or elements, though. The closest I can find is in ElementDecoration, but that's not exposed as a public interface. Even if I could use that, though, it dirties all of them, not just the one I need re-rendered...

RenderElement is only seemingly called when something actually changes (like mouse movement, etc) rather than all the time, so I don't think that's the right approach, but there's nothing publicly exposed to invalidate a single decorator.

[mikke89]

I liked the idea of having essentially a virtual texture name [...] but I realized when thinking more about it that that would mean you couldn't easily re-use the same animation at different speeds.

I guess you could always integrate the speed into the animation name, and parse that manually. But generally, yeah, I'd prefer the decorator approach myself.

I'm not sure I follow what you mean by dirtying and so on here, I wonder if you are overthinking it here. The decorator's render function should be called every time it is rendered, so simply render the appropriate texture at that time. The only exceptions I can think of is if the element is hidden, or if you have enabled power saving mode. In the latter case you can use Context::RequestNextUpdate to request a new update after some given duration.

[Paril]

I'm using the loadDocument sample code, and the document doesn't re-render if you sit there idle - is that a part of the new power saving stuff/is that enabled by default? If so then it probably is just user error on my part. It does re-render if you move the mouse around but not if you're idle.

[mikke89]

Yeah, that sounds like the power saving mode. That is enabled on some of the samples, on some of the backends. See Backend::ProcessEvents.

[Paril]

Ooh I see, okay. Cool. That is probably what it is then - I had it working with a custom decorator, that was the only remaining hitch, heh. Thanks!