Discussion :

[LittleWhite]

Oui, il y a bien un "z fighting" entre les pays et le maillage de la sphère. Un glPolygonOffset pourrait aider.

[aimad41]

En faite le probléme est tout autre, ma triangulation n'etait pas bonne, vu que le positionnement est sur un ellipsoid, j'ai subdivisé mes triangles, les choses sont rentré dans l'ordre, mais j'ai un autre soucis et de taille.

Le polygon mapping (texture, uv mapping), aprés quelques articles, docs, recherche, j'arrive à la formule suivante (je montre le 1er vecteur, je construit ma face avec 3 vecteurs pas de soucis):

v1.normalize();
u = Math.atan2(v1.x, v1.z) / (2. * Math.PI) + 0.5;
v = Math.asin(v1.y) / Math.PI + .5;

la sphére est aligné selon l'axe y, ma formule me semble bonne (wikipedia), mais en realité c'est une autre histoire :

Je séche depuis 3 jours, j'avance plus, need ur help

[p3ga5e]

Pour que l’on t’aide, il faudrait que tu nous lâche plus d’infos !
D’après ta formule mathématique, j’en déduis que tu cherche à requêter une texture equirectangulaire ! non ?

Personnellement, j’aurais opté pour une interpolation des coordonnées sphériques (latitude et longitude) entre le vertex et le pixel shader, plutôt que d’extraire les angles à partir de la normal du pixel !
v1 est bien la normal de la surface ?

Sinon, concernant les buffers , pour quel solution as-tu opté?

[aimad41]

Hello

oui c'est ça désolé pour le peu d'info le code est assez long :/

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
 
try {
 
 
    var d = new poly2tri(land, {cloneArrays:true});
    d.triangulate();
 
    var geometry = new THREE.Geometry();
    var tx1,ty1,tx2,ty2,tx3,ty3=0.0;
    var vec1,vec2,vec3 = 0;
    var i1,i2,i3 = 0;
 
    for (var i=0; i<land.length; i++){
      var vector = self.latLongToVector3(land[i].y,land[i].x,120,1.0);
      geometry.vertices.push(vector);
    }
 
    for (var i=0; i<triangles.length; i++){
 
      //var face = new THREE.Face3(triangles[i][0], triangles[i][1], triangles[i][2]);
      var i1 = self.vertexToIndex(land,triangles[i].getPoint(0));
      var i2 = self.vertexToIndex(land,triangles[i].getPoint(1));
      var i3 = self.vertexToIndex(land,triangles[i].getPoint(2));
 
      //console.log(i1,triangles[i].getPoint(0), geometry.vertices[i1]);
      var face = new THREE.Face3(i1, i2, i3);
 
      geometry.faces.push(face);
 
      //polygon mapping texture
      v1 = geometry.vertices[i1].clone();
      v2 = geometry.vertices[i2].clone();
      v3 = geometry.vertices[i3].clone();
      v1.normalize();
      v2.normalize();
      v3.normalize();
 
      tx1 = Math.atan2(v1.x, v1.z) / (2. * Math.PI) + 0.5;
      ty1 = Math.asin(v1.y) / Math.PI + .5;
 
      tx2 = Math.atan2(v2.x, v2.z) / (2. * Math.PI) + 0.5;
      ty2 = Math.asin(v2.y) / Math.PI + .5;
 
      tx3 = Math.atan2(v3.x, v3.z) / (2. * Math.PI) + 0.5;
      ty3 = Math.asin(v3.y) / Math.PI + .5;
 
      //polygon mapping texture
      geometry.faceVertexUvs[0].push([
        new THREE.Vector2(tx1,ty1),
        new THREE.Vector2(tx2,ty2),
        new THREE.Vector2(tx3,ty3),
        ]);
 
      self.faceIndex++;
    }
    } catch (e){
      console.log(name,'error triangulation',e);
    }

Alors en effet une texture equirectangulaire, je ne suis pas assez calé en trigo pour pouvoir faire tout les calcules si on choisit d'interpoler depuis les données latitude longtitude, du coup j'ai opté pour la solution la plus straight.

Pixel shader ? C'est dans le referentiel open gl es 2.0 ? il me semble qu'on est limité au vertex shader et fragment shader ?

Je suis pas encore à l'aise avec le GL SL, mais je sais qu'on peux le faire coté vertex shader et fragment shader je suppose ?

Pour les lignes, je suis pas satisfait du resultat, j'ai vais plus tard les dessiner sous form de QUAD.

Le buffer est generé par Three.js, donc limité, position et color + texture, pour les lignes j'ai du reparser mes données pour les dessiner avec la primitive LINES, ça crée des doublons mais c'est le seul moyen que j'ai trouvé pour ne faire qu'un appel draw.

Question polygon pareil, merge des vertex et faces, et insertion des uvs calculés, unique buffer donc, position, color, uv

Le plus propre serait de passer par le vertex shader je suppose, mais j'essaie deja d'avoir une interpolation correcte spherique (j'ai peur du soucis distorsion sur les pôles)

[LittleWhite]

pixel shader == fragment shader (c'est réellement le même, il a juste deux noms (un souvent utilisé dans DirectX et l'autre dans OpenGL. Pour moi, le terme de fragment shader est un peu mieux choisi, car la carte graphique gère des blocs de pixels (des fragments) (on peut en voir un peu les effets dans cet article : http://geeks3d.developpez.com/compte...ques-opengl-4/ ).)

[p3ga5e]

Ok je pensais que tu travailler sur ton propre pipeline de rendu !

J’entends par pipeline de rendu un couple Vertex et Fragment shader (ou Pixel Shader ), dans Three.js tu peux customiser le pipeline à l’aide de l'objet ShaderMaterial sur lequel tu peux également ajouter de nouveaux paramètres uniform, mais également des attributs pour les Vertex (cf cet exemple) ce qui n’est pas terrible car tous attributs de vertex devraient être associé à la géométrie.
Il y a un an je m’étais basé sur le ShaderMaterial pour calculer les animations skinnés sur GPU, cet technique m’a permis d’ajouter un nouvel attribut indiquant l’assignation du vertex a une des articulations du squelette paramétré par un nouvel Uniform.
Depuis, Three.js à ajouter la notion de BufferGeometry te permettant de customiser les attributs VBO et de travailler avec des IBO

Pour ton cas je procéderais de la manière suivant :
Pour le Vertex shaker, j’utiliserai uniquement l’attribut vec3 position, mapper par Three.js sur la collection geometry.vertices, afin que x contient les longitudes, y les latitudes ( et z l’élévation ?)

Code VertexShader :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
varying vec2 latlong;
const float r = 1.0;
const float h = 3.5;
#define DEG2RAD 0.017453292519943295769236907684886
 
vec4 latLongToVec4(vec2 gps)
{
    float phi = (gps.y)*DEG2RAD;
    float theta = (gps.x-180)*DEG2RAD;
    return vec3(
     -(r+h) * cos(phi) * cos(theta),
      (r+h) * sin(phi),
      (r+h) * cos(phi) * sin(theta),
	  1.0 );  
}
 
void main() 
{
	latlong = position.xy;
	gl_Position = projectionMatrix * modelViewMatrix * latLongToVec4( latlong );	
}

L’interpolation linéaire sur les angles latitude et longitude est assuré par la déclaration varying vec2 latlong; cela me permet de connaitre la position GPS de chaque pixel rendu et le pixel shader devient trivial

Code PixelShader :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
varying vec2 latlong;
uniform sampler2D map;
void main() 
{
	gl_FragColor = texture2D(map, vec2((latlong.x+180.0)/360.0, (latlong.y+90.0)/180.0 ));
}

[aimad41]

Je vais me documenter sur le buffer geometry j'ai vu qu'il bypass pas mal de routine peu utile et customisable a 100% donc oui meilleure choix indéniable !

Aprés réflexion je m'interroge, ici on calcul a chaque frame chaque chaque pixel notre vecteur, mais n'est-ce pas inutile, dans le sens ou ce calcul je le fais une seule et unique fois, coté cpu donc au demarrage puis le buffer ne change plus . Je me questionne question perf, alors aprés on vas me dire que c'est peu couteux ect.. mais est-ce cohérent ? :

[p3ga5e]

Tu t’interroges sur une éventuelle chute de perfs concernant la transformation des coordonnées sphériques en cartésien sur le vertex shader ? Si tu disposes vraiment de l’accélération matérielle alors tu n’as pas trop à t’en soucier. Ne perd pas de vu que les shaders sont exécutés, sur GPU de manière parallèle, donc il préférable d’exécuter le maximum de calculs sur GPU que sur CPU.

Concernant la pertinence, ma technique à l’avantage de réduire considérablement les buffers alloués en RAM et en VRAM , l’inconvénient est que Three.js est conçu pour travailler avec des données cartésiennes , les BoundingSphere et BoundingBox du prototype Geometry seront faux or Three.js s’en sert pour le fustrum culling, le calcul d’intersection par rayon et bien d’autre.

Pour en revenir à ton problème de "texturage", en utilisant le pipeline de rendu défini par le prototype MeshBasicMaterial, en gardant le changement de coordonnée sphérique en cartésien sur le CPU et en utilisant le calcul des texel (u et v) décrit dans mon pixel shader, cela donne quoi ?

[aimad41]

Mille excuses ! Cela fonctionne one shot !

Je te rejoins également concernant le fait de "paralléliser" un maximum de calculd, concernant le coté gestion mémoire, sommes nous pas limité dans le sens ou si tu lances tout ces calculs avec un chipset graphique intégré que ce passe t'il ? Ne faut'il pas équilibrer justement la balance entre charge cpu et gpu, je veux dire dans un contexte performance , le gpu consomme beaucoup plus q'un cpu, ça chauffe vite sur du laptop type netbook, alors je sais tu vas me dire c'est pas adapté à ce type d'application, mais c'est si on pense niveau conception à ce type de support, tu commences par toutes les questions perfs coté construction, création, allocation ect...

Par exemple dans mon cas ici, j'ai fusionné toutes les geometry pour ne faire qu'un seul appel drawElements, résultat convainquant sur un netbook, pareil pour toutes les objets présent (polylines ect..), niveau memoire tout vas bien sans texture avec le consommation explose littéralement, normal je présume, image 8k (200m coté gpu)

D'ailleurs en parlant de polylines, j'ai découvert que sur windows (je suis sur une debian, du coup m'en suis apercu aprés) la fonction glLineWidth ne fonctionne pas ou tout du moins limité à 1px, du coup j'ai du réfléchir à comment dessiner des lignes avec une certaine épaisseur, j'ai choisis de créer des QUADS, je sais pas si c'est super super opti mais c'est tout ce que mes connaissances m'ont permis de faire, pour chaque segments (2vertex, je construis mon quad), pour des points espacés pas de soucis, pour des points plus dense, je rencontre des soucis.

Je veux bien que tu détailles le coté perf memoire avec ta solution

Autre point critique ! Le picking, au survol j'envoi un rayon , je recup l'index de la face detecté, et ceux a chaque mouvement ! Mon plus gros soucis de perf se situe ici , j'ai essayé en vain la methode readPixel histoire de régler le soucis en natif (d'ou l'utilisation du buffer color, une color pour chaque pays, sorte d'index), mais ça ne fonctionne pas, je sais pas si c'est du a Three.js ou non, je ne pense pas


J'imagine que dans un contexte plus générale, la méthode readPixel est à privilégier, je ne sais pas, dans le sens ou la fonction sera appelé a chaque mouvement de souris, ce doit être forcement moins gourmand ..

[aimad41]

Trianguler une carte c'est une opération qui pompe un max de calculs, tu ne peux pas le faire décemment au runtime.

Il faut le précalculer, et il y'a des logiciels 3d qui font ça très bien.

Je triangule au runtime, j'ai aucune connaissance au soft type Blender and co', coté perf, avec un fichier shape 700k, rendu en 1.2s, fichier shape 3.8M, rendu en 7.5s incluant triangulation, subdivision et egalement construction de quads pour mes frontiéres.. evidemment dans un contexte de production, autant founir les données compilées déjà, mais si tu veux ajouter par exemple un rendu de terrain, ou de batiment, tu n'est plus limité et trianguler un polygone d'une dizaine de vertex c'est risible avec la puissance de calcul actuel des processeurs.

J'ôse esperer un jour l'idée d'une phase tesselation coté gpu avec de l'opengl es, accessible il me semble sur les moteurs graphiques versions desktop)

[p3ga5e]

D'ailleurs en parlant de polylines, j'ai découvert que sur windows (je suis sur une debian, du coup m'en suis apercu aprés) la fonction glLineWidth ne fonctionne pas ou tout du moins limité à 1px

Les développeurs du projet ANGLE soutiennent qu’ils respectent la norme OpenGL ES 2.0 (voir ce ticket ) apparemment supporter une largeur supérieur à 1 est difficilement implementable avec DirectX 9

Tu disposes vraiment de l’accélération matérielle GPU sous linux ? Ce ne serait donc pas mythe …

Je veux bien que tu détailles le coté perf memoire avec ta solution, on as si je me trompes pas, buffer positions, index, color et texture + uv dans le cas d'un material et d'une geometry Three js, si j'ai bien compris, avec notre shader ces routines on les maitrises ? du coup les uv ne plus sont nécessaire par exemple ?

Mon pipeline n’a besoin que d’un seul attribut Dans le VertexBuffer, un vec2 contenant la longitude et la latitude.

J’ai l’impression que tu mélange les attributs, les indices et les uniforms.

• Les attributs définissent la structure d’un sommet et se retrouvent dans le VertexBuffer , donc position, normal et uv.
• Les uniforms paramètrent le pipeline de rendu, tel la couleur diffuse et la texture d’un matériau.
• Les indices se trouvent dans autre buffer

Il me semble que le renderer de Three.js s’adapte aux attributs de chaques geometries

Autre point critique ! Le picking, au survol j'envoi un rayon , je recup l'index de la face detecté, et ceux a chaque mouvement ! Mon plus gros soucis de perf se situe ici , j'ai essayé en vain la methode readPixel histoire de régler le soucis en natif (d'ou l'utilisation du buffer color, une color pour chaque pays, sorte d'index), mais ça ne fonctionne pas, je sais pas si c'est du a Three.js ou non, je ne pense pas, si t'as une idée sur ce point..

Tu auras de bien meilleur perfs avec la technique du ColorPicking l’exemple Three.js se trouve ici. Si tu souhaites garder le lancer rayon vérifie que toutes tes geometries ont leurs boudingSphere et boundingBox de calculés.

[aimad41]

En effet je connais ce ticket, microsoft en même temps, il ne me choque plus depuis IE 6

Concernant le picking, j’étais convaincu qu'une seule technique était disponible , le rayon est un killer perf, il plombe littéralement les performances de mon globe, je regarde de plus prés ton example, j'aurai du voir la source plus tôt , il utilise la methode readPixel , m'en doutais..

J'ai bien compris la différence entre les différents variables que vont composer mon material, pas de soucis et en effet on économise coté buffer.

Par contre à quoi correspond le boundingSphere et le Box??? j'ai vu qu'en effet c'était présent dans tout les geometry... je vais chercher l'information !

Merci à toi pour tes lumières, j'ai vraiment avancé !

Accélération matérielle sous linux je confirme, uniquement sur Chrome cela dit, Firefox par contre non

Il me semble que le renderer de Three.js s’adapte aux attributs de chaques geometries .

Ouip c'est ce que je disais