Sou lento , mas
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] ]
}
}
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):
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:
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] ]
@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.
Comentários muito úteis
Ele será adicionado na v5, irei fornecê-lo.