Réunion du 09-07-2024

De OSWiki
Aller à la navigation Aller à la recherche

Changements du code de la semaine

Permissions

  • Commit c8b135: Correction de la vérification de l'autorisation de modifier un objet partagé dans un groupe .

Ajout de llGetNotecardLineSync

string llGetNotecardLineSync( string nom, integer ligne );

Cette fonction renvoie la chaîne de caractères contenant le texte de la ligne <ligne> demandée dans une notecard <nom>. Elle récupère <ligne> de la notecard dans le cache des notecards de la région immédiatement sans déclencher d'événement de type "dataserver".

Limitation des mises à jours des agents

  • Commit b06ecf : Maintenant, les agents envoient des demandes de non-actualisation aux viewers pour en ignorer certaines.
  • Le code de gestion des périphériques (souris et clavier) du viewer semble être inefficace. Cela peut entraîner des problèmes de réactivité ou de fluidité dans l'interaction avec le monde virtuel. Pour pallier à ces problèmes, augmenter les mises à jour des agents peut être une solution pour améliorer la synchronisation et la réponse aux actions des utilisateurs, même si cela peut entraîner d'autres défis en termes de charge de traitement et de bande passante.
  • Les viewers peuvent envoyer davantage de demandes de mises à jour lorsque le GPU est capable de traiter un plus grand nombre d'images par seconde et qu'il a un taux de rafraîchissement élevé. S'il fait 400fps (frame par seconde), il envoie environ 300 mises à jour par seconde. Cela peut entraîner des pertes de paquets de données. En réponse à cela, Linden Lab a réduit le nombre de mises à jour à 10 par seconde, ce qui a affecté négativement l'expérience des utilisateurs en termes de fluidité, entraînant des plaintes. Les scripts de véhicules de Second Life demande 45 mises à jour par seconde. Actuellement, les serveurs de Second Life ignorent tous les événements plus rapides que 45 mises à jour par seconde.
  • Firestorm permet 125 mises à jour par seconde. Peut-être pour les combats ? Ubit Umarov a ajouté du code pour ignorer ce qui va au delà de 45 mises à jour par secondes . OpenSim n'envoie que 10 mises à jour de mouvement par seconde avec les réglages par défaut ce qui est correct pour une région sociale.
  • 125 mises à jour c'est une mise à jour toutes les 8ms, qui doit être traitée et transformée en données pour la frame suivante, ce pour quoi on ne dispose que de 16ms de manière réaliste. De plus avec le viewer Firestorm PBR actuel la plupart des utilisateurs n'ont même pas 25 fps.
  • Informations complémentaires en anglais : [1][2]

Avertissement

Attention : Ce résumé existe pour orienter vos recherches. Des erreurs d'interprétation ne sont pas à exclure. Pour plus de précisions, veuillez vous référer aux sources ou vous adresser directement aux développeurs d'OpenSimulator en assistant aux réunions du mardi ou sur le canal IRC. Je ne fais pas partie des développeurs, ne vous adressez pas à moi pour les joindre. Merci.😉


Modules

Génération des niveaux de zoom de maptile en parallèle

Situation

  • Régénération des maptiles d'une grille : suppression des anciennes cartes du disque pour que Robust les régénère . Robust démarre un thread de rendu et au bout d'un moment, toutes les maptiles sont à nouveau disponible. C'est un processus assez long.

Projet

  • Vincent Sylvester réfléchit à une solution pour créer les différents niveaux de zoom de maptile en parallèle pour accélérer leur génération mais, il est confronté à des problèmes de verrouillage.
NDLR  : Verrouillage  : peut-être des conflits ou des blocages mis en place pour éviter des problèmes d'incohérences dans les données générées ou des conflits d'accès aux ressources partagées.


  • Il envisage de générer chaque niveau de zoom sur son propre thread, mais cela pourrait entraîner une utilisation accrue de la mémoire pour la mise en cache des tuiles.

Problèmes

  • La dépendance entre les niveaux de zoom peut poser problème : une solution proposée par Vincent Sylvester consisterait à générer chaque niveau de zoom de manière indépendante, en ajoutant progressivement les carreaux aux niveaux supérieurs.
  • OpenSim ne peut pas prendre toute les ressources d'une machine comme un jeu PC.
  • Il semble qu'actuellement Robust puisse générer 13000 maptile en 10 minutes. L'assemblée a l'air de penser que ce n'est déjà pas si mal.

Visionneuse de carte

  • Une visionneuse de carte proposée par Joe Magarac http://animats.com/sl/map/
  • Maintenez CTRL et la souris gauche enfoncées pour incliner et faire pivoter la carte.

Serveur d'argent NSL/DTL avec le support de BTCPay

Nouvelle version

NDLR  : Traduction littérale générée par DeePL des premières lignes de la documentation sur GitHub : "Il s'agit d'une version modifiée de DTL/NSL Secure Money Server par Fumi.Iseki et NSL retravaillé pour interagir avec BTCPay Server en tant que passerelle de paiement et processeur de crypto-monnaies dans un contexte auto-souverain, où vous avez 100% du contrôle et vous êtes derrière votre propre système sans aucun frais ou tiers.... Liberté."


  • Pré-requis :
    • Voir la documentation.
    • Opensimulator >= v0.9.3 (SSL/TLS recommandé).
    • Nécessite un serveur Web protocole HTTPS (important! ne pas utiliser sans TLS/SSL). En raison de la suppression des fonctions xmlrpc dans PHP 8, la version de PHP la plus compatible est la dernière PHP 7.4. La partie PHP ne fonctionne pas avec PHP 8.

Rappel

  • Ubit Umarov souligne qu'OpenSim ne touche pas aux modules d'argent et encore moins aux systèmes pyramidaux choses cryto.
  • À la remarque "C'est peut-être pour cela que la caisse d'opensin se retrouve vide", il répond : " Oui, vide mais pas en prison."
NDLR  : J'ai bien ri, donc je vous en fait profiter.


Divers

Réflexions sur la vitesse des NPC

Le problème

  • Vincent.Sylvester a remarqué que les NPC semblent se déplacer plus lentement que les avatars normaux ce qui est ennuyeux quand on essaie de les suivre. Leur mouvements sont contrôlés par du code. Il a fait des tests asynchrones pour isoler le NPC des autres éléments du simulateur et des tests simfps (simulated frames per second) pour évaluer les performances du simulateur. Cela n'a rien donné.
  • Les NPC et les avatars utilisent le même code de déplacement "moveto".
NDLR  : Je n'ai pas vraiment compris si les NPC et les avatars utilisaient vraiment le même mode de déplacement. Ubit Umarov ajoute plus loin : "Je ne suis pas sûr qu'il y ait une comparaison, puisque la mécanique de mouvement est différente."


Causes envisagées

  • Est-ce que les animations de marche sont identiques ? : ce sont des animations côté viewer, les animations ne devraient pas avoir d'incidence.
  • Le NPC porte t-il un AO[3] (animations overriders) scripté  ? Les AO et les scripts côté serveur peuvent avoir un impact sur les animations mais pas sur la vitesse.
  • Le réseau : il faudrait faire des tests locaux et des tests avec des machines plus éloignées.
  • Est-ce que les NPC sont trop lents ou les avatars trop rapides ?
  • Cela peut aussi dépendre du moteur physique : à tester.

Solutions envisagées

  • Ajuster la vitesse de déplacement des NPC, y compris l'injection de vitesse.
  • Tests supplémentaires : réseau, moteur physique.

Problème de précision et problème physique

Conditions

  • Grille OpenSim 0.9.3,
  • Deux varregions de respectivement 8x8 et 16x16

Problèmes rencontrés

  1. le mouvement du véhicule est très saccadé pendant environ 30 secondes
  2. Quand le simulateur est démarré depuis un certain temps, il y a des zones ou le moteur physique détecte un objet physique alors qu'il n'y a rien. L'objet a été déplacé ou supprimé mais, le moteur physique agit comme s'il était toujours là. On peut se tenir debout sur "l'objet". Rien ne s'affiche avec la visualisation des invisibles activée. Le redémarrage du simulateur corrige le problème.

Questions de Cuga Rajal

  • À propos de deux régions  : pourrait-il y avoir un lien entre la variation de précision en virgule flottante et les problèmes de physique ?
  • Cette gigue pourrait-elle être à l'origine de la lenteur du moteur physique ?
  • Est-ce que la taille de la région peut être aussi à l'origine du problème 2 ? Est-il possible d'avoir d'autres problèmes de physique avec une grande varregion ?

Réponses

  • 8x8, c'est un peu à la limite de ce qu'on veut pour la physique. Il y a beaucoup de variables qui circulent à cette échelle. 16x16, ce serait étonnant si cela ne provoquait pas des collisions bizarres.
  • Il faudrait répéter la situation sur une simulation de taille standard (256x256). Tester au coin 0,0 et au coin opposé.
  • Le problème 2 ne semble pas lié à un problème de précision. La suppression d'objets est asynchrone et peut prendre du temps.
  • La boîte englobante (bouding box)[4] pour la physique dans OpenSim fait 1024x1024, pour le moteur physique BulletSim. Sur des régions plus grande
  • 🏗️

Problème de précision des grandes régions -- réunion du 30-04-2024

Source

http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2024-07-09

Récupérée de « https://cogito.no-ip.info/cogito/OSWiki/index.php?title=Réunion_du_09-07-2024&oldid=9681 »