Three.js: Le décalage/répétition UV doit faire partie des matériaux plutôt que des textures

Article connexe : https://github.com/mrdoob/three.js/issues/3549

vous devez cloner les textures par matériau (perdre une tonne de mémoire)

Dans quel sens des tonnes de mémoire sont-elles gaspillées ?

la probabilité d'avoir besoin de décalages/répétitions UV partagés sur une texture "partagée" est faible

Que veux-tu dire par là?

Si nous gardons l'approche actuelle, une chose qui doit être modifiée, c'est que lorsqu'une texture est clonée, l'image partagée ne doit être transmise au GPU qu'une seule fois.

si vous avez un objet avec un grand nombre de cadres/feuilles, de nombreux objets inutiles sont créés et, comme vous l'avez dit, l'image est copiée plusieurs fois sur le GPU, ce qui est extrêmement inutile. Encore plus inutile, si vous avez plusieurs objets qui doivent être à différents points dans différentes animations, vous devrez créer un ensemble unique de textures par matériau/objet unique, donc cela devient rapidement ennuyeux à manipuler, où un uniforme de matériau pourrait beaucoup plus facilement être manipulé sans avoir ces structures de données de décalage/répétition de texture supplémentaires construites autour d'une API mal pensée juste pour le faire fonctionner. J'ai un ralentissement majeur dans un certain cas d'utilisation de mon application où je dois créer ces groupes de textures uniques partout, et j'ai l'impression que la seule solution serait de remplacer tous les matériaux de base que j'utilise avec des shadermaterials pour contourner ce problème unique, ou bien bifurquer ma version THREE.js et faire les modifications nécessaires.

Concernant la deuxième affirmation :

Je voulais dire que le paradigme actuel ne facilite le travail que dans les cas où vous souhaitez appliquer la même texture avec le même décalage/répétition UV, mais c'est généralement un cas rare, car il semble beaucoup plus probable que vous vouliez définir cela comme les autres uniformes, par matériau, et partagent un matériau plutôt que simplement la texture.

La principale mise en garde avec le sys actuel. est que le décalage/répétition n'existe vraiment qu'en tant qu'uniforme unique qui affecte toutes les textures du shader, mais le fait qu'il soit attaché à THREE.Texture signifie qu'il ne peut pas être utilisé correctement comme uniforme et trompe les gens en leur faisant croire que les décalages/répétitions peuvent être choisis différemment pour les différentes textures qui peuvent être appliquées sur les matériaux de base (c'est-à-dire que vous pouvez définir un décalage diffus et un décalage normal de carte différents, mais ce n'est pas réellement possible même s'ils peuvent être définis uniquement sur les différentes textures). Je peux voir qu'il s'agissait peut-être d'un vestige du moteur de rendu canvas, mais cela n'a tout simplement aucun sens avec le système de matériel webGLrender / GLSL, qui l'a largement usurpé.

mrdoob a déclaré qu'il devrait être de la forme suivante comme raison de ne pas l'avoir par matériau,

material.map
material.mapOffset
material.mapRepeat
matériel.env
material.envOffset
material.envRepeat
... etc.

mais encore une fois, le décalage / répétition ne fonctionne pas par type de carte même maintenant, ce n'est donc pas vraiment un argument valide. De toute façon, cela gaspillerait trop d'uniformes de l'avoir par type de carte (sans compter que vous n'utilisez généralement qu'un seul ensemble d'UV, vous n'auriez donc pas vraiment plusieurs décalages pour une normalmap / bumpmap / diffusemap / specularmap). Je pense que si vous pesez toutes les options raisonnablement, cela devrait vraiment être une propriété matérielle plutôt qu'une propriété de texture. Je ne pense vraiment pas qu'il y ait d'avantages au système actuel. Je pense que l'animation de matériaux via le décalage UV est une raison majeure d'avoir même la propriété, et ne peut même pas être correctement utilisée pour cela. Sans compter que si vous n'aviez pas besoin de ces uniformes, ils pourraient être omis de la compilation des shaders, alors qu'ils sont maintenant là tant qu'une carte l'est.

@QuaziKb Avec tout le respect que je vous dois, si vous proposez un changement fondamental à la bibliothèque, comme celui que vous avez proposé ici, vous devez fournir un argument clair et convaincant pour ce changement. Argumenter à partir du cadre de référence de votre application particulière ne va pas le couper.

Cela étant dit, moi aussi, j'aimerais voir le décalage/répétition déplacé de Texture vers les matériaux.

Je pense qu'il est raisonnable de supposer que les cartes suivantes ont les mêmes valeurs de décalage/répétition :

specularMap
normalMap
bumpMap
alphaMap
aoMap (future)
glossMap (future)
displacementMap (future)

La seule exception est

C'est la façon dont il est mis en œuvre maintenant; même si chaque carte a ses propres valeurs de décalage/répétition, elles ne sont pas respectées.

Ainsi, nous pourrions ajouter à MeshPhongMaterial , MeshLambertMaterial , MeshBasicMaterial , et SpriteMaterial , nous ajouterions

mapOffset // or mapTranslate
mapRepeat // or mapScale

Nous supprimerions offset et repeat de Texture .

De cette façon, la mise en œuvre d'une feuille de sprites est simple. Chaque sprite a un matériau, et ces matériaux partagent une seule texture. La texture a une image. La texture n'a plus besoin d'être clonée. Côté GPU, les matériaux partageraient un seul programme de shader.

À mon humble avis, il s'agit d'une API plus naturelle.

J'essaie de me rappeler pourquoi l'API a été implémentée de cette façon. Je suppose qu'il y avait une bonne raison.

Désolé, je ne voulais pas suggérer que c'était particulier à mon exemple, simplement que l'API actuelle entraîne un gonflement important lorsqu'elle est utilisée pour animer des feuilles / décalages de sprites par objet / matériau unique, sans véritable solution. Naturellement, le but principal de l'avoir comme uniforme plutôt que de simplement intégrer le décalage/répétition dans les UV de sommet du modèle est d'animer le décalage, et je suggérais que cela ne peut pas être fait sans contourner l'API, rendant l'uniforme beaucoup moins utile attaché aux textures que s'il l'était à la matière.

Je pense qu'il est raisonnable de supposer que les cartes suivantes ont les mêmes valeurs de décalage/répétition :
carte
...
alphaMap

FWIW, ce comportement (l'implémentation actuelle) me cause une frustration importante en ce moment même. J'essaie d'animer la révélation d'un maillage en interpolant le décalage alphaMap du matériau du maillage indépendamment de sa map diffuse (qui reste fixe). Après une certaine frustration, j'ai découvert via https://github.com/mrdoob/three.js/pull/4987 et ce bug que ce n'est pas possible.

@jcarpenter Quel est le "bug"

Correction : par "bug" je voulais dire ce problème. Une confusion due à un temps excessif dans une culture Bugzilla. :p Je comprends que ce n'est pas un bogue, mais plutôt le comportement prévu.

WRT à une amélioration, sur la base de mon expérience avec les applications de création de contenu 3D traditionnelles comme Cinema 4D, j'imagine que l'utilisateur peut à la fois :

• définir un décalage/échelle/répétition pour chaque texture dans un matériau, indépendamment des autres textures, _et_
• définir le décalage/l'échelle/la répétition du matériau parent

Alternativement, pour le cas d'utilisation sur lequel je travaille ("tenter d'animer la révélation d'un maillage"), ce serait fantastique d'avoir une option pour wrapS et wrapT qui ne s'enroule pas du tout. Selon le GIF ci-joint de Cinema4D, qui a une option pour désactiver entièrement la mosaïque pour le mappage UVW. Sur la base de tests assez approfondis avec les méthodes wrapS et wrapT existantes, rien de tel n'est possible. Ce qui signifie que mes options pour animer la révélation d'éléments dans three.js semblent limitées à la position d'interpolation et à l'opacité de l'ensemble du maillage ... À moins que quelque chose ne me manque.

D'accord. Le but est de simplifier tout cela (en utilisant une seule matrice3 dans le shader) et d'avoir un décalage/répétition (ou translation/échelle) par texture.

Toute personne qui veut aider avec cela serait très appréciée!

@jcharpentier

Malheureusement, la seule façon de le faire pour le moment est d'utiliser plusieurs maillages avec différents matériaux ou un matériau de shader personnalisé. Les deux sont en quelque sorte impliqués pour un utilisateur qui vient de sauter dans le flux de travail three.js.

Il y a un compromis constant entre la convivialité, les performances et l'extensibilité. Ma suggestion serait de réécrire la façon dont les textures et les matériaux fonctionnent actuellement dans l'api, de sorte que les textures soient strictement des paramètres que vous branchez, et les valeurs qui sont en fait uniformes dans le shader comme le mode décalage/répétition/enroulement soient spécifiquement liées au Matériel. Dans certains cas, vous ne voulez pas gaspiller un uniforme à contrôler les UV pour des textures qui n'ont jamais besoin de changer (ce serait un énorme gaspillage d'avoir 4 * 5 uniformes supplémentaires dans un matériau phong si vous n'en avez besoin que pour la diffusion), donc ce serait cool s'il y avait de la magie dans les coulisses qui détecte si des UV spécifiques sont nécessaires et que la texture est reconstruite pour répondre à ces demandes, ou si un paramètre pouvait éventuellement être transmis pour spécifier le nombre d'UV réglables requis et quoi cartes qu'ils compensent et comment, mais c'est un problème difficile à résoudre.

Le but est de simplifier tout cela (en utilisant une seule matrice3 dans le shader) et d'avoir un décalage/répétition (ou translation/échelle) par texture.

@mrdoob

1. Voulez-vous dire _per material.map_ donc la transformation de texture est dans le matériau ? Il y a beaucoup de cartes matérielles, malheureusement. Nous pourrions continuer à supposer que toutes les transformations de texture sont les mêmes, à l'exception de lightmap.
2. Souhaitez-vous également soutenir la rotation ? Si c'est le cas, vous devez également ajouter le centre de rotation -- à moins que vous ne vouliez lier le centre de rotation au centre de la texture.

Ce serait un changement très apprécié. Devoir cloner des textures juste pour les mettre à des valeurs de répétition uniques semble terriblement encombrant. Est-ce ainsi que procèdent les autres bibliothèques ?

1. Voulez-vous dire _per material.map_ donc la transformation de texture est dans le matériau ? Il y a beaucoup de cartes matérielles, malheureusement. Nous pourrions continuer à supposer que toutes les transformations de texture sont les mêmes, à l'exception de lightmap.

Je pense que nous devrions avoir un mat3 par carte et devrait être composé des propriétés Texture .

1. Souhaitez-vous également soutenir la rotation ? Si c'est le cas, vous devez également ajouter le centre de rotation -- à moins que vous ne vouliez lier le centre de rotation au centre de la texture.

Rotation oui. Centrer ou pas... Je ne sais pas, mais pour autant que je sache, tout cela peut être encodé dans un seul mat3 pour le shader (par map).

Voici un prototype montrant comment un Matrix3 peut être passé à un shader et représenter une transformation définie par offsetX , offsetY , repeatX , repeatY , rotation , rotationCenterX et rotationCenterY .

Si center n'est pas autorisé comme option, alors il doit être câblé à ( 0.5, 0.5 ) .

Commentaires bienvenus.

EDIT : démo mise à jour

C'EST BIEN! :+1: :+1:

Je pense que j'irais avec translation et scale (au lieu de offset et repeat ) cependant.

Quelles devraient être exactement les nouvelles propriétés du matériau ? Il existe de nombreuses cartes matérielles.

Que faut-il supprimer des propriétés de la texture ?

Je suppose que wrapS/T devrait rester sur la texture.

Je pense que texture.offset et texture.repeat devraient être supprimés.

Je pense que les nouvelles propriétés devraient être... texture.translation , texture.rotation , texture.scale , texture.center et texture.matrix . Nous aurons probablement aussi besoin d'une méthode texture.updateMatrix() qui serait appelée au moment du rendu. Ceci, bien sûr, a le défi de s'assurer que nous ne le faisons qu'une seule fois, même si la texture est réutilisée.

En se référant au titre de cet article et aux arguments de https://github.com/mrdoob/three.js/issues/5876#issuecomment -69483293, je pensais qu'il s'agissait de déplacer ces propriétés vers le matériau.

/ping @bhouston pour les commentaires.

Mes pensées sont que le décalage/répétition de texture devrait être cuit dans les UV autant que possible. C'est plus facile. C'est ainsi que procèdent UE4/Unity 5 pour la plupart.

L'exception est que Unity 5 a la possibilité de spécifier un décalage/répétition global par matériau qui est partagé entre toutes les textures - mais cela n'affecte pas ce qui sont considérés comme des cartes ancrées telles que les cartes lightMap ou ambientOcclusion (celles n'a pas de sens d'être ajusté.)

La raison pour laquelle je ne préconise pas beaucoup de flexibilité ici est que les modèles créés par des professionnels ont des UV appropriés qui rendent cela généralement inutile - les outils de création de contenu ont des moyens de le faire. L'autre problème est que WebGL a une limite inférieure ridiculement basse pour les uniformes fragmentés - 16 Vec4. Si vous devez avoir une répétition/décalage par carte, et que nous obtiendrons bientôt beaucoup de cartes, nous gaspillons des uniformes fragmentés pour très peu de valeur.

En fait, j'ai récemment ajouté des commandes de répétition/décalage, puis de luminosité/gain par texture dans Clara.io et j'annulerai ces modifications car cela entraîne un débordement des uniformes de fragments sur les appareils bas de gamme, tels que tous les appareils Apple iOS. Bien que la répétition/le décalage et la luminosité/le gain fonctionnent très bien sur les ordinateurs de bureau avec NVIDIA 980, mais nous devons concevoir pour tout le monde, pas pour les machines haut de gamme. ;)

Nous devons traiter les uniformes fragmentés avec respect et ne les utiliser que lorsque cela est nécessaire. Je crois que ce n'est pas un de ces cas.

L'exception est que Unity 5 a la possibilité de spécifier un décalage/répétition global par matériau

C'est essentiellement ce que fait three.js maintenant - bien qu'il obtienne le décalage/répétition de la carte diffuse, et que toutes les autres textures matérielles utilisent le paramètre de cette carte.

La proposition consiste à supprimer le décalage/répétition de la texture et à l'ajouter au matériau à la place - avec peut-être un changement de nom. Encore une fois, toutes les textures matérielles partageraient les mêmes paramètres (même si certains utilisateurs ne seraient pas satisfaits). Cela permettrait de maintenir une utilisation uniforme faible.

Malheureusement, nous n'obtenons pas beaucoup de consensus à ce sujet.

Faire ce que fait Unity 5 est une bonne idée. Je le mettrais aussi sur le matériau au lieu de la texture. Vous avez mon soutien.

Par carte n'est pas vraiment idéal, mais cela pourrait être résolu en le faisant spécifier avec des drapeaux/clés d'une manière ou d'une autre lorsque les matériaux sont construits, au cas où cela serait nécessaire.

Généralement, la seule raison de modifier les UV dans le shader est que vous voulez les animer. Si vous souhaitez simplement transformer les UV de manière statique, nous ne devrions pas modifier le shader pour ajouter cette fonctionnalité.

Le seul changement proposé au shader est de remplacer

vUv = uv * offsetRepeat.zw + offsetRepeat.xy;

avec

vUv = ( uvTransform * vec3( uv, 1 ) ).xy;

D'accord. Que diriez-vous de ceci... Nous ajoutons texture.dynamic ( false par défaut) ce qui produit :

vUV = uv;

Si l'utilisateur définit texture.dynamic à true alors nous calculons texture.matrix sur texture.translation , texture.rotation , texture.scale et texture.center , on passe ça au programa et on produit :

vUv = ( uvTransform * vec3( uv, 1 ) ).xy;

Bien sûr, si texture.dynamic change, nous devons recompiler le programme.

De cette façon, nous obtenons le meilleur des deux mondes?

@mrdoob

1. Selon vous, est-ce que scale une propriété de la texture ou est-ce que texture.scale une propriété du matériau ? J'espère qu'il s'agit de ce dernier, car c'est de cela que traite ce fil.
2. Nous n'avons pas besoin d'une propriété .matrix . Le nouveau Matrix3 est un uniforme qui remplace l'uniforme matériel offsetRepeat . Il est calculé à partir des autres paramètres du moteur de rendu et transmis au GPU comme n'importe quel autre uniforme.

1. Selon vous, est-ce que scale une propriété de la texture ou est-ce que texture.scale une propriété du matériau ? J'espère qu'il s'agit de ce dernier, car c'est de cela que traite ce fil.

Je ne suis pas d'accord avec ce fil. Je ne pense pas que nous devrions polluer les matériaux avec mapMatrix , envMapMatrix , ... Ni mapTranslation , mapRotation , mapScale . Je pense que c'est plus propre si THREE.Texture a translation , rotation , scale et, peut-être center .

1. Nous n'avons pas besoin d'une propriété .matrix . Le nouveau Matrix3 est un uniforme qui remplace l'uniforme matériel offsetRepeat . Il est calculé à partir des autres paramètres du moteur de rendu et transmis au GPU comme n'importe quel autre uniforme.

Nous avons en quelque sorte besoin de quelque chose comme ça. Disons que l'on réutilise la même texture dans différentes maps. Nous ne voulons pas calculer le Matrix3 pour chaque instance.

Je ne suis pas d'accord avec ce fil. Je ne pense pas qu'il faille polluer les matériaux avec mapMatrix, envMapMatrix, ... Ni mapTranslation, mapRotation, mapScale. Je pense que c'est plus propre si THREE.Texture a une traduction, une rotation, une échelle et peut-être un centre.

Une texture aurait-elle encore besoin d'être clonée pour avoir des propriétés de répétition différentes ? Dans les petites scènes, ce n'est probablement pas grave, mais dans les grandes scènes où il y a déjà plus de 40 textures, c'est un cauchemar de mémoire.

@titansoftime image doit être découplé de THREE.Texture . Idéalement, un seul THREE.Image pourrait être utilisé par différents THREE.Texture chacun avec différentes translation , rotation , ... configurations.

L' image

Ça a du sens. Est-ce que texture.clone() fonctionne déjà de cette façon, ou doit-il être configuré manuellement ?

texture.clone() fonctionne de cette façon, mais WebGLRenderer est incapable de savoir que l'image est la même, donc c'est là que le téléchargement de la texture est inutile...

Je ne suis pas d'accord avec ce fil. Je ne pense pas qu'il faille polluer les matériaux avec mapMatrix, envMapMatrix, ... Ni mapTranslation, mapRotation, mapScale. Je pense que c'est plus propre si THREE.Texture a une traduction, une rotation, une échelle et peut-être un centre.

C'est essentiellement ce que nous faisons maintenant. Chaque texture a sa propre propriété offset et les décalages individuels ne sont pas respectés -- le moteur de rendu utilise le même décalage pour chaque texture du matériau.

FWIW, je pense que nous devrions faire ce que j'ai dit dans https://github.com/mrdoob/three.js/issues/5876#issuecomment -69483293 .

Je ne vois pas pourquoi l'API ne peut pas permettre de faire ce que @jcarpenter veut faire (animer le décalage du alphaMap , alors que map reste le même). On pourrait le faire dans canvas, mais je pense que c'est plutôt une tâche pour le GPU.

Il y a une tonne de choses que l'on peut faire en jouant avec les décalages de différentes cartes... décaler uniquement le alphaMap , mettre à l'échelle le normalMap , etc.

N'avoir qu'un seul uvTransform par matériau semble très très limitatif.

Oh, attendez. Je pense que je comprends pourquoi vous préférez par matériau. De cette façon, un seul vUv est calculé dans le vertex shader, au lieu de calculer l'uv par pixel dans le fragment shader. Droit?

par matériau est idéal car les décalages sont en fait simplement mis en œuvre à l'aide d'un uniforme du matériau et n'ont rien à voir avec la texture, nous nous retrouvons donc avec une solution de contournement absurde si nous devons modifier l'uniforme par matériau qui doit être fabriqué des tonnes de nouveaux objets/textures (ce qui est assez mauvais en JS/terrible en WebGL) juste pour contrôler quelque chose qui n'est en réalité qu'une caractéristique des uniformes matériels qui sont cachés aux utilisateurs. L'avoir dans une texture n'est en aucun cas avantageux, plus efficace ou même plus clair, et cela signifie que la seule application réelle de spécifier les UV qui changent au moment de l'exécution, l'animation, est rendue lente et inefficace à cause de l'API.

Les textures doivent spécifier une image et tout ce qui se rapporte à cette image. Les décalages UV n'ont rien à voir avec les propriétés de l'image / de l'image, et tout à voir avec le matériau affichant la texture, il est absurde d'avoir même cette fonctionnalité si elle ne fait pas partie du matériau, car il doit y avoir des tonnes de clonage en cours par exemple, et la mise à jour de plusieurs textures simultanément si l'on veut réellement utiliser la fonctionnalité dans de nombreux cas.

imaginez que l'on a une image différente pour chaque image d'une tuile animée et que vous vouliez également contrôler le décalage/la répétition de cette tuile. Ils devraient mettre à jour chaque image entrante avec les décalages, ainsi que des copies de chaque image pour chaque instance unique de matériau utilisant cette tuile, cela se transforme rapidement en centaines de nouveaux objets et affectations supplémentaires, pour quelque chose qui ne fait que contrôler quelques chars par matériau dans les coulisses utilisant tous ces objets sans raison valable.

en ce qui concerne les transformations par carte, même si ce serait bien, le coût uniforme est trop élevé sans raison dans la plupart des cas, sauf si nous avons une API complexe pour contrôler quand et comment les transformations doivent être uniques ou partagées ou dynamiques, IMO avoir ce contrôle serait une bonne chose, mais cela devrait être soigneusement réfléchi.

Oh, attendez. Je pense que je comprends pourquoi vous préférez par matériau. De cette façon, un seul vUv est calculé dans le vertex shader, au lieu de calculer l'uv par pixel dans le fragment shader. Droit?

Non. L'uv est calculé dans le vertex shader comme toujours.

Imaginez une feuille de sprites et 20 sprites. Actuellement, nous avons besoin de 20 matériaux clonés et de 20 textures clonées -- tout comme dans http://threejs.org/examples/misc_ubiquity_test2.html. (BTW, notez que nous avons déjà SpriteMaterial.rotation .)

En déplaçant le décalage vers le matériau, nous aurions besoin de 20 matériaux clonés et d'une texture.

En fait, en déplaçant l'offset vers le sprite, nous aurions besoin d'un matériau et d'une texture.

Imaginez une feuille de sprites et 20 sprites. Actuellement, nous avons besoin de 20 matériaux clonés et de 20 textures clonées

Ohm, je n'envisageais pas ce cas d'utilisation. Merci!

Je vais réfléchir à ça...

Je ne préconise pas de transformations UV dans la texture.

Pour deux raisons : (1) c'est déroutant, (2) il y a plus d'événements à propager, et (2) c'est du gaspillage.

Confusion : la raison en est que nous n'avons qu'une seule variable UV pour les cartes principales, mais s'il y a une transformation UV sur l'une des textures, il est déroutant que cette transformation UV puisse être appliquée à toutes les cartes qui utilisent le premier UV canal, que les autres textures aient ou non une transformation. Si nous permettions à chaque map d'avoir sa propre transformation UV dans le matériau, je serais plus d'accord avec la transformation UV associée à la texture - mais c'est difficile à faire en raison de son utilisation uniforme des fragments.

Plus de propagation d'événements : L'autre problème que j'ai rencontré dans Clara.io est la propagation d'événements lors de la tentative d'animation de paramètres de texture. On a besoin de chaque texture pour garder une trace de chaque matériau qui l'utilise, puis dire à ces matériaux qu'ils sont sales et doivent être recalculés. Il n'est pas impossible de le faire, juste plus de travail.

Gaspillage : L'autre problème est que si vous avez plusieurs instances d'un modèle 3D ou d'un dépit et qu'elles ont toutes la même texture animée. Dans ce cas, vous devrez avoir des copies distinctes de la texture en mémoire juste pour les animer différemment, même si les données de texture elles-mêmes sont les mêmes. C'est un peu un gaspillage dans ce sens par rapport à la mise des données de transformation UV sur les matériaux.

Ainsi, si nous n'avons qu'une seule transformation UV autorisée par matériau, je la mettrais sur le matériau lui-même. Je suivrais le modèle Unity 5 où ils ont un décalage UV, une rotation dans le matériau. Les développeurs de jeux connaissent déjà cette approche.

Je pense que les sprites sont également bien gérés par UV Transform sur les matériaux - c'est très similaire au cas du modèle 3D ci-dessus.

Having only one uvTransform per material seems very very limiting.

Tout à fait d'accord ici. Ne pas avoir cette fonctionnalité est extrêmement limitatif. Il y a des effets fantastiques qui pourraient être fournis ici qui ne le sont tout simplement pas parce que chaque décalage est verrouillé ensemble.

Mais comment rendre cette fonctionnalité disponible sans s'étouffer avec des clones ?

Je pense que le fait d'avoir les valeurs sur le matériau plutôt que sur la texture est logique pour le cas d'utilisation courant où toutes vos textures seraient mises en correspondance.

Tout à fait d'accord ici. Ne pas avoir cette fonctionnalité est extrêmement limitatif. Il y a des effets fantastiques qui pourraient être fournis ici qui ne le sont tout simplement pas parce que chaque décalage est verrouillé ensemble.

Mais comment rendre cette fonctionnalité disponible sans s'étouffer avec des clones ?

THREE.ShaderMaterial ou THREE.RawShaderMaterial vous donneraient cette capacité, et étant donné qu'elle ne fonctionne pas actuellement avec des matériaux ordinaires, c'est l'itinéraire que vous devriez utiliser de toute façon.

Si vous faites quelque chose de plus funky, ce sera probablement plus funky que de simplement ajuster les répétitions et les décalages des cartes indépendamment, donc vous vous pencheriez probablement de cette façon de toute façon.

+1 pour ça, les gars.

Ce serait très utile lorsque vous avez une feuille de sprite géante (aka atlas) et que vous souhaitez réutiliser sa texture sur plusieurs instances THREE.Sprite .

des nouvelles à ce sujet? Ce problème est toujours une faille assez flagrante dans l'API. La plupart des types de cartes ont des décalages/répétitions qui ne sont pas utilisés, et la propagation d'événements rend quelque chose comme un sprite animé sur un plan plus lent/mémoire qu'il ne devrait l'être.

La flexibilité pour les cartes animées N'EXISTE PAS dans le système actuel. L'argument revient sans cesse selon lequel nous réduirions la flexibilité en liant les paramètres au matériau. Cet argument est sans objet car cette flexibilité n'existe pas dans le système actuel. Vous ne pouvez définir le décalage/répétition que globalement pour le matériau, et il provient de la map diffuse (?). Cela conduit à un problème encore pire où il y a des paramètres "décalage" / "répétition" redondants sur la plupart des cartes utilisées, et chaque fois que vous souhaitez partager des textures pour l'animation, vous ne pouvez pas, vous devez faire un clone, donc la flexibilité est considérablement réduit. Vous vous attendez à ce que chaque texture / map ait des décalages uniques, mais ce n'est pas possible dans l'état actuel des choses, et dans la plupart des cas, vous voulez en fait un ensemble de décalages UV car il serait ennuyeux de définir les décalages sur la même chose pour normal/spec /diffuse (une normal map défilant sur une map diffuse fixe est une utilisation de niche où un matériau de shader pourrait être utilisé).

Si vous regardez les shaders réels en cours de construction, le décalage / répétition de la texture EST lié au matériau, mais étrangement copié à partir d'une carte qui ne devrait en aucun cas être sous contrôle. Le matériau DOIT être sous contrôle pour que cela soit rapide et élégant sans redondance.

Le meilleur des deux mondes est possible avec des tonnes de drapeaux supplémentaires, mais je ne pense pas que ce soit une meilleure solution que de simplement demander aux utilisateurs d'essayer d'utiliser le matériau du shader à la place pour ce genre de cas de bord spécifiques.

La solution à cela est le NodeMaterial de @sunag btw.

J'ajoute aussi mon +1 pour ça ! Cela rendrait le travail avec des feuilles de sprite beaucoup plus agréable.

:+1: J'ai trouvé cela surprenant. J'ai dû commencer à dupliquer mes textures pour chaque sprite du jeu, car tous mes sprites répétés s'animaient les uns les autres. On dirait que cela signifie que je charge des données de sprite redondantes sur le GPU ?

Est-ce que quelqu'un a une solution à ce problème ? Serait-il possible de manipuler l'offset UV en définissant directement l'uniforme sur le shader, en contournant l'interface Texture ?

La solution à cela est le NodeMaterial de @sunag btw.

@bhouston , pourriez-vous s'il vous plaît fournir un lien? Il n'y a pas de référentiel public sous le compte de @sunag avec ce nom.

@rhys-vdw Il se trouve ici dans la branche dev uniquement :

https://github.com/mrdoob/three.js/tree/dev/examples/js/nodes

C'est nouveau, donc je ne sais pas s'il est prêt à être utilisé sur les sprites, mais c'est un système de shader entièrement basé sur des graphes, il vous donnera donc la possibilité de modifier arbitrairement les accès aux textures.

C'est nouveau, donc je ne sais pas s'il est prêt à être utilisé sur les sprites, mais c'est un système de shader entièrement basé sur des graphes, il vous donnera donc la possibilité de modifier arbitrairement les accès aux textures.

@bhouston Je peux créer un exemple avec Node, ça a l'air bien.

À propos du THREE.SpriteMaterial vous pouvez accéder à l'offset/à l'échelle pour créer le spritesheet avec ceci par exemple :

var offsetX = frameX / mapWidth;
var scaleX = mapWidth / frameWidth;

sprite.material.map.offset.x = offsetX;
sprite.material.map.repeat.x = scaleX;

https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/plugins/SpritePlugin.js#L53

Le système basé sur les nœuds n'est pas un correctif... Il ne résout toujours pas les problèmes avec l'API. Il faut 2 secondes pour ajouter un décalage/répétition au prototype de matériau et faire en sorte que le moteur de rendu lise cela au lieu de la texture. Je l'ai déjà fait pour mon projet, mais le fait reste qu'il s'agit d'un défaut évident dans l'API qui devrait être officiellement modifié pour éviter les maux de tête aux nouveaux utilisateurs qui rencontreront ce problème s'ils essaient de faire quelque chose de commun.

...donc cela vous donnera la possibilité de modifier arbitrairement les accès aux textures.

tbh je ne sais pas ce que cela signifie. Pour animer des uniformes de shader d'ensemble individuels pour le "décalage" et la "répétition" par matériau.

À propos du THREE.SpriteMaterial, vous pouvez accéder à l'offset/à l'échelle pour créer la feuille de sprite avec ceci par exemple...

@sunag , le problème n'est peut-être pas clair. Le code que vous avez partagé modifie la texture, qui est partagée par toutes les instances de ce matériau. Cela signifie qu'il est impossible d'avoir deux matériaux partageant une texture, mais avec des décalages uniques - par exemple, deux sprites ennemis montrant des images d'animation différentes.

Je l'ai déjà fait pour mon projet, mais le fait reste qu'il s'agit d'un défaut évident dans l'API qui devrait être officiellement modifié pour éviter les maux de tête aux nouveaux utilisateurs qui rencontreront ce problème s'ils essaient de faire quelque chose de commun.

@QuaziKb Y a-t-il un PR que je peux cibler pour mon projet ?

Bien que tout cela ne soit pas un problème si, comme l' a dit

Si nous gardons l'approche actuelle, une chose qui doit être modifiée, c'est que lorsqu'une texture est clonée, l'image partagée ne doit être transmise au GPU qu'une seule fois.

Est-ce exact?

@sunag , le problème n'est peut-être pas clair. Le code que vous avez partagé modifie la texture, qui est partagée par toutes les instances de ce matériau. Cela signifie qu'il est impossible d'avoir deux matériaux partageant une texture, mais avec des décalages uniques - par exemple, deux sprites ennemis montrant des images d'animation différentes.

Hmm, pour ce que NodeMaterial résoudrait certainement, vous pourrez partager la même texture avec différents matériaux et un décalage UV indépendant et des avantages tels que des filtres personnalisés et d'autres choses qu'un matériau basé sur des nœuds peut offrir.

https://github.com/mrdoob/three.js/issues/7522

Mais pour le moment, quelqu'un a essayé d'instancier l'uuid comme ceci : ?

THREE.Texture.prototype.createInstance = function() {

    var inst = this.clone();

    inst.uuid = this.uuid;
    inst.version = this.version;

    return inst;

}

si vous utilisez needsUpdate mettez également version .

Exemple:

var uniqueTextureOffset = map.createInstance();
var material = new THREE.SpriteMaterial( { map: uniqueTextureOffset } );

Maintenez le même uuid et version partagera le texture sur GPU.

https://github.com/mrdoob/three.js/blob/master/src/renderers/WebGLRenderer.js#L2832
https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLProperties.js#L11

Même si pour moi c'est une solution provisoire. Je crois en NodeMaterial pour l'avenir.

Pouvons-nous s'il vous plaît déplacer les transformations UV vers le matériau ?

Que diriez-vous du meilleur des deux mondes. Ajoutez un drapeau overrideOffsetRepeat sur le matériel avec un nouveau uvOffset et uvRepeat sur le matériel. De cette façon, si le drapeau est faux, il est rétrocompatible, et c'est la valeur par défaut. Et si c'est vrai, il utilise le décalage/répétition de matière. Je soutiendrais cela car il semble que le besoin soit intense et généralisé. @WestLangley ? @mrdoob ?

(Bien que je supporte vraiment l'utilisation de NodeMaterial pour tout ce qui va de l'avant, mais c'est pénible de passer à celui-ci.)

Je pense toujours que la solution pour cela est de créer THREE.Image . https://github.com/mrdoob/three.js/issues/5876#issuecomment -81189892

THREE.Image

@mrdoob , cela signifierait-il que chaque Texture attribué serait cloné avec un Material ?

@mrdoob a écrit :

Je pense toujours que la solution pour cela est de créer THREE.Image

Oui, cela fonctionnerait, mais ce serait un peu moins rétrocompatible (si nous exigeons maintenant que tout le monde crée des images avant de créer une texture), mais une conception globale plus propre. Peut-être qu'il est possible d'avoir une image créée automatiquement par texture si on ne la spécifie pas séparément, cela permettrait d'obtenir une rétrocompatibilité ? Et vous n'auriez besoin de manipuler l'image directement que si vous vouliez faire quelque chose de délicat.

Je suppose que cette solution nécessiterait deux fois les nouveaux objets pour un ensemble de sprites - une texture pour chaque sprite et un matériau ? Où est l'autre approche qui nécessiterait juste un nouveau matériau pour chaque sprite ?

Je sais que Unity prend en charge la répétition/décalage par matériau, mais les outils VFX haut de gamme comme 3DS Max, Maya, Softimage ne le font pas - ils ont juste un nœud Bitmap et un nœud Texture (qui contient à la fois le nœud Bitmap ainsi qu'un mappage UV nod), qui est similaire au design de

UE4 est également similaire à ce que propose

Les outils avancés séparent l'image/le bitmap de la texture et ils séparent également un nœud de mappage UV séparé, sous cette forme :

 -> Bitmap
 -> UVMapping

Nous n'autorisons pas beaucoup d'options UVMapping dans le StandardMaterial principal pour le moment. Mais divers types d'UVMappings utilisés dans UE4, Maya, Softimage, 3DS Max, seraient le canal à utiliser, une transformation à lui appliquer, pour utiliser les coordonnées mondiales comme source, ou si l'on devait faire une projection sphérique, cube, planaire sur la base des paramètres requis pour ces projections.

UE4 a une texture de sprite qui permet la répétition/le décalage dans le matériau :

https://docs.unrealengine.com/latest/INT/Engine/Paper2D/Sprites/index.html

Maya, Softimage, 3DS Max et UE4 ont la séparation de Bitmap/Image de Texture (et de la génération UV) comme le suggère @mrdoob , mais ils utilisent également tous des graphiques de shader pour y parvenir. Unity3D, qui n'a pas de graphiques de shader, est l'outil qui intègre le décalage/répétition dans le matériau lui-même, probablement parce qu'il ne peut pas correctement le séparer en un nœud de graphique de shader.

Peut-être qu'il est possible d'avoir une image créée automatiquement par texture si on ne la spécifie pas séparément, cela permettrait d'obtenir une rétrocompatibilité ? Et vous n'auriez besoin de manipuler l'image directement que si vous vouliez faire quelque chose de délicat.

Exactement 😊

Probablement un peu déplacé à mentionner, mais je voudrais recommander que PTEX soit incorporé dès que possible.
http://ptex.us/PtexFile.html
S'il existe un moyen de faire des projections typiques, etc., convertissez/convertissez en NodeTexture (?) Ou une option qui est un nouveau système de mappage de texture de base plus puissant et plus complet ? ... eh bien, c'est peut-être quelque chose à considérer à l'avance.
[Suite au même point :]
Le concept avec ptex n'est pas vraiment une image 2D mais une relation uv afin que vous puissiez peindre/tamponner/projeter autour d'une surface complexe sans le concept/défi de la façon de traduire 2D en 3D, ce qui est mathématiquement un hack au mieux en comparaison ( toujours techniquement aux prises avec la destruction).
Je souligne simplement que ptex aurait dû avoir plus de sens et être une priorité il y a plus de 20 ans et ne devrait pas être considéré comme une extension ou un interprète de deuxième classe, mais vraiment pour moi c'est l'inverse. Cela devrait être l'ancienne façon originale de dire de manière déclarative comment une image 2D est projetée/estampée dans le seul vrai système de niveau de base toujours fonctionnel de ptex. Quoi qu'il en soit, il suffit de faire respecter l'idée qu'il devrait être intégré sinon mieux prendre un rôle plus central.
Merci pour l'opportunité de faire de nobles suggestions. J'étais tellement heureux que le ptex ait été fabriqué selon les spécifications. J'y ai pensé moi-même plus de 10 ans auparavant, mais en tant qu'enfant, je n'avais pas le pouvoir de définir de nouvelles spécifications, etc. Avec le recul, j'aurais dû voir que j'aurais peut-être pu essayer de faire la différence au lieu du rôle d'observateur que je maintiens toujours. Voici donc une tentative pour réparer une erreur de longue date.

Peut-être que quelqu'un peut démarrer un nouveau fil de discussion si quelqu'un ayant une compréhension plus approfondie des méthodes actuelles potentiellement dans Flux peut faire une proposition plus applicable sur la façon dont cela fonctionnerait dans THREEjs.
Encore merci pour l'opportunité d'être entendu.

@MasterJames sorte de hors-sujet... créez un nouveau fil s'il vous plaît ?

Même si nous avions une image pour que la "texture" puisse toujours être utilisée, tous les matériaux devraient être réécrits, car ils ne prennent pas en charge plus d'un décalage/répétition UV. Évidemment, cela pourrait changer, mais finirait probablement par ajouter de la complexité car des uniformes redondants seraient alors nécessaires (à quelle fréquence voulez-vous plus d'un ensemble de décalages/répétitions pour que, par exemple, une carte normale soit décalée d'un diffus) je pense qu'à la fin pour le web où les performances sont primordiales, le cas d'utilisation le plus courant est celui où il existe un décalage/répétition global qui affecte chaque carte, et il est logique que cela soit sur le matériau puisqu'il finit par faire partie de l'architecture des matériaux. Les matériaux de shader personnalisés peuvent très bien gérer les cas de bord.

@QuaziKb Oui. C'est ce que NodeMaterial s'attaque.

N'est-il pas vrai que Texture utilise la même instance de texture OpenGL pour chaque .clone() , ou est-ce que j'ai raté quelque chose. Le recharge-t-il réellement pour chaque clone ? Si c'est le cas, alors c'est un problème _très_ sérieux.

@evrimoztamur , je crois qu'il copie la texture à chaque fois. Vous pouvez vérifier ce qui se passe en utilisant WebGL Inspector .

J'ai essayé toutes les approches auxquelles je pouvais penser, y solution de contournement de @sunag , mais rien n'a fonctionné. Sur la base de mes expérimentations n'ayant pas donné de résultats et de la discussion ci-dessus, j'ai examiné comment d'autres bibliothèques gèrent l'animation de sprite. J'ai trouvé que les API Sprite et SpriteManager de Babylon.js étaient une solution qui répondait à mes besoins particuliers. Il gère les feuilles de sprite, le décalage et la répétition, et les animations. Il s'agit peut-être d'un niveau d'abstraction plus élevé que celui que THREE.js vise à fournir, mais cela pourrait valoir le détour comme référence.

@rhys-vdw : Pour un projet en cours, je me suis retrouvé avec une version bâtarde de MeshBasicMaterial :
https://gist.github.com/karimbeyrouti/790d2e1a8c0137b16bae

Lorsque vous définissez la carte, cela attribue automatiquement les uniformes de décalage/répétition (qui sont dans un matériau caché). Vous pouvez facilement les définir séparément - cela vous évitera d'avoir besoin de cloner des textures pour le moment. (fonctionne avec r73)

Je viens de soumettre un PR qui devrait résoudre ce problème, PR # 8278

@WestLangley a écrit :

Je pense qu'il est raisonnable de supposer que les cartes suivantes ont les mêmes valeurs de décalage/répétition :

carte
carte spéculaire
normalCarte
bumpMap
alphaMap
aoMap (futur)
glossMap (futur)
déplacementMap (futur)

Pas toujours. J'utilise actuellement différentes valeurs de répétition pour une carte et une bumpmap sur le même matériau (asphalte) pour masquer le fait que les deux sont carrelés avec des carreaux plutôt petits. De cette façon, je n'ai pas besoin de générer/avoir une grosse texture. C'est très pratique. :-)

EDIT : C'est du moins ce que je pensais avoir fait. L'astuce a probablement été ignorée. Et je peux obtenir des résultats similaires en ajoutant du bruit dans le shader ou quelque chose du genre. La démo Matrix3 de WestLangley est cool.

Je pense que cela résout le problème des instances avec différents UV dans Sprite. Il est possible de modifier les vertex et pixel shader conservant la même texture.

https://threejs.org/examples/#webgl_sprites_nodes

Il utilise SpriteNodeMaterial et Mesh avec un PlaneBufferGeometry partagé. L'interface n'est pas adaptée à Sprite mais fonctionne. Peut-être qu'il peut évoluer vers SpriteMesh pour rendre une interface plus conviviale

ce fil est TL; DR pour moi. mais je viens de découvrir ce code en r68 (ancien projet, oui):

        // uv repeat and offset setting priorities
        //  1. color map
        //  2. specular map
        //  3. normal map
        //  4. bump map
        //  5. alpha map

        var uvScaleMap;

        if ( material.map ) {

            uvScaleMap = material.map;

        } else if ( material.specularMap ) {

            uvScaleMap = material.specularMap;

        } else if ( material.normalMap ) {

            uvScaleMap = material.normalMap;

        } else if ( material.bumpMap ) {

            uvScaleMap = material.bumpMap;

        } else if ( material.alphaMap ) {

            uvScaleMap = material.alphaMap;

        }

        if ( uvScaleMap !== undefined ) {

            var offset = uvScaleMap.offset;
            var repeat = uvScaleMap.repeat;

            uniforms.offsetRepeat.value.set( offset.x, offset.y, repeat.x, repeat.y );

        }

Donc voilà...

si vous allez proposer un changement fondamental à la bibliothèque, comme celui que vous avez proposé ici, vous devez fournir un argument clair et convaincant pour ce changement

J'essayais de définir une répétition différente sur les cartes diffuses et normales et je m'arrachais les cheveux parce que cela ne fonctionnait pas. puisque l'API place ce paramètre dans la texture, je pensais pouvoir le faire. alors oui, que diriez-vous de garder mes cheveux pour un argument convaincant ? ce ticket est toujours ouvert, 3js a toujours ce paramètre sur les textures, et il n'est respecté que pour l'une des textures = c'est, en effet, déjà le paramètre EST par matière.

Si vous n'allez pas déplacer cela à sa place, dites au moins que cela n'a aucun effet dans les documents ?

@sunag pour les relations publiques :
https://github.com/mrdoob/three.js/pull/11531

Un problème que j'ai rencontré :
https://jsfiddle.net/f0j2v3s8/

Il semble que la transparence de SpriteNodeMaterial soit perdue, il n'y a aucune combinaison de mélange que je puisse utiliser pour que cet exemple fonctionne.

Des idées?

@karimbeyruti a écrit :

Lorsque vous définissez la carte, cela attribue automatiquement les uniformes de décalage/répétition (qui sont dans un matériau caché). Vous pouvez facilement les définir séparément - cela vous évitera d'avoir besoin de cloner des textures pour le moment. (fonctionne avec r73)

Je pense que c'est obsolète puisque uniforms.offsetRepeat est changé en uniforms.uvTransform (r88).

En ce qui concerne le cas d'utilisation « réutiliser un atlas de textures avec plusieurs instances d'Object3D », je suggère une simple promenade :

1. stocker les données UVs (décalage, répétition) dans un objet json atlas ;
2. accrocher la paire de fonctions onBeforeRender\onAfterRender d'Object3D ;
3. dans le rappel avant le rendu, chargez les données UV de l'objet json atlas et définissez-les sur material.map;
4. dans le rappel après rendu, réinitialisez-le ;

Il en résultera :

1. une seule texture et un seul matériau partagé par plusieurs objets, aucun clone n'est nécessaire et le compteur info.memory.textures n'augmentera pas ;
2. mais toujours toutes les autres maps (normales, ao, déplacement...) doivent respecter la même translation UV ;