Pixi.js: Emballage de polygone

Les gens disent qu'il a été ajouté dans l'unité il y a 1 an

impressionnant.
mobile n'est toujours pas assez de mémoire.
donc besoin de ça..
que pensez-vous des performances par polygone texturepacking

C'est génial ! @SeminYun au cas où vous n'auriez pas trouvé les informations sur les performances, voici un test qu'ils ont fait sur iphone 4s : https://www.codeandweb.com/blog/2015/10/01/cocos2d-x-performance-optimization
l'image a fait 36 ​​ips non rognée et 60 ips rognée ! Parlons d'amélioration ! Ce support de texture serait très, très bienvenu dans pixi !! :)

Remarque : cet avantage en termes de performances se fait au détriment du processeur. Déjà quelque chose de terriblement limité dans JS. J'aimerais comparer cela dans pixi et voir à quoi ressemble la différence.

Agréable. En plus, espérons-le, de ces avantages en termes de performances, cela rendra certainement certaines feuilles de sprites plus petites tandis que les images peuvent tenir à l'intérieur des trous alpha ! Ainsi, beaucoup de feuilles de sprites se chargeront plus rapidement. Bonne chose!

Je vais bientôt l'implémenter dans la branche WIP v4.1 :)

Cela ne pourrait-il pas être rendu via Mesh au lieu de créer une nouvelle fonctionnalité ?

@englercj 100% correct. La nouvelle configuration de Sprite s'adaptera également à cela!

les uvs et la géométrie doivent être du côté "texture" ou "modèle", pas dans l'instance, donc le maillage n'est pas une solution.

Toute mise à jour?

Étant donné que le mode polygone est toujours désactivé par défaut pour le format de données PixiJS, il semble que les polygones ne soient pas pris en charge dans Pixi.

Comme le suggèrent les deux derniers commentaires, il devrait figurer quelque part dans l'agenda de sortie de PixiJs à partir de la version 4.1. Quelqu'un peut-il confirmer que cette fonctionnalité a déjà été intégrée à PIXI 4.* ?

Et si elle est prise en charge, est-ce que quelqu'un sait comment activer cette fonctionnalité dans TexturePacker pour le format json PixiJS ?

Il sera ajouté en v5, je le fournirai.

Merveilleux! Merci beaucoup.

Super @ivanpopelyshev !

Des nouvelles ici ?

Pas de nouvelles, mais personne n'a confirmé qu'ils en avaient sérieusement besoin. Je peux le faire comme un plugin pour la v4, mais qui le testera et confirmera qu'il fonctionne ? Et la v5 est en phase alpha, donc personne ne l'utilisera pendant plusieurs mois si je l'ajoute là.

Pas de nouvelles, mais personne n'a confirmé qu'ils en avaient sérieusement besoin.

Hein? Tu veux dire, sauf pour nous ?

Je suis sûr que pour de nombreux projets, cela peut optimiser les « feuilles de calcul » avec différents formats d'images, car chaque image peut être beaucoup plus proche les unes des autres. J'en avais déjà eu besoin plusieurs fois, pour pouvoir créer des feuilles de calcul où je mettais de petites images dans la partie transparente d'une grande image pour avoir une image de sortie de feuille de calcul plus petite.

Je ne peux pas parler pour les autres, mais j'utiliserais beaucoup cette fonctionnalité

S'il vous plaît écrivez un e-mail à @GoodBoyDigital , s'il est d'accord, je me concentrerai sur cette chose.

J'ai besoin de cette fonctionnalité.

Je pense qu'il est temps de le marquer pour la v5.

Est-il disponible en tant que plugin pour v4.x ? ou dois-je attendre la v5 pour cette fonctionnalité ?

V5, c'est sûr, ce sera incroyablement facile à mettre en œuvre avec de nouveaux systèmes !
(avec dosage !)

Le mercredi 6 juin 2018 à 10 h 05, sudhalucky [email protected] a écrit :

Est-il disponible en tant que plugin pour v4.x ? ou dois-je attendre la v5 pour cela
caractéristique?

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/pixijs/pixi.js/issues/2243#issuecomment-394998933 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AC998nI2I61yvKnAEcwik_-jBCsiGUnvks5t55tigaJpZM4G0VPE
.

>

Directeur technique

Accueil : www.goodboydigital.com
Téléphone : 020 8533 1177
Adresse : Unité B1, Matchmakers Wharf, Homerton Road, Londres, E9 5FF

j'ai besoin de cette fonctionnalité

Ce plugin prend en charge l'emballage de polygones : https://github.com/gameofbombs/pixi-heaven

Utiliser PIXI.heaven.Sprite

@ivanpopelyshev Merci pour le bon conseil sur pixi-heaven. Jetez certainement un œil à cela. Mais pour le simple emballage de polygones, ce plugin semble un peu surchargé pour le simple emballage de polygones. Le fichier README indique qu'il nécessite même le plugin Spine (même si nous n'utilisons pas Spine dans un projet) et il dit que son utilisation coûte des performances. Je viens de jeter un coup d'œil rapide à ce référentiel, donc il me manque peut-être quelque chose ici, mais je ne vois aucune raison pour laquelle le conditionnement de polygones doit compromettre les performances pendant l'animation et avoir besoin de Spine.

Ce que je recherche, c'est un moyen de garder les feuilles de sprites aussi petites et efficaces que possible en largeur et en hauteur pour avoir des temps de chargement plus rapides. J'ai pensé que pour beaucoup de projets, il y avait beaucoup de blancs dans les feuilles de sprite parce que les images sont 100% transparentes sur de grandes régions. Cela pourrait être rempli avec les images plus petites qui doivent maintenant sortir des rectangles de ces images transparentes.

Avec l'emballage de polygones, nous pourrions rendre les feuilles de sprites beaucoup plus petites, comme cet exemple simplifié (chaque couleur différente est un sprite différent) :

Vous pouvez voir ici que la grande forme ronde permet maintenant aux petites formes de remplir le trou transparent qui n'est normalement qu'un grand espace manquant. Et sur la droite, vous voyez que deux triangles peuvent utiliser le même espace, ce qui entraîne une diminution de 50% de l'espace utilisé.
Avec des feuilles de sprites normales, cela donnerait une très grande feuille de sprites, où toutes les images ont besoin de rectangles complets, même si elles sont transparentes pour les grandes régions, ce qui donnerait une feuille de sprites beaucoup plus grande et prendrait beaucoup plus de temps à charger.

Cette fonctionnalité ne rendra pas seulement les feuilles de sprites beaucoup plus petites dans de nombreux cas, comme une publication de vous-même ci-dessus, même les appels de dessin pourraient être plus rapides, car au lieu de dessiner un grand rectangle, seuls les plus petits polygones doivent être dessinés. Mais pour ce dernier, vous en savez beaucoup plus à ce sujet que moi.

Il existe également un article sur le site Web de Texturepacker sur l'augmentation importante des performances avec l'emballage de polygones :
https://www.codeandweb.com/texturepacker/tutorials/cocos2d-x-performance-optimization

Et ils fournissent un autre exemple réel où cela est très utile et très efficace :

Donc pour conclure ; Je ne suis pas convaincu que PIXI.heaven.Sprite soit une solution pour cela et je m'attendrais à ce que les performances augmentent, pas diminuent.

+1 pour cette fonctionnalité

Ce problème a été automatiquement marqué comme obsolète car il n'a pas eu d'activité récente. Il sera fermé si aucune autre activité ne se produit. Merci pour vos contributions.

Je vois des +1 ici et le 6 juin 2018 @GoodBoyDigital a écrit :
« V5, c'est sûr, ce sera incroyablement facile à mettre en œuvre avec de nouveaux systèmes !
(avec dosage !) »

Maintenant, nous lisons que l'étiquette « Résolution : ne sera pas réparée » a été ajoutée par le bot obsolète et le problème a (automatiquement) été fermé. Plus tôt, nous avons été informés que ces « bots » devaient être pris avec des pincettes, donc je ne suis pas sûr :

Cette fonctionnalité est toujours la bienvenue. Est-ce toujours en préparation pour la v5 ?

Je pense que @CodeAndWeb doit d'abord activer le polygone dans texturePacker pour le framework pixijs.
Il semble désactiver.

Vous pouvez utiliser le format "JSON (Hash)" pour l'essayer - il active le polygone packer mais désactive certaines choses spécifiques à PixiJS (détection d'animation). Le reste du format est identique.

Chaque sprite reçoit 3 entrées supplémentaires :

"vertices": [ [147,74], [194,68], [204,200], [153,266], [56,267], [15,220], [1,180], [11,72], [64,70], [66,3], [132,1] ],
"verticesUV": [ [194,901], [200,948], [68,958], [2,907], [1,810], [48,769], [88,755], [196,765], [198,818], [265,820], [267,886] ],
"triangles": [ [8,9,10], [6,7,8], [5,0,2], [6,0,5], [5,3,4], [6,8,0], [0,1,2], [5,2,3], [0,8,10] ]

• les sommets sont les points dans le système de coordonnées du sprite
• verticesUV sont les sommets dans l'atlas de texture
• les triangles sont les triangles construits à partir des sommets

@djmisterjon Il n'est pas non plus si difficile de modifier vous-même le modèle d'un modèle pour les sorties dans texturePacker ou de créer votre propre modèle personnalisé pour les sorties (ce qui est plutôt génial en fait !):
https://www.codeandweb.com/texturepacker/documentation/custom-exporter

@Friksel intéressant, merci pour les conseils, cela peut être très utile pour de nombreux systèmes personnalisés.

Bonjour, existe-t-il un support pour cela dans PixiV5 ? S'il n'y en a pas, quelqu'un peut-il peut-être mettre en évidence la fonctionnalité à utiliser à partir de Pixiv5 pour l'implémenter ? Cela pourrait être intéressé par la mise en œuvre de cela pour mon projet.