Pixi.js: Embalagem poligonal

Criado em 13 dez. 2015  ·  33Comentários  ·  Fonte: pixijs/pixi.js

Sou lento , mas

dude

Formato

{"frames": {
"animal_extractor.png":
{
    "frame": {"x":2,"y":326,"w":164,"h":136},
    "rotated": false,
    "trimmed": false,
    "spriteSourceSize": {"x":0,"y":0,"w":164,"h":136},
    "sourceSize": {"w":164,"h":136},
    "pivot": {"x":0.5,"y":0.5},
    "vertices": [ [140,34], [164,76], [164,88], [95,127], [74,136], [50,136], [0,108], [0,62], [32,19], [86,15], [101,0], [106,0] ],
    "verticesUV": [ [142,360], [166,402], [166,414], [97,453], [76,462], [52,462], [2,434], [2,388], [34,345], [88,341], [103,326], [108,326] ],
    "triangles": [ [9,10,11], [3,8,9], [7,3,5], [3,0,1], [5,6,7], [5,3,4], [3,7,8], [3,9,0], [3,1,2], [0,9,11] ]
}
}
Stale 🙏 Feature Request 🥶 Low Priority

Comentários muito úteis

Ele será adicionado na v5, irei fornecê-lo.

Todos 33 comentários

As pessoas dizem que foi adicionado na unidade 1 ano atrás

impressionante.
móvel nem sempre é memória suficiente.
então preciso disso ..
como você pensa sobre o desempenho por empacotamento de textura de polígono

Isso é brilhante! @SeminYun caso você não tenha encontrado as informações de desempenho, aqui está um teste que eles fizeram no iphone 4s: https://www.codeandweb.com/blog/2015/10/01/cocos2d-x-performance-optimization
a imagem ficou 36fps sem corte e 60 fps cortada! Falando em melhoria! Este suporte de texturas seria muito, muito bem-vindo no pixi !! :)

Nota: Esse benefício de desempenho tem o custo da CPU. Algo totalmente restrito em JS já. Eu adoraria comparar isso em pixi e ver como é a diferença.

Agradável. Além dos benefícios de desempenho, esperançosamente, isso definitivamente tornará algumas spritesheets menores, enquanto as imagens podem caber em buracos alfa! Portanto, muitas spritesheets carregam mais rápido. Coisa boa!

Vou implementá-lo no branch WIP v4.1 em breve :)

Isso não poderia ser renderizado via malha em vez de criar um novo recurso?

@englercj 100% correto. A nova configuração do Sprite irá acomodar isso muito bem também!

Os uvs e a geometria devem estar no lado da "textura" ou do "modelo", não no caso, então a malha não é uma solução.

Qualquer atualização?

Como o modo de polígono ainda está desabilitado por padrão para o formato de dados PixiJS, parece que os polígonos não são suportados no Pixi.

Como o último par de comentários sugere, deve estar em algum lugar na agenda de lançamento de PixiJs a partir da versão 4.1. Alguém pode confirmar se este recurso já fez parte do PIXI 4. *?

E se for compatível, alguém sabe habilitar esse recurso no TexturePacker para o formato PixiJS json?

Ele será adicionado na v5, irei fornecê-lo.

Maravilhoso! Muito obrigado.

Ótimo @ivanpopelyshev !

Alguma notícia aqui?

Nenhuma notícia, mas ninguém confirmou que eles precisam seriamente. Posso torná-lo um plugin para a v4, mas quem irá testá-lo e confirmar se funciona? E a v5 está em estágio alfa, então ninguém a usará por vários meses se eu adicioná-la lá.

Nenhuma notícia, mas ninguém confirmou que eles precisam seriamente.

Huh? Quer dizer, exceto para nós?

Tenho certeza de que para muitos projetos isso pode otimizar 'planilhas' com diferentes formatos de imagens porque cada imagem pode estar muito mais próxima uma da outra. Já precisei algumas vezes, para poder criar planilhas onde coloco pequenas imagens na parte transparente de uma imagem grande para ter uma imagem de saída de planilha menor.

Não posso falar pelos outros, mas usaria muito esse recurso

Por favor, escreva um e-mail para @GoodBoyDigital , se ele concordar, irei me concentrar nisso.

Eu preciso desse recurso.

Acho que é hora de marcá-lo para v5.

Ele está disponível como um plugin para v4.x? ou devo esperar pela v5 para este recurso?

V5 com certeza, isso será incrivelmente fácil de implementar com novos sistemas!
(com lote!)

Na quarta-feira, 6 de junho de 2018 às 10:05, sudhalucky [email protected] escreveu:

Ele está disponível como um plugin para v4.x? ou devo esperar por v5 para isso
característica?

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/pixijs/pixi.js/issues/2243#issuecomment-394998933 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AC998nI2I61yvKnAEcwik_-jBCsiGUnvks5t55tigaJpZM4G0VPE
.

>

Diretor técnico

Home: www.goodboydigital.com
Telefone: 020 8533 1177
Endereço: Unidade B1, Matchmakers Wharf, Homerton Road, Londres, E9 5FF

eu preciso desse recurso

Este plug-in suporta empacotamento de polígonos: https://github.com/gameofbombs/pixi-heaven

Use PIXI.heaven.Sprite

@ivanpopelyshev Obrigado pela bela dica sobre o pixi-heaven. Definitivamente, dê uma olhada nisso. Mas, apenas para compactação de polígonos, esse plugin parece um pouco sobrecarregado para compactação apenas de polígonos. O README afirma que requer até mesmo o plug-in Spine (embora não usemos o Spine em um projeto) e diz que custa desempenho para usá-lo. Acabei de dar uma olhada rápida nesse repo, então posso estar faltando alguma coisa aqui, mas não vejo nenhuma razão para que a compactação de polígonos precise comprometer o desempenho durante a animação e precise do Spine.

O que estou procurando é uma maneira de manter as spritesheets tão pequenas e eficientes quanto possível em largura e altura para ter tempos de carregamento mais rápidos. Achei que para muitos projetos há muitos espaços em branco nas spritesheets porque as imagens são 100% transparentes em grandes regiões. Isso poderia ser preenchido com as imagens menores que agora precisam sair dos retângulos dessas imagens transparentes.

Com o empacotamento poligonal, poderíamos tornar as spritesheets muito menores, como neste exemplo simplificado (cada cor diferente é um sprite diferente):
polygon packing
Você pode ver aqui a grande forma redonda agora permite que as formas pequenas preencham o orifício transparente que normalmente é apenas um grande espaço ausente. E à direita, você vê que dois triângulos podem usar o mesmo espaço, resultando em uma redução de 50% no espaço usado.
Com spritesheets normais, isso resultaria em uma spritesheet muito grande, onde todas as imagens precisam de retângulos completos, embora sejam transparentes para grandes regiões, o que resultaria em uma spritesheet muito maior e levaria muito mais tempo para carregar.

Este recurso não apenas tornará as spritesheets muito menores em muitos casos, como uma postagem sua mencionada acima, até mesmo as chamadas poderiam ser mais rápidas, porque ao invés de desenhar um grande retângulo, apenas os polígonos menores precisam ser desenhados. Mas quanto ao último, você sabe muito mais sobre isso do que eu.

Há também um artigo no site do Texturepacker sobre grande aumento de desempenho com empacotamento poligonal:
https://www.codeandweb.com/texturepacker/tutorials/cocos2d-x-performance-optimization

E eles fornecem outro exemplo do mundo real onde isso é muito útil e muito eficiente:
tp-screenshot-2652

Então, para concluir; Não estou convencido de que PIXI.heaven.Sprite seja uma solução para isso e eu esperaria que o desempenho aumentasse, não diminuísse.

+1 para este recurso

Este problema foi marcado automaticamente como obsoleto porque não teve atividades recentes. Ele será fechado se nenhuma outra atividade ocorrer. Obrigado por suas contribuições.

Vejo alguns + 1s aqui e em 6 de junho de 2018 @GoodBoyDigital escreveu:
"V5 com certeza, isso será incrivelmente fácil de implementar com novos sistemas!
(com batching!) "

Agora lemos que o rótulo 'Resolução: Não Consertará' foi adicionado pelo bot desatualizado e o problema foi (automaticamente) fechado. Anteriormente, fomos informados que esses 'bots' devem ser pegos com um grão de sal, então não tenho certeza:

Esse recurso ainda é muito bem-vindo. Ainda está em desenvolvimento para a v5?

Acho que @CodeAndWeb precisa habilitar o polígono no texturePacker para a estrutura pixijs primeiro.
Parece desabilitado.

Você pode usar o formato "JSON (Hash)" para tentar - ele ativa o empacotador de polígonos, mas desativa algumas coisas específicas do PixiJS (detecção de animação). O resto do formato é idêntico.

Cada sprite recebe 3 entradas adicionais:

"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] ]
  • vértices são os pontos no sistema de coordenadas do sprite
  • vértices UV são os vértices no atlas de textura
  • triângulos são os triângulos construídos a partir dos vértices

@djmisterjon Também não é tão difícil alterar o modelo a para saídas no texturePacker você mesmo ou criar seu próprio modelo personalizado para saídas (o que é muito bom, na verdade!):
https://www.codeandweb.com/texturepacker/documentation/custom-exporter

@Friksel interessante, obrigado pelas dicas, pode ser muito útil para muitos sistemas customizados.

Olá, há suporte para isso no PixiV5? Se não houver, alguém pode destacar qual recurso usar do Pixiv5 para implementá-lo? Pode estar interessado em implementar isso para meu projeto.

Esta página foi útil?
0 / 5 - 0 avaliações

Questões relacionadas

lucap86 picture lucap86  ·  3Comentários

courtneyvigo picture courtneyvigo  ·  3Comentários

gaccob picture gaccob  ·  3Comentários

Makio64 picture Makio64  ·  3Comentários

distinctdan picture distinctdan  ·  3Comentários