Réunion du 07-12-2021
Traduction en cours Source : http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2021-12-07
Introduction
[11:02] Ubit Umarov : bonjour [11:03] Selby.Evans @grid.kitely.com:8002 : Salut Jamie [11:04] Gavin.Hird @grid.xmir.org:8002 : Salut Jamie [11:04] Jamie.Jordan @grid.kitely.com:8002 : Salut tout le monde [11:04] Selby.Evans @grid.kitely.com:8002 : Salut Jamie [11:07] Ubit Umarov : Eh bien, Andrew semble un peu en retard. [11:08] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je vais lui jeter des cacahuètes
Sortie de la version 0.9.2.0 le 05-12-2021
[11:08] Ubit Umarov : comme vous le savez certainement, dimanche dernier, la version 0.9.2.0 est sortie. [11:08] Gavin.Hird @grid.xmir.org:8002 : /clap [11:09] Gavin.Hird @grid.xmir.org:8002 : quand est-ce que la soirée de lancement aura lieu ? [11:09] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ubit Umarov est en train de le regarder lol [11:09] Ubit Umarov : ouais lol [11:09] Ubit Umarov : http://opensimulator.org/wiki/0.9.2.0_Release [11:10] Ubit Umarov : la version de développement est maintenant 0.9.2.1 Dev [11:10] Vincent.Sylvester @hg.zetaworlds.com:8002 : Le Changelog est assez long comparé au précédent, si long que même après avoir parcouru l'historique git, je n'ai toujours pas trouvé tout ce qui vaut la peine d'être mentionné. [11:10] Ubit Umarov : comme déjà sur ces régions [11:10] Gavin.Hird @grid.xmir.org:8002 : aussi festif que le booster covide [11:10] Ubit Umarov : oups [11:10] Ubit Umarov : la version devel est maintenant 0.9.2.1 Yeti Dev. [11:10] Ubit Umarov : :) [11:10] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai éliminé quelques bogues qui traînaient depuis des années. [11:11] Vincent.Sylvester @hg.zetaworlds.com:8002 : L'une des versions les plus productives, je dirais. [11:11] Ubit Umarov : presque deux ans depuis la 0.9.1.1. [11:11] Gavin.Hird @grid.xmir.org:8002 : Il y travaille jour et nuit (avec de l'aide bien sûr). [11:12] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il y a aussi beaucoup d'anticipation dans les arrières plans alors que les choses évoluent vers de nouveaux standards, ce qui est toujours utile pour réduire les coûts et éviter que certaines choses ne fonctionnent plus. [11:13] Vincent.Sylvester @hg.zetaworlds.com:8002 : YEngine devient la valeur par défaut et fournit une base de référence bien plus agréable pour les scripts. [11:13] Ubit Umarov: :) [11:13] Ubit Umarov : bien sûr, vous le savez tous déjà. [11:13] Ubit Umarov : vous l'utilisez ou un dérivé. [11:14] Ubit Umarov : comme zeta et kitely [11:14] Ubit Umarov : ou xmir :) [11:14] Gavin.Hird @grid.xmir.org:8002 : xmir est entièrement en Y [11:14] Gavin.Hird @grid.xmir.org:8002 : pas de changement ici, seulement quelques omissions. [11:14] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai inondé la boîte de messagerie d'Ubits de correctifs récemment qui devraient, je l'espère, apporter des changements utiles pour la prochaine version, une fois qu'il les aura lus. [11:15] Ubit Umarov : oh je parlais de la version 0.9.2.0. [11:15] Gavin.Hird @grid.xmir.org:8002 : 0.9.2.0 sans EEP [11:15] Ubit Umarov : :) [11:16] Gavin.Hird @grid.xmir.org:8002 : donc si quelqu'un veut une version dé-eep-isée... [11:16] Ubit Umarov : zeta suit habituellement Dev. [11:16] Ubit Umarov : kitely attend habituellement une version, mais cette fois-ci, la version 0.9.2.0 a été incorporée il y a quelque temps. [11:16] Ubit Umarov : parce que c'est nécessaire pour les nouveaux viewers. [11:17] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je compile les patchs directement sur le noyau pour ne pas avoir à fusionner chaque changement, ce qui me rendait fou. [11:17] Ubit Umarov : merci à tous pour votre aide :) [11:18] Vincent.Sylvester @hg.zetaworlds.com:8002 : D'après les changements apportés aux notes de publication, il semble que le plan consiste à publier plus régulièrement des versions maintenant ? [11:18] Gavin.Hird @grid.xmir.org:8002 : hehe - ce n'était pas aussi le plan la dernière fois ? [11:19] Ubit Umarov : J'avais prévu de sortir la version 0.9.2.0 l'année dernière. [11:19] Ubit Umarov : donc... nous verrons bien :)
Version de développement 0.9.2.1 et première modification
Paramètre AllowLoginFallbackToAnyRegion
[11:19] Ubit Umarov : comme pour la 0.9.1.1, la 0.9.2.1 sera bientôt disponible. [11:20] Ubit Umarov : cela dépend du nombre de problèmes que les gens signaleront maintenant. [11:20] Ubit Umarov : j'ai déjà fait un changement à ce propos :) [11:21] Ubit Umarov : en 0.9.2.0, même les simples standalones doivent définir une région avec des flags par défaut. [11:21] Ubit Umarov : cette information est seulement dans les notes de version. [11:21] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il y a toujours beaucoup de problèmes sur Mantis, mais beaucoup d'entre eux représentent des problèmes qu'il faut essayer de reproduire, donc ils sont là depuis des années, il faut vraiment plus de types de statut pour trier les choses comme étant périmées, nécessitant des tests, etc.... [11:21] Ubit Umarov : donc en 0.9.2.1 ce ne sera plus nécessaire, en fonction d'une nouvelle option que j'ai ajoutée. [11:23] Ubit Umarov : le truc c'est que si à la connexion aucune région "officielle" n'est trouvée pour envoyer l'utilisateur, le code envoie juste vers n'importe quelle région qu'il trouve en ligne. [11:23] Ubit Umarov : comme vous pouvez l'imaginer cela peut constituer une grande violation de la vie privée, etc... [11:23] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il peut également échouer si la région est mal configurée. [11:23] Ubit Umarov : donc la 0.9.2.0 ne permettra pas cela ... [11:24] Gavin.Hird @grid.xmir.org:8002 : ou un grand embarras selon... [11:24] Ubit Umarov : 0.9.2.1 le permet avec cette nouvelle option. [11:24] Ubit Umarov : ouais [11:24] Ubit Umarov : un vieux problème d'opensim [11:24] Ubit Umarov : mais pour bloquer totalement l'option comme je l'ai fait en 0.9.2.0. [11:25] Ubit Umarov : donc... j'ai ajouté l'option, avec la recommandation de ne la laisser à true que lorsque cela n'a pas d'importance. [11:26] Ubit Umarov : donc c'est le premier code ajouté à la 0.9.2.1 :) [11:26] Ubit Umarov : un jour et quelques bits après la sortie ;)
Cycle des versions dans OpenSimulator
Cycle des versions pour OpenSimulator
https://bitbucket.org/opensimulator/opensim/commits/
[11:26] Vincent.Sylvester @hg.zetaworlds.com:8002: post fixes partout [11:26] Gavin.Hird @grid.xmir.org:8002 : Je pensais que l'incrémentation du numéro de version était la première étape. [11:27] Ubit Umarov : bien j'arrête de poursuivre le nom postfixes sur les versions. [11:27] Ubit Umarov : un numéro mineur sur la version, signifie des petits changements ou des corrections de bugs. [11:27] Ubit Umarov : je n'ai jamais compris comment on pouvait avoir seulement une version xxx-postfixes. [11:27] Ubit Umarov : un peu trop optimiste :p [11:28] Ubit Umarov : comme vous l'avez remarqué, l'étape de la version candidate (release candidate) a aussi été arrêtée. [11:28] Ubit Umarov : elles ne donnent pas retour supplémentaire. [11:28] Ubit Umarov : donc c'est juste une perte de temps. [11:29] Gavin.Hird @grid.xmir.org:8002 : comment peut-on avoir une release candidate pour quelque chose qui est en beta ? [11:29] Gavin.Hird @grid.xmir.org:8002: :-) [11:29] Gavin.Hird @grid.xmir.org:8002 : ou est-ce alpha ? [11:29] Ubit Umarov: http://opensimulator.org/wiki/Release_Cycle [11:29] Ubit Umarov : eh bien, nous les avons eus. [11:29] Ubit Umarov : même RC1, RC2... etc... [11:30] Vincent.Sylvester @hg.zetaworlds.com:8002 : A ce stade, si vous voulez toujours l'appeler une alpha, alors je me demande ce qu'est Win11, car il fonctionne de manière beaucoup moins fiable. [11:30] Ubit Umarov : les numéros de version simples et normaux suffisent. [11:30] Gavin.Hird @grid.xmir.org:8002 : Win11 est un virus du secteur de démarrage [11:30] Ubit Umarov : comme je l'ai dit, les chiffres mineurs signifient des changements mineurs etc... [11:30] Ubit Umarov : comme la plupart des logiciels. [11:31] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je considère comme une bêta quelque chose que vous pouvez exécuter et qui ne décidera pas aléatoirement d'exploser si vous le laissez seul. [11:32] Ubit Umarov : comme vous pouvez le voir sur l'ancien cycle de publication, la version à publier a été même placé [12] Ubit Umarov : sur une branche appelée... xxx.postfixes [11:33] Ubit Umarov : comme brak 0.9.2.0 sur git a le code release. [11:33] Ubit Umarov : branck [11:33] Gavin.Hird @grid.xmir.org:8002 :J'appelle cela une bêta quand il ne prend pas encore conscience qu'il fonctionne dans une machine virtuelle, et vient avec toutes sortes de recommandations erronées basées sur le moment où le système fonctionne - comme le meilleur moment pour appliquer les mises à jour. [11:33] Ubit Umarov : oui, je ne sais pas taper... branche 0.9.2.0 :) [11:34] Ubit Umarov : et sur un point similaire du master, il y a le tag0.9.2.1Dev pour marquer le début du travail sur la 0.9.2.1. [11:34] Ubit Umarov : Je pense que ceci est plus "propre", et vous ? [11:35] Ubit Umarov: https://bitbucket.org/opensimulator/opensim/commits/
Mantis et attente de rapport de bogues : à vos tests !
[11:35] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'attends l'afflux de problèmes sur la mantis et d'autres personnes qui vont faire exploser le canal IRC. La sortie a été d'une certaines manière tellement calme que personne ne l'a remarquée jusqu'à présent. [11:36] Ubit Umarov : Beaucoup de gens ne regardent que la sortie d'une version. [11:36] Ubit Umarov : et il y a des gens avec d'autres cas d'utilisation, etc. [11:36] Vincent.Sylvester @hg.zetaworlds.com:8002 : Mantis a besoin d'un peu d'amour je pense, un peu plus de balises d'état et la mise à jour des numéros de version. [11:36] Ubit Umarov : il est donc normal de recevoir plus de rapports de bogues. [11:37] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ce qui reste sur les problèmes non résolus a besoin d'une meilleure structure pour voir ce qui existe et pourquoi. [11:37] Ubit Umarov : nous allons voir comment ça se passe et si nous avons besoin de sortir une version même ce mois-ci lol. [11:37] Ubit Umarov : si un problème majeur est trouvé (et que nous pouvons le résoudre). [11:38] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'aimerais juste une étiquette "needs testing"(besion de test) pour signaler les problèmes à revoir, soit après avoir été corrigés, soit après avoir réalisé une tonne de travail. [11:38] Ubit Umarov: sur mantis? [11:38] Vincent.Sylvester @hg.zetaworlds.com:8002: Oui [11:38] Gavin.Hird @grid.xmir.org:8002 : les commentaires des utilisateurs sont nécessaires. [11:38] Ubit Umarov : Eh bien, beaucoup de gens négligent tout cela. [11:39] Ubit Umarov : quelqu'un m'a dit qu'il ne voyait que les versions jusqu'à 0.9,1,1 à installer. [11:39] Ubit Umarov : j'ai ajouté 0.9.2.0 et 0.9.2.1Dev et je les vois. [11:39] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je veux juste y apporter plus de structure pour qu'il soit plus facile de voir ce qui est encore un problème maintenant et pour que les gens qui cherchent à aider sachent clairement ce qu'ils peuvent faire pour aider. [11:40] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il y a probablement quelques douzaines de problèmes enfouis dedans qui devraient être examinés, mais les trouver et les confirmer demande beaucoup de travail. [11:40] Vincent.Sylvester @hg.zetaworlds.com:8002 : Comme tous les problèmes de freeswitch, reproduire cela est presque impossible maintenant que freeswitch devient de plus en plus difficile à configurer, semble-t-il. [11:40] Ubit Umarov : J'espère que tout va bien pour Andrew. [11:40] Ubit Umarov : ou son chat. [11:41] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il s'est probablement endormi quelque part [11:41] Vincent.Sylvester @hg.zetaworlds.com:8002 : l'hiver vous fait ça. [11:43] Vincent.Sylvester @hg.zetaworlds.com:8002 : Avec le nettoyage que j'ai fait, j'ai enterré quelques problèmes importants qui ont été soumis, je dois les retrouver et les remettre en haut de la liste je pense. [11:44] Gavin.Hird @grid.xmir.org:8002 : comme ?
Problème de cache d'objet
[ http://opensimulator.org/mantis/view.php?id=8934 issue 8934]
[11:44] Vincent.Sylvester @hg.zetaworlds.com:8002 : Surtout ce comportement bizarre du cache d'objet qui devient ennuyeux quand il se produit. [11:44] Vincent.Sylvester @hg.zetaworlds.com:8002 :Je dois revenir aux tests, j'ai désactivé ce cap pour la région où cela se passait le plus mal pour voir si cela donne de meilleurs résultats. [11:45] Vincent.Sylvester @hg.zetaworlds.com:8002 : Désactiver le côté viewer semble aider, mais ce n'est pas idéal. [11:45] Gavin.Hird @grid.xmir.org:8002 : Je ne vois jamais de mise en cache bizarre des objets [11:45] Gavin.Hird @grid.xmir.org:8002 :es-tu sûr que ce n'est pas un problème de viewer ? [11:45] Ubit Umarov : certaines options du côté de la viewer sont brisées. [11:45] Ubit Umarov : jamais utilisé chez SL, donc ignoré. [11:45] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je pense que c'est le viewer qui ne comprend pas les données qu'il reçoit. [11:46] Gavin.Hird @grid.xmir.org:8002 : ok, est-ce que ça enregistre quelque chose ? [11:46] Ubit Umarov : voici Andrew le dormeur. [11:46] Ubit Umarov : :) [11:46] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai un journal de débogage que je dois mettre et voir ce qu'il fait, mais je soupçonne qu'il dira que tout va bien tel quel. [11:46] Gavin.Hird @grid.xmir.org:8002 : Bonjour Andrew [11:47] Andrew Hellershanks : Bonjour, tout le monde. [11:47] Vincent.Sylvester @hg.zetaworlds.com:8002 : Soit l'appel est malformé en chemin vers le viewer, soit le viewer ne le comprend pas. [11:47] Andrew Hellershanks : J'étais en train de travailler sur mon ordinateur portable et j'ai oublié quel jour on était. [11:47] Gavin.Hird @grid.xmir.org:8002 : mais que se passe-t-il ? [11:47] Ubit Umarov: oups [11:47] Ubit Umarov : j'ai oublié la réunion :) [11:48] Vincent.Sylvester @hg.zetaworlds.com:8002 : En fait, ce qui se passe, c'est que les anciennes prims qui sont en cache dans le viewer peuvent être éditées sans problème du point de vue de la région. [11:48] Gavin.Hird @grid.xmir.org:8002 : maintenant nous devons recommencer à zéro. [11:48] Ubit Umarov : ok andrew peut faire un résumé de ce que nous avons dit :) [11:48] Vincent.Sylvester @hg.zetaworlds.com:8002 : Mais quand on force le viewer à redessiner la prim, il utilise la version en cache qui montre toujours l'état précédent de la prim. [11:48] Gavin.Hird @grid.xmir.org:8002 : forcer le viewer à redessiner le prim ? [11:49] Vincent.Sylvester @hg.zetaworlds.com:8002 : Zoomer très loin et revenir en arrière [11:49] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai posté une vidéo sur la façon de le reproduire sur Mantis qui montre ce qui se passe. [11:49] Gavin.Hird @grid.xmir.org:8002: how often do you flush changes to persistent storage? [11:50] Vincent.Sylvester @hg.zetaworlds.com:8002: On the region it's fine, you edit, that change takes when you nuke the viewer cache it all looks fine, it's definitely local viewer cache messing up [11:50] Andrew Hellershanks: ty, Ubit. [11:50] Vincent.Sylvester @hg.zetaworlds.com:8002: What's odd is that there seems to be code to tell the viewer to purge the object from cache [11:50] Vincent.Sylvester @hg.zetaworlds.com:8002: Let alone the viewer itself is editing the prim so it should know to purge it from cache and retrieve a new copy instead [11:50] Gavin.Hird @grid.xmir.org:8002: why is that odd [11:51] Gavin.Hird @grid.xmir.org:8002: cache is ment to be purged or invalidated at any time [11:52] Vincent.Sylvester @hg.zetaworlds.com:8002: It's probably there to make sure things are purged, but in regards to testing this issue it is strange the viewer doesn't do this itself as well, knowing which prim is being edited so knowing that it shouldn't used the local cache version afterwards yet it still does [11:52] Gavin.Hird @grid.xmir.org:8002: if your change has not been written to persistent storage and you do something that force the viewer to invalidate the caceh and retrieve it from persistent storage, you will lose cahnges [11:52] Gavin.Hird @grid.xmir.org:8002: so you need to set your region to write your changes back to the db more often [11:53] Vincent.Sylvester @hg.zetaworlds.com:8002: The edit on the region works properly that's not the issue, you can verify this using physics [11:53] Gavin.Hird @grid.xmir.org:8002: so where does it not work? [11:53] Vincent.Sylvester @hg.zetaworlds.com:8002: I scaled a prim down to reveal terrain underneath and when I had the viewer redraw the prim showing the original size the part I scaled back became phantom [11:55] Vincent.Sylvester @hg.zetaworlds.com:8002: https://www.youtube.com/watch?v=pYmTDf76jcw [11:56] Vincent.Sylvester @hg.zetaworlds.com:8002: Ubit been telling me to leave object cache enabled for performance reasons, though outside of particularly slow regions I don't really see much difference in that, perhaps I am more patient than others when it comes to waiting for a region to load [11:57] Vincent.Sylvester @hg.zetaworlds.com:8002: It's just driving me mad when you make changes to something, turn around to have them all undone and you gotta nuke cache and relog each time [11:57] Ubit Umarov: i see caching working fine most the time [11:57] Gavin.Hird @grid.xmir.org:8002: I don't think ti was undone in your example, because wjhen you walked around there after the zoom, you came to the point where you stepped up to the resized prim [11:58] Gavin.Hird @grid.xmir.org:8002: it is a drawing problem in the viewer [11:58] Vincent.Sylvester @hg.zetaworlds.com:8002: Yep like I said on the region itself the edit sticks just fine, the viewer just doesn't follow because it grabs the cached version [11:58] Ubit Umarov: yeah that clip is irritating ofc [11:58] Gavin.Hird @grid.xmir.org:8002: but I don't see the point of those zooms? [11:59] Vincent.Sylvester @hg.zetaworlds.com:8002: Forces redrawing [11:59] Gavin.Hird @grid.xmir.org:8002: for what purpose? [11:59] Vincent.Sylvester @hg.zetaworlds.com:8002: So it triggers cache fetch [11:59] Ubit Umarov: and that is not even viewer cache [11:59] Gavin.Hird @grid.xmir.org:8002: why? [11:59] Ubit Umarov: that is in memory things [11:59] Gavin.Hird @grid.xmir.org:8002: exactly Ubit [12:00] Vincent.Sylvester @hg.zetaworlds.com:8002: That's the thing, disabling viewer object cache in the viewer directly entirely removes this behavior [12:00] Gavin.Hird @grid.xmir.org:8002: why do you want to trigger cache fetch? [12:00] Vincent.Sylvester @hg.zetaworlds.com:8002: After doing that I couldn't get a single prim to "misbehave" in that manner [12:00] Gavin.Hird @grid.xmir.org:8002: did you only test this in FS? [12:01] Gavin.Hird @grid.xmir.org:8002: or does other viewers behave the same [12:01] Vincent.Sylvester @hg.zetaworlds.com:8002: I have not tested with other viewers so far [12:01] Gavin.Hird @grid.xmir.org:8002: ok, but FS has a very particular cache implementation [12:01] Gavin.Hird @grid.xmir.org:8002: so it could be an issue there [12:02] Gavin.Hird @grid.xmir.org:8002: also I still don't get the need to trigger a cache feetch [12:02] Gavin.Hird @grid.xmir.org:8002: fetch [12:02] Vincent.Sylvester @hg.zetaworlds.com:8002: Because when you work on something it randomly does that while you aren't looking and then you turn around to see all the changes you made half an hour ago seemingly undone when they actually aren't [12:03] Vincent.Sylvester @hg.zetaworlds.com:8002: Made me question my sanity first few times I saw that [12:03] Gavin.Hird @grid.xmir.org:8002: never, ever experienced that [12:03] Vincent.Sylvester @hg.zetaworlds.com:8002: The mantis ticket exists simply to track this on OpenSim end and to get verification that OpenSim does send proper information [12:03] Gavin.Hird @grid.xmir.org:8002: what is the size of the region you work on? [12:03] Vincent.Sylvester @hg.zetaworlds.com:8002: var or normal doesn't matter happens on both [12:04] Gavin.Hird @grid.xmir.org:8002: ok [12:04] Gavin.Hird @grid.xmir.org:8002: have you tweaked the occlusion settings in your viewer? [12:04] Andrew Hellershanks: Allow me to interject a quick reminder. The Open Simulator Community Conference is this weekend. Check out the web site at https://conference.opensimulator.org/ for the schedule of events. [12:04] Vincent.Sylvester @hg.zetaworlds.com:8002: Did tell FS devs about this, but haven't heard back, guess I will open a ticket on their end in this regard to get the ball rolling [12:05] Vincent.Sylvester @hg.zetaworlds.com:8002: I have ambient occlusion turned off [12:05] Gavin.Hird @grid.xmir.org:8002: that was not what I meant [12:06] Gavin.Hird @grid.xmir.org:8002: objects off camera can be occluded to speed up rendering [12:06] Gavin.Hird @grid.xmir.org:8002: typically things behind you [12:06] Gavin.Hird @grid.xmir.org:8002: but also objects hidden by others [12:07] Vincent.Sylvester @hg.zetaworlds.com:8002: Outside of disabling object cache I haven't changed viewer debug settings yet [12:07] Gavin.Hird @grid.xmir.org:8002: ok [12:08] Gavin.Hird @grid.xmir.org:8002: how much GPU memory have you allocated for the viewer? [12:08] Vincent.Sylvester @hg.zetaworlds.com:8002: There is a setting for that? [12:08] Gavin.Hird @grid.xmir.org:8002: there is for texture memory [12:09] Vincent.Sylvester @hg.zetaworlds.com:8002: That's set to 512 mb [12:09] Gavin.Hird @grid.xmir.org:8002: ok [12:09] Gavin.Hird @grid.xmir.org:8002: how much GPU memory do you ahve? [12:09] Vincent.Sylvester @hg.zetaworlds.com:8002: Not sure if that has bearing on it, but worth a try I guess [12:10] Vincent.Sylvester @hg.zetaworlds.com:8002: Regular Nvidia 1080 so not all that much and it has to drive 4 screens so probably got 2-4gb left ot play with [12:11] Vincent.Sylvester @hg.zetaworlds.com:8002: Like I said merely opened the mantis so we can rule out OpenSim as the cause of this if it does indeed send proper notice to invalidate an object that's been edited [12:11] Gavin.Hird @grid.xmir.org:8002: I think I have heard LL say the viewer code is not particularly happy with GPU memory over 4 Gb, but I might be wrong [12:12] Ubit Umarov: well opensim did sent right information, you seen prim change size [12:12] Ubit Umarov: and the zoom is 100% viewer side [12:12] Gavin.Hird @grid.xmir.org:8002: yes it is [12:12] Vincent.Sylvester @hg.zetaworlds.com:8002: Yep from going through the support code for object cache I didn't find anything that stuck out to being a potential cause for this if it wasn't working right [12:13] Ubit Umarov: so.. vodoo [12:13] Vincent.Sylvester @hg.zetaworlds.com:8002: I will make a note to poke FS via a ticket as I haven't gotten a return on my email yet [12:13] Ubit Umarov: guess not easy to try repo similar circunstances at sl [12:13] Gavin.Hird @grid.xmir.org:8002: I think it might be the viewer does not invalidate the cached item when it is persisted to the region, [12:14] Vincent.Sylvester @hg.zetaworlds.com:8002: That would be my guess too [12:14] Ubit Umarov: if you relog the prim is as it was edited [12:14] Ubit Umarov: no ? [12:14] Vincent.Sylvester @hg.zetaworlds.com:8002: Not always, but more likely, if I nuke cache it definitely is as it fetches it from region [12:15] Gavin.Hird @grid.xmir.org:8002: but there is caching in the viewer, but also in flotsam, yeah? [12:15] Ubit Umarov: so region just did its thing.. [12:15] Vincent.Sylvester @hg.zetaworlds.com:8002: I made some experiments leaving cache and just disabling caching system, mixed results there and I don't know the internals of what causes it to invalidate it either [12:15] Ubit Umarov: nothing to so with flotsam [12:15] Ubit Umarov: prims are not even on it [12:15] Gavin.Hird @grid.xmir.org:8002: ok [12:16] Vincent.Sylvester @hg.zetaworlds.com:8002: This issue has been around for years now, I have seen that first time all the way back in 2017 even [12:16] Ubit Umarov: ( unless if rez from inventory possible ) [12:16] Vincent.Sylvester @hg.zetaworlds.com:8002: It must be something small just a missing line somewhere in the viewer code, but chances of me finding that within the decade are slim [12:17] Gavin.Hird @grid.xmir.org:8002: but in any case it should be invalidated in the viewer cache when persisted to the region [12:17] Ubit Umarov: i remember there was a viewer cache option that did show prims, if we did move away and back.. boing all gone till relog :) [12:18] Ubit Umarov: i show a fs dev.. answer was " why did you set that option.. it is not used.." [12:18] Ubit Umarov: done :) [12:18] Andrew Hellershanks: As you are talking about viewer behaviour and caching I'll add in a comment/question in case it might be related. [12:19] Andrew Hellershanks: I was noticing the other day that after I logged in to a region some of the textures were blurry (because they had not fully loaded yet?). I forced a texture refresh and they fully loaded and looked good. A few moments later they went blurry again then eventually fully loaded once again and looked ok. [12:20] Andrew Hellershanks: It seems a bit odd that a fully texture would "unload" and need to be loaded a second time. [12:20] Gavin.Hird @grid.xmir.org:8002: texture trashing [12:20] Gavin.Hird @grid.xmir.org:8002: too little texture meory most likely [12:21] Vincent.Sylvester @hg.zetaworlds.com:8002: Dayturn used to do that for me quite a bit, few releases ago it stopped though [12:21] Andrew Hellershanks: I hadn't moved. It was like a given texture wasn't loaded fully, then loaded and showed properly then reverted to a partially loaded state, then settled down to a fully loaded state. [12:22] Andrew Hellershanks: The only thing I was doing during that time was using Tex Refresh in the viewer to help it load a partially loaded texture. [12:22] Vincent.Sylvester @hg.zetaworlds.com:8002: Viewer loads close things first then everything farther away so it might eventually load a prim the next region over causing it to fill texture memory [12:22] Gavin.Hird @grid.xmir.org:8002: There has a been a lot of fixes to texture memory allocation, so that basically got rid of it [12:23] Andrew Hellershanks: Vincent, ok. Sounds like it viewer side. I'm running the latest version of FS. [12:23] Gavin.Hird @grid.xmir.org:8002: plus if you have oversize textures, meaning larger than 1024x1024 it goes nuts about it [12:23] Ubit Umarov: just see it happen [12:23] Ubit Umarov: if a prim is a old to be cachable.. [12:23] Andrew Hellershanks: Wasn't my region or my objects so I have no idea of the size of the texture(s). [12:24] Ubit Umarov: ( simple box) [12:24] Ubit Umarov: we log in.. resize it.. zoom out completly that in.. the size change is gone [12:24] Gavin.Hird @grid.xmir.org:8002: older objects might have 2048x2048 textures applied to them [12:24] Ubit Umarov: fs shoes the prim as it was at login even on edit tab [12:25] Ubit Umarov: we relog, and go get the changed prim [12:25] Ubit Umarov: so.. fs is doing some mess [12:25] Ubit Umarov: i can't test at sl [12:25] Gavin.Hird @grid.xmir.org:8002: it is still possible to do that, but you have to sneak the texture that size in via direct upload to db [12:25] Ubit Umarov: bc can't rez a box for 30 mins or to [12:25] Ubit Umarov: or so.. [12:26] Ubit Umarov whispers: test at sl rez a box and leave there for some time ( 30min) ? [12:26] Ubit Umarov: so it is flagged as cachable [12:27] Ubit Umarov: then login and repeat change size zoom out, zoom in.. [12:29] Andrew Hellershanks: We are at about the hour and a half mark. Does anyone have any other questions before this meetings is wrapped up? [12:30] Andrew Hellershanks: I don't see any one typing so I will take that as that is all for today. [12:30] Selby.Evans @grid.kitely.com:8002: https://www.reddit.com/r/metaverse/ [12:30] Andrew Hellershanks: I hope to see some of you at the OSCC event this weekend. [12:30] Jamie.Jordan @grid.kitely.com:8002: great meeting [12:31] Andrew Hellershanks: Enjoy the OSCC events. We can talk about it this coming Tuesday. [12:31] Andrew Hellershanks: Thank you all for coming. See you again next week.