Bonjour,
Voici après quelques tests (assez sommaire).
Programme: test6, 50 boite sont lachée au rythme 1 toutes les 250ms.
Le test environ 6 secondes.SOR_LCP: Le solveur d'ode gain de
54% en vitesse, il represente à peu pres 20% du temps total.
Collider: gain
5% (16% du temps total). Ce n'est pas surprenant. Peu d'effet sur les collisons, la separation des espace (objets) est plus utile.
raydium_texture_find_by_name : gain 6% a mon avis ne reprsente rien si ce n'est la dispersion des tests. par contre 3% du temps total.
raydium_ode_callback: 50% plus lent (pas tres significatif) 5% du temps total.
Les mesures ne sont pas très precises, j'aurais préféré des cycles, je fais avec ce que j'ai.
On gagne donc pas mal au niveau du solveur
. Et c'est à peu près tout.
Par contre on peut aussi balayer devant notre porte, certaines fonctions raydium sont appelées de façon très intensives, a optimiser (au moins un peu).
J'ai a peu près identifié le problème avec odenet. Lorsqu'un objet se desactive, on n'envoie plus d'infos sur kle reseau. Du coup l'objet distant continue avec la dernière vitesse lineaire et angulaire envoyée.
Il faudrait un evenèment reseau pour indiquer que l'objet se desactive. Avec update de la position rotation et desactivation sur la machine cliente.
Enfin toutes les primitives d'ajout de force ne peuvent marcher au travers de la couche reseau, puisque la physique des objets est calculé par une machine et les forces appliquées par une autre. (sauf bien sur pour les objets locaux a une instance de raydium), suis je clair ?
Un ajout de force devra donc etre forcement un fonction plannifiée reseau dès le depart.
Bonne soirée
Ouille