Texture atlas patch for particle systems

[mandrav]

NOTE: The bug I found earlier is fixed now and the download link has been re-enabled.


This is *not* a project but I couldn't think of where else to post this.
<rant>Since there is a special forum for bug-reports, maybe there should be one for patches too?</rant>

Anyway...

This patch adds texture atlas (a.k.a. sprite-sheet) support in particle systems. Here's the code documentation:

Code: Select all

    //! Sets if the material's texture is to be used as a texture atlas.
    //! A texture atlas is a texture that contains more than one texture inside.
    //! You could call it a sprite-sheet too.
    //! Imagine the texture divided into an imaginary grid of cells of the specified
    //! size.
    //! If the particle system is set in texture atlas mode, each particle will have
    //! a different part (cell) of the atlas as its texture. This allows for more interesting
    //! and variant particle systems.
    //! @param use: If true, the texture will be used as a texture atlas. If false,
    //! it is used in the normal Irrlicht way.
    //! @param gridCell: The grid cell count for the atlas. For example, if your texture is
    //! size of 512x64 and you have 8 sub-textures of size 64x64 in it, then the grid
    //! cell size would be 8x1.
    //! @param randomPick: Decides how to pick which cell to use for the next particle.
    //! If this is true, the next cell is picked randomly. If it is false, the order
    //! is sequential: the next cell in the horizontal direction is picked. When the
    //! last cell is picked, it then starts again with the first cell of the next row.
    //! When all cells are used, it starts again from cell (1,1).

In other words, you create a texture containing multiple same-sized sub-textures, assign it to the particle system's material and tell the particle system that it is a big texture containing smaller ones .
Take this texture as an example:




It is a 512x64 texture containing 8 64x64 sub-textures. To make the particle system use it (with this patch), all you have to do is add this line of code any time after particle system's creation:

Code: Select all

ps->setUseTextureAtlas(true, core::dimension2d<u32>(8,1), true);

That's it. Now, every particle spawned will have a different texture picked from the texture atlas .

I hope you enjoy this.

Download link.

[mandrav]

No one is interested in this? Not even a comment if it works for you or not?


Anyway, could a mod move it to the "Code snippets" section? I think it's a more appropriate place for it.

[hybrid]

I think this is definitely interesting I have even provided a better way to change texture coords using the texture matrices. So you could stick with the old texture coord settings and change the matrix to choose the proper subtexture. No need to erase or change vertices, just one matrix!
Do you use this extension for large particle systems, or for billboards based on particles? I'm just wondering about the numbers and what your project looks like

[mandrav]

I think this is definitely interesting I have even provided a better way to change texture coords using the texture matrices. So you could stick with the old texture coord settings and change the matrix to choose the proper subtexture. No need to erase or change vertices, just one matrix!

I saw this texture matrix patch and I think it's great, not to mention it was really missing from irrlicht .
But I don't think it can be used here. You see, all particles use the same texture so altering the texture matrix would affect all particles...

Do you use this extension for large particle systems, or for billboards based on particles? I'm just wondering about the numbers and what your project looks like

What you can do with this, is add variety in your particle systems. Instead of spawning the same particle over and over again, you can make it spawn variations of the old particle texture allowing for some interesting effects.
So, this numbers texture is just a sample for testing it (each particle gets a different number) .

[hybrid]

Ah, I see. So texture changes are upon spawning, I did not check the code in every detail
Well, yes, this makes the matrix unusable - but I do understand the usage now. could give interesting coloring effects with gradient textures.
I think I'll make an affector which uses a large texture and updates the texture matrix. The two things combined could also be useful, but with the given setup it would be rather easy then. I'll just have to think about a nice case study to make some screenshots afterwards.

[kburkhart84]

Nice feature, I'll have to test it out.

[mandrav]

Nice feature, I'll have to test it out.

Please, do

I'll just have to think about a nice case study to make some screenshots afterwards.

One example is "fire" (or "dust cloud"). Imagine creating a 8x1 atlas with different fire particle textures in it. The fire will become much nicer because of the variety in particle textures. Add to that a texture matrix rotation and you got a very cool fire effect .
The only thing missing (I guess) is a texture-matrix-rotation-affector but this shouldn't be hard to add.

[buhatkj]

im curious,
what if rather than do this, we instead simply placed several (n) particle systems together, each having been assigned a seperate standard texture, and cut the particle output of each to 1/nth of the total particle output we wanted. would that be more or less efficient than this implementation?

similarly, does 1 large texture or several small texture of the same total size take up less memory?

[mandrav]

im curious,
what if rather than do this, we instead simply placed several (n) particle systems together, each having been assigned a seperate standard texture, and cut the particle output of each to 1/nth of the total particle output we wanted. would that be more or less efficient than this implementation?

Think about it: you 're asking if multiple particle systems are more efficient than a single one...

similarly, does 1 large texture or several small texture of the same total size take up less memory?

In terms of memory, it's the same thing. But by combining multiple images in a larger texture, you minimize state changes which in turn makes your application run faster.

[buhatkj]

OK, that's what i didn't know, was if the state changes made a difference. i guess they do.

[mandrav]

OK, that's what i didn't know, was if the state changes made a difference. i guess they do.

Switching textures is the second most expensive state-change IIRC (the most expensive being shaders).