SL projects updates 22/2: LSL functions for materials avialable for Aditi testing

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.

Regions roller-test102 and roller-test103, both on channel DRTSIM-253, have the server-side scripting support (note the SLurls are for 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.

LSL fucntions for handling materials
Parameters have been added to the llSetPrimitiveParams() and llGetPrimitiveParams() functions to enable scripted control of materials maps

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]

Additional Notes

  • 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.

Known Issues

  • 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 (BUG-6187). 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.

9 thoughts on “SL projects updates 22/2: LSL functions for materials avialable for Aditi testing

  1. I don’t build materials stuff and can’t see it unless I want to not move and just stare( my machine exceeds the suggested specs). But is this project basically adding lag to sims for everyone so a few can see more shiny stuff or rather stuff that is more shiny?

    Like

    1. Materials add considerable depth to SL. While they require ALM to be enabled, this shouldn’t result in major performance hit for most systems with a mid-range GPU card or higher. Materials do not require the use of Shadows, which tend to be the heavy-hitter in terms of degrading viewer performance).

      This project shouldn’t “add lag” to regions. However, because it is scripted controls, and because of what it is handling (e.g. a means to swap / change the appearance of diffuse (texture) maps, normal maps and specular maps on an object), there is a risk that if carelessly used or deliberately abused, then problems may be experienced either viewer-side or server-side.

      That’s why the Lab have always been so cautious when introducing this capability, which has been widely and repeatedly requested by builders and scripters since before materials were even introduced to SL, and why there is now further open testing on Aditi. They are aware that there may be some risk, and they are working to ensure that risk is mitigated, by throttling the performance of the new functions (not the simulator).

      Like

      1. I’ll give my personal experience with ALM and materials. My main machine is (still) a 5-year-old laptop with an Intel Pentium dual-core T4300 CPU, 4GB of DDR2 RAM and its GPU is a (now no longer supported) ATI Mobility Radeon HD4500 with 512MB DDR3 RAM. This system was by no means high-end when I bought it, and today it’s downright obsolete; however, I think it’s representative of the kind of performance a significant percentage of SL users can expect from their machines.

        I run it with ALM on at all times, except when I’m in seriously crowded areas (such as Firestorm Q&A sessions). Activating ALM is a 50% frame rate drop, but, on a reasonable area and with judicious manipulation of other settings (draw distance, water reflections), it is still serviceable. Materials have deteriorated its performance – it’s a 10%-25% (depending on how extensive their usage in the region is) drop compared to the previous, non-materials, viewer I was using (Firestorm 4.4.2.34167).

        Of course, I activate shadows, ambient occlusion and DoF only when taking snapshots, and only after I’ve framed the shot.

        Like

  2. No. It is simply allowing scripts to edit more types of textures, essentially. Scripters could already lag you just as much with regular non-materials texture changing, should they wish too.

    Like

  3. I found funny that a few are so thrilled by the use of the oculus rift on Sl but don’t say any about how the new rendering system when used in it’s full splendor (alm on,shadows on+a good sky wind light setting like fine day for example!)!
    Cause then Second Life becomes visual stunning and not only for pictures, the lucky ones, and more and more hopeful, that run Sl at all times on those conditions for sure will agree.

    Like

  4. I love materials, they can really add amazing depth. I use them on all my builds, come take a look in world. From a scripting point of view I’ll most likely use it for end user texture change menus. However I can see having some fun with this in other ways. I think throwing words about such as abuse sounds absurd. Surely creativity is about pushing the medium to it’s limits, and even getting it to do things no one thought of. I can’t see how throttling for example the rate a face can change shine will make much difference.

    Like

Comments are closed.