PBR LSL funtionality is lacking existing legacy material features

[Kristy Aurelia]

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.

Edited November 18, 2023 by Kplh

[Innula Zenovka]

You don't need the texture uuid, though, to work with the new PRIM_GLTF_* flags.  See https://wiki.secondlife.com/wiki/LlSetPrimitiveParams for more details.

The following examples use llGet/SetPrimitiveParams for the sake of simplicity but you can, of course, use llGet/SetLinkPP too.

Let's take a look at PRIM_GLTF_BASE_COLOR, which has the following arguments

 [PRIM_GLTF_BASE_COLOR, integer face, string texture, vector repeats, vector offsets, float rotation_in_radians, vector linear_color, float alpha, integer gltf_alpha_mode, float alpha_mask_cutoff, integer double_sided ]

In effect it combines PRIM_TEXTURE (string texture, vector repeats, vector offsets, float rotation_in_radians),  PRIM_COLOR (vector linear_color, float alpha) and PRIM_ALPHA_MODE (integer gltf_alpha_mode, float alpha_mask_cutoff).   The final argument, integer double_sided, specifies whether the face is visible from both sides or only one.

Something like

default
{
	state_entry()
	{
		llOwnerSay(llList2CSV(llGetPrimitiveParams([PRIM_GLTF_BASE_COLOR,0])));
	}
}

may return something like 

, <1.000000, 1.000000, 0.000000>, <0.000000, 0.000000, 0.000000>, 0.000000, , , , ,

because LSL won't return the texture uuid.    It's also returning empty fields for the colour vector, alpha value of the colour, alpha mode and cutoff, and double_sided because, in this case, the creator of the material didn't set values for them.   

However, even though you can't read the texture uuid, you can still use it:

integer iFaceToChange = 0 ;//change this to the number of the face to change, 0 in this example
integer iGLTF = 48; //value of the flag PRIM_GLTF_BASE_COLOR, but easier to type
list lTemp;
vector vColourToUse = <1.0,0.0,0.0>; // change this to the vector value of the color to use (x, y and z values between 0.0 and 1.0);

default
{
    state_entry()
    {
        lTemp = llGetPrimitiveParams([iGLTF,iFaceToChange]);//read the current gltf_base_color values of the face you want to change
        //this returns a list [ string texture, vector repeats, vector offsets, float rotation_in_radians, vector color, float alpha, integer gltf_alpha_mode, float alpha_mask_cutoff, integer double_sided ]
        lTemp = llListReplaceList(lTemp,[vColourToUse,1.0],4,5);//change the value of items 4 and 5 in the list (lsl starts counting at 0), "vector color", to that of vColorToUse and 1.0 is the alpha value (fully opaque
        llSetPrimitiveParams([iGLTF,iFaceToChange]+lTemp);//and apply the new values
        llRemoveInventory(llGetScriptName());//delete the script after it's finished
    }
}

This will turn face 0 of the item red.

If you want to make it less than fully opaque, you'll need to need to specify the alpha mode and alpha mask cutoff, too

lTemp = llListReplaceList(lTemp,[vColourToUse,0.5,PRIM_GLTF_ALPHA_MODE_BLEND],4,6);

would set the alpha to 0.5.     

If you want to make things fully invisible, though, it's recommended that you use PRIM_GLTF_ALPHA_MODE_MASK.

To toggle the visibility on and off, try this

integer iFaceToChange = 0 ;//change this to the number of the face to change, 0 in this example
integer iGLTF = 48; //value of the flag PRIM_GLTF_BASE_COLOR, but easier to type
list lTemp;
vector vColourToUse = <1.0,1.0,1.0>; // change this to the vector value of the color to use (x, y and z values between 0.0 and 1.0);
integer iVisible = TRUE;
default
{
    state_entry()
    {
        lTemp = llGetPrimitiveParams([iGLTF,iFaceToChange]);//read the current gltf_base_color values of the face you want to change
        lTemp = llListReplaceList(lTemp,[vColourToUse,(float) iVisible,PRIM_GLTF_ALPHA_MODE_MASK,1.0],4,7);
        //
        llSetPrimitiveParams([iGLTF,iFaceToChange]+lTemp);//and apply the new values
    }

    touch_end(integer num_detected)
    {
        iVisible =!iVisible;
        lTemp = llListReplaceList(lTemp,[vColourToUse,(float) iVisible,PRIM_GLTF_ALPHA_MODE_MASK,1.0],4,7);
        llSetPrimitiveParams([iGLTF,iFaceToChange]+lTemp);//and apply the new values
    }
}

You can alter the texture offsets, repeats and rotations in a similar way by updating the values of 

vector repeats, vector offsets, float rotation_in_radians

You can also use PRIM_GLTF_EMISSIVE as a substitute for fullbright.    This uses the arguments

 [ string texture, vector repeats, vector offsets, float rotation_in_radians, vector emissive_tint ]

Using <0.0,0.0,0.0> as the emissive_tint is the equivalent of setting PRIM_FULLBRIGHT to FALSE.  So you could do something like this:

integer iToggle;
list lTemp;
list lColours =[<0.5,0.5,0.5>,<0.0,0.0,0.0>];
vector vTint;
default
{
    state_entry()
    {
        lTemp = llGetPrimitiveParams([PRIM_GLTF_EMISSIVE,0]);
        vTint = llList2Vector(lColours,iToggle);
        lTemp = llListReplaceList(lTemp, [vTint],-1,-1);
        llSetPrimitiveParams([PRIM_GLTF_EMISSIVE,0]+lTemp);
    }

    touch_end(integer num_detected)
    {
        iToggle = !iToggle;
        vTint = llList2Vector(lColours,iToggle);
        lTemp = llListReplaceList(lTemp, [vTint],-1,-1);
        llSetPrimitiveParams([PRIM_GLTF_EMISSIVE,0]+lTemp);
    }
}

 

 

Edited November 18, 2023 by Innula Zenovka

[arton Rotaru]

It's true that there is no way to get the params of a PBR asset by script.

What can be get are the overrides of a PBR material. Setting params to an empty string will set the values of the original PBR asset. So you either get an empty string for a base color texture, which will set the original assets texture, or the UUID of the override texture. If perms does allow this.

https://wiki.secondlife.com/wiki/GLTF_Overrides

 

 

[Kristy Aurelia]

32 minutes ago, Innula Zenovka said:

However, even though you can't read the texture uuid, you can still use it:

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.

Edited November 18, 2023 by Kplh

[arton Rotaru]

4 minutes ago, Kplh said:

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.

Checkout the link I have posted in the reply above yours.

[Innula Zenovka]

9 minutes ago, Kplh said:

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.

Yes, I know.  However, the examples I posted retain the existing texture.  Try them with an object of your choice.

Edited November 18, 2023 by Innula Zenovka

[Kristy Aurelia]

6 minutes ago, arton Rotaru said:

Checkout the link I have posted in the reply above yours.

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?

Edited November 18, 2023 by Kplh

[arton Rotaru]

Just now, Kplh said:

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?

Overrides are what makes this flexible without creating a new asset everytime someone does change a param of the PBR material on an object.

[Innula Zenovka]

1 minute ago, Kplh said:

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?

Blinn-Phong (traditional LSL) layers and GLTF layers are different.   Changes to the Blinn-Phong layers don't affect GLTF and changes to GLTF don't affect Blinn Phong.    So if you want to use PBR but want the object to look as expected for people using non-PBR capable viewers, you need to set both the Blinn-Phong and GLTF characteristics.

[Kristy Aurelia]

13 minutes ago, arton Rotaru said:

someone does change a param of the PBR material on an object.

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:

1. Object has PBR material with Texture A as base colour applied by item creator.
2. A user who bouth that object applies Texture B to the base colour texture to override it.
3. 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...

Edited November 18, 2023 by Kplh

[arton Rotaru]

Yes, that is the problem of perms and getting the texture UUIDs.

Edited November 18, 2023 by arton Rotaru

[Innula Zenovka]

Just now, Kplh said:

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:

1. Object has PBR material with Texture A as base colour applied by item creator.
2. A user who bouth that object applies texture B to the base colour texture to override it.
3. They add my script to the object and my script want 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...

Try testing with an alt.   You should find the texture applied in step 2 is preserved.   I've been experimenting with objects using materials made by a friend.   The objects are full perms to me, but I don't have copies of the materials in my inventory, and the examples I posted above preserve my friend's textures (i.e. they don't set them to "").

Dave P (Runitai Linden) told me that LSL can see the texture uuid, and use it, even though it won't tell you what it is unless you have the correct perms.   

Try it.

[Kristy Aurelia]

1 minute ago, arton Rotaru said:

Yes, that is the problem of perms and getting texture UUIDs.

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.

[Kristy Aurelia]

14 minutes ago, Innula Zenovka said:

Try testing with an alt.   You should find the texture applied in step 2 is preserved.   I've been experimenting with objects using materials made by a friend.   The objects are full perms to me, but I don't have copies of the materials in my inventory, and the examples I posted above preserve my friend's textures (i.e. they don't set them to "").

Dave P (Runitai Linden) told me that LSL can see the texture uuid, and use it, even though it won't tell you what it is unless you have the correct perms.   

Try it.

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?

Edited November 18, 2023 by Kplh

[arton Rotaru]

I just tried it, it looks like you can't drop a texture as an override on PBR materials if it isn't full perms. The texture has to be full perms.

Edited November 18, 2023 by arton Rotaru

[arton Rotaru]

6 minutes ago, Kplh said:

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?

I would consider overrides as overrides, regardless of they are being set by script or manually.

[Kristy Aurelia]

9 minutes ago, arton Rotaru said:

I just tried it, it looks like you can't drop a texture as an override on PBR materials if it isn't full perms. The texture has to be full perms.

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.

[Innula Zenovka]

This is me changing by script a full perms object to which a materials object has been applied that I don't have in my inventory

https://gyazo.com/c4a67338ddfe58b09e727dc19f6825de

The colour changes and the texture remains unchanged.

[Innula Zenovka]

24 minutes ago, Kplh said:

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?

That's certainly what it means with GLTF.   Not sure about legacy materials.   I'll have to experiment. 

[arton Rotaru]

I was unable to drop an object on an Alt when the PBR asset applied to a face is no mod.

[arton Rotaru]

5 minutes ago, Innula Zenovka said:

That's certainly what it means with GLTF.   Not sure about legacy materials.   I'll have to experiment. 

PBR will set the values stored in the original asset by setting the params to an empty string. You don't need to llGet those params beforehand.

[arton Rotaru]

15 minutes ago, arton Rotaru said:

I was unable to drop an object on an Alt when the PBR asset applied to a face is no mod.

Object Copy/Mod/NoTrans
PBR asset No-Mod/Copy/Trans

Could be send to an Alt and the Alt was able to edit the PBR materials overrides.

I'm not sure what to think of this, and I will stop right here. I HATE dealing with these permissions stuff.

[arton Rotaru]

39 minutes ago, Kplh said:

though that would be a topic for another thread.

What we can conclude at least, is that there is much more that can be done with PBR materials and LSL than one would expect at first glance.

[arton Rotaru]

2 hours ago, Kplh said:

Edit: also that wiki page says: "upcoming PBR Terrain project.", but that's a separate later update, right?

Yes, this won't make it in this initial release, as the code of the GLTF viewer is basically frozen by now.

[Qie Niangao]

This is a good thread; I'm glad @Kplh started it.

We're gonna need a bunch of PBR threads, in several subforums. 

Need a keyboard macro for this, or at least a Bookmark:

7 hours ago, arton Rotaru said:

https://wiki.secondlife.com/wiki/GLTF_Overrides

and its Category page, https://wiki.secondlife.com/wiki/Category:GlTF … until we get something better? Is the Doc team writing up something? How hard is that job? (and who/what is the "Doc team" these days?)