Maestro Linden used the Server Beta meeting to announce that Simon Linden’s work on adding some LSL support for materials is now available for testing on Aditi.
Please note that this is very much a work-in-progress, and the Lab’s own testing is still underway.
The following details can also be found on the Server Beta Meeting wiki page.
Materials can be added to object faces with llSetPrimitiveParams() functions using the following parameters:
- [PRIM_SPECULAR, integer face, string texture, vector repeats, vector offsets, float rotation_in_radians, vector color, integer glossy, integer environment]
- [PRIM_NORMAL, integer face, string texture, vector repeats, vector offsets, float rotation_in_radians]
- [PRIM_ALPHA_MODE, integer face, integer alpha_mode, integer alpha_cutoff]
- Valid alpha_mode options are PRIM_ALPHA_MODE_NONE, PRIM_ALPHA_MODE_BLEND, PRIM_ALPHA_MODE_MASK, PRIM_ALPHA_MODE_EMISSIVE
Materials can be read with the various llGetPrimitiveParams() functions using the following parameters:
- [PRIM_SPECULAR, integer face] returns [string texture, vector repeats, vector offsets, float rotation_in_radians, vector color, integer glossy, integer environment]
- [PRIM_NORMAL, integer face] returns [string texture, vector repeats, vector offsets, float rotation_in_radians]
- [PRIM_ALPHA_MODE, integer face] returns [integer alpha_mode, integer alpha_cutoff]
- Behaviour for both getting and setting materials parameters should basically correspond to behaviour with PRIM_TEXTURE
- The color vectors use 0.0-1.0 as the range, as with llSetColor()
- The integer parameters for PRIM_SPECULAR correspond to the same values that you see in the build tool
- Components of a material can be ‘reset’ as follows:
- PRIM_NORMAL and PRIM_SPECULAR settings are set to default values by setting the texture to NULL_KEY
- PRIM_ALPHA_MODE settings are set to default values by setting the alpha_mode to PRIM_ALPHA_MODE_BLEND – mask_cutoff is actually reset to 0 unless the alpha mode is PRIM_ALPHA_MODE_MASK
- When PRIM_NORMAL, PRIM_SPECULAR, and PRIM_ALPHA_MODE settings are all set to default values, the material is deleted from that prim face, and LI may be updated accordingly
- This new scripted capability will only work on the nominated test regions
- ALM must obviously be enabled.
- The version currently on Aditi lacks proper throttling, so there could be performance issues if scripts behave badly. A throttle will be added in due course
- There is a viewer rendering issue, where the face will not be rendered and you’ll see log spam (
). This can happen:
- If the viewer has ALM enabled
- And a prim face has a material on it
- And PRIM_ALPHA_MODE is PRIM_ALPHA_MODE_BLEND (this is the default after a material is added)
- And the diffuse texture does not have an alpha channel (e.g. plywood)
With reference to BUG-6187, Maestro added, “One thing to keep in mind … is that if your diffuse texture lacks an alpha channel, you’ll also want to set the alpha mode to PRIM_ALPHA_MODE_NONE to avoid the bug, even if you really just want to add a normal map.”
The bug itself doesn’t mean the alpha mode should be set every time a materials map is changed, only when adding a material to a face which previously didn’t have a material. Maestro went on to give some further information on the issue:
What happens when you add a material via the build tool, is that the viewer inspects whether the current diffuse texture has an alpha channel and automatically sets the alpha mode to ALPHA_MODE_NONE if the diffuse texture is opaque, but keeps it at _BLEND if there’s an alpha channel. Unfortunately, the simulator can’t do this, because it doesn’t necessarily have the texture asset and doesn’t have the right libs to process texture assets in that manner. The build tool has some trickery where it always greys out the UI for alpha mode when the texture doesn’t have an alpha channel. Anyway, it’s kind of a hassle, but once PRIM_ALPHA_MODE is set to something ‘friendly’, you should be able to update normal or specular settings without touching it again.
As this is a viewer rendering bug, there is no timescale as to when a fix may appear.
The Lab is particularly interested in seeing how use of these new parameters may affect performance (such as through rapid and repeated changes to maps), and what kinds of rates cause these issues, so that they can more accurately assess the required level of throttling.
Depending upon how further testing goes, what additional changes the Lab needs to make, and what has already been scheduled at the time, these updates might be available on an RC on Agni in a few weeks.