We should not have to worry about doubling up scripting calls to cover use cases for either Blinn-Phong or PBR materials, and lets not get started on the fact that we can't use LSL to even probe for which of these is being used in the first place.

As previously mentioned the current method of altering the alpha value of a PBR material is far more memory and CPU intensive than it really should be. It's a sloppy implementation at best, and is a major reason why many items that use Alpha switching or fading as part of their core functionality are not adopting PBR materials at all. As someone that loves the Halloween season I can tell you it has absolutely effected things like fading ghosts, jump scares, and other such creepy things. It has also effected mesh body, head, and body part creators as well because the current workaround for this functionality is nowhere near as elegant a solution as we have had for the majority of time SecondLife has existed.

While my opinion may not be popular, I personally believe that this should have been a showstopper this whole time and should have prevented PBR from being released on the main grid until after it was properly fixed and made ready.

I believe that llSetAlpha, llSetLinkAlpha, and such similar calls as well as the llSetPrimitiveParams, llSetLinkPrimitiveParams, and llSetLinkPrimitiveParamsFast parameters used for setting alpha values should be expanded to work for either type of material and the alpha setting in the texture tab of the build floater should be modified to work in this manner too.

To simplify this the material alpha settings for the current PBR material (or override if present) could be used to determine the maximum opacity for a surface using PBR materials just as it would be for a any Blinn-Phong diffuse texture. Doing this would preserve current functionality in scripts that are used on objects with Blinn-Phong materials and allow their use on objects with PBR materials without unnecessary bloat, memory, or CPU overhead being added. This could easily increase the adoption and use of PBR materials in various markets across SecondLife.

Absolutely agree with this. Give us a straightforward function to change the transparency of the face, just as available with regular blinn-phong textures.

Ideally, have both llSetLinkAlpha and PRIM_COLOR just change the transparency value for the PBR texture so as to not break existing script systems, unless anyone can see a utility for having an object which turns invisible in blinn-phong but not in PBR or vice-versa. Failing that, llSetLinkPBRAlpha() as proposed above and PRIM_PBR_COLOR for primitive parameters should be added.

Just because PBR allows all the additional variables to be mapped and used, does not mean that most users will need this, or need the ludicrously over-convoluted and messy scripts this will generate. The current implementation seems to be based on the notion that just because the rendering engine considers all these variables together, when dealing with a PBR texture, so should the user be forced to do so. Of course you'd retain the existing functions which allow you to control all the variables at once- but we seriously and fairly urgently need the utility to only change the ones we actually need. Failing to do this will discourage content creators from adopting PBR for anything which requires complex scripting, and thus somewhat defeat the point of having it in the first place.

I had to try and hide a PBR face and after 30 minutes I completely agree with all of the statements already made in this request.

You need too much information to change PBR settings and even then the behavior isn't always predictable. The wiki examples, for example, do not work at all for me and just deepen the mystery of changing PBR through scripting.

Having to do lots of queries to get all the PBR settings before you can change them is also more cpu/memory intensive on scripts and in turn the simulators so having something that can replicate old behavior as a simple command will be beneficial for all sides.

We need this because right now alpha changes for pbr materials are required to know a great deal more information about the basecolor material settings. This is awkward at best, and slow at worst because if you don't know the other values in your script you have to do a read-modify-write.

Yes, we do want to be able to script gradual fade effects for PBR, just like we have for BlinnPhong all these years.

We're looking for something similar to llSetLinkAlpha() for PBR. A function that was already approved as needed earlier for blinnphong textures, and widely used. Lets get this on the roadmap please. This isn't a request for a new feature -- it's asking for the same functionality that has already been vetted in the past, but was not implemented for PBR for some reason.

I am not sure if the example at https://wiki.secondlife.com/wiki/GLTF_Overrides#Examples should be considered a valid workaround. It is too memory and time inefficient, and awkward when dealing with a popular use case of having mod permissions to the object but not full permissions to the material texture.

Is there any progress on this? My builders have started submitting PBR builds for me to script, but the current method for making PBR transparent is a hideous, inefficient mess at best, and breaks things since I can't even read all of the parameters I'm supposed to preserve due to permissions. This applies to full bright as well, since toggling that on Blinn-Phong does nothing if PBR materials are in use.

I also encountered the problem of switching alpha on tinted materials, since the server does not return color parameters on objects with incomplete rights and the tint is reset to white, this is a serious flaw. A function like this would solve this problem, and also reduce the number of functions used in the script for simultaneously switching alpha for pbr and blingfong.Or is there another option to equalize the alpha of Blinfong and PBR, then it would not break the old products when applying PBR material to them.

Yup adjusting alpha right now is literally cancer.

Need excatly this,

and also one for each parameter without the need of every other ones.

Need it to be able to script "mod ok" stuff we didn't create, the ones we don't have the full perm texture or uuid.

Also more texture anim commands would be awesome, like being able to animate several faces differently unlike now when you can only animate 1 face or all faces with the same parameters.

And even more if we could animate the texture, the normals, the ORM, the emissive each with different settings,

I'm already thinking about crazy stuff lol

This is one feature im desperate for, right now there is no way of fading out any of my products smoothly, Im not sure why this has not been addressed yet.