[C#] GLWireframe

[artemisart]

J'ai retesté avec la bonne nouvelle version .
Plutôt que de le faire sur toute ma scène, j'ai testé juste pour un bâtiment (environ 22 000 sommets).
Le "baking" a duré 55 secondes, j'ai activé le speed bake comme tu me l'a conseillé. J'ai également rajouté une ligne dans ton script pour masquer la géométrie dans le GetSetMeshes.
Ensuite dans la scène, la chute de performance est indéniable,mais c'est bien mieux qu'avant.

Bizarre, les 55 secondes sont avec le SpeedBake ou le Bake ?
Si c'est le SpeedBake, c'est clairement pas normal, si c'est le Bake, c'est long, mais y a peut-être une explication.
Sinon tu utilise Unity 4 ou 3.5 ? (parce que j'ai fait aucun test de perf avec la v4).

Théoriquement, je pense que c'est beaucoup plus rapide avec plein de petits meshes que un gros (à cause de la suppression des edges en double), même si le nombre de vertices est égal au final.

Également, j'ai relancé ma scène en désactivant le script sur la caméra, et il effectue quand même le baking!?

C'est le baking au tout début ou à chaque frame qui est effectué ?
Je vais rajouter une condition pour empêcher le baking dans le OnPostRender si le script est pas activé , j'update le script dans 2s.

[artemisart]

Par curiosité, j'ai retester avec la fonction bake, et le framerate passe à 38FPS, pour un temps de baking aux environs des 2 mn

Ok, et sinon les infos du OnGUI donnent quoi ? (change le rect pour pouvoir les voir).

[axel]

Justement je me demandais à quoi servait le Rect
Donc il m'indique:
Baking : 0ms (0)
render : environ 30ms

Cela correspond à quoi?

Sinon pour les 55 second, c'est avec le speedbake.

Quant au bake lorsque je désactive le script, il s'agit de celui au lancement.

Et j'utilise la 3.5

[artemisart]

Justement je me demandais à quoi servait le Rect
Donc il m'indique:
Baking : 0ms (0)
render : environ 30ms

Cela correspond à quoi?

Le baking, c'est le temps que le script mets pour update le wire des meshes qui ont bougés, le truc entre parenthèses est le nombre de meshes qui ont bougés.
Le render, c'est le temps que mets le script à rendre tous les wires (ça englobe tous les appels à la classe GL).

Sinon pour les 55 second, c'est avec le speedbake.

Glups, je vais voir ce que je peux faire .

Quant au bake lorsque je désactive le script, il s'agit de celui au lancement.

Je viens de découvrir que Awake est appelé même si le script est désactivé (bug ?), suffit donc de le remplacer par Start (j'update le script dans 2s).

[artemisart]

Script mis à jour, encore optimisé !
Pour supprimer les edges en doubles, je comparais les Vector3 avec la fonction Equals...
J'ai remplacé par une fonction toute simple et... 3x fois plus rapide !!!

Pour info, voici la fonction Equals du Vector3 (code décompilé avec MonoDevelop) :

Code : Tout sélectionner

		public override bool Equals (object other)
		{
			if (!(other is Vector3))
			{
				return false;
			}
			Vector3 vector = (Vector3)other;
			return this.x.Equals (vector.x) && this.y.Equals (vector.y) && this.z.Equals (vector.z);
		}

L'opérateur == :

Code : Tout sélectionner

		public static bool operator == (Vector3 lhs, Vector3 rhs)
		{
			return Vector3.SqrMagnitude (lhs - rhs) < 9.99999944E-11f;
		}

Et ma fonction (on pouvait pas faire plus simple... 2x plus rapide que ==, 3x plus rapide que Equals) :

Code : Tout sélectionner

		private bool V3Equals (Vector3 a, Vector3 b)
		{
			return a.x == b.x && a.y == b.y && a.z == b.z;
		}

[Max]

Bon, je viens de refaire un test. Ça marche bien, et ça speed pas mal, ce qui n'est jamais trop évident sur ce genre de rendu.

Sur une scene comportant une quarantaine d'objet totalisant pas loin de 40.000 faces, on commence à peine à sentir l'impact
du rendu des wireframe. En info j'ai un first backing de 4500 ms, edge= 51000 et un baking à 0 ms.

Par contre, juste un petit défaut, ton rendu Wireframe est brut, donc pas soumis au fustrumculling. Pas énorme défaut, car c'est le genre
de chose qui sert beaucoup pour du debug, mais sur des scène bien chargé et en wire complète, cela aura forcement un impact aussi en
terme de perf

sinon, beau boulot

[artemisart]

Sur une scene comportant une quarantaine d'objet totalisant pas loin de 40.000 faces, on commence à peine à sentir l'impact
du rendu des wireframe. En info j'ai un first backing de 4500 ms, edge= 51000 et un baking à 0 ms.

Pas mal, pas mal, et le rendu ?

Par contre, juste un petit défaut, ton rendu Wireframe est brut, donc pas soumis au fustrumculling. Pas énorme défaut, car c'est le genre
de chose qui sert beaucoup pour du debug, mais sur des scène bien chargé et en wire complète, cela aura forcement un impact aussi en
terme de perf

J'ai aucune idée de comment faire du frustum culling en fait (et faut que ça soit plus rapide que de tout mettre en brut aussi ^^).

sinon, beau boulot

Merci .

[Max]

J'ai aucune idée de comment faire du frustum culling en fait (et faut que ça soit plus rapide que de tout mettre en brut aussi ^^).

Ben à vue de pif (comme l'on dit), le plus simple serait dans MeshWire.Render() de faire le rendu des GL qui si le gameobject associé est visible
par la curent camera. ( un truc du genre GLobject.renderer.isVisible is true...).
A tester si cela a une réel plus value dans la pratique (sur une scene simple avec deux cube certainement pas, mais sur des scène plus complexes....)

[artemisart]

J'ai aucune idée de comment faire du frustum culling en fait (et faut que ça soit plus rapide que de tout mettre en brut aussi ^^).

Ben à vue de pif (comme l'on dit), le plus simple serait dans MeshWire.Render() de faire le rendu des GL qui si le gameobject associé est visible
par la curent camera. ( un truc du genre GLobject.renderer.isVisible is true...).
A tester si cela a une réel plus value dans la pratique (sur une scene simple avec deux cube certainement pas, mais sur des scène plus complexes....)

Merci pour l'astuce ! c'est vrai que j'y avais pas pensé du tout, et le gain est énorme dans certaines scènes (j'ai mis à jour le script du premier post).

Attention par contre, on ne voit pas forcément les gains en editor :

Note that object is considered visible when it needs to be rendered in the scene. It might not be actually visible by any camera, but still need to be rendered for shadows for example. Also, when running in the editor, the scene view cameras will also cause this value to be true.

Donc il faut mettre la cam de la SceneView dans le vide si on veut vraiment voir les perfs.

D'ailleurs, comment je peux modifier le shader pour ajouter un léger offset dans le z depth ? (pour éviter que le wire se fonde dans le mesh).

[Max]

Cool, là ça envoi, et on arrive à garder un FPS plus constant