Problem with pixi rope and texture packer spritesheet.

[scypion]

Hello!

I'm trying to create in pixi.js timer. Something similar to this https://codepen.io/carsy/pen/VvqJwm. But instead of white disappearing white line, I have to use png asset. I found solution in Pixi mesh rope. Straight line curved to circle. And it's working. But there is an issue connected with Texture packer.

When I'm using png, for example from url like this https://i.imgur.com/PsFcDS6.png. Everything is OK. My timer start from 0 and filling to circle. Attachment "good".

But when I put same png line to spritesheet with another assets using Texture Packer, my rope look like on "bad" attachment. There is some alpha on line ends becoming more visible when line is more stretched. Line asset on created spritesheet is same as separately png. But behave another on rope.

I tried many texture packer settings, but nothing helps. I also tried do same things on another project, nothing.

I don't understand why same asset behave differently when is on spritesheet. What could be the problem?

Regards,

Stevie

 

Attachments:

Good

Bad

[ShrewdPixel]

Greetings! 

I can't be absolutely certain without looking at the code, but this appears to be one of the "Gotchas" listed in the Pixi Wiki for sprite-sheet textures. (In particular for PIXI.mesh.Rope)

Here's a link to the exact part of the Wiki that describes this problem and lists possible workarounds: https://github.com/pixijs/pixi.js/wiki/v4-Gotchas#pixitexture

The wiki describes the workaround to use them as standalone textures, also lists which versions of Pixi that have been updated to work better.

 

Hope that helps, and Good Luck!

[ivan.popelyshev]

Make sure you use latest v4, I remember that we fixed mesh texture support long time ago. My telepathy tells me that it should work, and if its not please make a fiddle for me to test.

[scypion]

@ivan.popelyshev I'm using latest version of pixi.js.

Here is js fiddle code for look: https://jsfiddle.net/zxyv8rnL/

[ivan.popelyshev]

ok, it looks like normal behaviour for scaleMode = LINEAR . Lets change it to NEAREST:

// baseTexture.mipmap = false; //just in case if something else goes wrong
baseTexture.scaleMode = 1;

I'm sorry, I cant explain it properly, its webgl-related stuff. Pixi fragment shader does not account for texture borders inside the atlas, and everything depends on scaleMode/texture-filtering , we cant do anything about it.

You can use "extrude" option in texturePacker, in which BOTH COLORS AND ALPHA are extruded from texture sides and that affects filtering.

I'm really cant explain everything because its two-hour lecture.

[ivan.popelyshev]

Alternatively, you can make a custom renderer that works with different shader, like https://github.com/pixijs/pixi-plugin-example for for meshes. But its only in case you are familiar with pixi architecture and is ready to dig on

[ShrewdPixel]

I'm not sure that 'baseTexture.scaleMode . = 1;' is going to deliver acceptable results; I tried it on the jsfiddle and the results were really ugly. (See screenshot)

It appears you may just have to load that as a standalone texture instead of using it with a spritesheet. The pixi.js wiki that I linked to was specific about loading resources separately: 

Things That Don't Support Spritesheet Textures

The following objects do not support Texture objects that are part of a Spritesheet shared with other Texture objects or where the Texture's frame is not the entire size of the BaseTexture. Using a Spritesheet with one of these classes will cause the transforms to render incorrectly.

• Sprite-based masks Ж
• Filters with sprite inputs (e.g., DisplacementFilter)
• PIXI.mesh.Mesh †
• PIXI.mesh.Plane †
• PIXI.mesh.Rope †
• PIXI.mesh.NineSlicePlane †
• PIXI.extras.TilingSprite ‡

PIXI.loader.add('atlas', 'atlas.json')
  .load((loader, resources) => {
    const sprite = new PIXI.Sprite(
      resources.atlas.textures.myTexture
    );
    someContainer.addChild(sprite);
    someContainer.mask = sprite; // <-- won't work
  });

Workaround: If you intend to use any of these advanced DisplayObjects, make sure they are loaded as standalone images and are not part of a bundled Spritesheet.

PIXI.loader.add('atlas', 'atlas.json')
  .add('myMask', 'myMask.png')
  .load((loader, resources) => {
    const mesh = new PIXI.Sprite(
      resources.myMask.texture
    );
    someContainer.addChild(sprite);
    someContainer.mask = sprite;
  });

I realize that this was supposed to be remedied in pixi.js 4.5, but if you can't get acceptable visual results, it might just to be better to load that texture as a standalone asset. 

Hope that helps, and Good Luck!

[ivan.popelyshev]

All items in the list were fixed, except DisplacementFilter. The problem is that you always have to take into account filtering modes, there are workarounds through TextureMatrix and extruding colors/alpha in texturepacker, but if you dont understand whats going on - dont use atlas.

[scypion]

Thank you for help guys  Finally, extrude option in Texture Packer helped. Problem solved.

[ShrewdPixel]

8 minutes ago, ivan.popelyshev said:

All items in the list were fixed, except DisplacementFilter. The problem is that you always have to take into account filtering modes, there are workarounds through TextureMatrix and extruding colors/alpha in texturepacker, but if you dont understand whats going on - dont use atlas.

Are you saying that the wiki is out of date? 

More specifically, is there any reason why adding individual assets in the loader along with the atlas is a bad practice and wouldn't be a viable solution to the problem scypion is experiencing? I'm still evaluating pixi and would genuinely like to know myself, and as a contributing member to the repo you seem pretty knowledgeable.

[ivan.popelyshev]

Its not a bad practice, its about whether or not you know what webgl operations are actually happening. Some fields/properties in pixi can be used only if you know underlying WebGL mechanics. Sometimes you can inject different shader that works better for atlas textures, but lacks batching. Sometimes you can make shader with batching, like in pixi-heaven or pixi-projection.

So, you have to know

1. Pixi stage

2. WebGL operations

3. pixi internal architecture.

Stage and basic things are available through the docs, but 2-3 can be learned only from source code and WebGL manuals. Of course you can look in this forum and in pixijs issues for a single problem, but I can't answer big questions like this one if a developer see the big picture: 

In the end, its all about BALANCING different penalties. If you dont have proficiency with atlas to solve small issues like "extrude colors for rope", dont use atlas for rope, change your pipeline.

It will take minimum a year for me to make articles and examples on everything i know about pixi and WebGL , and because I'm still developing plugins on pixi, it will require a year more.

PixiJS team released 5.0.0-rc today: https://github.com/pixijs/pixi.js/releases/tag/v5.0.0-rc , but there are no examples of new features, it will take another year. Unfortunately we dont have strong team of mathematicians that made Flash  Instead, developers who use pixi and need its extra features have to learn everything by source code.

[ShrewdPixel]

18 minutes ago, ivan.popelyshev said:

Instead, developers who use pixi and need its extra features have to learn everything by source code.

Challenge Accepted.  After I get done porting the library to Ruby gems for easier import to the Rails assets pipeline, I'll see what I can do there.

Thanks for the insight.