Réunion du 05-04-2022

Source : http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2022-04-05

Introduction

La réunion de cette semaine s'est tenue dans la région Hurliman Plaza d'osgrid car la région Dev Outreach ne fonctionnait pas.

[11:05] Jamie.Jordan @grid.kitely.com:8002 : cela faisait longtemps :-)

[11:05] Ubit Umarov : je suppose qu'une partie de la migration est toujours en cours.

[11:06] Ubit Umarov : mais il y a eu un gros problème au milieu et la grille a dû être coupée tous ces jours pour le réparer.

[11:06] Andrew Hellershanks : C'est en train de devenir la réunion de voyage. :)

[11:06] Kayaker Magic : Vérification de la radio, est-ce que quelqu'un peut voir ce que je tape maintenant ?

[11:06] Andrew Hellershanks : Je peux, Kayaker.

[11:07] Jagga Meredith : yup

[11:07] Kayaker Magic : J'avais un décalage de 5 minutes dans le chat jusqu'à ce que je me reconnecte !

[11:07] Vincent.Sylvester @hg.zetaworlds.com:8002 :il semblerait que la région fonctionne en dsl [1] sur "wet string"

[11:07] Andrew Hellershanks : Gavin a du mal à venir ici.

[11:07] Ubit Umarov : Une chance, j'ai eu un troll sur moi jusqu'à maintenant :)

[11:08] Kayaker Magic : Déjà entendu parler de barbed-wire-net ? Envoyer Internet à travers une ferme via le fil de clôture.

[11:08] Ubit Umarov: lol

[11:08] Ubit Umarov : maintenant tu as un troll au-dessus de toi kayaker

[11:08] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il semble que nous devions apprendre à misterblue comment fonctionnent les sièges.

[11:08] Gavin.Hird @grid.xmir.org:8002 : Bonjour à tous

[11:09] Andrew Hellershanks : Bonjour, Gavin.

[11:09] Andrew Hellershanks : Bonjour à tous.

[11:09] Selby.Evans @grid.kitely.com:8002 : Salut Gavin

[11:10] Jagga Meredith : Si jamais vous avez besoin d'un endroit pour vous rencontrer, ma région Interfaith est toujours prête (sauf complications). Il y a plusieurs lieux de rencontre là-bas.

[11:10] Gavin.Hird @grid.xmir.org:8002 : J'ai une région entière avec un lieu de réunion

[11:10] Kayaker Magic : Est-ce que c'est ici sur OSGrid Jagga ?

[11:10] Gavin.Hird @grid.xmir.org:8002 : grid.xmir.org:8002:Barcola

[11:10] Jagga Meredith: Oui

Les noms des Plaza de Osgrid

Page des développeurs OpenSim

[11:11] Misterblue Waves : J'ai parlé à Hurliman il y a quelques semaines. Il fait des trucs en robotique en ce moment.

[11:11] Misterblue Waves remarque que nous sommes à "Hurliman Plaza".

[11:11] Ubit Umarov : Oh ? bien

[11:11] Ubit Umarov : oui, il semble qu'il ait été développeur opensim aussi. [11:13] Andrew Hellershanks : Je ne savais pas qu'il y avait/a un vrai Hurliman.

[11:13] Ubit Umarov : osgrid a nommé certaines places avec les noms des core devs.

[11:13] Ubit Umarov : lbsa, bade teravus celui-là...

[11:14] Ubit Umarov: don't ask the criteria [11:14] Andrew Hellershanks: Interesting bit of trivia. :) [11:15] Jagga Meredith: AFK. have to RL. no issues [11:15] Andrew Hellershanks: Glad to see everyone. We lost a few people at the past couple of meetings due to the recent outage of osgrid. [11:16] Andrew Hellershanks: ok, Jagga. Thanks for dropping by. [11:18] Ubit Umarov: well i did sent emails about the location at zeta [11:18] Ubit Umarov: also was on the site [11:19] Andrew Hellershanks: Good of you to do that. [11:19] Gavin.Hird @grid.xmir.org:8002: I never had any infor about a different location, so just assumed it did not happen [11:20] Kayaker Magic: I have a question about terrain texture, perhaps Gavin can answer: [11:20] Vincent.Sylvester @hg.zetaworlds.com:8002: It was on mailing list, wiki and irc [11:20] Gavin.Hird @grid.xmir.org:8002: which mailing list? [11:20] Vincent.Sylvester @hg.zetaworlds.com:8002: http://opensimulator.org/pipermail/opensim-users/ [11:20] Andrew Hellershanks: Not all regular attendees may be on the mailing list. [11:20] Andrew Hellershanks: Ah. I'm not on that one so I didn't see the message but I did see it in IRC. [11:21] Kayaker Magic: On a large var, after the terrain has loaded, the texture slowly fills in. But I thought the viewer constructed the textures, they should blink in almost instantly! What causes this delay? [11:21] Gavin.Hird @grid.xmir.org:8002: I have given up those mailing list because I was never able to reply to anything [11:21] Vincent.Sylvester @hg.zetaworlds.com:8002: I just read it too, mailing lists are too complicated for my simple brain [11:21] Gavin.Hird @grid.xmir.org:8002: constructed the textures? [11:22] Kayaker Magic: Terrain textures are made from 4 textures and some altitude settings. [11:22] Andrew Hellershanks: Gavin, were you subscribed to the list? It seems odd that you couldn't reply to a message unless you weren't on the list. [11:22] Gavin.Hird @grid.xmir.org:8002: yes I was [11:22] Ubit Umarov: viewer does the terrain texture composition yes [11:22] Gavin.Hird @grid.xmir.org:8002: what is that name of that gook who's code crased OSG in 2014 [11:22] Ubit Umarov: not a light thing.. [11:22] Gavin.Hird @grid.xmir.org:8002: he did something with my addresses that nobody have been able to undo [11:23] Vincent.Sylvester @hg.zetaworlds.com:8002: Terrain can actually fully load with just one texture applied and the other textures load in afterwards. In the viewer the terrain has LOD so the patches are not all the same, they get generated each bit by bit [11:23] Vincent.Sylvester @hg.zetaworlds.com:8002: Should be one of the first things to load, so situations of having to wait for terrain to load should be rare [11:23] Gavin.Hird @grid.xmir.org:8002: how large is the VAR in question? [11:23] Ubit Umarov: the outof order sending we try do to does slow that a bit [11:23] Ubit Umarov: but see no issues [11:24] Kayaker Magic: I notice it on 4x4s, but it is most easy to demonstrate on an 8x8 [11:24] Gavin.Hird @grid.xmir.org:8002: ok [11:24] Ubit Umarov: wlel my 1km region loads fine [11:25] Ubit Umarov: mk sure your terrain textures do have a power of 2 size [11:26] Gavin.Hird @grid.xmir.org:8002: might be some interation loop over the terrain that gets larger and larger the more regions you throw at it [11:26] Ubit Umarov: oh and get last master [11:26] Ubit Umarov: some dev made a little bug a few days ago.. [11:26] Kayaker Magic: Don't the textures come out of the asset server? They are all converted to powers of two on upload, if they were not that to start wth. [11:26] Ubit Umarov: coff coff [11:26] Ubit Umarov: no they are not [11:26] Gavin.Hird @grid.xmir.org:8002: the composition is done by the viewer [11:27] Gavin.Hird @grid.xmir.org:8002: 4 texures being composited over the terrain [11:27] Ubit Umarov: at least some viewer do not resample [11:27] Ubit Umarov: and accept non power of 2 [11:28] Ubit Umarov: but they do slow down [11:28] Ubit Umarov: even complain on logs [11:29] Ubit Umarov: and yes.. composition is a bit heavy, and based on those heights settings on terrain [11:29] Gavin.Hird @grid.xmir.org:8002: I suspect some iteration just explodes the more regions you throw at it for the same texture set/terrain [11:29] Ubit Umarov: that do define what textures are blended for a particular land height [11:30] Ubit Umarov: i do notice viewrs like to get the pacth in sequence order [11:30] Ubit Umarov: or do slow down [11:30] Ubit Umarov: our per distance is basicly a fail with current viewrs [11:30] Gavin.Hird @grid.xmir.org:8002: I have not particularly looked into that code [11:31] Ubit Umarov: they always display the terrain no matter how far it is ( but do tesselate it ) [11:31] Ubit Umarov: when oyu select terran per distance option [11:32] Kayaker Magic: I just tried an experiment: I uploaded a 1672x867 image. Now in inventory it is 1024x512. Downsampled to the nearest power of two, as I expected. [11:32] Ubit Umarov: region does sent a circle around the avatar [11:32] Gavin.Hird @grid.xmir.org:8002: the texture is composited over the tesselated terrian [11:32] Ubit Umarov: then sends all the rest of the terrain [11:32] Gavin.Hird @grid.xmir.org:8002: so much more geometry [11:32] Kayaker Magic: I have never seen a texture in-world that was NOT a power of two. [11:32] Gavin.Hird @grid.xmir.org:8002: I have :-) [11:32] Ubit Umarov: dev outreach has some 768 pixel i think [11:33] Kayaker Magic: How do you make them? [11:33] Ubit Umarov: like any other [11:33] Ubit Umarov: viewers do not resample [11:33] Ubit Umarov: at least not all [11:33] Gavin.Hird @grid.xmir.org:8002: You sneak them in the backdoor [11:33] Andrew Hellershanks: :) [11:33] Ubit Umarov: well yeah oyu can also inject texture assets [11:34] Kayaker Magic: I'm on firestorm, I've never seen a viewer fail to downsample to a power of 2 [11:34] Ubit Umarov: like on bin/assets etc [11:34] Ubit Umarov: fs does complain [11:34] Ubit Umarov: it does it.. but complains [11:34] Ubit Umarov: it is a slow process [11:34] Kayaker Magic: No, I just tried it. It quietly downsamples without complaining. [11:34] Ubit Umarov: well gpu does it.. but heat waste for no reason [11:35] Ubit Umarov: seen the logs? [11:35] Ubit Umarov: viewer logs.. [11:35] Ubit Umarov: i also had a viewer dev telling regions size should also only be power of 2 [11:36] Gavin.Hird @grid.xmir.org:8002: they should [11:36] Andrew Hellershanks: What happens if it isn't? [11:36] Ubit Umarov: other wise minimap rez is also slower and heavier [11:36] Gavin.Hird @grid.xmir.org:8002: viewer will not handle it [11:36] Ubit Umarov: it does [11:36] Gavin.Hird @grid.xmir.org:8002: unless it still has the old Aurora sim code [11:36] Ubit Umarov: but does resampling all the time [11:37] Ubit Umarov: 768m is a popular size [11:37] Gavin.Hird @grid.xmir.org:8002: but it consist of 3x3 256 regions [11:37] Ubit Umarov: yes, legal by our rules [11:38] Gavin.Hird @grid.xmir.org:8002: if it was 768 x 256 the viewer would barf on it [11:38] Ubit Umarov: well a viewer dev told it had bad impact [11:38] Kayaker Magic: From the SL knowledgebase: " When uploaded, images are converted into a valid size. Valid scales are square powers of two. To prevent unintended distortion, keep this in mind when creating images. The maximum resolution for uploaded textures is 1024 pixels. If you upload an image that is a higher resolution than this, it will be scaled down to pass the upload requisites. Valid image sizes include the following values: 2, 4, 8, 16, 32, 64, 128, 256, 512, and 1024 " [11:39] Gavin.Hird @grid.xmir.org:8002: Kayaker, you have to upload other sizes directly to the asset dbv [11:39] Gavin.Hird @grid.xmir.org:8002: db [11:39] Ubit Umarov: yes that is called power of two :p [11:39] Gavin.Hird @grid.xmir.org:8002: the viewer will try and scale to a pwoer of 2 [11:40] Ubit Umarov: currently it is a performance issue [11:40] Gavin.Hird @grid.xmir.org:8002: it should still be possible to upload a 256x128 or 256x64 texture [11:40] Ubit Umarov: they can do other sizes.. just bad [11:40] Kayaker Magic: Well, most users can only use the viewer, so most of the time images are powers of two, so most people are unlikely to use non-powers of two on terrain and therefore that is most likely NOT the reason terrain texture loads slow. [11:40] Gavin.Hird @grid.xmir.org:8002: it is not [11:41] Ubit Umarov: it is a heavy thing as i said [11:41] Gavin.Hird @grid.xmir.org:8002: I am sure it has to do with the number of iterations it must do over the large tesselated terrain to kae the composited textures [11:41] Gavin.Hird @grid.xmir.org:8002: to make* [11:41] Ubit Umarov: actually none bc of that [11:41] Ubit Umarov: it makes the texture per patch full rez [11:42] Ubit Umarov: the GPU does the rendering [11:42] Ubit Umarov: the tesslation preserves UV map [11:42] Ubit Umarov: wel may make mips.. [11:42] Ubit Umarov: problem is nearby patchs [11:43] Ubit Umarov: the presence of one impacts the neibourg [11:43] Misterblue Waves: oopps... RL calls... take care everyone [11:43] Ubit Umarov: so out of order may force redraws [11:43] Ubit Umarov: but ages since i looked to code [11:44] Kayaker Magic: I thought it used Perlin Noise to blend the textures, which can be calculated locally for any patch and still match at the edges. [11:44] Ubit Umarov: just remember that out send in circles etc is bad [11:44] Ubit Umarov: yes also adds some noise [11:44] Ubit Umarov: i did the code for warp3d rendering [11:44] Ubit Umarov: you can go see it [11:45] Ubit Umarov: seems close to viewers result [11:45] Ubit Umarov: warp3d terrain tex are closer to what we see on viewer than older code [11:46] Ubit Umarov: can't claim the same, ofc :) [11:46] Ubit Umarov: wle abotu this week code changes [11:46] Kayaker Magic: OK, my next question is about the fsassets: I notice that all assets are GZopped, even images and mesh which are already compressed. Is there an OpenSim.ini option to request that files are not gzipped? [11:46] Ubit Umarov: let me see [11:46] Ubit Umarov: yeah fsassets was made like that.. can't change now [11:47] Ubit Umarov: should only gzip text assets [11:47] Ubit Umarov: but well 2 late [11:48] Ubit Umarov: abotu code... [11:48] Andrew Hellershanks: Can't the code tell whether the asset is compressed in the database or does it always assume it was compressed? [11:48] Kayaker Magic: I have been reading fsassets lately, they are all gzipped. I did some statistics on images and mesh, gzipping only saves a small percentage of disk space. [11:48] Ubit Umarov: cant' change the that code now [11:48] Ubit Umarov: yes should not gzip mesh, that are already gzipped [11:48] Kayaker Magic: I'm told that the asset server will look for a non-compressed fsassets file and use that if available. [11:49] Ubit Umarov: and gzip on jp2000 also goes nothing useful [11:49] Ubit Umarov: old bug.. [11:49] Ubit Umarov: 2 late to fix, so fsassets feature [11:49] Andrew Hellershanks: Is it the OS code or the viewer that decompresses the assets? If there is a way to know if an asset is compressed or not the code can be fixed without breaking compatibility with existing assets. [11:50] Ubit Umarov: yeha to slow down a already slow thing [11:50] Kayaker Magic: OS does the first decompression [11:50] Ubit Umarov: well [11:50] Ubit Umarov: code.. [11:50] Ubit Umarov: added a time throttle to osFlushTerrain [11:51] Ubit Umarov: in fact possible should be removed.. [11:51] Ubit Umarov: terrain updates are automatic [11:52] Ubit Umarov: --- added little cache on robust grid_info replies [11:52] Ubit Umarov: since they do not change, no need to keep parsing the ini file.. [11:52] Ubit Umarov: or ini files [11:52] Ubit Umarov: .. on terrain, replaced the bitarray used to control changed patchs [11:53] Ubit Umarov: ie to flag them as dirty and in need to send to viewers [11:53] Kayaker Magic: If not a bitarray, how are you flagging them now? [11:53] Ubit Umarov: replaced that by a specialized bitarray that does faster scans per 32 bit [11:54] Ubit Umarov: ie when scanning for changed ones, jumps 32 at same time, if all false [11:55] Ubit Umarov: and has some few things like that for terrain code [11:55] Ubit Umarov: coudl jump 64 :) [11:56] Ubit Umarov: but automatic detection of native cpu barrel shifts on 64 is not trivial [11:56] Ubit Umarov: so 32 is a safer option [11:56] Ubit Umarov: made mode changes to prebuild, following MB ones [11:57] Ubit Umarov: made it add defines like NET48 like sdk mode does [11:57] Ubit Umarov: and made use of it to add TLS1.3 if compiled for .net4.8 [11:57] Ubit Umarov: 4.6 only supports tls1.2 [11:58] Ubit Umarov: and a few more changes [11:58] Ubit Umarov: llie on the prebuild.xml the solution field may define the default framework to use [11:59] Ubit Umarov: instead of having it per project [11:59] Ubit Umarov: added also a variate that will force one, even if projects define one [11:59] Ubit Umarov: variant.. [12:00] Ubit Umarov: back o terrain changed a bit the initial code that sends the patchs [12:00] Ubit Umarov: still not happy... heavy things [12:00] Ubit Umarov: and that per distance problem [12:01] Ubit Umarov: good idea to send per distance.. just viewers do not like lit [12:01] Ubit Umarov: Oh and did remove the legacy Clouds module [12:01] Ubit Umarov: since several viewers do not have them also [12:02] Ubit Umarov: oyu do remember those clouds? all at 100m ? [12:02] Kayaker Magic: I never used them, never saw them [12:02] Ubit Umarov: where standard back in 2007 [12:03] Kayaker Magic: ancient past.... [12:03] Ubit Umarov: yeah [12:03] Selby.Evans @grid.kitely.com:8002: must go -- bye all [12:03] Ubit Umarov: some viewers possible wil stil show them.. but not eepp viewers [12:03] Ubit Umarov: cya selby.Evans [12:04] Ubit Umarov: guess those where the code changes.. [12:05] Kayaker Magic: I've got to run also. People to meet in RL [12:05] Ubit Umarov: ok [12:05] Andrew Hellershanks: ok, Kayaker. Thanks for coming. [12:05] Andrew Hellershanks: We will be wrapping it up soon as we have just passed the hour mark. [12:06] Andrew Hellershanks: Any final comments or questions before we wrap it up for today? [12:06] Ubit Umarov: ah and osgrid is back.. but thing you did notice that [12:06] Ubit Umarov: :p [12:06] Ubit Umarov: think.. [12:07] Andrew Hellershanks: :) I checked the osgrid web page and saw the green ONLINE indicator on the web page. [12:07] Ubit Umarov: :) [12:08] Andrew Hellershanks: If there is nothing further for today I'll call this gathering to a close. If our usual meeting location isn't back online next week we will meet here. [12:08] Andrew Hellershanks: Thank you all for coming. See you again next week.