« Réunion du 09-07-2024 » : différence entre les versions

De OSWiki
Aller à la navigation Aller à la recherche
Ligne 12 : Ligne 12 :
== Limitation des mises à jours des agents ==
== Limitation des mises à jours des agents ==
* [http://opensimulator.org/viewgit/?a=commit&p=opensim&h=b06ecf801469f966705a17f8b5323c1741f23168 Commit b06ecf] : Maintenant, les agents envoient  des '''demandes non-actualisation aux viewers''' pour en ignorer certaines.  
* [http://opensimulator.org/viewgit/?a=commit&p=opensim&h=b06ecf801469f966705a17f8b5323c1741f23168 Commit b06ecf] : Maintenant, les agents envoient  des '''demandes 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.
* '''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.  
* 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.  
* '''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.
* 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''' : [https://jira.firestormviewer.org/browse/FIRE-34171][https://feedback.secondlife.com/bug-reports/p/directional-input-delays-with-latest-pbr-capable-viewers]
* '''Informations complémentaires en anglais''' : [https://jira.firestormviewer.org/browse/FIRE-34171][https://feedback.secondlife.com/bug-reports/p/directional-input-delays-with-latest-pbr-capable-viewers]

Version du 12 juillet 2024 à 09:48

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 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.😉


Noyau

Scripts

Base de données

Modules

Bugs

Tests

Projets en cours / Infos

Réflexions sur la vitesse des NPC

Viewers

Source

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