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.

Very important issue!

I hope this issue does get fixed because many of the products we sell use fade in and out as their key functions. This should be a top priority for PBR.

Upvote

Please these things should be essential

I think, like Alex suggested, a new flag for llSetLinkPrimitiveParamsFast(integer link_number,[PRIM_VISIBLE,integer face, bool visible]) would be the most useful way. I'd really appreciate to have something like that since the current workaround (grabbing values and reapplying them in a loop) is really a code monster.

Happy :)

This was discussed at the Jan 16th SUG meeting, with Brad Linden from the PBR team present and promising to look into it. I'm commenting here to highlight just how essential this is.

Consider the current: llSetLinkAlpha(iLink_num,fVisibility,ALL_SIDES);

...and compare to something like:

GTLFAlphaAllSides(integer link, float alpha)

{

integer face=llGetLinkNumberOfSides(link);

while(face)

{

--face;

list temp=llGetLinkPrimitiveParams(link,[PRIM_GLTF_BASE_COLOR,face]);

temp=llListReplaceList(temp,[alpha],5,5);

if(llList2Integer(temp,6)==0) temp=llListReplaceList(temp,[1],6,6);

llSetLinkPrimitiveParamsFast(link,[PRIM_GLTF_BASE_COLOR,face]+temp);

}

llSetLinkAlpha(link,alpha,ALL_SIDES);

}

To perform the same function we need to loop through each face, read a list of parameters, replace the alpha value in that list, check the mask type and change that too if it's opaque (unlike llSetLinkAlpha with blinn-phong materials, setting alpha when the mask type is opaque will not work), then resend the list back to the face. After we've done that we STILL need to do the same llSetLinkAlpha command if we can't be certain whether we're dealing with a PBR material or not, because there is no way for a script to reliably determine if a PBR material is set on a face.

It's worth adding that this monstrosity isn't really enough. Because of the issue with opaque masking, this is a destructive technique that changes the mask mode of the texture when applied. In many cases we can't rely on that being a good approach and will need to store the current mask value for each toggled face when hiding, then read back and re-set the stored value when showing.

Clearly this is a problem, and it's worth keeping in mind we're not talking about some obscure need here. Every single mesh body will require a function like this for some of its most common usage. Showing/hiding parts is a standard function in most weapons, vehicles, many clothes, etc. Relying on this technique to replace such a widespread function in SL will create a whole lot more script lag across the grid, and is frankly likely to lead to a whole lot of complaints about broken content. Not fixing this will be a disaster.

The proposals at the SUG were something along the lines of giving us an llSetLinkVisibility(integer linknum, integer visibility, integer face); and the equivalent [LINK_VISIBILITY, integer linknum, integer visibility, integer face] llSLPPF paramater, where integer visibility is a TRUE/FALSE which determines whether the face should be rendered at all. As well as the advantages mentioned by Kirsty Aurelia below, this would solve a number of issues referred to above, not least the non-destructive handling of alpha mask values, and potential issues with emissiveness etc.

Another option to consider would be to change the way llSetLinkAlpha functions when a PBR material is used on the relevant face, turning it into a simple rendering on/off as above when the alpha value given is 1.0 or 0.0. While this would have the disadvantage of the function having a situational effect, it would mean a whole lot of things could work with PBR textures without updates, where currently there is a lot of content which will literally be broken just by applying a PBR texture to it.

This is an issue that I believe needs to be addressed as a major priority to make PBR actually work and should be considered a showstopper. I'm facing this issue right now for the show/hide functionality of OpenCollar, an extremely popular product, and honestly our current thinking is that we're simply going to have to tell our many partners and customers that PBR cannot responsibly be supported without better script support for this common function.

This functionality is a hard necessity for things like retrofitting a mesh body to use PBR. Having to either have the hide/show script know what the base color texture UUID is supposed to be for each face or outright give up using GLTF overrides for that purpose is frankly not a workable position for a lot of things you might want to do with PBR.

I think a function like llLinkVisible() would be a good idea for a number of reasons. It would address issues where there is no straightforward way to toggle visibility of PBR enabled surfaces, while allowing visibility to be toggled without losing the alpha state of a given face in the existing prim alpha property.

Something like:

llSetVisibility(integer face, integer visible)

llSetLinkVisibility(integer link, integer face, integer visible)

And in llSetPrimitiveParams():

[PRIM_VISIBLE, face, visible]