Optimisation pour nuage de points

[Pico57]

Il sert principalement à faire des mesures pour le moment (les autres fonctions techniques ne sont pas encore vraiment déterminées). Je ne vois pas comment ne pas l'afficher vu que je crée mes points de mesure grâce à un raycasthit sur celui-ci.

[artemisart]

Je comprend pas trop comment tu raycast un nuage de point (vu que le ray va s’arrêter sur une surface (-> triangles) donc un mesh) mais de toute façon tu peux avoir le collider indépendant du renderer, donc mettre un mesh simplifié pour le rendu.

[Pico57]

Quand j'importe mon FBX, j'ai un mesh qui corrrespond au maiilage du nuage de points. Ensuite, MeshToplogy.Points permet de retrouver le rendu nuage de points plutot que d'avoir la pièce maillée. Le Raycast, s'arrète sur un collider, j'ai donc mis un Mesh Collider sur mon nuage et c'est bon. Par contre, le Raycast ne s'arrète pas pile-poil sur un point mais au point d'intersection sur le mesh. Je suis justement en train de voir pour récupérer le point le plus proche (avec NavMeshAgent.FindClosestEdge).

[sotec]

sinon, un système de LOD, : tu fais 3 ou 4 objets avec ton nuage de points, avec différentes qualité, tu met tout ça dans un LOD et quand tu est loin, tu vois la version petite qualité, et quand tu zoom tu vois la version la plus éloigné.

[artemisart]

Ensuite, MeshToplogy.Points permet de retrouver le rendu nuage de points plutot que d'avoir la pièce maillée.

Donc le nuage de point n'est pas très important niveau rendu ?
Parce que dans ce cas tu peux très bien utiliser un mesh (même un peu chargé) avec une bonne normal map (ou parallax mapping, ou encore tessellation), ça sera toujours plus léger que un nuage de point.

Par contre, le Raycast ne s'arrète pas pile-poil sur un point mais au point d'intersection sur le mesh. Je suis justement en train de voir pour récupérer le point le plus proche (avec NavMeshAgent.FindClosestEdge).

Le point qui sera "touchée" par le rayon (donc le plus proche du rayon) ne sera pas le point le plus proche du point d'impact sur le mesh, sauf si le mesh correspond bien au nuage (dans ce cas le nuage est inutile).
Donc si le mesh n'est pas assez détaillé (correspond pas assez au nuage), toute précision est perdue (en même temps, faire un truc de ce genre sur mobile/tablette avec une précision telle qu'il faut un nuage de 1.4M points, je comprends pas trop).

[Pico57]

@sotec:
J'ai déjà pensé à faire de la LOD mais voilà plusieurs choses :
1-A cause de la taille de la pièce Unity la découpe tout seul car il n'accepte pas les objets avec plus de 65535 verts ou tris. Ce qui fait que Unity me découpe l'object en 22 sous-objets. Ca, ça pourrait être bien pratique déjà. (mais c'est le seul point positif)
2-Mes objets sont tous à la même distance de la caméra donc la LOD n'a que peux d'effet vu que tous mes objets gardent le même niveau de détail.
3-Pour faire mon zoom, je change la valeur du fielofview de ma camera donc l'éloignement du point de vue par rapport à l'objet reste toujours le même. J'ai pensé que c'était mieux que de déplacer la position de la camera. Peut-être avez vous une meilleure manière de zoomer ?

@artemisart:
Pour la normal map, je vais voir ce que ça donne, je n'ai pas encore eu l'occasion d'utiliser ça.

Le point qui sera "touchée" par le rayon (donc le plus proche du rayon) ne sera pas le point le plus proche du point d'impact sur le mesh

Je ne vois pas pourquoi. On part du principe que l’utilisateur veut sélectionner un point mais il va forcément taper à coté, on considère donc que le point qu'il voulait est celui le plus proche de là où il a réellement tapé.

[artemisart]

Le point qui sera "touchée" par le rayon (donc le plus proche du rayon) ne sera pas le point le plus proche du point d'impact sur le mesh

Je ne vois pas pourquoi. On part du principe que l’utilisateur veut sélectionner un point mais il va forcément taper à coté, on considère donc que le point qu'il voulait est celui le plus proche de là où il a réellement tapé.

Il va taper à côté, sur le mesh collider.
Donc plus le mesh collider sera "simplifié", plus les points s'en éloigneront logiquement (à moins que tous les points soient sur la même surface, dans ce cas ils sont inutiles).
Si on considère que chaque tri est vertical, dans les coordonnées x et y, chaque point aura un z différent par rapport au tri (comme si le tri était une image où chaque pixel représente un point), donc point le plus proche du point d'impact sera très proche de la surface du tri (= résultat très similaire au point d'impact du raycast), et le point que l'utilisateur veut sélectionner sera pas forcément celui là (en quelque sorte, le "grain" du mur sera perdu).

[Pico57]

Il va taper à côté, sur le mesh collider.
Donc plus le mesh collider sera "simplifié", plus les points s'en éloigneront logiquement (à moins que tous les points soient sur la même surface, dans ce cas ils sont inutiles).

Si je met le mesh collider en convexe, je suis entièrement d'accord avec toi, il est possible de taper complètement à côté du point que l'on veut. Par exemple sur ce morceau qui est dans l'encadrure de la porte :

Par contre, tant que je n'active pas le convexe, le collider est bien confondu avec le mesh ; en tout cas c'est mon impression car mes points de mesures ont l'air bien plaqué sur le mesh.

Si on considère que chaque tri est vertical, dans les coordonnées x et y, chaque point aura un z différent par rapport au tri (comme si le tri était une image où chaque pixel représente un point), donc point le plus proche du point d'impact sera très proche de la surface du tri (= résultat très similaire au point d'impact du raycast), et le point que l'utilisateur veut sélectionner sera pas forcément celui là (en quelque sorte, le "grain" du mur sera perdu).

Si je comprend bien, tu veux parler par exemple du cas du renfoncement de la porte, prendre un point dans ce plan (ou son équivalent dans le nuage de point qui n'est pas affiché sur ce screen) :

Oui, l'erreur peut être vite agrandie mais on peut aussi se déplacer dans la pièce pour se mettre à une position plus adéquate à cette mesure, par exemple :


EDIT :
J'en profite pour poser une autre question, c'est du scripting mais je vais éviter de multiplier les sujets.
Comme j'en parlais plus haut, j'essaye d'utiliser la fonction : NavMesh.FindClosestEdge
Voilà le morceau de code intéressant, qui est très proche de la documentation (C#) :

Code : Tout sélectionner

	private GameObject Click2 ;	
	public NavMesh mesh ;void CreatePoint ()
	{
		Ray ray = mainCamera.ScreenPointToRay ( Input.mousePosition ) ;
		RaycastHit hit ;
		
		if (Physics.Raycast (ray, out hit, 20.0f) )
		{
			NavMeshHit nearesthit ;
			if (mesh.FindClosestEdge(hit.point, out nearesthit, -1))
			{
				Click2 = Instantiate (boule, nearesthit.position , Quaternion.identity) as GameObject ;
				Click2.transform.parent = mesurePts.transform ;
				Click2.name = "PointProche"+PtCount ;
			}
		}
	}

Assets/Plugins/Mesure3.cs(78,34): error CS0176: Static member `UnityEngine.NavMesh.FindClosestEdge(UnityEngine.Vector3, out UnityEngine.NavMeshHit, int)' cannot be accessed with an instance reference, qualify it with a type name instead

En suivant les conseils de cette erreur (CS0176), j'ai rempacé mesh.FindClosestEdge(hit.point, out nearesthit, -1) par NavMesh.FindClosestEdge(hit.point, out nearesthit, -1). C'est cool, on ne me renvois pas d'erreur, en revanche la fonction renvois toujours false et cela ne me parait pas normal de ne pas identifier le mesh dans lequel on souhaite faire la recherche.
Je ne comprend pas à quoi sert à la variable passableMask (3ème élément dans NavMesh.FindClosestEdge), peut-être le soucis viens de là.
Si qqn a déjà utilisé NavMesh.FindClosestEdge, merci d'avance.