PBR LSL funtionality is lacking existing legacy material features

[arton Rotaru]

32 minutes ago, Qie Niangao said:

(and who/what is the "Doc team" these days?)

If you check who has written those wiki pages, it's mostly a few Residents and Cosmic Linden, who is one of the Devs of the project, so far. 🤷‍♂️

Edited November 18, 2023 by arton Rotaru

[Qie Niangao]

1 minute ago, arton Rotaru said:

[…] a few Resindents and Cosmic Linden, who is one of the Devs of the project, so far. 🤷‍♂️

Yeah. Maybe I'm PBR-phobic, but I don't feel confident that I'd be following any "best practices" no matter how long I study all this. (But maybe it's a poor content creator who blames the docs. Just an old bad habit of a programmer.)

But I guess this is pretty much the level of discourse we had for Blinn-Phong content creation and people figured that out.

[Wulfie Reanimator]

9 hours ago, Innula Zenovka said:

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.

Anyone know where's the wiki page to actually edit those GLTF params?

[Frionil Fang]

18 minutes ago, Wulfie Reanimator said:

Anyone know where's the wiki page to actually edit those GLTF params?

https://wiki.secondlife.com/wiki/Template:LSL_Constants/PrimitiveParams

[Warwick Falconer]

Innula, thanks for the clear example - very helpful.  With a little modification I found I can read the texture information, save the original color in a variable and restore, while at the same time making a specific link shift between transparent and solid.  However, I am unable to find if/how glow can be set on a link in a pbr-textured linkset.  Any info on that?

[arton Rotaru]

2 hours ago, Warwick Falconer said:

 However, I am unable to find if/how glow can be set on a link in a pbr-textured linkset.  Any info on that?

Glow is not part of the glTF Spec. Hence it got removed from functioning on PBR materials altogether. The creator community was quite unhappy about that, though. So we voiced that and the developer was willing to enable it, but not as part of the glTF PBR material. Hence, it's also not on the PBR material editor itself.

PRIM_GLOW can be used as usual with PBR materials, though. It's using the emissive map of the pbr material as a "mask". Hence, the emissive map and the emissive tint color of the PBR material have to be something other than black to make glow work.

[elleevelyn]

4 minutes ago, arton Rotaru said:

PRIM_GLOW can be used as usual with PBR materials, though. It's using the emissive map of the pbr material as a "mask". Hence, the emissive map and the emissive tint color of the PBR material have to be something other than black to make glow work.

thanks, I wondered about that. So I can happily carry on being my glowy self when I want to

[Qie Niangao]

I realize this is an old thread but it seems to have the relevant background, so here goes:

Shouldn't it be possible for a script to get the base color map of a glTF Material applied to a surface, given all the right permissions? I don't mean a base color override, but rather the base color inside the Material.

What I had in mind was to use a script to populate the Blinn-Phong diffusemap with the glTF base color map (and same with normalmaps), so I don't have to keep building with both non-PBR and PBR during the transition while some still can't see the PBR content. 

But it's my understanding that PRIM_RENDER_MATERIAL returns an impenetrable asset from which there's no extracting the component material maps, and PRIM_GLTF_BASE_COLOR returns only the override parameters which will only reveal a texture if it has been overridden from whatever the Material specified internally.

First, is this correct? If I really wanted to write and use such a script, while building I'd need to specify override textures for each surface, not let them populate materials I can use throughout a build?

And second, if this is how it works, does it make sense that it works this way? or is it yet another instance of IP paranoia holding back the platform?

(I suppose I could do it the other way: paint the basecolor texture as diffusemap first, then have a script use it as the basecolor override on the surface, but that's again defeating glTF Materials reuse, and would be a miserable way to build.)

[Jenna Huntsman]

1 hour ago, Qie Niangao said:

But it's my understanding that PRIM_RENDER_MATERIAL returns an impenetrable asset from which there's no extracting the component material maps, and PRIM_GLTF_BASE_COLOR returns only the override parameters which will only reveal a texture if it has been overridden from whatever the Material specified internally.

Yes, this is how this works.

The stated reason for things working this way is because the region (where the script is executed) doesn't actually know anything about the contents of a material asset, but does know the overrides (this is because the overrides are stored locally on the region, whereas content in the material asset is on the CDN, which the region doesn't communicate with if it can be avoided).

[Kristy Aurelia]

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.

[Wulfie Reanimator]

11 minutes ago, Kplh said:

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.

For this reason, LL is considering/working on adding a new function called llSetVisible (or similar) which can be used to show/hide an object without affecting its actual color/alpha values.

The problem of changing PBR alpha without affecting PBR color will still remain, but hide/show is a very general thing people need.

Edited February 27 by Wulfie Reanimator

[OptimoMaximo]

On 11/18/2023 at 10:37 PM, Qie Niangao said:

How hard is that job?

Not much. Just tedious and maybe long for the correct wording and correctness proofreading.

On 11/18/2023 at 10:37 PM, Qie Niangao said:

and who/what is the "Doc team" these days?

The users. This spares LL the effort and a few coins.