Kristy Aurelia

Just FIY, sensors now scan up to 32 items: https://releasenotes.secondlife.com/simulator/2024-03-18.8333615376.html

I just used glitter as an example of what PBR would work great with, there are plenty of other use cases, 'better colour accuracy' doesn't sound as fun. Though, I guess metallic sci-fi parts would be a good example too.

Any mention of PBR materials/Appliers? Metallic glitter and such would look amazing with PBR.

Interesting bug in LSL PBR handling https://feedback.secondlife.com/scripting-bugs/p/pbr-colour-data-is-lost-when-setting-pbr-overrides So the colour/alpha seem to share the same override, so if you rely on making things visible/invisible, you might lose colour data. In that specific scenario, the prim starts with no overrides, and it cannot retrieve colour value from the material, but, changing alpha causes colour to initialise to white, and populate the override material with a colour that did not match the original material.

Yup, that is really annoying... with brands that do mod items, at least we can fix it ourselves... but... when you consider, it takes me a few minutes to fix my item... it takes the creator the same amount of time + a little bit more to repackage it in a box and setup a redelivery... so... let's use some fake numbers, if it takes me 5 mins to fix my mod item, and it takes the creator 10mins to fix and update vendors etc. Having 3 customers for that specific item, gives a net gain of 5 minutes fixing time saved... 100 customers? That's nearly 500 minutes of fixing time saved...

Anyone else finding Dimples of Venus agressively deep? Especially if you compare a with a RL picture from Wikipedia

'stateless scripts' - uhm, not really what I meant, I mean a script is like an exe, it uses no memory on the heap/stack until it runs. If the script code and stack/heap was separated. those could be move around separately. If you save the exe and memory separately, you could move exe around as you please, and then load in and let it work with a chunk of memory. Effectivery what hybernation does. But at the moment, the same memory budget is used by the entire script, including code, stack, event queue. global varaibles. And the code could be separated from that as it is static. Having separately controlled budgets for all of them would give the system the most flexibility. On a different topic: 32bit sim does sound stupid, you could go on a 30k prim sim, rezz 30k boxes and fill in ~3.7GB of LinkSetData. Edit: especially when you consider dropping 32bit viewer... which is used by large group of people on video variety of machines... while a sim is in a closed and controlled environment... Why wasn't the server updated to 64bit way before the viewer? Surely it is easier when there are no customers with outdated PCs to worry about.

Is that, on a mod object, with no-mod material preapplied? I hope not... otherwise, that will mean shopping for stuff will require not only items be mod but also materials to be mod as well... though that would be a topic for another thread.

Okay... so then... how many layers of overrides are there? Base PBR material (Step 1) <- overriden by User Changes to the material (Step 2) <- overriden by LSL changes to the material? Edit: "told me that LSL can see the texture uuid"... hold on, does that mean that the list gets populated with a UUID, which gets redacted for functions like llOwnerSay() or llList2String()? Does that also apply for legacy materials too?

Okay... so even though overrides help getting around some cases... my main point is still valid, of scripts not being able to change colour/alpha/etc when PBR is in use, when they can do that on legacy materials.

does 'someone' include... applying a full material from a material object in the inventory, and then manually editing a face, to have different base colour texture? For example: Object has PBR material with Texture A as base colour applied by item creator. A user who bouth that object applies Texture B to the base colour texture to override it. They add my script to the object and my script wants to make the item transparent... my script will receive "" as texture UUID, and setting transparency will set the override to "" meaning the texture applied in Step 2 is lost? I've not tested it fully on PBR sims because I don't have objects with restricted permissions made by other people, and if I make objects myself... I have full perms, so in those cases I do get the UUIDS...

Wait... what... just how many layers are there then... Base legacy materials <- Get Overriden by PBR materials (assuming capable PBR viewer) <- Get Overriden by LSL material? Edit: also that wiki page says: "upcoming PBR Terrain project.", but that's a separate later update, right?

If you do that, you'll pass empty texture to the function, which will in turn clear the texture, in addition to applying the colour changes. The point is - you've lost the texture now. If you want to make an object transparent, when you make it visible again, you want it to be visible with the texture it had.

With PBR being just around the corner, it seems that LSL side is lacking a lof of functionalit that legacy materials have. PBR does not have LSL equivalents for things like llGetColor, llSetColour, llGetAlpha, llSetAlpha, llSetLinkColor, llSetLinkAlpha, llGetTextureOffset and other similar functions. Which means, a lot of older scripted items that change alpha and such cannot be updated to use PBR materials. The new PBR llSetLinkPrimitiveParamsFast functionality all takes texture UUID as parameter, but you cannot get texture existing texture UUIDs due to permissions. Meaning, that you either need to have a texture UUID, or you cannot change alpha or tint colour or any other parameters without reseting the texture to blank. In practice what this means is if you have an item, which has multiple linked parts, which change hide/show one of them based on scripted state, you cannot apply PBR materials to them, because the show/hide will not affect PBR materials properly. Or if you have something that changes tint colour over time, that change will not be visible if PBR material is applied. I have raised a Jira for it ( https://jira.secondlife.com/browse/BUG-234689 ), but I think it is worth to spread the word as well, as from LSL point of view this is a step backwards as we effectively lose existing functionality or are stuck being unable to update existing items to use PBR, which is not good for overall PBR adoption.

This is probably the best long-term solution. Splitting code from memory would allow optimizations such as: when an avatar object comes close to a region crossing, the neighbouring sim could preload script code data over multiple seconds ahead of the avatar crossing the border, and on border crossing, it would only need to load in the actual memory part. If the avatar moves away, it could discard the code data at a convenient time. It would also help with silly things like global variable and function names eating up script memory. And it would give more flexibility for extensions in the future, such as increasing code memory, but not heap, or heap memory but not code etc. Code being separate also has an advantage that it would only change if a script is saved.