Particle Editor. Texture props, Spritesheet order. (Particles)

Bugs
,
1

Hi all.

Recently I started actively using the Particle Editor and discovered several problems.

What I noticed:

  1. In the json output, wrapU/wrapV/wrapR are not applied to the texture. They need to be positioned by hand.

  2. Also, if you write noMipmap in json manually, this property will not be applied to the texture.

  3. It’s not very clear how spritesheet works. I expected approximately the same order as in the picture. In reality, there is no order, frames can run chaotically.

particlesSheet
particlesSheet1012×518 2.14 KB

2

could you provide playground repros for the issues ?

3

Certainly!

Here you can see the texture and run through the animation through different frames. Their order is not very clear. I added manually invertY: false

4

In the PG, the width of the sprite texture is 450px whereas the cell width is 112px => 450/112~4.01 > 4, so the system thinks there are 5 sprites in each row. As you only have 4 sprites per row, you should set a width of 112.5 (=450/4). Same thing for the height.

Setting noMipmap by hand does work for me (see the PG above), but it’s a bug that this property is not serialized. This PR will fix it:

And in my testing, setting the Clamp U / V properties on the texture (using the inspector) does change the wrapU/wrapV properties in the exported json. Could you retest on your end?

2 Likes
5

Yes, I tried to set 112.5, but the input does not allow me to write a float number. I am attaching a screenshot. I think it would be good to add support for float numbers, because I want to leave as much data as possible in json, and not add it manually in the code

cellSizes
cellSizes1812×204 19.4 KB

About noMipmap/wrapU/wrapV/wrapR. Sorry, I dug around and it was my mistake. The thing is that I cloned the system using sys.clone(name, newEmitter, cloneTexture), and did not use the third cloneTexture argument. Therefore the json properties were not applied

6

Really, a non integer number for a picture width/height should be considered invalid, I only mentioned the computation because it happened to work when done programmatically.

But the real fix is to update your picture and just make it a 448x224 picture instead of 450x225. This way, a cell size of 112x112 will work as expected.

1 Like
7

Okay, I got it. Once again you help me out :slight_smile:

Thank you very much for your help!