scypion

Problem with pixi rope and texture packer spritesheet.

Recommended Posts

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 :)

good.png

Bad :(

bad.png

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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!

Screen Shot 2019-01-31 at 3.37.32 PM.png

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.