new kind of submeshes suggestion : meshParts

[jerome]

Hi,

 

Sorry for the next part of this post, but as I'm not good enough at expressing accurate things in english, I will do this in french.

So, non-french readers please don't mind.

Maybe someone could translate afterwards... or maybe it will not be worth it at all

 

Ok, je bascule.

 

Je me place du point de vue de l'utilisateur (du développeur) de BJS.

Quand il utilise des meshes fournis par l'API (je ne parle donc là pas de ce qui viendrait d'un import blender ou autres) comme la sphère, le cube, etc, il dispose immédiatement des méthodes fournies par AbstractMesh, Mesh et peut-être de méthodes propres au type de Mesh lui-même.

S'il souhaite intervenir sur une sous-partie du mesh (texturer ou colorer différemment une face d'un cube, un "anneau" d'une sphère ou d'un cylindre par exemple), il doit utiliser, si j'ai bien compris, les subMeshes.

 

Les subMeshes permettent d'accèder sur le mesh parent aux vertices ou aux indices en passant en paramètre un index de départ et un nombre d'unités à récupérer, bref un compteur. C'est simple, pratique et puissant.

 

Le problème est que le développeur n'a pas forcément connaissance de l'ordre dans lequel le mesh est construit.

Sans lire le code et l'algo qui construit la sphère, on ne peut pas savoir s'il s'agit de cercles concentriques empilés les uns sur les autres, les faces reliant ensuite ces cercles, ou des cercles se croisant aux pôles comme les quartiers d'une orange par exemple.

 

Mon idée serait donc -c'est encore très flou dans ma tête- une nouvelle forme de subMeshes supplémentaire (il faut garder l'actuel parce que c'est puissant et ça permet de tout faire quand on sait où adresser l'index/compteur).

Disons quelque chose d'un peu plus haut niveau que l'actuelle fonction, appelons le meshParts pour la suite.

 

Un meshParts pourrait être simplement un tableau de subMeshes prédéfinis par le concepteur du mesh initial qui en a, lui, la maîtrise de la conception. Ce serait une interface simple et utile pour l'utilisateur, amha. Ceci lui permettrait d'accéder à un peu de la "logique" du mesh pensée par son concepteur.

 

Je m'explique par des exemples.

Prenons la sphère : le tableau des meshParts pourrait être l'ensemble des subMeshes (pré-défini par le concepteur) correspondant chacun à un anneau. Pas besoin de connaître les index/compteurs, chaque subMesh/meshPart est un anneau. Point.

Ou être un quartier d'orange !!! selon le choix du concepteur ...

 

Idem pour le cylindre : un anneau = un meshPart

 

Pour le cube : une face = un meshPart

 

etc

pas de règle, c'est le concepteur du mesh qui choisit le découpage en meshParts qu'il souhaite (et comment il fabrique le meshPart évidemment) selon la logique qu'il trouve la meilleure ou selon ce qu'il souhaite exposer au développeur pour travailler/modifier son mesh initial.

 

Voilà, c'était l'idée qui m'est venue en bossant sur le tube après les remarques de Wingy sur comment colorer un anneau du tube différemment (sans passer par les textures, ni tomber dans les shaders et le GLSL tout de suite).

 

Merci d'avoir tenu jusque là.

Pas sûr d'être bien clair, même en français 

[GameMonetize]

Lol even in French i'm not sure to get it

[Wingnut]

I saw "de Wingy" in there.  Oh no!  Once again, we are SO screwed!

 

French.  pffft.  It's not French, it's Ribbonese, eh, dk?  nod. 

[GameMonetize]

If I get it correctly, you want array of submeshes. But want to you want to do with this? Submeshes are mainly used to have a group of materials affected to a single mesh.

[spritefire]

I only understand English. Only thing I got from it was something about changing the faces of a cube and , sub meshes, and changing the colouring of a tube with glsl shaders.. Oh and a mention of an orange

[jerome]

arf

Je me disais bien que ça allait être difficile en français aussi 

DK, je reprends ton exemple : je veux affecter un groupe de materials à un seul mesh.

 

Je suis utilisateur de BJS, je choisis par exemple le torus knot.

Je n'ai aucune idée de la façon dont il est construit, l'algo est trop compliqué pour moi à comprendre/extraire du code dans github. Je ne sais donc pas a priori, si je veux, disons, mettre un material différent sur 36 ème anneau à partir de quel index du mesh torus knot, je dois commencer à récupérer les vertices/indices ni sur quelle longueur.

 

Par contre, si le concepteur du torus knot avait, dans son algo de creation du mesh, rempli en même temps un tableau référençant des parties (meshParts) du mesh selon une logique qui lui semblait la plus pertinente, j'aurais pu en tant que simple utilisateur modifier le material d'une (ou de plusieurs) de ces parties sans avoir à connaitre précisément quel sous-ensemble du torus knot (au sens quel index/quelle longueur) était accédé.

 

Pas clair ?

 

Revenons à notre exemple :

Le torus knot pourrait donc fournir un tableau meshParts.

Chaque élément du tableau serait alors peut-être un vertexData ou quelque chose y ressemblant, disons a minima un ensemble de positions et d'indices  définissant une partie précise du mesh initial.

Dans le cas du torus knot, ça pourrait être un ensemble d'anneaux constituant le torus knot : torus.meshParts[36] => les positions et indices du 36 ème anneau.

 

Changeons d'exemple : http://www.babylonjs-playground.com/#1Q5J6R#6

Il n'y a là qu'un unique mesh, un ribbon.

Comment l'utilisateur qui veut accéder aux 254° anneau peut-il connaitre l'index de position du premier vertex à utiliser dans un submesh ?

Ca me semble compliqué pour lui, d'autant que le mesh est construit sur une fonction mathématique (pas d'accès a priori à l'algo pour compter les itérations simplement) ?

Par contre si moi, le concepteur du mesh ribbon, je remplis un tableau en mettant dans chaque élément les références des vertex/indices de chaque anneau, je donne un accès plus "logique" aux parties du mesh à mon utilisateur.

Ca pourrait être des anneaux ou des tranches longitudinales ou des sections radiales, qu'importe. C'est le concepteur qui décide qu'elles sont les sous-parties à exposer à l'utilisateur.  

 

De façon plus globale, ce serait la notion de parties (ou sous-parties) d'un mesh donné, ces parties ayant une définition logique arbitraire (des anneaux, des secteurs, des faces) et étant référencées au préalable, à la construction du mesh.

Ca ne semble d'ailleurs pas très coûteux à implémenter quand on code l'algo de construction d'un mesh.

[GameMonetize]

je comprends mais je pencherais plus pour de la doc par type d'objets

[joshcamas]

"de Wingy" - I laughed so hard when I saw this. This made my day. 

[jerome]

@DK : you're the boss, boss. So we'll do ! 

However, I will probably do something dedicated to ribbons because it makes sense to access a given portion once constructed as it receives an array of paths for paramater : the BJS user knows the array of paths he passes, so he would be happy to access a related portion of the final shape, I think.

 

@others : aaarff... this "de Wingy" seems very mysterious, does it ?   

I just talked about a Wingy suggestion about the way to change colors of only one part of the tube. My long speech was about a new feature I asked for : the way to access a part (or sub-part as you prefer) of a mesh without knowing anything about vertex/indice indexes to start from, as it is required when using subMesh().

 

Not so mysterious, you know, at last