THREE.ComposedTexture - play GIF, APNG etc as texture

Hi, this looks cool!
I’m new to gumroad, how do you distribute the class?
It’s an npm module? A tag script?
Which is the license model?


1 Like

Thanks :heart: you get the source files from gumroad, containing the example as well, further updates will be sent out directly to your mail you used. You’re free to use it in commercial and non-commercial projects, just minify it with your final bundle.


This looks great!

I have a question regarding optimization, I’m looking forward to fill a scene with multiple animated textures.

Would you say using this approach with GIFs/APNG is a better at optimization than using VideoTexture with .webm?

1 Like

Thank you.

That depends on multiple things of your scenario, how long/how many frame and how large the animations are, if you need clean transparency, and if there are many different animations.

Just got the script from your Gumroad, and I gotta say it works amazing!

They are very simple and small, but will have lots of different files. I’m using it for environmental purposes. I tested it without re-using the texture to see if it can candle multiple GIFs without lagging and it works good. (I’m attaching a video) (Butterflies are the animated sources)

I think I’ll stick with this solution instead of VideoTexture :slight_smile:

Thank you!

1 Like

Looks great! :+1:

Yes for sprite purposes like that it’s perfectly suited.

1 Like

This works great but is somehow blowing up the memory of my website :frowning:
I am displaying 4 gifs in my scene (their filesizes are 74 MB combined).
My website’s heap memory (chrome dev tools) goes from 55MB to 1GB when I compare the scene without versus with the 4 gifs.
Is there a known memory leak somewhere?

74 MB for a single GIF is quite huge, usually they’re optimized to be around 1-10 MB. There is no known memory leak, when decoded/encoded they’re also in a compressed image format if you used one of the example ones.

With the dev tools you should be able to trace down where the heavy memory usage comes from more precisely. Also make sure to drop references to the original loaded files after they’re decoded.

Thank you fyrestar for the wise words. I also became aware that some of those gifs were just too heavy, so I removed those ones and I also compressed all of them and reduced their size by half.

Can you explain a bit more about the reference dropping after decoded? Is this already done in your example file?

1 Like

It’s just about making sure that you don’t keep variables; or better properties in objects still being used -holding the blob files loaded in your app referencing them. if it’s never referenced outside of the loading procedure it will get collected by the GC.

Sometimes people just try to misuse something to carry the data along assigning the blobs to a unrelated object just to pass it along, but as long as that object is used the property holing the blob stays in memory.

In short: if you (would) assign the blob to some app abstract class like “Resource”, as a property resource.blob you would need to null the property for it to get collected, or if you made an URL for a blob calling URL.revokeObjectURL, it’s more about general JS than a THREE.js specific subject.