Second Life Wiki - User contributions [en]

Project Bento Resources and Information

2026-05-13T19:14:21Z

Wulfie Reanimator: Added a link to updated rigs that can be used with base Blender. Removed outdated note about editing the wiki.

{{TOCright}}

'''Welcome to Project Bento! As we mentioned in [https://community.secondlife.com/t5/Featured-News/Introducing-Project-Bento-New-Bones-Added-to-Second-Life-Avatar/ba-p/2987206 our announcement], Project Bento is adding new bones and attachment points to the avatar skeleton.'''

'''Project Bento Testing is now Complete! Project Bento is now Live in all regions on all viewers!'''

== What is Project Bento?? ==

Project Bento is an update to the Second Life Avatar Skeleton which is what allows Second Life Avatars to move and come to life, as well as enabling the creation of more lifelike and intricate rigged mesh attachments.

===Bone Updates===

The Project Bento Update added bones to the skeleton to expand rigging and animation support in the following areas:

* Facial Area (new)
* Spine (additional bones)
* Hands (new finger bones)
* Tail (new)
* Wings (new)
* Hind Legs for Quadruped Avatars (new)

A full list of the alterations for the skeleton are [[Project Bento Skeleton Guide|here]].

===Slider System / Shape Updates===
Additionally Project Bento updated the existing avatar shape system to make the adjustment sliders affect these new bones on top of it's previous (unaltered) shape control functionality.

'''Scope of slider interactions'''

While the updates to the slider system made it so that these new bones move with sliders, it does not override, or affect in any way existing behavior on the default Linden Avatar head and hands. The default Linden Avatar depends on ''morph targets'' to perform hand poses and facial expressions. This is a completely different system from using ''bone based rigging'' on mesh attachments worn in the same regions of the body (which is what Project Bento adds support for). While these two systems are affected ''similarly'' by slider manipulation by design, it is good to keep in mind that it is an approximation, and only that. It is fundamentally impossible to exactly mimic the motion of a morph target based system with a bone based rigging system. For example : sliders will affect a mesh attachment head differently than it affects the Linden Avatar head. This is unavoidable due to how both systems differ mechanically.

===Animation File Updates===
On top of additional bones and slider integration, Project Bento also increased the maximum allowable size of animation files, and also removed the restriction on BVH animation file uploads that prevented translation based bone movement.

===Partial Skeletons===
Upload of rigged content no longer needs all the bones specified in the DAE file for convenience purposes. For rigged content, simply omitting unused/missing bones from the skinning data is now allowed.

== Caveats & Best Practices ==

*Due to the restrictions of the pre-existing Second Life Animation System. Playing animations that affect bone scale will (continue to) not work with Project Bento, however the slider system has been incorporated to adjust bone positions and bone scale.
*Any slider controls that affect the position ( translation ) of a specific bone will be overridden if the user plays an animation that moves that bone. Since presently the animation system has no means of knowing the positional offset that the slider is providing, that animation will be played based off of the bones natural ( pre-slider adjustment ) position. However the slider's influence on the affected bones scale will not be altered, as animations presently cannot affect bone scale.

Because of the above two restrictions it is ill advised, to mix content where you want the translation based sliders to work with translation based animations. Because the animation will always override the slider.
For a list of all the bones that are influenced by sliders that adjust their position refer to this : https://wiki.secondlife.com/wiki/Project_Bento_Skeleton_Guide#Bones_Currently_Affected_By_Positional_Sliders

This was the best practical alternative to simply not allowing translation based animations at all due to the possibility of them overriding sliders. The community asked for the ability to have translation/position based animations available for greater creative control and it was agreed upon that suffering the confusion from this conflict of behavior was still an overall gain.

Prior to Project Bento, rigging to attachment points was never formally supported, and was strongly discouraged, as once an animation stops playing it often leaves the attachment points in a deformed location that is very difficult for a resident to understand. With the addition of Project Bento, meshes rigged to Attachment points ''may be rejected by the server'' since one of the primary reasons for the addition of these new bones was to discourage this process.

== Current Content & Resources ==

=== Models & Skeleton Files / Test Content ===

'''Modern glTF (glb) and Collada (dae) files''':

This model was created with compatibility for Blender 5 and 4.5 (the last version to include Collada export).

* [https://github.com/LittleBitwise/Second-Life-Skeleton human female] (Github repository)

'''Note:''' The bones in the glb file are aligned differently than the ones in the dae file! Use the file that matches the filetype you're going to export.

'''Collada (dae) files''':

The following model files are compatible with the old project viewer, as of 2016-07-14, and should work with currently implemented sliders. Includes weighting to the new mFaceJawShaper bone.

* [https://bitbucket.org/lindenlab/secondlife-creator-resources/raw/master/models/collada/female_2016_08_05.dae.zip human female] (August 5, 2016) (attention, this rig is broken)
* [https://bitbucket.org/lindenlab/secondlife-creator-resources/raw/master/models/collada/male_2016_08_05.dae.zip human male] (August 5, 2016)
* [https://bitbucket.org/lindenlab/secondlife-creator-resources/raw/master/models/collada/angel_2016_08_05.dae.zip angel] (August 5, 2016)

'''Maya (ma) files''':

These are also current with the skeleton of July 14, 2016:

* [https://bitbucket.org/lindenlab/secondlife-creator-resources/raw/master/models/maya/MayaBentoFemaleAugust2016.ma.zip maya human female] (August 17, 2016)
(NOTE: Standard Skeleton with bone located in standard positions determined by the avatar_skeleton.xml file.)
* [https://bitbucket.org/lindenlab/secondlife-creator-resources/raw/master/models/maya/MayaBentoMaleAugust2016.ma.zip maya human male] (August 17, 2016)
(NOTE: Standard Skeleton with bone located in standard positions determined by the avatar_skeleton.xml file.)

'''FBX files''':

* [https://bitbucket.org/lindenlab/secondlife-creator-resources/raw/master/models/fbx/FBXBentoFemaleSeptember2016.fbx fbx human female] (September 10, 2016)
* [https://bitbucket.org/lindenlab/secondlife-creator-resources/raw/master/models/fbx/FBXBentoMaleSeptember2016.fbx fbx human male] (September 10, 2016)

These are based on the Maya files above.

'''3ds Max (max) files'''

All files are saved as 3dsmax2012 files, if your version predates this, they probably won't load.

"Basic" skeleton files contain no additional nodes and will not work for advanced control rigs and animation export, but are simpler, contain less clutter and might be ideal for simple rigging&skinning work. However bone rotation axis will not behave ideally for animations.

"Normal/Animation" Rigs have additional nodes for ease of use with animations, but animation must be done on "mBoneName_DRV" point helper nodes instead of the bones directly. These skeleton files have nodes oriented in a manner that will make joints rotate on their local axis. This is particularly useful for mimicing animation in parts of the bento skeleton such as the hands and face where the bone is not aligned with an axis ( perpendicular to other things in the scene ). Hopefully these skeleton rigs will help understanding of the new joints.

For both skeletons ( both "basic" and "animation" ) the mesh skinning and rigging should be done to the mBoneName or "collision volume" (fitmesh) bones / dummies only. All skeletons are default (female) bone positions ONLY.

* [https://bitbucket.org/polysail/bento-max2012-skeletons/raw/bc20e9c13a37b6d834ce92b63339f911f08c2e5b/BentoBones_BonesOnly_2012.max basic skeleton bone nodes] (December 26, 2016)
* [https://bitbucket.org/polysail/bento-max2012-skeletons/raw/bc20e9c13a37b6d834ce92b63339f911f08c2e5b/BentoBones_DummyNodesOnly_2012.max basic skeleton dummy nodes] (December 26, 2016)
* [https://bitbucket.org/polysail/bento-max2012-skeletons/raw/bc20e9c13a37b6d834ce92b63339f911f08c2e5b/LocalAnimationOrientation_Bones_2012.max skeleton bone nodes] (December 26, 2016)
* [https://bitbucket.org/polysail/bento-max2012-skeletons/raw/bc20e9c13a37b6d834ce92b63339f911f08c2e5b/LocalAnimationOrientation_DummyNodes_2012.max skeleton dummy nodes] (December 26, 2016)

Dec, 2016 update fixes minor rotation issues in the collision volume bones that existed in the initial August 2016 posting.

=== Test Animations ===
* [https://bitbucket.org/lindenlab/secondlife-creator-resources/raw/master/animations/anim/bento_randomize_bones_and_attachments.anim scramble the positions] of all bones and attachments
* [https://bitbucket.org/lindenlab/secondlife-creator-resources/raw/master/animations/anim/bento_reset_bones_and_attachments.anim reset the positions] of all bones and attachments to the default.

=== Animation Export Tools ===

'''Maya'''

The following tools are used for export of BVH animation files from Autodesk Maya Software. The exporter was authored by Aura Linden and is available for free below.

It works ideally with the skeleton included in [https://marketplace.secondlife.com/p/MayaStar-Plugin-System-for-Maya-Autodesk/5454253 Mayastar], maintained by Cathy Foil. But should be able to be used as a standalone script as well.

* [https://bitbucket.org/lindenlab/secondlife-creator-resources/raw/master/tools/maya/Maya_BVH_Export_Bento_Project.mel Maya BVH Animation Exporter] - mel script --'''Note: when animating in Maya for export, orient your skeleton in Y+ up , X+ forward orientation.'''
* [https://bitbucket.org/lindenlab/secondlife-creator-resources/raw/master/tools/maya/maya_bvh_export_instructions.txt Maya BVH exporter instructions] - text file

'''Blender'''

While blender does not have any freely available animation exporters specifically for Second Life, it has an excellently maintained plugin package known as [https://blog.machinimatrix.org/avastar/ Avastar] maintained by Gaia Clary.

'''3DSMax'''

Autodesk 3D Studio Max presently does not have any publicly available animation exporters. However, polysail resident is presently working on a plugin that will do so. Completion date is TBD.

=== Reference ===

* Some helpful models to show the locations of various types of bones can be found at [https://marketplace.secondlife.com/p/Avatar-Testing-and-Visualization-Kit/9842033 Avatar Testing and Visualization Kit]

== Scale Locking Option ==

With Project Bento, the option to have an uploaded mesh attachment completely ignore all slider input was also added.

When you upload a model beneath the standard "Include skin weight" and "Include joint positions" check boxes, there is now an additional check box for "Lock scale if joint position defined". If you check this box, then any joint that has a position defined will also have its scale locked. Scale locking will be enforced whenever a joint would normally be scaled by a slider thus "immunizing" it to all slider influence.
To make a bone truly slider-proof, you will have to pay attention to the joint hierarchy. Any change to the scale of a parent bone will also cause the child bone to move, so you will have to make sure the bone's ancestors also have joint positions defined. A joint position will be ignored unless it differs from the bone's default location by at least 0.1 mm (ie, 0.0001 m in the units used by the skeleton definition file). If you want to lock a joint without changing its position, use a very small offset that will not be large enough to have a visual effect (some fraction of a mm).

This feature was primarily included to assist with making "animated attachments" that re-purpose bone sets, such as the hind legs, wings or tail into pets or weapon attachments. Ideally such attachments would not want slider influences due to the fact that the bones comprising them are "borrowed" from another part of the body.

==Reset Skeleton Menu Option [Viewer]==
With the addition of Project Bento a new menu option was added to the viewer. If you Right-Click another avatar the option to "''Reset Skeleton''" will appear, along with it's cousin "''Reset Skeleton and Animations''". This added functionality provides any resident the ability to attempt to visually fix another avatar that looks deformed on their screen.

'''Note this option does not send any data to the server. This means that if you use "Reset Skeleton" on a deformed avatar ( including yourself ) that currently does NOT perform this action for everyone else viewing the deformed avatar.'''

This was done because visibly deformed avatars aren't always deformed universally. The logic for why this is is long and complex, involving the mechanics of how avatars are loaded. This feature isn't a fix-all, but is a great alternative to completely logging out of the client and reconnecting, which, prior to this update, used to be the only reliable way to resolve this sort of issue.

==I found a problem? How can I give feedback?==

As always if you discover an undocumented bug please report it at [https://feedback.secondlife.com Second Life Feedback Portal] with the tag [BENTO] in the summary line for it to be properly addressed!

If you have a display problem, please test to see if there is a difference with with hardware skinning Enabled and Disabled
:Me->Preferences->Graphics->Advanced->Avatar Rendering->Hardware skinning checkbox

Touch end

2026-04-30T07:13:26Z

Wulfie Reanimator: Added new example (moved from Touch)

{{LSL_Event|event_id=4|event_delay|event=touch_end
|p1_type=integer|p1_name=num_detected|p1_desc
|event_desc=Triggered when agent stops clicking on task
|constants
|spec
|caveats=* If a prim [[face]] has [[Navigating Shared Media|Shared Media]] enabled and the avatar's viewer supports this feature, LSL scripts will not detect touches on that face. Touches from older clients will be detected.
* Rigged mesh attachments do not support touch events, this is because you can steer your avatar/camera by click dragging your avatar body which is what the rigged mesh replaces. The only way to get a touch event on a rigged mesh attachment is via the right click context menu and clicking the "Touch" button.
|examples=You can use index 0 through (<code>num_detected</code>-1) with the various llDetected... functions to handle simultaneous touches at once.

For most purposes, it's usually enough to handle just with the first toucher e.g. [[llDetectedKey]](0). It is rare (but not impossible) for <code>num_detected</code> to be greater than 1.
<source lang="lsl2">
default
{
touch_start(integer num_detected)
{
llResetTime();
}

touch_end(integer num_detected)
{
llInstantMessage(llDetectedKey(0), "You held the mouse button down for " + (string) llGetTime() + " seconds");
}
}</source>

This next example demonstrates detecting when the owner of the object clicks-and-holds on the object for 1 second in order perhaps to access a management menu or similar, Normal brief clicks are distinguished.
<source lang="lsl2">
default
{
touch_start(integer num_detected)
{
llResetTime(); // Set llGetTime to 0
}

touch_end(integer num_detected)
{
// Check how much time elapsed since touch_start
if (llGetTime() <= 1.0)
{
// The user did a normal quick click on the object
// Execute actions for normal clicks...
}
else
{
// The owner has touched this object for longer than 1 second
// Execute some special feature such as issuing a management dialog...
}
}
}
</source>
|notes=*If using a touch to change states be careful about the touch_ event order. '''The best advice is NOT to do state changes from within touch_start.''' Use touch_end and do the state change there. Changing state from within touch_start can cause the next occurrence of THAT touch_start code to be missed.

*On clicking a prim with touch events we trigger touch_start (on first contact), touch (during) and touch_end (as released).

|helpers
|also_header
|also_events=
{{LSL DefineRow||[[touch_start]]|}}
{{LSL DefineRow||[[touch]]|}}
|also_functions=
{{LSL DefineRow||[[llPassTouches]]|}}
|also_articles
|also_footer
|notes
|mode
|deprecated
|cat1=Touch
|cat2=Detected
|cat3=Grab
|cat4=Passable
}}

Touch start

2026-04-30T07:06:11Z

Wulfie Reanimator: Added new example (moved from Touch)

{{LSL_Event|event_id=2|event_delay|event=touch_start
|p1_type=integer
|p1_name=num_detected
|p1_desc=Number of agents detected touching during the last clock cycle
|event_desc=Triggered by the start of agent clicking on task
|constants
|spec
|caveats=* If a prim [[face]] has [[Navigating Shared Media|Shared Media]] enabled and the avatar's viewer supports this feature, LSL scripts will not detect touches on that face. Touches from older clients will be detected.
* The default behavior is: If you have a multi-prim object and the root has a [[touch_start]] handler AND one or more child prims has a [[touch_start]] handler, the root prim's handler will be called when it (the root) or a child without a handler is touched. If you touch a child prim that has a [[touch_start]] handler, it will receive the event and the root prim will not.
** This behavior can be configured with [[llPassTouches]]. After configuring a prim's touch-passing behavior you can delete the script that configured the prim.
* Rigged mesh attachments do not support touch events, this is because you can steer your avatar/camera by click dragging your avatar body which is what the rigged mesh replaces. The only way to get a touch event on a rigged mesh attachment is via the right click context menu and clicking the "Touch" button.
* [https://feedback.secondlife.com/scripting-bugs/p/touch-start-only-triggers-on-the-second-touch-if-touch-is-already-active Due to a known issue], if a resident is already touching a scripted object, [[touch_start]] runs only every other time that other residents touch it.
|examples=You can use index 0 through (<code>num_detected</code>-1) with the various llDetected... functions to handle simultaneous touches at once.

For most purposes, it's usually enough to handle just with the first toucher e.g. [[llDetectedKey]](0). It is rare (but not impossible) for <code>num_detected</code> to be greater than 1.
<source lang="lsl2">
default
{
touch_start(integer num_detected)
{
key avatarKey = llDetectedKey(0);
string avatarName = llDetectedName(0);

llInstantMessage(avatarKey, "Hello " + avatarName );
}
}
</source>

This next example demonstrates detecting when the owner of the object clicks-and-holds on the object for 1 second in order perhaps to access a management menu or similar, Normal brief clicks are distinguished.
<source lang="lsl2">
default
{
touch_start(integer num_detected)
{
llResetTime(); // Set llGetTime to 0
}

touch_end(integer num_detected)
{
// Check how much time elapsed since touch_start
if (llGetTime() <= 1.0)
{
// The user did a normal quick click on the object
// Execute actions for normal clicks...
}
else
{
// The owner has touched this object for longer than 1 second
// Execute some special feature such as issuing a management dialog...
}
}
}
</source>
|helpers
|also_header
|also_events=
{{LSL DefineRow||[[touch]]|}}
{{LSL DefineRow||[[touch_end]]|}}
|also_functions=
{{LSL DefineRow||[[llSetTouchText]]|}}
{{LSL DefineRow||[[llPassTouches]]|}}
{{LSL DefineRow||[[llDetectedTouchFace]]|}}
{{LSL DefineRow||[[llDetectedTouchST]]|}}
{{LSL DefineRow||[[llDetectedTouchUV]]|}}
{{LSL DefineRow||[[llDetectedTouchPos]]|}}
{{LSL DefineRow||[[llDetectedTouchNormal]]|}}
{{LSL DefineRow||[[llDetectedTouchBinormal]]|}}
|also_articles
|also_footer
|notes=*If using a touch to change states be careful about the touch event order. '''The best advice is not to do state changes from within touch_start.''' Add a [[touch_end]] handler and do the state change there. Changing state from within [[touch_start]] can cause the next occurrence of THIS [[touch_start]] code to be missed.

*On clicking a prim with touch event handlers, the following handlers are triggered: [[touch_start]] (on first contact), [[touch]] (during) and [[touch_end]] (as released).
|mode
|deprecated
|cat1=Touch
|cat2=Detected
|cat3=Grab
|cat4=Passable
}}

Touch

2026-04-30T07:03:19Z

Wulfie Reanimator: Added new example, moving another to touch_start instead...

{{LSL_Event|event_id=3|event_delay|event=touch
|p1_type=integer|p1_name=num_detected|p1_desc
|event_desc=Triggered whilst an agent is clicking the task. It will continue to be triggered until the the prim/object is stopped being clicked (it triggers multiple times).
Triggered on touch start, each minimum event delay while held, and touch end.
|constants
|spec
|caveats=* If a prim [[face]] has [[Navigating Shared Media|Shared Media]] enabled and the avatar's viewer supports this feature, LSL scripts will not detect touches on that face. Touches from older clients will be detected.
* Rigged mesh attachments do not support touch events, this is because you can steer your avatar/camera by click dragging your avatar body which is what the rigged mesh replaces. The only way to get a touch event on a rigged mesh attachment is via the right click context menu and clicking the "Touch" button.
|notes=*On clicking a prim with touch events we trigger touch_start (on first contact), touch (during) and touch_end (as released).

|examples=You can use index 0 through (<code>num_detected</code>-1) with the various llDetected... functions to handle simultaneous touches at once.

For example, the following script shows the names of everyone touching it (click and hold) as floating text.
<source lang="lsl2">
list touchers;

default
{
// Collect names of avatars touching the object.
touch(integer num_detected)
{
integer i;
for (i = 0; i < num_detected; ++i)
{
string name = llDetectedName(i);
if (llListFindList(touchers, [name]) == -1)
{
touchers += name;
}
}
llSetText("I am being touched by " + llList2CSV(touchers) + ".", <1,1,1>, 1);
}

// Remove names of avatars as they let go.
touch_end(integer num_detected)
{
integer i;
for (i = 0; i < num_detected; ++i)
{
string name = llDetectedName(i);
integer index = llListFindList(touchers, [name]);
touchers = llDeleteSubList(touchers, index, index);
}
if (llGetListLength(touchers) > 0)
{
llSetText("I am being touched by " + llList2CSV(touchers) + ".", <1,1,1>, 1);
}
else
{
llSetText("", <1,1,1>, 1);
}
}
}
</source>

For most purposes, it's usually enough to handle just with the first toucher e.g. [[llDetectedKey]](0).
<source lang="lsl2">default
{
touch(integer num_detected)
{
llOwnerSay("I am being touched by " + llDetectedName(0) + ".");
}
}
</source>
|helpers
|also_header
|also_events=
{{LSL DefineRow||[[touch_start]]|}}
{{LSL DefineRow||[[touch_end]]|}}
|also_functions=
{{LSL DefineRow||[[llSetTouchText]]|Set the pie menu's text for touch-action}}
{{LSL DefineRow||[[llPassTouches]]|Allows clicks captured by a child prim to be passed to the root as well}}
|also_articles
|also_footer
|notes
|mode
|deprecated
|cat1=Touch
|cat2=Detected
|cat3=Grab
|cat4=Passable
}}

Touch

2026-04-30T06:38:47Z

Wulfie Reanimator: Updated examples.

{{LSL_Event|event_id=3|event_delay|event=touch
|p1_type=integer|p1_name=num_detected|p1_desc
|event_desc=Triggered whilst an agent is clicking the task. It will continue to be triggered until the the prim/object is stopped being clicked (it triggers multiple times).
Triggered on touch start, each minimum event delay while held, and touch end.
|constants
|spec
|caveats=* If a prim [[face]] has [[Navigating Shared Media|Shared Media]] enabled and the avatar's viewer supports this feature, LSL scripts will not detect touches on that face. Touches from older clients will be detected.
* Rigged mesh attachments do not support touch events, this is because you can steer your avatar/camera by click dragging your avatar body which is what the rigged mesh replaces. The only way to get a touch event on a rigged mesh attachment is via the right click context menu and clicking the "Touch" button.
|notes=*On clicking a prim with touch events we trigger touch_start (on first contact), touch (during) and touch_end (as released).

|examples=You can use numbers 0 through (num_detected-1) with the various llDetected... functions to get detected agent keys etc. For most purposes, it is adequate to bother only with the first detected toucher e.g. llDetectedKey(0). It is rare (but not impossible) for num_detected to be other than 1.
<source lang="lsl2">default
{
touch(integer num_detected)
{
llOwnerSay("I am being touched by " + llDetectedName(0) + ".");
}
}
</source>

This next example demonstrates detecting when the owner of the object clicks-and-holds on the object for 1 second in order perhaps to access a management menu or similar, Normal brief clicks are distinguished.

<source lang="lsl2">
default
{
touch_start(integer num_detected)
{
llResetTime(); // Set llGetTime to 0
}

touch_end(integer num_detected)
{
// Check how much time elapsed since touch_start
if (llGetTime() <= 1.0)
{
// The user did a normal quick click on the object
// Execute actions for normal clicks...
}
else
{
// The owner has touched this object for longer than 1 second
// Execute some special feature such as issuing a management dialog...
}
}
}
</source>
|helpers
|also_header
|also_events=
{{LSL DefineRow||[[touch_start]]|}}
{{LSL DefineRow||[[touch_end]]|}}
|also_functions=
{{LSL DefineRow||[[llSetTouchText]]|Set the pie menu's text for touch-action}}
{{LSL DefineRow||[[llPassTouches]]|Allows clicks captured by a child prim to be passed to the root as well}}
|also_articles
|also_footer
|notes
|mode
|deprecated
|cat1=Touch
|cat2=Detected
|cat3=Grab
|cat4=Passable
}}

LlDetectedLinkNumber

2026-04-30T06:28:31Z

Wulfie Reanimator:

{{LSL_Function
|inject-2={{Issues/SVC-2996}}{{LSL_Function/detected|number|linkNumber|error={{HoverText|0|zero}}}}
|func_id=40|func_sleep=0.0|func_energy=10.0
|func=llDetectedLinkNumber
|return_type=integer
|return_subtype=link
|return_subtype_disp=link_number
|Return_text=of the triggered event. If not supported by the event, returns zero.
|p1_type=integer|p1_name=number
|func_footnote=For {{LSLGC|Touch|touch}} and {{LSLGC|Collision|collision}} categories of events only.
|func_desc
|spec
|caveats
|constants
|examples=
<source lang="lsl2">
default
{
// Drop this script into the root prim of of a build
// Touch any prim to learn its link number
touch_start(integer num_detected)
{
llOwnerSay("Link number clicked: " + (string)llDetectedLinkNumber(0));
}
}
</source>
|helpers
|also_functions=
{{LSL DefineRow||[[llDetectedTouchFace]]|}}
|also_events=
{{LSL DefineRow||[[touch_start]]|}}
{{LSL DefineRow||[[touch]]|}}
{{LSL DefineRow||[[touch_end]]|}}
{{LSL DefineRow||[[collision_start]]|}}
{{LSL DefineRow||[[collision]]|}}
{{LSL DefineRow||[[collision_end]]|}}
|also_articles
|issues
|notes
|cat1=Link
|cat2=Touch
|cat3
|cat4
}}

LlRezObjectWithParams

2026-03-31T21:04:02Z

Wulfie Reanimator: Copied rez distance section from llRezObject.

{{LSL_Function
|inject-2=
{{LSL_Function/inventory|inventory|uuid=false|type=object}}
{{LSL_Function/position|pos|region=*}}
|func_id=|func_sleep=0.1|func_energy=200.0
|func=llRezObjectWithParams|sort=RezObjectWithParams
|return_type=key
|p1_type=string|p1_name=inventory
|p2_type=list|p2_name=params
|func_desc=Instantiate {{LSLP|inventory}} object at {{LSLP|pos}} with an initial set of parameters specified in {{LSLP|params}}.

{{LSLP|pos}} will default to the position of the object containing the script, unless REZ_POS is specified. (see below)
|return_text=which will be the key of the object when it is successfully rezzed in the world.
|spec=
{{:LSL Constants/llRezObjectWithParams}}
|caveats=
*Silently fails to rez {{LSLP|inventory}} if REZ_POS is too far from the geometric center of the object trying to rez {{LSLP|inventory}} (generally 10 meters; see [[llRezObject]]).
* When scripting attachments meant to rez objects, remember that when used in the root of an ([[attach|attached]]) [[attachment]] <code>[[llGetPos]]</code> doesn't return the position of the attachment but instead returns the position of the avatar's bounding box geometric center. Read [[llGetPos]] and [[llParticleSystem#Caveats | llParticleSystem Caveats]] for more information.
* If the object is unattached and the owner of the object does not have copy permission on {{LSLP|inventory}}, the object will no longer be present in inventory after it is rezzed (so another attempt to rez (the same object) will fail); if the owner does have copy permission, then a copy is rezzed, and the original {{LSLP|inventory}} remains in inventory.
* If the object is attached and the owner of the object does not have copy permission on {{LSLP|inventory}}, an error is shouted on [[DEBUG_CHANNEL]]: "Cannot rez no copy objects from an attached object."
*Silently fails if you don't have offline building rights on the land. To have the right, your objects needs to ''either'':
** Be on land you own yourself.
** Be on land where anyone is allowed to build, e.g. a sandbox.
** Be deeded to the group that owns the land.
** Be set to the same group that owns the land and the land have the parcel flag 'allow group to build' set.
** The group role "Always allow 'Create Objects'" will only work to override this when you are online, in the region, or have a child agent in the region. See [[#SVC-3145|SVC-3145]] in the Issues subsection of Deep Notes for more information.
* See [[object_rez]] for examples on how to establish communications between the rezzing object and the new prim.
|constants
|examples=
The list of parameters is entirely optional. If you want to rez an object exactly where the rezzer is, you may call the function with an empty list.
<syntaxhighlight lang="lsl2">
default
{
touch_start(integer total_number)
{
llRezObjectWithParams("Object", []);
}
}
</syntaxhighlight>

The below example rezzes an object slightly above the rezzer, slowly spinning and with automatic cleanup. See [[:Category:LSL Temporary|Temporary]]
<syntaxhighlight lang="lsl2">
default
{
touch_start(integer total_number)
{
llRezObjectWithParams("Object", [
REZ_FLAGS, REZ_FLAG_TEMP | REZ_FLAG_PHANTOM,
REZ_POS, <0,0,1>, TRUE, TRUE,
REZ_OMEGA, <0,0,1>, TRUE, 0.5, PI
]);
}
}
</syntaxhighlight>

The below is a basic example of firing a typical bullet from a worn attachment. The bullet is fired with a left-click during [[mouselook]].
<syntaxhighlight lang="lsl2">
default
{
control(key id, integer level, integer edge)
{
integer click = level & edge;

if (click & CONTROL_ML_LBUTTON) {
llRezObjectWithParams("Bullet", [
REZ_POS, <2,0,0>, TRUE, TRUE, // Relative offset 2 meters forward
REZ_ROT, ZERO_ROTATION, TRUE, // Relative rotation
REZ_VEL, <100,0,0>, TRUE, FALSE, // Relative velocity 100m/s forward
REZ_DAMAGE, 40,
REZ_LOCK_AXES, <1,1,1>, // Disable all rotation
REZ_FLAGS, 0
| REZ_FLAG_PHYSICAL
| REZ_FLAG_TEMP
| REZ_FLAG_DIE_ON_COLLIDE
| REZ_FLAG_DIE_ON_NOENTRY
| REZ_FLAG_NO_COLLIDE_OWNER
| REZ_FLAG_NO_COLLIDE_FAMILY
| REZ_FLAG_BLOCK_GRAB_OBJECT
]);
}
}

run_time_permissions(integer perm)
{
if (perm) {
llTakeControls(CONTROL_ML_LBUTTON, TRUE, FALSE);
}
}

attach(key id)
{
if (id) {
llRequestPermissions(llGetOwner(), PERMISSION_TAKE_CONTROLS);
}
}

state_entry()
{
if (llGetAttached()) {
llRequestPermissions(llGetOwner(), PERMISSION_TAKE_CONTROLS);
}
}
}
</syntaxhighlight>
|helpers
|also_constants=
{{LSL DefineRow||[[PRIM_TEMP_ON_REZ]]|}}
|also_functions=
{{LSL DefineRow||[[llRezAtRoot]]|Rezzes the object at the requested position}}
{{LSL DefineRow||[[llRezObject]]|Rezzes the object at the requested position}}
{{LSL DefineRow||[[llGetStartString]]|}}
{{LSL DefineRow||[[llGetStartParameter]]|}}
{{LSL DefineRow||[[llGodLikeRezObject]]|}}
{{LSL DefineRow||[[LlGetParcelFlags#Examples]]|Test if the parcel allows this script to rez}}
|also_tests
|also_events=
{{LSL DefineRow||[[object_rez]]|triggered when this object rezzes an object from inventory}}
|also_articles
|notes='''Maximum rez distance'''
*The {{LSLP|distance}} scales with the size of the object the script is in.
**The formula is <code>10 + llVecMag(llGetScale()) * 0.5</code>
*The {{LSLP|distance}} measured is between the [[llGetPos|center]] of the rezzing {{LSLP|prim}} and the [[llGetPos|center]] of the {{LSLP|prim}} that is rezzed.
**The tests did not include rezzing from or the rezzing of link_set objects.
**A <code>0.01</code> meter cube could rez just beyond <code>10.0</code> meters away.
**A <code>10.0</code> meter cube could rez just beyond <code>18.66</code> meters away.
**A <code>32.0</code> meter cube could rez just beyond <code>37.71</code> meters away.
**A <code>64.0</code> meter cube could rez just beyond <code>65.42</code> meters away.
|permission
|inventory
|negative_index
|cat1=Rez
|cat2=Object
|cat3=Inventory
|cat4
}}

LlRezObject

2026-03-31T21:01:16Z

Wulfie Reanimator: Updated rez distance section with formula and up to official scale.

{{LSL_Function
|inject-2={{Issues/SVC-3145}}{{Issues/SVC-6578}}{{Issues/SVC-6686}}{{Issues/SCR-485}}
{{LSL_Function/inventory|inventory|uuid=false|type=object}}
{{LSL_Function/position|pos|region=*}}
|func_id=104|func_sleep=0.1|func_energy=200.0
|func=llRezObject|sort=RezObject
|p1_type=string|p1_name=inventory
|p2_type=vector|p2_name=pos
|p3_type=vector|p3_name=vel|p3_desc=velocity (max [[llVecMag|magnitude]] is approximately 200m/s)
|p4_type=rotation|p4_name=rot|p4_desc=rotation
|p5_type=integer|p5_name=param|p5_desc=[[on_rez]] event parameter and value returned by [[llGetStartParameter]] in the rezzed object (or by each of the items in a coalesced object).|p5_hover=on_rez event parameter and value returned by llGetStartParameter in the rezzed object.
|func_footnote=The root of {{LSLP|inventory}} is not at {{LSLP|pos}} but the [[llGetGeometricCenter|center]] of {{LSLP|inventory}} is. To have the root prim at {{LSLP|pos}} use [[llRezAtRoot]] instead.
|func_desc=Instantiate {{LSLP|inventory}} object at {{LSLP|pos}} with velocity {{LSLP|vel}} and rotation {{LSLP|rot}} with start parameter {{LSLP|param}}
|return_text
|spec
|caveats=
*Silently fails to rez {{LSLP|inventory}} (to have it's geometric center at {{LSLP|pos}}) if {{LSLP|pos}} is too far from the geometric center of the object trying to rez {{LSLP|inventory}}.
**If your script is mysteriously failing to rez things, make sure you haven't (say) written "<code><0.0,0.0,1.0></code>" for the {{LSLP|pos}} parameter rather than (say) <code>[[llGetPos]]() + <0.0,0.0,1.0></code>".
* When scripting attachments meant to rez objects, remember that when used in the root of an ([[attach|attached]]) [[attachment]] <code>[[llGetPos]]</code> doesn't return the position of the attachment but instead returns the position of the avatar's bounding box geometric center. Read [[llGetPos]] and [[llParticleSystem#Caveats | llParticleSystem Caveats]] for more information.
* If the object is unattached and the owner of the object does not have copy permission on {{LSLP|inventory}}, the object will no longer be present in inventory after it is rezzed (so another attempt to rez (the same object) will fail); if the owner does have copy permission, then a copy is rezzed, and the original {{LSLP|inventory}} remains in inventory.
* If the object is attached and the owner of the object does not have copy permission on {{LSLP|inventory}}, an error is shouted on [[DEBUG_CHANNEL]]: "Cannot rez no copy objects from an attached object."
*Silently fails if you don't have offline building rights on the land. To have the right, your objects needs to ''either'':
** Be on land you own yourself.
** Be on land where anyone is allowed to build, e.g. a sandbox.
** Be deeded to the group that owns the land.
** Be set to the same group that owns the land and the land have the parcel flag 'allow group to build' set.
** The group role "Always allow 'Create Objects'" will only work to override this when you are online, in the region, or have a child agent in the region. See [[#SVC-3145|SVC-3145]] in the Issues subsection of Deep Notes for more information.
* See [[object_rez]] for examples on how to establish communications between the rezzing object and the new prim.
|constants
|examples=<syntaxhighlight lang="lsl2">default
{
touch_start(integer param)
{
llRezObject("Object", llGetPos() + <0.0,0.0,1.0>, <0.0,0.0,0.0>, <0.0,0.0,0.0,1.0>, 0);
}
}</syntaxhighlight>
<syntaxhighlight lang="lsl2">// Rez an object on touch, with relative position, rotation, and velocity all described in the rezzing prim's coordinate system.
string object = "Object"; // Name of object in inventory
vector relativePosOffset = <2.0, 0.0, 1.0>; // "Forward" and a little "above" this prim
vector relativeVel = <1.0, 0.0, 0.0>; // Traveling in this prim's "forward" direction at 1m/s
rotation relativeRot = <0.707107, 0.0, 0.0, 0.707107>; // Rotated 90 degrees on the x-axis compared to this prim
integer startParam = 10;

default
{
touch_start(integer a)
{
vector myPos = llGetPos();
rotation myRot = llGetRot();

vector rezPos = myPos+relativePosOffset*myRot;
vector rezVel = relativeVel*myRot;
rotation rezRot = relativeRot*myRot;

llRezObject(object, rezPos, rezVel, rezRot, startParam);
}
}</syntaxhighlight>
|helpers
|also_constants=
{{LSL DefineRow||[[PRIM_TEMP_ON_REZ]]|}}
|also_functions=
{{LSL DefineRow||[[llRezObjectWithParams]]|Modern alternative with more parameters.}}
{{LSL DefineRow||[[llRezAtRoot]]|Rezzes the object at the requested position}}
{{LSL DefineRow||[[llGetStartParameter]]|}}
{{LSL DefineRow||[[llGodLikeRezObject]]|}}
{{LSL DefineRow||[[LlGetParcelFlags#Examples]]|Test if the parcel allows this script to rez}}
|also_tests
|also_events=
{{LSL DefineRow||[[object_rez]]|triggered when this object rezzes an object from inventory}}
|also_articles
|notes='''Maximum rez distance'''
*The {{LSLP|distance}} scales with the size of the object the script is in.
**The formula is <code>10 + llVecMag(llGetScale()) * 0.5</code>
*The {{LSLP|distance}} measured is between the [[llGetPos|center]] of the rezzing {{LSLP|prim}} and the [[llGetPos|center]] of the {{LSLP|prim}} that is rezzed.
**The tests did not include rezzing from or the rezzing of link_set objects.
**A <code>0.01</code> meter cube could rez just beyond <code>10.0</code> meters away.
**A <code>10.0</code> meter cube could rez just beyond <code>18.66</code> meters away.
**A <code>32.0</code> meter cube could rez just beyond <code>37.71</code> meters away.
**A <code>64.0</code> meter cube could rez just beyond <code>65.42</code> meters away.
|permission
|inventory
|negative_index
|cat1=Rez
|cat2=Object
|cat3=Inventory
|cat4
}}

LlRezObject

2026-03-30T19:36:50Z

Wulfie Reanimator:

{{LSL_Function
|inject-2={{Issues/SVC-3145}}{{Issues/SVC-6578}}{{Issues/SVC-6686}}{{Issues/SCR-485}}
{{LSL_Function/inventory|inventory|uuid=false|type=object}}
{{LSL_Function/position|pos|region=*}}
|func_id=104|func_sleep=0.1|func_energy=200.0
|func=llRezObject|sort=RezObject
|p1_type=string|p1_name=inventory
|p2_type=vector|p2_name=pos
|p3_type=vector|p3_name=vel|p3_desc=velocity (max [[llVecMag|magnitude]] is approximately 200m/s)
|p4_type=rotation|p4_name=rot|p4_desc=rotation
|p5_type=integer|p5_name=param|p5_desc=[[on_rez]] event parameter and value returned by [[llGetStartParameter]] in the rezzed object (or by each of the items in a coalesced object).|p5_hover=on_rez event parameter and value returned by llGetStartParameter in the rezzed object.
|func_footnote=The root of {{LSLP|inventory}} is not at {{LSLP|pos}} but the [[llGetGeometricCenter|center]] of {{LSLP|inventory}} is. To have the root prim at {{LSLP|pos}} use [[llRezAtRoot]] instead.
|func_desc=Instantiate {{LSLP|inventory}} object at {{LSLP|pos}} with velocity {{LSLP|vel}} and rotation {{LSLP|rot}} with start parameter {{LSLP|param}}
|return_text
|spec
|caveats=
*Silently fails to rez {{LSLP|inventory}} (to have it's geometric center at {{LSLP|pos}}) if {{LSLP|pos}} is too far from the geometric center of the object trying to rez {{LSLP|inventory}}.
**If your script is mysteriously failing to rez things, make sure you haven't (say) written "<code><0.0,0.0,1.0></code>" for the {{LSLP|pos}} parameter rather than (say) <code>[[llGetPos]]() + <0.0,0.0,1.0></code>".
* When scripting attachments meant to rez objects, remember that when used in the root of an ([[attach|attached]]) [[attachment]] <code>[[llGetPos]]</code> doesn't return the position of the attachment but instead returns the position of the avatar's bounding box geometric center. Read [[llGetPos]] and [[llParticleSystem#Caveats | llParticleSystem Caveats]] for more information.
* If the object is unattached and the owner of the object does not have copy permission on {{LSLP|inventory}}, the object will no longer be present in inventory after it is rezzed (so another attempt to rez (the same object) will fail); if the owner does have copy permission, then a copy is rezzed, and the original {{LSLP|inventory}} remains in inventory.
* If the object is attached and the owner of the object does not have copy permission on {{LSLP|inventory}}, an error is shouted on [[DEBUG_CHANNEL]]: "Cannot rez no copy objects from an attached object."
*Silently fails if you don't have offline building rights on the land. To have the right, your objects needs to ''either'':
** Be on land you own yourself.
** Be on land where anyone is allowed to build, e.g. a sandbox.
** Be deeded to the group that owns the land.
** Be set to the same group that owns the land and the land have the parcel flag 'allow group to build' set.
** The group role "Always allow 'Create Objects'" will only work to override this when you are online, in the region, or have a child agent in the region. See [[#SVC-3145|SVC-3145]] in the Issues subsection of Deep Notes for more information.
* See [[object_rez]] for examples on how to establish communications between the rezzing object and the new prim.
|constants
|examples=<syntaxhighlight lang="lsl2">default
{
touch_start(integer param)
{
llRezObject("Object", llGetPos() + <0.0,0.0,1.0>, <0.0,0.0,0.0>, <0.0,0.0,0.0,1.0>, 0);
}
}</syntaxhighlight>
<syntaxhighlight lang="lsl2">// Rez an object on touch, with relative position, rotation, and velocity all described in the rezzing prim's coordinate system.
string object = "Object"; // Name of object in inventory
vector relativePosOffset = <2.0, 0.0, 1.0>; // "Forward" and a little "above" this prim
vector relativeVel = <1.0, 0.0, 0.0>; // Traveling in this prim's "forward" direction at 1m/s
rotation relativeRot = <0.707107, 0.0, 0.0, 0.707107>; // Rotated 90 degrees on the x-axis compared to this prim
integer startParam = 10;

default
{
touch_start(integer a)
{
vector myPos = llGetPos();
rotation myRot = llGetRot();

vector rezPos = myPos+relativePosOffset*myRot;
vector rezVel = relativeVel*myRot;
rotation rezRot = relativeRot*myRot;

llRezObject(object, rezPos, rezVel, rezRot, startParam);
}
}</syntaxhighlight>
|helpers
|also_constants=
{{LSL DefineRow||[[PRIM_TEMP_ON_REZ]]|}}
|also_functions=
{{LSL DefineRow||[[llRezObjectWithParams]]|Modern alternative with more parameters.}}
{{LSL DefineRow||[[llRezAtRoot]]|Rezzes the object at the requested position}}
{{LSL DefineRow||[[llGetStartParameter]]|}}
{{LSL DefineRow||[[llGodLikeRezObject]]|}}
{{LSL DefineRow||[[LlGetParcelFlags#Examples]]|Test if the parcel allows this script to rez}}
|also_tests
|also_events=
{{LSL DefineRow||[[object_rez]]|triggered when this object rezzes an object from inventory}}
|also_articles
|notes='''Maximum rez distance'''
*After tests on server 1.38, these figures were measured - (on some earlier server versions the same ''further-than-10-meter'' rezzes have been possible).
*The {{LSLP|distance}} measured is between the [[llGetPos|center]] of the rezzing {{LSLP|prim}} and the [[llGetPos|center]] of the {{LSLP|prim}} that is rezzed.
**The tests did not include rezzing from or the rezzing of link_set objects.
**A <code>10.0</code> meter cube could rez a <code>0.5</code> meter cube just beyond <code>18.6</code> meters away.
**A <code>0.01</code> cube could rez a <code>0.5</code> meter cube just beyond <code>10.0</code> meters away.
|permission
|inventory
|negative_index
|cat1=Rez
|cat2=Object
|cat3=Inventory
|cat4
}}

Preview Grid

2026-03-07T16:26:39Z

Wulfie Reanimator:

{{Help|Viewer=*|Misc=*}}

In addition to the Second Life main grid (known as "[[Land#Agni|Agni]]") that many thousands of Residents log into each day, there is another [[Land#Grid|grid]] open to the public, known as the preview grid, beta grid, or "Aditi." Aditi is where we test server software under development.

For login instructions, read below in [[Preview_Grid#How do I log in to Aditi?|How do I log in to Aditi?]]

If you change your password on AGNI, it may not transfer to the ADITI login servers. Keep your old password in case it doesn't. You will need to [https://support.secondlife.com/create-case/ contact Support] to get it resync'd.

==What We Do with the Preview Grid==

The preview grid is used for development and testing of new features and bug fixes. You will find that as you move from one region to another, you will frequently be moving to regions that are running a different version of the server software. To get the most of the preview grid, you need to know where you are.

===How do I know what version is running on the region I'm in?===
[[Image:Helpversion.jpg|right]]

Some regions have a "channel name" imprinted into the ground over and over again. If the ground texture doesn't make it obvious, look at "About Second Life" in the help menu where you will see a wealth of information about your own system, as well as about the server software running the region you are in. The image below shows you where in the help dialog to find the channel the region you're in is running. (Just to the right of that is the version.)

The most important information in the image here is "Second Life Server"; that's the channel that you're on. The version number is also important, but the biggest changes you will see are between different channels.

==Reporting Bugs or Problems==

This will vary depending on the channel of the region, and on the state of the release. If you find problems in the "Second Life Beta Server" channel before that version has been deployed to the main Second Life service, please use our [http://jira.secondlife.com Bug Tracker] to check to see if that problem has already been reported, and to report it if not. When reporting a problem, please give as much information as possible: what region you were in, exactly what you did and what behavior you saw, when it happened, and the version of both your viewer software and of the server software running in the region where you saw the problem.

In general, you will use the same procedure for problems found on regions in other channels, but sometimes those channels are being used for a focused test by other developers.

==What is on the Preview Grid==
[[File:Aditi image.jpeg|200px|thumb|right|A map from Aditi]]

Aditi has usually about 120 regions (sims). Some of them share the same name and coordinates with regions on the main grid (usually from [[Sansara]]). Some regions are special and used for testings and have different names. Access is sometimes denied in part of the sims. Usually, when you login first time to Aditi, you will start at Waterhad hidden lakes telehub (looks exactly like Waterhad on the main grid). Preview grid has a lower population density.

We will be using Aditi for beta testing of the next server version, but we will also be using it for early previews of software that isn't going to be on Second Life right away, and for some specific public testing of bug-fixes being worked on by some teams of developers.

The regions on Aditi are divided into different channels. There will always be two core channels:

* '''Second Life Production Server''' : this has the same version of the software as is running on the main Second Life hosts. This exists for purposes of comparison. Sometimes, it will have the *previous* release, right after a new server has been deployed to Second Life.

* '''Second Life Beta Server''' : this channel is designated for the version of the server we're planning on next deploying to Second Life in a rolling restart. Generally, after a new server version is deployed to Second Life, it will be at least a few days before the next beta version goes out to Aditi.

In addition, there will sometimes be other channels for specific tests and/or early betas of upcoming features.

==How do I log in to Aditi?==

Check out the [https://lindenlab.freshdesk.com/support/solutions/articles/31000156725-accessing-aditi Accessing Aditi] page at Second Life's support solution center for detailed tips on how to access Aditi for the first time.

In order to access the Beta Grid (Aditi) for the first time, you will have a slightly different login process than usual. Specifically, you'll have to attempt to login once, which triggers an automatic update of your account to copy it to the Beta Grid (Aditi). You should receive an error message when you attempt to login that states '''Login Failed. We're currently in the process of syncing this account. Please try again later.'''

This error message is normal, and if you wait 10-15 seconds, you can try your login one more time and it should succeed, granting you access to the Beta Grid.

You can use the same Second Life viewer you already use to log into Second Life. At the login screen, hit {{KeyCombo|ctrl=*|shift=*|G}}. At the bottom of the screen to the right of the "Log In" button, you will see a dropdown menu that allows you to select the grid that you want to log in to:
*[[Image:Grid_Selection.jpeg]]
*Select "'''Second Life Beta Test'''" (aka Preview or Aditi) to log into the Test Grid. To return to the Main Grid select "'''Second Life Main Grid (Agni)'''" at your next login. (On some third-party viewers a number of other grids may be listed in this dropdown.)

There are other SL internal development grids which are not available for public access. Some viewers list them. Unless your last name is Linden, you won't be able to log into them.

Some viewers display names other than "Second Life Beta". This is the case for the Firestorm viewer. Preview Grid, Second Life Beta Grid, Test grid, and Aditi are all indicating the same grid.

{{note|Starting with Viewer version 2.6.0, you will need to go to the Me->Preferences->Advanced menu and enable "Show Advanced Menu" before the above will work.

The key combination works in versions 5+ without having to change any settings.}}

Once you do log into Aditi, you should have all of the inventory that you have on Main Grid (Agni). However, in subsequent logins to Aditi new items acquired in the Second Life Main Grid (Agni) will not be available to your Aditi account until the next inventory sync, which should be within 24 hours after your Aditi login. The process is scheduled for a 6 AM SLT start. How long it may take to get to your account is an unknown.

'''IN NO EVENT''' will you be able to transfer money or objects back from the Preview Grid for use in the Main Second Life Grid (Agni).

If you change your password or username on the main Second Life grid, you will need to contact the Support team to request a manual copy to update your account.
To contact Support for a manual copy to update your account on the Beta Grid (Aditi):
* Visit [https://support.secondlife.com/create-case/ the create a ticket section of support.secondlife.com]
* Sign in to your Second Life account, if you aren't already logged in.
* On the '''Submit A Ticket''' page, select '''Account Issue''' as the Issue Type
* For the Account Issue dropdown, select '''Viewer Login Issues'''
* Enter the name of the avatar you'd like to use on the Beta Grid and in the ''Please describe the issue'' box, explain that you'd like your account recopied to Aditi or the Beta Grid.
* Click '''Submit''' to send your request to Support.

== Uploading Mesh on Aditi ==
You must accept the IP Terms specifically for Aditi, even if you have already accepted the terms on the Main grid. 
The Aditi IP Terms agreement can be found here: https://secondlife.aditi.lindenlab.com/my/account/ip/accept.php 
You do not need to have payment information on file to upload mesh on Aditi.

== Using Web Profiles on Aditi ==
[[Web profiles]] are available on Aditi with a bit of tweaking. To test web based profiles in the Viewer (2.5+) on ADITI, the WebProfileURL debug setting needs to be changed before logging in to the Viewer. You have two ways of doing this:
* The debug setting can be accessed via Advanced->Debug Settings. Change the value to https://my-demo.secondlife.com/. This process will be automatic once login.cgi has been updated.
* You can invoke your viewer with the following executable parameter:
** --set WebProfileURL "https://my-demo.secondlife.com/"
** Removing this variable or setting it to "https://my.secondlife.com/" will set it back to use the AGNI based profiles
* Before logging back into AGNI remove this variable.
* This is Aditi , so things might be borked. Please bear with us.

== Using Marketplace on Aditi ==
The Marketplace supports Beta testing on Aditi! All Merchants will have access to this grid for Beta testing, but will only be able to test purchasing items using L$, since Aditi is not set up to test out other payment methods.

In order to participate in Beta testing, you just need to login to the Aditi grid using your viewer of choice. Your account should automatically be set up and you should receive L$50,000 to start.

Nothing that happens on the test grid (Aditi) has any effect on your avatar, inventory, L$, or marketplace listings on the main grid (Agni). Objects, inventory and L$ on the Beta grid may be damaged by bugs, be removed, or disappear at any point during Beta testing.

To access functions on the Beta grid:

* Grid: Aditi (see [http://wiki.secondlife.com/wiki/Aditi#How_do_I_log_in_to_Aditi.3F this section] for more details)
* Marketplace.com: [https://marketplace.aditi.lindenlab.com https://marketplace.aditi.lindenlab.com] (NOTE: you may see old listings, which were migrated from production when Aditi was set up. Changes made to these listings will not have an impact on production.)
* Magic Boxes for Aditi: [https://marketplace.aditi.lindenlab.com/stores/75 https://marketplace.aditi.lindenlab.com/stores/75]
* Secondlife.com: [http://secondlife.aditi.lindenlab.com/ http://secondlife.aditi.lindenlab.com/]
* If no region is specified for the Beta, you can try one of the following regions:
** Virtual Trade Campus South: {{Region|Virtuatrade Campus S|127|127|27|grid=aditi}}
** Virtual Trade Campus SE: {{Region|Virtuatrade Campus SE|86|124|34|grid=aditi}}
** Or one of the [[#Permanent Sandbox Regions|permanent sandbox regions]]
* Note that you may need to accept a security exception to complete a purchase using L$. Since this is a test web site, no actual sensitive information will be passed, so it is safe to do on the Aditi web site.

If you find a problem or have a suggestion, first try it out on Production before filing a bug on the Feedback Forum. See the KB instructions on [https://community.secondlife.com/knowledgebase/english/how-to-report-a-bug-r224/ How to report a bug] for general help on filing a bug.

== Updating Your Account on Aditi ==

'''Revised:''' May 2018

Inventory updates are now a process that sync's your AGNI (main grid) inventory into your ADITI inventory. No overwrite or loss of ADITI inventory as previously.

Once you login and off, your inventory will re-sync next at about 6 AM PT. The login/out is the trigger. No need to change the password to update inventory.

Change your password regularly to protect your account. But, '''save your old password'''. Sometimes the Aditi login process does not update. Try your old password. (2017 bug)

If your inventory or password does NOT update, you will need to contact SL Support for help.

Your AGNI trash does sync to ADITI...

== Regions on Aditi ==

Aditi has limited capacity, so regions are frequently taken offline in order to make room for regions with more interesting test cases. See [http://aditi.coreqa.net/gridtool.php this page] for the status of several Aditi regions.

=== Permanent Sandbox Regions ===
Residents who wish to test their content before bringing it to the main grid have been given dedicated regions to do so:
* [[File:Parcel_lght_G.png]] [secondlife://Aditi/secondlife/Cloud%20Sandbox%201/128/128 Cloud Sandbox 1 (128,128)]
* [[File:Parcel_lght_G.png]] [secondlife://Aditi/secondlife/Mesh%20Sandbox%202/128/128 Mesh Sandbox 2 (128,128)]
* [[File:Parcel_lght_G.png]] [secondlife://Aditi/secondlife/Sandbox%20Astutula/128/128 Sandbox Astutula (128,128)]
* [[File:Parcel_lght_G.png]] [secondlife://Aditi/secondlife/Sandbox%20Pristina/128/128 Sandbox Pristina (128,128)]
* [[File:Parcel_lght_G.png]] [secondlife://Aditi/secondlife/Sandbox%20Wanderton/128/128 Sandbox Wanderton (128,128)]
* [[File:Parcel_lght_A.png]] [secondlife://Aditi/secondlife/Materials%20Adult/128/128 Materials Adult (128,128)]

= See Also =
* [[Preview Grid Common Questions]]
* [[Beta Server Office Hours]] are held ''on the preview grid'' at {{Region|Morris|192|251|35|grid=aditi}}. These are to discuss beta testing of the next upcoming release of Second Life; when there is not a release pending, we will discuss general SVC issues listed in the JIRA.
* The [https://community.secondlife.com/forums/forum/310-second-life-server/ Release Team blog] has discussions about rolling restarts, server release beta testing in general, and specific versions of the server that are about to be released. Also, see the archived [http://forums-archive.secondlife.com/348/1.html Server Deploy Forums] for updates before February 2010.

= Notes =
{{References}}

[[Category:Bug Tracker]]
[[Category:Quality Assurance]]
[[Category:QA_Portal]]

Preview Grid

2026-03-07T16:14:56Z

Wulfie Reanimator: Removed outdated paragraph about needing to contact support, which has been fixed since 2024.

{{Help|Viewer=*|Misc=*}}

In addition to the Second Life main grid (known as "[[Land#Agni|Agni]]") that many thousands of Residents log into each day, there is another [[Land#Grid|grid]] open to the public, known as the preview grid, or "Aditi." Aditi is where we test server software under development.

For login instructions, read below in [[Preview_Grid#How do I log in to Aditi?|How do I log in to Aditi?]]

If you change your password on AGNI, it may not transfer to the ADITI login servers. Keep your old password in case it doesn't. You will need to [https://support.secondlife.com/create-case/ contact Support] to get it resync'd.

==What We Do with the Preview Grid==

The preview grid is used for development and testing of new features and bug fixes. You will find that as you move from one region to another, you will frequently be moving to regions that are running a different version of the server software. To get the most of the preview grid, you need to know where you are.

===How do I know what version is running on the region I'm in?===
[[Image:Helpversion.jpg|right]]

Some regions have a "channel name" imprinted into the ground over and over again. If the ground texture doesn't make it obvious, look at "About Second Life" in the help menu where you will see a wealth of information about your own system, as well as about the server software running the region you are in. The image below shows you where in the help dialog to find the channel the region you're in is running. (Just to the right of that is the version.)

The most important information in the image here is "Second Life Server"; that's the channel that you're on. The version number is also important, but the biggest changes you will see are between different channels.

==Reporting Bugs or Problems==

This will vary depending on the channel of the region, and on the state of the release. If you find problems in the "Second Life Beta Server" channel before that version has been deployed to the main Second Life service, please use our [http://jira.secondlife.com Bug Tracker] to check to see if that problem has already been reported, and to report it if not. When reporting a problem, please give as much information as possible: what region you were in, exactly what you did and what behavior you saw, when it happened, and the version of both your viewer software and of the server software running in the region where you saw the problem.

In general, you will use the same procedure for problems found on regions in other channels, but sometimes those channels are being used for a focused test by other developers.

==What is on the Preview Grid==
[[File:Aditi image.jpeg|200px|thumb|right|A map from Aditi]]

Aditi has usually about 120 regions (sims). Some of them share the same name and coordinates with regions on the main grid (usually from [[Sansara]]). Some regions are special and used for testings and have different names. Access is sometimes denied in part of the sims. Usually, when you login first time to Aditi, you will start at Waterhad hidden lakes telehub (looks exactly like Waterhad on the main grid). Preview grid has a lower population density.

We will be using Aditi for beta testing of the next server version, but we will also be using it for early previews of software that isn't going to be on Second Life right away, and for some specific public testing of bug-fixes being worked on by some teams of developers.

The regions on Aditi are divided into different channels. There will always be two core channels:

* '''Second Life Production Server''' : this has the same version of the software as is running on the main Second Life hosts. This exists for purposes of comparison. Sometimes, it will have the *previous* release, right after a new server has been deployed to Second Life.

* '''Second Life Beta Server''' : this channel is designated for the version of the server we're planning on next deploying to Second Life in a rolling restart. Generally, after a new server version is deployed to Second Life, it will be at least a few days before the next beta version goes out to Aditi.

In addition, there will sometimes be other channels for specific tests and/or early betas of upcoming features.

==How do I log in to Aditi?==

Check out the [https://lindenlab.freshdesk.com/support/solutions/articles/31000156725-accessing-aditi Accessing Aditi] page at Second Life's support solution center for detailed tips on how to access Aditi for the first time.

In order to access the Beta Grid (Aditi) for the first time, you will have a slightly different login process than usual. Specifically, you'll have to attempt to login once, which triggers an automatic update of your account to copy it to the Beta Grid (Aditi). You should receive an error message when you attempt to login that states '''Login Failed. We're currently in the process of syncing this account. Please try again later.'''

This error message is normal, and if you wait 10-15 seconds, you can try your login one more time and it should succeed, granting you access to the Beta Grid.

You can use the same Second Life viewer you already use to log into Second Life. At the login screen, hit {{KeyCombo|ctrl=*|shift=*|G}}. At the bottom of the screen to the right of the "Log In" button, you will see a dropdown menu that allows you to select the grid that you want to log in to:
*[[Image:Grid_Selection.jpeg]]
*Select "'''Second Life Beta Test'''" (aka Preview or Aditi) to log into the Test Grid. To return to the Main Grid select "'''Second Life Main Grid (Agni)'''" at your next login. (On some third-party viewers a number of other grids may be listed in this dropdown.)

There are other SL internal development grids which are not available for public access. Some viewers list them. Unless your last name is Linden, you won't be able to log into them.

Some viewers display names other than "Second Life Beta". This is the case for the Firestorm viewer. Preview Grid, Second Life Beta Grid, Test grid, and Aditi are all indicating the same grid.

{{note|Starting with Viewer version 2.6.0, you will need to go to the Me->Preferences->Advanced menu and enable "Show Advanced Menu" before the above will work.

The key combination works in versions 5+ without having to change any settings.}}

Once you do log into Aditi, you should have all of the inventory that you have on Main Grid (Agni). However, in subsequent logins to Aditi new items acquired in the Second Life Main Grid (Agni) will not be available to your Aditi account until the next inventory sync, which should be within 24 hours after your Aditi login. The process is scheduled for a 6 AM SLT start. How long it may take to get to your account is an unknown.

'''IN NO EVENT''' will you be able to transfer money or objects back from the Preview Grid for use in the Main Second Life Grid (Agni).

If you change your password or username on the main Second Life grid, you will need to contact the Support team to request a manual copy to update your account.
To contact Support for a manual copy to update your account on the Beta Grid (Aditi):
* Visit [https://support.secondlife.com/create-case/ the create a ticket section of support.secondlife.com]
* Sign in to your Second Life account, if you aren't already logged in.
* On the '''Submit A Ticket''' page, select '''Account Issue''' as the Issue Type
* For the Account Issue dropdown, select '''Viewer Login Issues'''
* Enter the name of the avatar you'd like to use on the Beta Grid and in the ''Please describe the issue'' box, explain that you'd like your account recopied to Aditi or the Beta Grid.
* Click '''Submit''' to send your request to Support.

== Uploading Mesh on Aditi ==
You must accept the IP Terms specifically for Aditi, even if you have already accepted the terms on the Main grid. 
The Aditi IP Terms agreement can be found here: https://secondlife.aditi.lindenlab.com/my/account/ip/accept.php 
You do not need to have payment information on file to upload mesh on Aditi.

== Using Web Profiles on Aditi ==
[[Web profiles]] are available on Aditi with a bit of tweaking. To test web based profiles in the Viewer (2.5+) on ADITI, the WebProfileURL debug setting needs to be changed before logging in to the Viewer. You have two ways of doing this:
* The debug setting can be accessed via Advanced->Debug Settings. Change the value to https://my-demo.secondlife.com/. This process will be automatic once login.cgi has been updated.
* You can invoke your viewer with the following executable parameter:
** --set WebProfileURL "https://my-demo.secondlife.com/"
** Removing this variable or setting it to "https://my.secondlife.com/" will set it back to use the AGNI based profiles
* Before logging back into AGNI remove this variable.
* This is Aditi , so things might be borked. Please bear with us.

== Using Marketplace on Aditi ==
The Marketplace supports Beta testing on Aditi! All Merchants will have access to this grid for Beta testing, but will only be able to test purchasing items using L$, since Aditi is not set up to test out other payment methods.

In order to participate in Beta testing, you just need to login to the Aditi grid using your viewer of choice. Your account should automatically be set up and you should receive L$50,000 to start.

Nothing that happens on the test grid (Aditi) has any effect on your avatar, inventory, L$, or marketplace listings on the main grid (Agni). Objects, inventory and L$ on the Beta grid may be damaged by bugs, be removed, or disappear at any point during Beta testing.

To access functions on the Beta grid:

* Grid: Aditi (see [http://wiki.secondlife.com/wiki/Aditi#How_do_I_log_in_to_Aditi.3F this section] for more details)
* Marketplace.com: [https://marketplace.aditi.lindenlab.com https://marketplace.aditi.lindenlab.com] (NOTE: you may see old listings, which were migrated from production when Aditi was set up. Changes made to these listings will not have an impact on production.)
* Magic Boxes for Aditi: [https://marketplace.aditi.lindenlab.com/stores/75 https://marketplace.aditi.lindenlab.com/stores/75]
* Secondlife.com: [http://secondlife.aditi.lindenlab.com/ http://secondlife.aditi.lindenlab.com/]
* If no region is specified for the Beta, you can try one of the following regions:
** Virtual Trade Campus South: {{Region|Virtuatrade Campus S|127|127|27|grid=aditi}}
** Virtual Trade Campus SE: {{Region|Virtuatrade Campus SE|86|124|34|grid=aditi}}
** Or one of the [[#Permanent Sandbox Regions|permanent sandbox regions]]
* Note that you may need to accept a security exception to complete a purchase using L$. Since this is a test web site, no actual sensitive information will be passed, so it is safe to do on the Aditi web site.

If you find a problem or have a suggestion, first try it out on Production before filing a bug on the Feedback Forum. See the KB instructions on [https://community.secondlife.com/knowledgebase/english/how-to-report-a-bug-r224/ How to report a bug] for general help on filing a bug.

== Updating Your Account on Aditi ==

'''Revised:''' May 2018

Inventory updates are now a process that sync's your AGNI (main grid) inventory into your ADITI inventory. No overwrite or loss of ADITI inventory as previously.

Once you login and off, your inventory will re-sync next at about 6 AM PT. The login/out is the trigger. No need to change the password to update inventory.

Change your password regularly to protect your account. But, '''save your old password'''. Sometimes the Aditi login process does not update. Try your old password. (2017 bug)

If your inventory or password does NOT update, you will need to contact SL Support for help.

Your AGNI trash does sync to ADITI...

== Regions on Aditi ==

Aditi has limited capacity, so regions are frequently taken offline in order to make room for regions with more interesting test cases. See [http://aditi.coreqa.net/gridtool.php this page] for the status of several Aditi regions.

=== Permanent Sandbox Regions ===
Residents who wish to test their content before bringing it to the main grid have been given dedicated regions to do so:
* [[File:Parcel_lght_G.png]] [secondlife://Aditi/secondlife/Cloud%20Sandbox%201/128/128 Cloud Sandbox 1 (128,128)]
* [[File:Parcel_lght_G.png]] [secondlife://Aditi/secondlife/Mesh%20Sandbox%202/128/128 Mesh Sandbox 2 (128,128)]
* [[File:Parcel_lght_G.png]] [secondlife://Aditi/secondlife/Sandbox%20Astutula/128/128 Sandbox Astutula (128,128)]
* [[File:Parcel_lght_G.png]] [secondlife://Aditi/secondlife/Sandbox%20Pristina/128/128 Sandbox Pristina (128,128)]
* [[File:Parcel_lght_G.png]] [secondlife://Aditi/secondlife/Sandbox%20Wanderton/128/128 Sandbox Wanderton (128,128)]
* [[File:Parcel_lght_A.png]] [secondlife://Aditi/secondlife/Materials%20Adult/128/128 Materials Adult (128,128)]

= See Also =
* [[Preview Grid Common Questions]]
* [[Beta Server Office Hours]] are held ''on the preview grid'' at {{Region|Morris|192|251|35|grid=aditi}}. These are to discuss beta testing of the next upcoming release of Second Life; when there is not a release pending, we will discuss general SVC issues listed in the JIRA.
* The [https://community.secondlife.com/forums/forum/310-second-life-server/ Release Team blog] has discussions about rolling restarts, server release beta testing in general, and specific versions of the server that are about to be released. Also, see the archived [http://forums-archive.secondlife.com/348/1.html Server Deploy Forums] for updates before February 2010.

= Notes =
{{References}}

[[Category:Bug Tracker]]
[[Category:Quality Assurance]]
[[Category:QA_Portal]]

PBR Materials

2026-03-07T13:46:54Z

Wulfie Reanimator: Clarified wording. /* PBR Stand-In Textures and Outdated Viewers */

{{multi-lang|1=PBR_Materials|2=/en}}
'''Physically Based Rendering'''

{{note|1=This page is being actively updated with new content and links as GLTF PBR Materials and related new features are being released. Contributions to this page may be from Second Life residents and staff members alike.}}

[[Category:glTF]]

== What is it and Why is it used? ==

The term “Physically Based Rendering” or “PBR” is a technical term for composing images in computer software. It refers to a collection of complex mathematical algorithms that attempt to ''accurately represent the ways that light interacts with objects in the real world.'' In other words, focus is put on the real physical properties of materials.

In the real world, light's unique behavior against metal is how the human eye can recognize "that object is made of metal" without us actually reaching out and touching it. The way a metal reflects light differs from that of a polished plastic or some other material, and these differences have been quantified by science.

Older techniques, such as the existing Blinn-Phong reflection model in Second Life, are more naive approximations of light that lack many nuances (eg. conductivity, microsurfaces, fresnel, energy conservation) that are now possible to simulate in real time.

==== How it applies to Second Life ====
By mimicking real-world physics principles in the virtual world it allows for the creation of more immersive recognizable realistic spaces, but also it helps us relate to fantastical worlds a little better too. While we may not be familiar with what a newly imagined creation is, a metal's inherent metal-ness and aged wood's inherent wood-ness remain constant, making it easier to intuitively understand what we are interacting with in a virtual environment.

Because tying the mathematics to simulate materials in virtual spaces to how they behave in the real-world makes things more immediately recognizable, PBR has become the foundation for creating imagined worlds over the last decade. The metallic shine of exoskeletal armor in superhero movies is driven by a PBR workflow, as is the plastic sheen of toys or the glint of frozen ice in animated classics. Now we are moving to bring this standardized quality to your home in Second Life.

Bringing PBR to Second Life means updating the basic calculations of how light is represented and interacts with the world of Second Life. The goal is to integrate these changes while minimally changing how everything that presently exists in Second Life (designed prior to the introduction of PBR) looks. While the preservation of creative intent and the aesthetic appeal of items users have enjoyed for over two decades of Second Life is always a priority, Second Life is an ever-evolving platform, and to continue to do so, some changes are inevitable.

Lastly, while we are attempting to mimic real-world reflections and material properties, Second Life has to run on a wide variety of devices, so some shortcuts have to be made. Reflections are not mirror-perfect, as has often been a long-standing hope and request from Residents. While the addition of a reflection system does bring dreams of distortion free mirrors for our avatars in Second Life closer to reality, unfortunately, due to the calculation requirements of doing perfect reflections, mirrors are sadly still, for the moment, not practical. Please see the note in the [[#Understanding_and_Assisting_the_New_Reflections_System|section below]] for more info.

== What does this mean for Residents? ==
[[File:PrePostPBR.png | thumb | right | The lamp in this screenshot uses [[PBR_Materials#Nomenclature_changes|Blinn-Phong]] (Classic SL Materials), and was created before PBR's integration into SL; and demonstrates some of the visual differences to existing content. The environment used for the screenshot is the viewer's default Midday preset (Note that the PBR viewer has a new Midday preset).
]]
=== Changes to Existing Content ===
The largest change by far is the addition of an environmental reflection system to Second Life. For most existing items, this change shouldn’t have a drastic immediately observable impact. A few things in your inventory that you already own may appear more reflective with the new graphics configuration and those reflections should feel more realistic and immersive with your current environment. As a general rule: the “shinier” an object was before, the more environment reflections it will pick up and the more visual difference there will be.

Another notable change is the addition of [https://en.wikipedia.org/wiki/Tone_mapping tonemapping] to the viewer. Tonemapping is a way of representing an image with a higher native dynamic range than the display can support. Tonemapping is a de-facto requirement of PBR pipelines. This means that colors in Second Life will generally appear more saturated with less detail being lost in shadows and highlights. [https://modelviewer.dev/examples/color.html Click here for some additional reading on the subject.]

The tonemapping method used is called '''Academy Color Encoding System ('''aka '''"ACES")''', and can be read about [https://www.oscars.org/science-technology/sci-tech-projects/aces here] and [https://docs.nvidia.com/gameworks/index.html#devices/shield-hdr-dev-guide/hdr-dev-guide-nvidia-shield.htm here].

[[PBR_Materials#Nomenclature_changes|Blinn-Phong]] content making use of the Specular parameters may look different if the items were never viewed under local lights, as the PBR viewer allows for the environment (sun ''and'' sky) to contribute to specular reflections. As such, if the object receives blue specular reflections from the sky, these reflections are tinted, and may look odd. This effect is the same as prior viewers, as if the object was lit by a blue local light.

=== Removal of Advanced Lighting Model ( ALM ) Graphics Option ===
There have been changes to the '''Graphics > Advanced Settings...''' Preferences. The most notable of which is the removal of the “Atmospheric Shaders”, "Local lights" and “Advanced Lighting Model” options.

For those users on lower-end hardware who depended heavily upon those options to navigate Second Life with an acceptable framerate, we recommend the following settings:
*{{code|Transparent Water: Disabled}}
*{{code|Screen Space Ambient Occlusion: Disabled}}
*{{code|Shadows: None}}
*{{code|Screen Space Reflections: Disabled}}
*{{code|Reflection Detail: Static Only}}
*{{code|Reflection Coverage: Manual only}}

The {{code|Local Lights}} setting has been superceded by updates made to the '''World > Improve graphics speed...''' "Quality & Speed" slider options. Users on low-end hardware should ensure that their "Quality & Speed" slider is set at an appropriate level for their hardware.

== What does this mean for Creators? ==
=== Nomenclature changes ===
The PBR project represents a large step towards integrating standard rendering techniques used in the games industry. As such, the nomenclature of some items has changed, notably, what was once called '''[[:Category:Materials|Materials]]''' is now referred to as '''Blinn-Phong'''. This does not represent any changes to the underlying rendering techniques (beyond those mentioned above); and as such Blinn-Phong ''is not'' the same as PBR Spec/Gloss workflows, seen in some game engines such as Unity.

=== Importing PBR Materials from External Software: ===
For creators who work with external tools such as Blender, Adobe Substance Painter, Cinema4D, 3D-Coat, or have used the Unreal or Godot game engines, the use of PBR texture sets should already be familiar. In fact, some creators have been using tools that use PBR workflows to create content for Second Life and have then been forced to sacrifice visual quality to convert that information into Second Life’s existing Blinn-Phong materials system.

Second Life is adopting the “Metallic/Roughness” PBR model, and in its ongoing commitment to using Open Source standards whenever it is practical to do so, the glTF 2.0 file format has been chosen as the upload format for PBR Material assets. One of the primary goals of implementing PBR Materials is to have more continuity from content creation applications towards Second Life, and have more consistent content behavior once it’s inworld.

=== Using Imported Materials in Second Life ===
[[File:Editing_Material.jpg|thumb|right|Material Editing]]
For people who build exclusively within Second Life, the addition of PBR also means that there will be a new [[LlGetInventoryType|Inventory Type]] called “Material”. These new Materials can be purchased on the Marketplace and are shareable like any other permitted object in Second Life.

PBR materials come as a bundle of textures. These all travel as a single unit and are applied all at once. If you wish to change tint, transparency, or other similar parameters of the Material you’ll need to modify the Material from the "Editing Material" floater.

{{KBcaution|Meshes uploaded after the PBR release will look slightly different (and more accurate to your editor of choice) due to a change in the way Second Life handles mesh assets (Previously, some data required for accurate tangent generation was discarded at upload time - this is no longer the case). This will mean that a PBR material applied to a mesh uploaded before PBR launched (28th November 2023) might look incorrect; a simple reupload of the mesh will solve this. '''This is not required, but recommended.'''}}

Applying existing materials works similarly to existing textures. You have two means of doing so:

==== Drag and Drop ====
Simply drag and drop onto the face of a prim or a mesh. For example, if you have a tiled floor material and you place it on a selected prim cube face that face will now look like a tile floor and reflect light like a tiled floor would with all the material qualities contained in the material.
[[File:DragAndDrop_Mat_Wiki.png | thumb | none | Drag and Drop Functionality.]]

==== Switch to PBR and select from Inventory ====
Alternatively, select a face on the prim or mesh you want to apply your material to and choose the “Blinn-Phong” drop-down and change it to “PBR Metallic Roughness”, then select “Choose an item from your inventory” and apply.
[[File:PBRSelectorV3.png |left| thumb | none | Menu drop-down demonstration.]][[File:Material_Dropdown.jpg|thumb|none|Dropdown as of v7.0.1.689]]

 

==== Texture Transforms ====
With PBR materials, texture transforms work in a slightly different way to Blinn-Phong transforms. Blinn-Phong (and OpenGL) has the texture origin in the lower left corner of the texture, whereas glTF materials (and Vulkan) has the texture origin in the upper left corner.

This means that PBR materials will react differently (namely, they are inverted in the Y (glTF v) axis) to Blinn-Phong materials.
For a simple solution to convert a Blinn-Phong texture transform to a PBR texture transform, please see [https://community.secondlife.com/forums/topic/507448-lsl-math-for-gltf-transformation/?do=findComment&comment=2678959 this forum thread].

For more information, [https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#images see here] and [https://github.com/KhronosGroup/glTF/tree/main/extensions/2.0/Khronos/KHR_texture_transform here].

=== Media-on-a-Prim ===
Media on a prim will continue to work largely as it has done prior to PBR's launch.

When using MOAP on a face with a PBR texture, it will function as if the media texture has an override to the '''Base Color''' and '''Emissive''' maps. Note that the emissive map is overridden, however the emissive tint is not (so, to disable the emissive map you can set the emissive tint to black <0,0,0>).

== Tools & Tutorials ==
As the PBR system is new, it is expected that existing users may be confused at first on how everything works. As such, Linden Lab and some third parties have provided some tutorials and informational videos:

*'''[https://www.youtube.com/watch?v=JtjGf06B8ZA Second Life University - PBR Materials]'''
*'''[https://www.youtube.com/watch?v=BJ1eRTlWDYk Second Life University - How to create PBR Materials]'''
*'''[https://substance3d.adobe.com/tutorials/courses/pbrguide Allegorithmic (Adobe) PBR Guide]'''

The above tutorials require knowledge and access to Adobe's Substance Painter (subscription based software on Adobe website, or sold as perpetual license with one year of updates on Steam). Below are some open source tools and links found Googling 'Blender', 'glTF' (requiring Blender 3.3)
*'''[https://www.khronos.org/blog/art-pipeline-for-gltf Khronos Art Pipeline tutorial]'''
*'''[https://materialmaker.org Material Maker software]'''
*'''[https://aiaicapta.in/gltf-packer/ glTF Packer software]'''
*'''[https://armorpaint.org Armorpaint software]'''
*'''[https://armorlab.org Armorlab software]'''
*'''[https://youtu.be/KTPdNUGwIGc glTF Blender Tutorial]'''
*'''[https://youtu.be/p7OPRoT6FkY Exporting glTF Alpha Textures tutorial]'''

== PBR Stand-In Textures and Outdated Viewers ==
It is worth mentioning that during the adoption period of a new system, a substantial portion of Second Life Residents view the world through third party viewers and mobile viewer solutions that will not have updated to be able to see the new content. Anyone viewing an object with a PBR Material on a viewer that cannot display it will only see the old Blinn-Phong materials (diffuse, normal, specular). By default, this is just the classic wood texture.

Those who wish their content to be viewable by as many people as possible, might consider creating a Diffuse texture (with baked lighting, the kind that is easily generated with tools like Substance Painter's [https://www.youtube.com/watch?v=OwNwygk4LQo Baked Lighting Filter]) and possibly a Normal/Specular map, and applying those to the object they’re placing the PBR material on, prior to applying the PBR material.

While this is an extra step in content creation, and complicates things somewhat, if you wish for your content to be appreciated by all, it’s worth considering adding this extra step to your workflow. People designing PBR materials for distribution and sale might also consider offering a “Diffuse Only fallback” texture to accompany the PBR material specifically for people who cannot see the PBR content.

{{KBcaution|Once a PBR Material is applied, the Blinn-Phong textures cannot be updated. To remedy this, remove the PBR Material, then make changes to the Blinn-Phong textures and then reapply the PBR Material.}}

== Understanding and Assisting the New Reflections System ==
Those creators that work at house-scale, or produce items that can be walked through, can gain additional control over the lighting in their creations by taking the time to fully understand the new toolkit that influences environmental reflections. There is a new type of volume that can be created and appended to object linksets specifically for scenes with these kinds of spaces. These volumes define a custom area where reflections are calculated, overriding the default solution. So-called “Reflection Probes” should be placed in a manner such that ''the fewest number of probes fills the largest amount of space possible with minimal overlap''. One probe per room is a good reference point for a general living space like a house. If multiple probes exist in a given area they can cause visual artifacts and negatively impact performance (also known as viewer lag). '''''Do not affix reflection probes to small creations such as furniture or decor.''''' Small items such as tables, chairs, musical instruments, candle sticks etc should use the reflection sample volume in the space in which they are placed. They should not have one appended. It is '''strongly''' recommended that any object that contains a reflection sample probe be left as “modify”, so the positioning of the probe can be adjusted or even removed by the owner of the item should they wish.

{{Enote|Reflection probes '''are not''' intended for use with planar mirrors, and will look incorrect when being used to do so. Planar mirrors have been flagged for future work, but are not directly in the scope of the PBR project.}}


== When is it Recommended to Create a Reflection Probe? ==
Manually placed probes are good for cleaning up undesirable noise and lighting from automatically placed probes that may be visually disruptive or confusing. If you look in the image of the room in a house, on the left hand side of it, you can see a blue tint on the floor, which is the reflected blue light from the sky. The probe filling half the room blocks this, and when it is extended to completely fill the room and just slightly beyond the thickness of the walls, (lower copy of the image) the problem is solved. The probe does not need to be a part of the linkset for the rest of the room in order to function; however, once you have them placed it’s possible to add them into linksets like any other prim.

=== Constructing a Reflection Sample Volume ( aka Reflection Probe ) ===
Start off in the Build Menu ''(Ctrl+3)'' by rezzing a basic prim. Under the <code>Features</code> tab, at the bottom check the box labelled <code>Reflection Probe</code>.
[[File:ProbeUI.jpg | thumb | none | Manual Probe Creation UI.]]

* <code>Reflection Probe</code>: Enabling this creates a Reflection Sampling Volume within the bounding box of the prim.
* <code>Box / Sphere Drop-down</code>: Choose whether you want this sample to project reflections within a box shaped volume or a spherical one.
* <code>Dynamic</code>: Allow skinned objects (e.g. Avatars, animesh, etc.) to be captured in the reflection.
* <code>Ambiance</code>: Affects how much objects within the volume are lit as if they have bounced light hitting them from faked indirect illumination. ''See [[PBR_Materials#Fine-Tuning_Reflection_Sample_Volumes|"Fine-Tuning Reflection Sample Volumes"]] for more info.
* <code>Near Clip</code>: Sometimes, there will be a large obstruction in the center of the volume you wish to use as a reflection probe. For example, suppose that there is a large architectural supporting structure in the middle of the room, such as a column. If the probe gets placed internally inside this, it will reflect the internal surface of the column instead of the room in which it is placed. Increasing Near Clip will make the sampling volume exclude objects n meters from the center so they don’t get included in the reflection. ''See [[PBR_Materials#Fine-Tuning_Reflection_Sample_Volumes|"Fine-Tuning Reflection Sample Volumes"]] for more info.

Select an appropriate probe shape for your scene. For example, if you want to create a reflection probe that covers a room, select a <code>Box</code> shape, or for other objects a <code>Sphere</code> shape is recommended.

Move the reflection probe and resize it as necessary to fit your desired purpose. For the room example, resize the box so the probe just touches the walls, ceiling and floor of the room.

Naming your probes is also recommended, so other people ( or yourself later on ) will remember why there’s a large transparent prim in the middle of your build.

If you wish to come back and edit the reflection probe later on, enable both <code>Show Reflection Probe Volumes</code> and <code>Select Reflection Probes</code> under <code>Build > Options</code>.

=== Fine-Tuning Reflection Sample Volumes ===
{{KBwarning|Sample volumes do not react to prim parameter changes. Options such as “Hollow” or “Taper” or “Shear” do not change how the sampling area behaves.}}

That said, it may be helpful to visualize <code>Near Clip</code> as the hollowing out of your reflection sample volume, but the hollow and near-clip are not in any way linked and doing so is purely a convenience. Reflection probe sample volumes only respond to changes in scale and position; however, different probe volumes behave differently when resized.
* <code>Box</code> Probes: These are affected by position and non-uniform scale.
Example: If I create a box reflection probe and scale it to 10m,30m,10m size, the full volume will be affected by the probe.
* <code>Sphere</code> Probes: These are affected by position and '''uniform''' scale only, otherwise the smallest dimension is used.
Example: If I create a spherical probe and scale it to 10m,30m, and 10m size , the probe will sample a 10 meter diameter spherical volume at the center of the probe. However, a 30m,30m,30m sphere will create a sampling volume of a 30 meter diameter sphere.
[[File:SphereProbeErrror.jpg | thumb | none | A diagram of how spherical probes function (or, don't function as you may expect) while non-uniformly-scaled.]]

<code>Reflection Probe Ambiance</code> controls how ambient light (Found in your [[Environmental_Enhancement_Project#EEP_Settings_Objects|environment preset]]) affects, or does not affect, the contents of the reflection probe, and the intensity of indirect lighting (aka Irradiance).
This value is influenced by the <code>Reflection Probe Ambiance</code> value found in the user's [[Environmental_Enhancement_Project#EEP_Settings_Objects|environment preset]], wherein if the Ambiance value given in the [[Environmental_Enhancement_Project#EEP_Settings_Objects|environment preset]] is higher than the value defined by the probe itself, it inherits the ambiance value of the [[Environmental_Enhancement_Project#EEP_Settings_Objects|environment preset]], or alternately if the ambiance value defined by the probe is higher, the probe's value is used.

There are a few operation modes that are set with the <code>Reflection Probe Ambiance</code> value, in tandem with above:
{| class="wikitable"
|+ Probe Ambiance behavior
! Value !! Description
|-
| 0.00 || Ambient color from the environment applies at full intensity. '''Default for pre-PBR skies.'''
|-
| 0.01 .. 0.99 || Blends ambiance with indirect lighting (sun + emissive or illuminated surfaces) within the probe.
|-
| 1.00 || Indirect light applies at full intensity, without ambient color. '''Default for PBR skies.'''
|-
| 1.01 .. 4.00 || Multiplier for indirect light, makes everything brighter within the probe.
|-
| 4.01 .. 100.00 || Multiplier for indirect light, but only further affects light from the sun. (Local lights are capped to 4.)
|}

=== Complex Reflection Probe placement ===

At times, you may wish to place a reflection probe in an area where the reflection probe types (Sphere or Box) do not conform to the shape of the area. For example, a Box probe in a loft room has a triangular shape, which results in "probe bleed" wherein the influence volume affects an area larger than what is needed, and thus bleeds out onto the exterior roof, which is undesirable.

In these cases, you may need to place multiple probes in order to blend together the sample volumes to achieve the desired result. In the loft room example, it's best to start with 3 box probes, which cover the floor, and each side of the roof. Then, use an additional box probe as "fill" to cover the gap inbetween the 3 probes. The main fill probe may need to be rotated at an angle to get the most coverage possible. If it is not possible to fill the gap between the 3 probes with this fill probe, you may wish to add more box probes to act as "secondary fill".

[TODO: Put photo examples of the above here!]

Alternately, Sphere probes may be used to achieve the same result. Sphere probes have considerably softer blending than box probes, so this may give you the best results in severe bleed conditions.

=== Unsupported use-cases ===
{{KBwarning|Do not attempt to do anything listed below. These uses are liable to either intentionally be disabled, or stop working in future updates.}}
You may be tempted to use reflection probes in the following ways, however these use-cases are either intentionally disabled or result in undefined behavior, and may work now but may not in future. '''You have been warned.'''

'''Under any circumstances, you should NOT:'''
* Wear a reflection probe. This intentionally does not work. (Reflection probes are a property of the scene, not an individual object / avatar)
* Attach a reflection probe to a physics-enabled object, e.g. vehicles. This intentionally does not work. (As above, the reflection probes are part of the scene; not part of an individual object. Reflection probes by design do not update in real-time, thus the object would always have incorrect reflections anyway.)

== PBR Material Composition ==
PBR-defined values are measured by optical sensors and other capture tools and recorded in databases. These parameters are then put into commercial software to be used by content creators. Using software designed to create PBR content is always recommended; however, understanding how PBR materials are assembled can assist with editing and compiling them. Having a direct understanding of what each individual color channel contributes is essential for editing PBR textures without relying upon some of the more advanced toolkits available.

All PBR Values are listed from 0 to 1.0, though in an actual image, the values range from 0 - 255.
PBR Materials are composed of a set of four specifically designed textures; they are as follows:

===Base Color [ RGB ] + Transparency [ A ]===
[RGB]: This is the unlit color of the surface. This differs from the “Diffuse” texture that Second Life uses. Diffuse textures often include faked reflection and specular information as well as added Ambient Occlusion shadows. Base Color textures do not get any of this added information. For metals ( as defined by the metalness value ), Base Color also determines specular reflection color, whereas, in non-PBR systems, this is defined by the Specular texture and tint. In certain PBR texturing applications, Base Color is sometimes also referred to as “Albedo”.
 [ A ]: Alpha Channel, dictates the transparency of the entire material overall.

The Base color texture should be devoid of lighting information.

===Occlusion [R] / Roughness [G] / Metalness [B]===
This texture is composed of 3 unrelated grayscale images stored in 3 different color channels of an RGB texture.
 [R]: (Ambient) Occlusion is lighting data, '''removing''' the need to bake down shadows on to the Base Color map. Note that ''white'' (<1,1,1>) means no occlusion is applied, and ''black'' (<0,0,0>) applies full occlusion.
 [G]: Roughness data ranges from 0 to 1.0, but the actual range of physical surfaces ranges from approximately 0.05 to 0.985. No surface is perfectly smooth or completely rough. The rougher a surface is the less mirror-like it behaves.
 [B]: Metalness values are mostly black or white. Either the material is a conductive metal like copper, or it’s a non-metal like fabric. 0.0 is Non-Metallic, 1.0 is Metallic. There are almost no materials with gray metalness values.
 The alpha channel is ignored, as per the [https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#additional-textures glTF 2.0 specification].

{{Enote|The Occlusion map '''is not''' controlled by the "Screen Space Ambient Occlusion" toggle in the Advanced Graphics Settings. '''The Occlusion map is ''always'' enabled.'''}}

===Emissive [ RGB ]===
This determines the amount and the color of unlit (ignores ambient light conditions) areas of your material. When giving an object a white emissive map, the object will act as if the Blinn-Phong "Fullbright" option was checked. This map is useful for items which are expected to emit light, e.g. a table lamp, where the lamp shade would appear to glow when the lamp is turned on. If you wish to toggle the lamp on and off, it's recommended to change the Emissive Tint value to black (functionally disabling the emissive map, thus turning the lamp off), and then changing the tint back to your desired color to turn the lamp back on. Leaving the Emissive slot empty is recommended when it’s unused.

Note that glow (The postprocessing effect), is controlled by a separate parameter in the build floater and is intentionally not part of the PBR material window. Glow is modulated by the emissive map, so black areas of an object's emissive map will not glow, similar to how Blinn-Phong emissive maps and glow work.

As per the [https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#additional-textures glTF 2.0 specification], the alpha channel is ignored.

===Normal [ RGB ]===
The normal maps generated by your baking application / normal map generation toolkit should be compatible with Second Life in most cases. The most common pitfall is using normal maps generated with “inverted” Green channels, such as those that are used for Direct3D and Unreal Engine. Normal texture data redirects light in a different direction based on the vectors indicated by the color, so if the green channel is backward, it’ll seem to be “pointing the wrong way”. To phrase the problem a different way, all the things that should be bumps look like dents, and vice versa. If this occurs, double check that your settings aren’t for Direct3D and try re-generating it. Also, taking it into image editing software and inverting the green channel only sometimes is a sufficient fix.

Normal map tangent spaces are an extremely technical subject that most users need not be concerned with as most modern applications default to the correct setting. However, if your normal maps look drastically different inside Second Life, compared to your source application, and you’ve already confirmed it’s not an inverted green channel, then checking which tangent space settings are being used is the next step. PBR Normals use Mikkelsen Tangent Space. (Often abbreviated MikkT) If you are unsure what this means, use similar workflows and settings for Second Life PBR as those that are generally recommended for the Godot 4 game engine.

As per the [https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#additional-textures glTF 2.0 specification], the blue channel of a normal map is only allowed to contain values above 0.5 to a max of 1 (255).

As per the [https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#additional-textures glTF 2.0 specification], the alpha channel is ignored.

== Material Reference Libraries ==
As PBR is ''Physically Based'', you may wish to know how to recreate a real-life material in PBR form. What color should you use? What metalness value should it have?

Fortunately, reference libraries exist which can tell you how to recreate a given material in a PBR workflow.

=== List of Reference Color Palettes & libraries ===
*'''[https://physicallybased.info/ Physically Based]'''
** Select the ''Godot'' Engine, with the Color Space as ''sRGB Linear'' and Color Representation as ''0-1'' (Depending on what you are doing, you may need to convert the value into gamma-corrected sRGB space, which can be done [https://davengrace.com/dave/cspace/ here.] Enter the value on the 3rd row.)
*'''[https://www.youtube.com/watch?v=TcTh-1X2FsQ Grzegorz Baran Library]'''
**Available on [https://www.youtube.com/watch?v=TcTh-1X2FsQ YouTube (video format, older)], or [https://gbar.gumroad.com/l/cbwkvo PDF (most up-to-date)].
*'''[https://seblagarde.wordpress.com/2014/04/14/dontnod-physically-based-rendering-chart-for-unreal-engine-4/ Dontnod Entertainment Library]'''
** A very small library, but useful nonetheless.
*'''[https://docs.studio-397.com/developers-guide/general-reference/pbr-an-introduction-authoring-guide Studio 397]'''
** A small collection of various materials.
*'''[http://wiki.polycount.com/wiki/PBR Polycount Wiki]'''
** Not so much a library in itself, but links out to other libraries. '''See the Color Charts section'''.

=== List of PBR asset libraries ===
*'''[https://ambientcg.com/ ambientCG]'''
** Provides CC0 licensed HDRi, Metal-Rough materials and .sbar (Substance Painter material) files.
*'''[https://polyhaven.com/ Poly Haven]'''
** Provides CC0 licensed HDRi, Metal-Rough materials and models.

== Uploading Materials ==
There are two different methods of creating PBR material assets:

=== Method 1 : Direct Upload a glTF File ===
The most convenient method to create an entirely new material is to directly upload a glTF file from your computer.

This is accessible via <code>Build > Upload > Material...</code>
[[File:PBRBuildMenu.jpg | thumb | none | PBR Upload in main build menu. ]]

Select a .GLB or a .GLTF file from your computer and Open it:
This will give the following window:
[[File:PBRMatMenu.jpg | thumb | none| The layout of the PBR material creation and editing interface.]]

All of the editable material properties that most creators are familiar with are integrated into the Material's vertically sizable window on upload.

Clicking “Save” pays the upload fees and creates the Material assets using the local filename. Using "Save As..." provides a window to name all the assets to unique inworld names. There is a 63 char limit for names of inventory assets but the naming floater on this Materials upload has no length restrictions.

Textures will be uploaded to the inventory's default Textures folder (NoMod, NoCopy, Transfer) with an appended "type" added to the given name. (ie. asset name (Base Color), asset name (Normal), asset name (Metallic Roughness). In naming the asset keep in mind that the bracketed appendix is included in the name's 63 character limit. The PBR object is uploaded (Mod, NoCopy, Transfer) to the inventory's Material folder with the appended text (Material). Presently, naming the glTF asset from Save As... will NOT append (Material) to the inventory's name. Saving from the locally named file will.

{{KBcaution|Each individual texture used to compose the Material object is charged a separate upload fee. (ie. If you have 4 textures (Base Color, Metallic Roughness, Emissive, Normal) you are charged 4 times. If you only have a Normal and Metallic-Roughness texture you will be charged for 2, etc.)}}

=== Method 2 : Edit a Blank. Create PBR Materials without a glTF File ===
If you have the necessary textures to compose a PBR material but do not have a glTF file you will need to build a Material from inventory. Make sure your textures are in the correct format, with the correct data in the proper channels. This requires some understanding of how [[PBR_Materials#PBR_Material_Composition:|PBR materials work]]. Once you have that, upload your textures as you normally would.

[[File:PBRMenuUI.jpg | thumb | none | The PBR Materials UI in the Build Floater.]]

* Find the "Materials" folder in your inventory, right click, and select "New Material" from the context menu.
* Name your new material something appropriate (E.g. "Red Bricks" for a red brick wall, etc.)
* Right click on your new material, and select "Open" from the context menu.
* Upload your PBR textures using the standard texture workflow (Usually, under <code>Build > Upload > Image</code>).
* In the material window, select the appropriate maps that you just uploaded in their respective slots.
{{KBwarning|While there may be a temptation to try and place a Blinn-Phong “Diffuse” texture into the “Base Color” slot and a Blinn-Phong “Specular" into the “Metallic/Roughness” slot, doing so will not produce desirable results. However, trying this won’t generate any warnings as there is no way to check that you’ve put the right texture type into the inputs, and the material will save and be applicable to objects. '''Unfortunately, what will be created is not a functional PBR material. Please do not do this.'''}}
* Once done, verify the material parameters are correct (E.g. Base color tint, M/R factor, Emissive tint, etc.)
* Save your new material.
* EITHER: [[PBR Materials#Drag_and_Drop|Drag and drop the material onto a rezzed prim]], OR edit the prim, click the "Blinn-Phong" drop-down, select "PBR Metallic-Roughness", and click "Choose from Inventory", and select your new material.



=== Creating Color Variants ===
After you’ve uploaded your first Material for your project, if you’re a store owner who would like to release more than one color palette for your creation, as many clothing and furniture designers find it useful to do, '''it’s important to not upload a new glTF file for every single variant of your Material'''. Most variant materials, only the base color will change. The Occlusion, Roughness, Metalness, Emissive and Normal map texture slots will remain the same. Since these maps have already been uploaded once, if we upload a second glTF File, they will be duplicated. Having different copies of the same texture, with differing UUID’s means that they will clog up download bandwidth and video card memory (not to mention your inventory as well). This is very bad for Second Life. So, for this reason, it’s recommended that when you create texture variants, you upload the additional copies of the base-color texture separately. Then open your newly uploaded material in edit mode, choose the Base Color texture, and change it out for one of your newly uploaded Base Color textures, and click “Save As”. This will create a second copy of your material that uses all the correct texture maps without needlessly duplicating them and causing additional lag.

{{KBtip| You can also avoid uploading additional textures altogether by uploading a white color variant, then making use of the Base Color Tint parameter!}}

== Double Sided Parameter : Uses and Dangers ==
“Double Sided” is a new property unique to Materials. When “Double Sided” is checked, the surface upon which this material is placed will be drawn twice; once for the outward-facing portion of the surface, and a second time for the inward-facing side of the surface that is normally invisible without a double-sided material. This option should only be used for very specific meshes that were designed to be used with double-sided materials, since placing materials with this parameter checked on normal objects will simply cause the viewer to draw it twice ( and thereby create additional viewer lag ) for no observable change. It is '''very strongly recommended''' that this option be unchecked for any material that is to be distributed for general use. Even more so if the “Modify” permission is revoked. If you wish to distribute a version of a material that has “Double Sided” checked, please include a second copy of the material that has “Double Sided” unchecked as well, with an accompanying explanation to the next user as to why this was done.

Example:
*LeafTextures_DoubleSided
*LeafTextures_SingleSided

When designing mesh content for use with the double-sided material parameter, it is also ''very strongly recommended that you separate the triangles you intend to use the double-sided material upon into a separate mesh “face”'', so as to not unintentionally render the portions of the mesh that already have triangles designed to represent the internal portion of the object a second time.

== LSL Scripting ==

Documentation for the LSL interface with glTF materials can be found on the following pages:
*[[GLTF Overrides]]
*[https://wiki.secondlife.com/wiki/Category:LSL_Material Category:LSL Material]

== Recommended Application Settings ==
The glTF file format is widely adopted and many applications have export functionality for this type of file.
Below is a non-comprehensive list of some of the more popular applications that export glTF files.

{{KBtip|'''The recommended HDRi for use in Second Life content creation is available at [https://github.com/Jenna-Huntsman/Second-Life-Resources/tree/main/PBR/HDRi this Github repository].''' This HDRi will closely match the lighting of objects under the PBR "Midday" environment preset.}}

{{KBcaution|While every effort has been made to ensure the recommended HDRi matches SL as close as possible, you may need to adjust the "Environment Exposure" parameter in your editing program to get 1:1 results with SL.}}
 
----
===[https://www.blender.org/ Blender]===

{{KBwarning|Older Blender versions have bugs in their glTF export tools which make their output incompatible with Second Life. '''Use of Blender versions of 3.3 and above are highly recommended to avoid issues.'''}}
 
{{KBcaution|Please ensure that you correctly set up an HDRi in your viewport, as otherwise the rendering in Blender and in SL will not match. Please see [[PBR Materials#Recommended_Application_Settings|here for a reference HDRi]]. '''Please see [https://www.polygonartists.com/hdri-environment-maps-in-blender/ this tutorial].'''}}

Upon starting your project:

Under: <code>Scene > Render Properties > Color Management</code>:
*{{code|View Transform: Standard}}
*{{code|Sequencer: Linear ACEScg}}

Create your materials within Blender using Principled BSDF Shader Nodes and the glTF Settings node. Export them according to the official '''[https://docs.blender.org/manual/en/3.6/addons/import_export/scene_gltf2.html Blender Documentation.]'''

{{KBcaution|Second Life does not support BSDF Clearcoat, Subsurface, Anisotropy or Transmission parameters at this time.}}

For materials creation, 2 example .blend files are provided, one using separate Occlusion, Roughness and Metallic textures ("Long Form"), and one that handles a pre-packed ORM map ("Short Form")

The below files are intended for use with Blender versions 3.3 and above.

* '''[https://github.com/Jenna-Huntsman/Second-Life-Resources/blob/main/glTF%20Node%20Tree%20-%20Long%20Form.blend glTF Node Tree - Long Form.blend]'''
* '''[https://github.com/Jenna-Huntsman/Second-Life-Resources/blob/main/glTF%20Node%20Tree%20-%20Short%20Form.blend glTF Node Tree - Short Form.blend]'''
 
----
=== [https://www.adobe.com/products/substance3d-painter.html Adobe Substance 3D Painter] ===
{{KBcaution|While Substance Painter is generally considered to be stable, in some (rare) situations Substance may output a malformed glTF which will be rejected by the viewer. If this happens, import your materials into Blender, then export a glTF from Blender - this should be fixed in a future version of Substance.}}
 
{{KBcaution|Please ensure that you correctly set up an HDRi in your viewport, as otherwise the rendering in Substance and in SL will not match. Please see [[PBR Materials#Recommended_Application_Settings|here for a reference HDRi]]. Please see [http://y2u.be/6goXJ2CJzaM this tutorial].}}
When starting your project:

*{{code|Template: PBR - Metallic Roughness Alpha-test (starter_assets)}}

OR

*{{code|Template: PBR - Metallic Roughness Alpha-blend (starter_assets)}}

Verify the following settings:
*{{code|Document Resolution: [Set as desired]}}
*{{code|Normal Map Format: OpenGL (Y+)}}
*{{code|Compute Tangents Per Fragment: YES}}

Under "Color Management":
{{KBtip| For a more in-depth explanation of the below settings, and issues that you may encounter, visit [https://mrlixm.github.io/blog/substance-painter-color-management/#aces-workflow this page].}}
*{{code|Color Management: OpenColorIO}}
*{{code|OpenColorIO Configuration: ACES 1.0.3}}
*{{code|Standard sRGB color space: Utility - sRGB - Texture}}
*{{code|8 bit images: Utility - sRGB - Texture}}
*{{code|16 bit images: Utility - sRGB - Texture}}
*{{code|Material color space default: Utility - sRGB - Texture}}

When exporting:

Settings Tab - Global Settings
*{{code|Output template: glTF PBR Metal Roughness}}
*{{code|Size: Based on each Texture Set's size}}
*{{code|Padding: Dilation + default background color - 8 bit}} '''OR''' {{code|Padding: Dilation infinite}}
{{KBtip|If you encounter color banding (AKA posterization) in your base color texture after export, you may wish to enable dithering.}}
*To enable dithering, open the {{code|Export Textures}} window, under the {{code|Settings}} tab, enable an override for the Base Color texture and swap the output format from {{code|8 bits}} to {{code|8 bits + dithering}}

Settings Tab - Per-Material settings
*{{code|Output maps > Normal Map: 8 bits}}

<li style="display: inline-block;">[[File:Substance_Painter_-_Export_Global_settings.png|thumb|Settings Tab - Global Settings]]</li>
<li style="display: inline-block;">[[File:Substance_Painter_-_Export_Per-Material_settings.png|thumb|Settings Tab - Per-Material settings]]</li>
 
----
=== [https://www.adobe.com/products/substance3d-designer.html Adobe Substance 3D Designer] ===
{{KBcaution|Substance Designer ''does not support glTF output'', unlike Substance Painter.}}

Under preferences, verify the following '''Project''' settings:
*{{code|Color Management: OpenColorIO}}
*{{code|OpenColorIO Configuration: ACES 1.0.3}}
*{{code|8 bit images: Utility - sRGB - Texture}}
*{{code|16 bit images: Utility - sRGB - Texture}}
*{{code|Floating point images: ACES - ACEScg}}
*{{code|2D and 3D View Display Default: sRGB}}

When exporting (Export Outputs):
*{{code|basecolor: Utility - sRGB - Texture}}
*{{code|normal: Utility - Raw}}
*{{code|roughness: Utility - Raw}}
*{{code|metallic: Utility - Raw}}
*{{code|ambientocclusion: Utility - Raw}}

If you use a custom node to output a [[PBR_Materials#Occlusion_.5BR.5D_.2F_Roughness_.5BG.5D_.2F_Metalness_.5BB.5D|pre-compiled ORM map]], this should also be set to Raw.
 
----
=== [https://www.maxon.net/en/cinema-4d Cinema 4D] ===
Please follow the documentation provided in this [https://www.bakedpixels.nl/blog/export-to-gltf-with-cinema-4d blog post].
 
----
===[https://3dcoat.com/ 3DCoat]===
{{KBwarning|As of version "2022-58", 3DCoat is unable to produce a spec-compliant glTF file, and thus should not be used for Second Life. '''Use at your own risk - you ''will'' have issues!}}

glTF export has been implemented since 3DCoat version 2020 and is found in the <code>File >Export > Export to glTF > glTF Separate (gltf + .bin + textures)</code>
 
----
=== [https://quixel.com/mixer Quixel Mixer] ===
Quixel Mixer has no glTF output, however, it does generate the functional textures, though they do need to be edited and combined in photo editing software.
Export them by going to <code>Export Target > Custom</code>

Texture Preset: Metalness Maps

Select:

Albedo , Roughness, Normal, AO , Metalness and ( if need be ) Emissive.

Click “Export to Disk” and open the folder that the files were placed into.

Albedo is the Base Color texture in this case.

AO , Roughness , Metalness get combined into the ORM map as per [[PBR_Materials#PBR_Material_Composition|this explanation.]]

Normal Map : Quixel generates Direct3D Normal Maps. The green channel needs to be inverted as [[PBR_Materials#Normal_.5B_RGB_.5D_|per here.]]

Upload to Second Life using [[PBR_Materials#Method_2_:_Edit_a_Blank._Create_PBR_Materials_without_a_GLTF_File|Method 2.]]
 
----
=== [https://www.autodesk.eu/products/3ds-max/overview Autodesk 3DS Max 2023] ===
Autodesk just added the ability to create glTF files using their new glTF Material and glTF Export functionalities as outlined in '''[https://help.autodesk.com/view/3DSMAX/2023/ENU/?guid=GUID-EFBB037D-C4EB-42D2-9CE1-30FCAD483C31 Autodesk's official documentation]'''. All prior versions of Autodesk software do not have this functionality.
 
----
=== [https://www.materialmaker.org/ Material Maker] ===
While [https://www.materialmaker.org/ Material Maker] does not currently export directly to glTF ([https://github.com/RodZill4/material-maker/issues/479 This may be added in future]), materials created with this program are compatible with Second Life.

Export your materials using the '''Godot 4 ORM''' export preset.

Upload to Second Life using [[PBR_Materials#Method_2_:_Edit_a_Blank._Create_PBR_Materials_without_a_GLTF_File|Method 2.]]
 
----
=== Adobe Photoshop ===
'''While Photoshop is not officially a PBR authoring tool''', the changes to Alpha Blending (changing into Linear space from sRGB) may require you to change your PS settings to get consistent results. Please see [http://www.kiransprojects.com/blog/2014/photoshop-blending-is-broken/ this article] for more information. (See the section titled "A Partial Solution"). Alternatively, [https://www.reddit.com/r/photoshop/comments/61clf8/how_to_fix_photoshops_incorrect_and_ugly_color/ this Reddit post] also gives a few options on how to achieve blending in the correct manner.
 
----
=== GIMP ===
'''While GIMP is not officially a PBR authoring tool''', the changes to Alpha Blending (changing into Linear space from sRGB) in Second Life will make textures created in GIMP display their alphas correctly (GIMP defaults to linear alpha calculation).

== Troubleshooting content ==

If you upload a piece of PBR content which does not match your editor, the advice from Linden Lab is to '''STOP: File a Feedback ticket. Do not attempt to "fix" the content.'''

That said, there are some troubleshooting steps which you can do yourself:
* Check that you are using the PBR Linden Midday preset (called "Midday") ''not "Midday (Legacy)"''. Other environments may not match the reference HDRi, causing some visual differences. (This is intended behaviour, and content should be able to be viewed under any light correctly, but for troubleshooting purposes this may be required).
** At present, there is a bug with the PBR Linden Midday preset which results in an excessive blue sheen, due to the use of an over-saturated (unrealistic) sky color, among some other issues. This has been fixed in the upcoming glTF Maintenance viewer.
* Are you using a reflection probe? If not, does the problem reproduce if a manual reflection probe is placed over the object?
** This is because a common source of the "blue sheen" in interior scenes is the use of an auto-probe. Auto-probes sample their surroundings, and combined with the approximate (and often incorrect) placement this will mean the sky is sampled on all sides, thus meaning the reflected light from the surroundings (which counters the blue light from the sky) is absent, leading to a larger-than-expected level of sky contribution on the object. Auto-probe placement can be worse in skyboxes or sky platforms
* Triple-check the settings used for your editor match the ones given [[PBR_Materials#Recommended_Application_Settings|here]], including the reference HDRi. '''Any''' deviation from these settings may cause visual differences between your editor and in-world.
* Check your content against a glTF reference viewer; such as:
** [https://modelviewer.dev/editor/ Modelviewer.dev]
** [https://github.khronos.org/glTF-Sample-Viewer-Release/ Khronos Sample Viewer]

If the above steps fail, then please '''[https://feedback.secondlife.com/ file some Feedback.]'''

A good Feedback ticket will include:
* An LM to a location where the problem can be examined in-world.
* A copy of the glTF content, attached to the ticket.
* Screenshots of the representation in-world, in a reference viewer, and in-editor.
** You should include screenshots of the object inside a manually placed reflection probe, and outside.

Lua Alpha

2026-03-02T19:46:08Z

Wulfie Reanimator: /* Second Life Lua (SLua) Alpha */

{{Warning|This functionality is in alpha. Instability is to be expected, and there may be very sharp edges. At this point it is expected that Luau can crash regions and perform other types of undesirable behavior.

'''🚨 PLEASE NOTE Memory and performance characteristics, and API specifics may change! Scripts are currently being run in unoptimized form for development purposes.'''}}

= Second Life Lua (SLua) Alpha =

[[File:Luau.png|720px|thumb|right|Luau logo]]

We're thrilled to announce the launch of the SLua Alpha* for Second Life! This significant update introduces the [https://lua.org Lua scripting language], offering creators enhanced performance, improved memory efficiency, higher memory limit (128 KB), and a more versatile scripting environment.

To get started, [[Try SLua|read the instructions here.]]

Slua has entered its Beta phase in December 2025. It's available in parts of the main grid! See below for a list of SLua regions.

== What is SLua? ==

SLua is scripting for Second Life based on [https://luau.org Luau], a fast, small, safe, and gradually typed embeddable scripting language derived from Lua. It is designed to be backwards compatible with Lua 5.1, incorporating features from future Lua releases and expanding the feature set with type annotations and a state-of-the-art type inference system. Luau is largely implemented from scratch, with the language runtime being a heavily modified version of the Lua 5.1 runtime, featuring a completely rewritten interpreter and other performance innovations.

== Why Lua? ==

The decision to integrate Lua into Second Life was driven by its ability to meet all the requirements for a scripting engine within the platform. Lua offers a high-quality scripting experience to creators, addressing many of the limitations present in the current LSL (Linden Scripting Language) environment. Its lightweight nature and performance optimizations make it an ideal choice for enhancing the scripting capabilities in Second Life. For more information on why Lua was chosen, please see the [[Lua FAQ]].

== How to Get Started with SLua ==

In order to play with SLua, you'll need to download our Lua project viewer, and either log onto our [https://lindenlab.freshdesk.com/support/solutions/articles/31000156725-accessing-aditi Aditi beta grid] or go to the SLua-enabled beta regions on the main grid.

* Access the latest build of the SLua-enabled Second Life Viewer from [https://releasenotes.secondlife.com/viewer.html here].

SLua-enabled regions on the main grid:
* [secondlife:///secondlife/SLua%20Beta%20Landing/128/128/2 SLua Beta Landing]
* [secondlife:///secondlife/SLua%20Beta%20Porridge/128/128/2 SLua Beta Porridge]
* [secondlife:///secondlife/SLua%20Beta%20Eraserhead/128/128/2 SLua Beta Eraserhead]
* [secondlife:///secondlife/SLua%20Beta%20Glass/128/128/2 SLua Beta Glass]
* [secondlife:///secondlife/SLua%20Beta%20Void/128/128/2 SLua Beta Void]
* [secondlife:///secondlife/SLua%20Beta%20Anderson/128/128/2 SLua Beta Anderson]
* [secondlife:///secondlife/SLua%20Beta%20Snausage/128/128/2 SLua Beta Snausage (Adult)]
* [secondlife:///secondlife/SLua%20Beta%20Nicolse/128/128/2 SLua Beta Nicolse]
* [secondlife:///secondlife/SLua%20Beta%20IsNeat/128/128/2 SLua Beta IsNeat]

SLua-enabled regions on the beta grid:
* [secondlife://Aditi/secondlife/SLua%20Yardang/241/235/27 SLua Yardang]
* [secondlife://Aditi/secondlife/SLua%20Tombolo/241/235/27 SLua Tombolo]
* [secondlife://Aditi/secondlife/SLua%20Mesa/241/235/27 SLua Mesa]
* [secondlife://Aditi/secondlife/SLua%20Tideland/241/235/27 SLua Tideland]

When editing a script in the new Lua project viewer, you'll notice a new '''Compiler''' drop-down near the save button. This drop-down will allow you to select which compiler will be used, as well as which script runtime will be used (LSO2, Mono, Luau).

[[File:Compiler_dropdown.png|Compiler selection dropdown]]

Compiler drop-down options:

* '''LSL: Legacy (LSO2)''' - Scripts written in LSL, to be run on the old LSO2 VM
* '''LSL: Mono'''- Scripts written in LSL, to be run on the Mono VM
* '''Lua''' - Scripts written in Lua, to be run on the SLua VM
* '''LSL: 2025 VM'''- Scripts written in LSL, to be run on the SLua VM

=== Transitioning from LSL to SLua ===
* '''Function Namespacing:'''
** In SLua, Linden Lab functions have been moved under the '''ll''' namespace.
** For example:
*** ''llSay'' becomes ''ll.Say''
*** ''llGetPos'' becomes ''ll.GetPos''
* '''Lists'''
** Lua indexes begin from 1, unlike LSL where indexes begin from 0.
** Lua uses <syntaxhighlight lang="lua" inline>{}</syntaxhighlight> for ''tables'', unlike LSL where <syntaxhighlight lang="lua" inline>[]</syntaxhighlight> is used for ''lists''.
* Types
** SLua doesn't support the usual vector/rotation syntax <syntaxhighlight lang="lua" inline><x, y, z></syntaxhighlight>
*** Instead, these values are created with the functions <syntaxhighlight lang="lua" inline>vector(x, y, z)</syntaxhighlight>, <syntaxhighlight lang="lua" inline>rotation(x, y, z, s)</syntaxhighlight>
*** Similar functions exist for '''uuid''' (key) and '''integer''' (distinct from the built-in '''number''' type)

=== SLua Libraries ===
* '''Coroutines:'''
** SLua supports coroutines, allowing for cooperative multitasking within scripts.
** Key functions include:
*** ''coroutine.create''
*** ''coroutine.status''
*** ''coroutine.resume''
** Refer to the [https://luau.org/library#coroutine-library coroutine library documentation] for more details.
* '''Bitwise Operations:'''
** SLua includes a ''bit32'' library for bitwise operations, enabling more efficient data manipulation.
** Refer to the [https://luau.org/library#bit32-library bit32 library documentation] for more details.
* '''JSON to Table Translation:'''
** SLua includes a modified [https://github.com/openresty/lua-cjson lua-cjson library] that translates tables into JSON objects and arrays and back.
** Vectors and quaternions are converted to strings, which may be changed back using the ''tovector'' and ''toquaternion'' functions, respectfully.
** Buffers are encoded as Base64 strings. They may be decoded using the ''llbase64.decode'' function.
** Functions:
*** <syntaxhighlight lang="lua" inline>json_text = lljson.encode(some_table)</syntaxhighlight>
*** <syntaxhighlight lang="lua" inline>some_table = lljson.decode(json_text)</syntaxhighlight>
* '''Base64 Encoding:'''
** A Base64 library capable of handling SLua strings and binary buffers, unlike classic ''ll'' namespace functions.
** Leveraged by the JSON functionality, but can also be called separately.
** Functions:
*** <syntaxhighlight lang="lua" inline>base64string = llbase64.encode(string_or_buffer)</syntaxhighlight>
*** <syntaxhighlight lang="lua" inline>str = llbase64.decode(base64string)</syntaxhighlight> for strings
*** <syntaxhighlight lang="lua" inline>buf = llbase64.decode(base64string, true)</syntaxhighlight> for buffers
* '''Standard Library:'''
** SLua comes equipped with a standard library of functions designed to manipulate built-in data types.
** Explore the [https://luau.org/library Luau Standard Library] for a comprehensive list of available functions.

== Feedback and Support ==

We encourage all creators to explore the new scripting capabilities and provide feedback. Your insights are invaluable in refining and enhancing this feature. For more information and to share your experiences, please refer to our [[Lua FAQ]].

== Example Scripts ==

To help you get started, we've assembled some example scripts that demonstrate the capabilities of SLua. These scripts cover various functionalities and can serve as a foundation for your own creations. Please feel free to propose changes to these scripts, or modify them to your heart's desire!

=== default_script.lua ===
This script is roughly equivalent to the default "new script" that gets created for LSL.
<syntaxhighlight lang="lua">
function state_entry()
ll.Say(0, "Hello, Avatar!")
end

LLEvents:on("touch_start", function(detected: {DetectedEvent})
ll.Say(0, "Touched.")
end)

-- Simulate the state_entry event
state_entry()
</syntaxhighlight>

=== dialog.lua ===
This script demonstrates how one can interact with dialog menus.
<syntaxhighlight lang="lua">
-- Define the menu buttons and dialog message.
local buttons = {"-", "Red", "Green", "Yellow"}
local dialogInfo = "\nPlease make a choice."

local ToucherID = nil
local dialogChannel = nil
local listenHandle = nil
local timerHandle = nil

-- This function is called when the script first starts.
function state_entry()
-- Get the object's key and compute a dialog channel number.
local key = ll.GetKey()
-- Extract the last 7 characters of the key and convert it from hex.
dialogChannel = -1 - tonumber(string.sub(tostring(key), -7, -1), 16)
end

-- Called when the object is touched.
LLEvents:on("touch_start", function(detected: {DetectedEvent})
ToucherID = detected[1]:getKey()
-- If there is already a listen handle, then remove it
if listenHandle then
ll.ListenRemove(listenHandle)
end
listenHandle = ll.Listen(dialogChannel, "", ToucherID, "")
ll.Dialog(ToucherID, dialogInfo, buttons, dialogChannel)
-- Set a 60-second timer for response.
if timerHandle then
LLTimers:off(timerHandle)
end
timerHandle = LLTimers:once(60,timeoutListen)
end)

-- Called when a dialog response is received.
LLEvents:on("listen", function(channel, name, sender_id, message)
if message == "-" then
-- Redisplay the dialog if the "-" option is selected.
ll.Dialog(ToucherID, dialogInfo, buttons, dialogChannel)
return
end
-- Stop the timer, and stop the listening handler.
ll.ListenRemove(listenHandle)
listenHandle = nil
if timerHandle then
LLTimers:off(timerHandle)
end
-- Let the user know what they selected
ll.Say(0, `You selected {message}`)
end)

-- Called when the timer expires.
function timeoutListen()
-- Stop the timer and clean up the listener.
if listenHandle then
ll.ListenRemove(listenHandle)
ll.Whisper(0, "Sorry. You snooze; you lose.")
end
end

-- Invoke state_entry on startup, since simulator doesn't invoke
-- it like it does in LSL
state_entry()
</syntaxhighlight>

=== user_input_coroutine.lua ===
This script demonstrates [https://www.lua.org/pil/9.html coroutines] and how they can simplify the overarching logic of a script, enabling us to write the bulk of our multi-event code within a centralized function instead of fragmenting across separate event handlers.
<syntaxhighlight lang="lua">
-- Wait for user input mid-function before doing something useful with it.
main = function(toucher)
local handle = ll.Listen(0, "", toucher, "")
local event = touch_start -- save function for later
touch_start = nil -- disable touch_start

ll.RegionSayTo(toucher, 0, "Do you want pants or gloves?")
local clothing = coroutine.yield() -- pause the routine's execution here
ll.RegionSayTo(toucher, 0, "For men or women?")
local gender = coroutine.yield()
ll.RegionSayTo(toucher, 0, "Favorite color?")
local color = coroutine.yield()
ll.RegionSayTo(toucher, 0, "Here's "..color.." "..clothing.." for "..gender)

ll.ListenRemove(handle)
touch_start = event -- restore touch_start
end

LLEvents:on("touch_start",function(detected: {DetectedEvent})
local toucher = detected[1]:getKey()
routine = coroutine.create(main) -- new coroutine
coroutine.resume(routine, toucher) -- run coroutine (with one argument)
end)

-- When the coroutine is suspended, incoming events can be handled
-- and we can resume() execution of the routine
-- and pass any number of arguments to be returned by yield()
LLEvents:on("listen", function(channel, name, id, message)
coroutine.resume(routine, message)
end)
</syntaxhighlight>

=== multi_user_input_coroutine.lua ===
Following from the above example, how can we handle multiple users? This is where coroutines shine.

Instead of disabling touches to prevent others from interacting with the object, we can create new copies of the coroutine each time an avatar touches the object. We can then resume whichever coroutine is needed, based on the avatar, while all of them track their own progress separately and automagically.
<syntaxhighlight lang="lua">
-- Key: avatar uuid; Value: coroutine thread
routines = {}

main = function(toucher)
local handle = ll.Listen(0, "", toucher, "")

ll.RegionSayTo(toucher, 0, "Do you want pants or gloves?")
local clothing = coroutine.yield()
ll.RegionSayTo(toucher, 0, "For men or women?")
local gender = coroutine.yield()
ll.RegionSayTo(toucher, 0, "Favorite color?")
local color = coroutine.yield()
ll.RegionSayTo(toucher, 0, "Here's "..color.." "..clothing.." for "..gender)

ll.ListenRemove(handle)
routines[toucher] = nil -- Remove from collection
end

LLEvents:on("touch_start",function(detected: {DetectedEvent})
local toucher = detected[1]:getKey()
local routine = routines[toucher]
if not routine then -- New user needs new routine
routine = coroutine.create(main)
routines[toucher] = routine -- Add to collection
coroutine.resume(routine, toucher)
end
end)

LLEvents:on("listen", function(channel, name, id, message)
coroutine.resume(routines[id], message) -- Resume a specific coroutine
end)
</syntaxhighlight>

=== More Examples ===

* Find more example scripts at [[Luau Example Scripts]]

* [https://roblox.github.io/lua-style-guide/gotchas/ Lua Gotchas, Footguns and Other Hazards]

[[Category:Lua]]

PBR Materials

2026-03-01T08:26:35Z

Wulfie Reanimator: Small rewrite of the introduction.. hopefully less dense, more practical /* What is it and Why is it used? */

{{multi-lang|1=PBR_Materials|2=/en}}
'''Physically Based Rendering'''

{{note|1=This page is being actively updated with new content and links as GLTF PBR Materials and related new features are being released. Contributions to this page may be from Second Life residents and staff members alike.}}

[[Category:glTF]]

== What is it and Why is it used? ==

The term “Physically Based Rendering” or “PBR” is a technical term for composing images in computer software. It refers to a collection of complex mathematical algorithms that attempt to ''accurately represent the ways that light interacts with objects in the real world.'' In other words, focus is put on the real physical properties of materials.

In the real world, light's unique behavior against metal is how the human eye can recognize "that object is made of metal" without us actually reaching out and touching it. The way a metal reflects light differs from that of a polished plastic or some other material, and these differences have been quantified by science.

Older techniques, such as the existing Blinn-Phong reflection model in Second Life, are more naive approximations of light that lack many nuances (eg. conductivity, microsurfaces, fresnel, energy conservation) that are now possible to simulate in real time.

==== How it applies to Second Life ====
By mimicking real-world physics principles in the virtual world it allows for the creation of more immersive recognizable realistic spaces, but also it helps us relate to fantastical worlds a little better too. While we may not be familiar with what a newly imagined creation is, a metal's inherent metal-ness and aged wood's inherent wood-ness remain constant, making it easier to intuitively understand what we are interacting with in a virtual environment.

Because tying the mathematics to simulate materials in virtual spaces to how they behave in the real-world makes things more immediately recognizable, PBR has become the foundation for creating imagined worlds over the last decade. The metallic shine of exoskeletal armor in superhero movies is driven by a PBR workflow, as is the plastic sheen of toys or the glint of frozen ice in animated classics. Now we are moving to bring this standardized quality to your home in Second Life.

Bringing PBR to Second Life means updating the basic calculations of how light is represented and interacts with the world of Second Life. The goal is to integrate these changes while minimally changing how everything that presently exists in Second Life (designed prior to the introduction of PBR) looks. While the preservation of creative intent and the aesthetic appeal of items users have enjoyed for over two decades of Second Life is always a priority, Second Life is an ever-evolving platform, and to continue to do so, some changes are inevitable.

Lastly, while we are attempting to mimic real-world reflections and material properties, Second Life has to run on a wide variety of devices, so some shortcuts have to be made. Reflections are not mirror-perfect, as has often been a long-standing hope and request from Residents. While the addition of a reflection system does bring dreams of distortion free mirrors for our avatars in Second Life closer to reality, unfortunately, due to the calculation requirements of doing perfect reflections, mirrors are sadly still, for the moment, not practical. Please see the note in the [[#Understanding_and_Assisting_the_New_Reflections_System|section below]] for more info.

== What does this mean for Residents? ==
[[File:PrePostPBR.png | thumb | right | The lamp in this screenshot uses [[PBR_Materials#Nomenclature_changes|Blinn-Phong]] (Classic SL Materials), and was created before PBR's integration into SL; and demonstrates some of the visual differences to existing content. The environment used for the screenshot is the viewer's default Midday preset (Note that the PBR viewer has a new Midday preset).
]]
=== Changes to Existing Content ===
The largest change by far is the addition of an environmental reflection system to Second Life. For most existing items, this change shouldn’t have a drastic immediately observable impact. A few things in your inventory that you already own may appear more reflective with the new graphics configuration and those reflections should feel more realistic and immersive with your current environment. As a general rule: the “shinier” an object was before, the more environment reflections it will pick up and the more visual difference there will be.

Another notable change is the addition of [https://en.wikipedia.org/wiki/Tone_mapping tonemapping] to the viewer. Tonemapping is a way of representing an image with a higher native dynamic range than the display can support. Tonemapping is a de-facto requirement of PBR pipelines. This means that colors in Second Life will generally appear more saturated with less detail being lost in shadows and highlights. [https://modelviewer.dev/examples/color.html Click here for some additional reading on the subject.]

The tonemapping method used is called '''Academy Color Encoding System ('''aka '''"ACES")''', and can be read about [https://www.oscars.org/science-technology/sci-tech-projects/aces here] and [https://docs.nvidia.com/gameworks/index.html#devices/shield-hdr-dev-guide/hdr-dev-guide-nvidia-shield.htm here].

[[PBR_Materials#Nomenclature_changes|Blinn-Phong]] content making use of the Specular parameters may look different if the items were never viewed under local lights, as the PBR viewer allows for the environment (sun ''and'' sky) to contribute to specular reflections. As such, if the object receives blue specular reflections from the sky, these reflections are tinted, and may look odd. This effect is the same as prior viewers, as if the object was lit by a blue local light.

=== Removal of Advanced Lighting Model ( ALM ) Graphics Option ===
There have been changes to the '''Graphics > Advanced Settings...''' Preferences. The most notable of which is the removal of the “Atmospheric Shaders”, "Local lights" and “Advanced Lighting Model” options.

For those users on lower-end hardware who depended heavily upon those options to navigate Second Life with an acceptable framerate, we recommend the following settings:
*{{code|Transparent Water: Disabled}}
*{{code|Screen Space Ambient Occlusion: Disabled}}
*{{code|Shadows: None}}
*{{code|Screen Space Reflections: Disabled}}
*{{code|Reflection Detail: Static Only}}
*{{code|Reflection Coverage: Manual only}}

The {{code|Local Lights}} setting has been superceded by updates made to the '''World > Improve graphics speed...''' "Quality & Speed" slider options. Users on low-end hardware should ensure that their "Quality & Speed" slider is set at an appropriate level for their hardware.

== What does this mean for Creators? ==
=== Nomenclature changes ===
The PBR project represents a large step towards integrating standard rendering techniques used in the games industry. As such, the nomenclature of some items has changed, notably, what was once called '''[[:Category:Materials|Materials]]''' is now referred to as '''Blinn-Phong'''. This does not represent any changes to the underlying rendering techniques (beyond those mentioned above); and as such Blinn-Phong ''is not'' the same as PBR Spec/Gloss workflows, seen in some game engines such as Unity.

=== Importing PBR Materials from External Software: ===
For creators who work with external tools such as Blender, Adobe Substance Painter, Cinema4D, 3D-Coat, or have used the Unreal or Godot game engines, the use of PBR texture sets should already be familiar. In fact, some creators have been using tools that use PBR workflows to create content for Second Life and have then been forced to sacrifice visual quality to convert that information into Second Life’s existing Blinn-Phong materials system.

Second Life is adopting the “Metallic/Roughness” PBR model, and in its ongoing commitment to using Open Source standards whenever it is practical to do so, the glTF 2.0 file format has been chosen as the upload format for PBR Material assets. One of the primary goals of implementing PBR Materials is to have more continuity from content creation applications towards Second Life, and have more consistent content behavior once it’s inworld.

=== Using Imported Materials in Second Life ===
[[File:Editing_Material.jpg|thumb|right|Material Editing]]
For people who build exclusively within Second Life, the addition of PBR also means that there will be a new [[LlGetInventoryType|Inventory Type]] called “Material”. These new Materials can be purchased on the Marketplace and are shareable like any other permitted object in Second Life.

PBR materials come as a bundle of textures. These all travel as a single unit and are applied all at once. If you wish to change tint, transparency, or other similar parameters of the Material you’ll need to modify the Material from the "Editing Material" floater.

{{KBcaution|Meshes uploaded after the PBR release will look slightly different (and more accurate to your editor of choice) due to a change in the way Second Life handles mesh assets (Previously, some data required for accurate tangent generation was discarded at upload time - this is no longer the case). This will mean that a PBR material applied to a mesh uploaded before PBR launched (28th November 2023) might look incorrect; a simple reupload of the mesh will solve this. '''This is not required, but recommended.'''}}

Applying existing materials works similarly to existing textures. You have two means of doing so:

==== Drag and Drop ====
Simply drag and drop onto the face of a prim or a mesh. For example, if you have a tiled floor material and you place it on a selected prim cube face that face will now look like a tile floor and reflect light like a tiled floor would with all the material qualities contained in the material.
[[File:DragAndDrop_Mat_Wiki.png | thumb | none | Drag and Drop Functionality.]]

==== Switch to PBR and select from Inventory ====
Alternatively, select a face on the prim or mesh you want to apply your material to and choose the “Blinn-Phong” drop-down and change it to “PBR Metallic Roughness”, then select “Choose an item from your inventory” and apply.
[[File:PBRSelectorV3.png |left| thumb | none | Menu drop-down demonstration.]][[File:Material_Dropdown.jpg|thumb|none|Dropdown as of v7.0.1.689]]

 

==== Texture Transforms ====
With PBR materials, texture transforms work in a slightly different way to Blinn-Phong transforms. Blinn-Phong (and OpenGL) has the texture origin in the lower left corner of the texture, whereas glTF materials (and Vulkan) has the texture origin in the upper left corner.

This means that PBR materials will react differently (namely, they are inverted in the Y (glTF v) axis) to Blinn-Phong materials.
For a simple solution to convert a Blinn-Phong texture transform to a PBR texture transform, please see [https://community.secondlife.com/forums/topic/507448-lsl-math-for-gltf-transformation/?do=findComment&comment=2678959 this forum thread].

For more information, [https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#images see here] and [https://github.com/KhronosGroup/glTF/tree/main/extensions/2.0/Khronos/KHR_texture_transform here].

=== Media-on-a-Prim ===
Media on a prim will continue to work largely as it has done prior to PBR's launch.

When using MOAP on a face with a PBR texture, it will function as if the media texture has an override to the '''Base Color''' and '''Emissive''' maps. Note that the emissive map is overridden, however the emissive tint is not (so, to disable the emissive map you can set the emissive tint to black <0,0,0>).

== Tools & Tutorials ==
As the PBR system is new, it is expected that existing users may be confused at first on how everything works. As such, Linden Lab and some third parties have provided some tutorials and informational videos:

*'''[https://www.youtube.com/watch?v=JtjGf06B8ZA Second Life University - PBR Materials]'''
*'''[https://www.youtube.com/watch?v=BJ1eRTlWDYk Second Life University - How to create PBR Materials]'''
*'''[https://substance3d.adobe.com/tutorials/courses/pbrguide Allegorithmic (Adobe) PBR Guide]'''

The above tutorials require knowledge and access to Adobe's Substance Painter (subscription based software on Adobe website, or sold as perpetual license with one year of updates on Steam). Below are some open source tools and links found Googling 'Blender', 'glTF' (requiring Blender 3.3)
*'''[https://www.khronos.org/blog/art-pipeline-for-gltf Khronos Art Pipeline tutorial]'''
*'''[https://materialmaker.org Material Maker software]'''
*'''[https://aiaicapta.in/gltf-packer/ glTF Packer software]'''
*'''[https://armorpaint.org Armorpaint software]'''
*'''[https://armorlab.org Armorlab software]'''
*'''[https://youtu.be/KTPdNUGwIGc glTF Blender Tutorial]'''
*'''[https://youtu.be/p7OPRoT6FkY Exporting glTF Alpha Textures tutorial]'''

== PBR Stand-In Textures and Outdated Viewers ==
It is worth mentioning that during the adoption period of a new system, a substantial portion of Second Life Residents view the world through third party viewers and mobile viewer solutions that will not have updated to be able to see the new content. Anyone viewing a PBR Material on a viewer that cannot display it will see the “underlying” non-PBR texture. By default, this is a pine box or a completely blank texture. Those who wish their content to be viewable by as many people as possible, might consider creating a Diffuse texture ( with baked lighting, the kind that is easily generated with tools like Substance Painter's “Baked Lighting Filter” ) and applying it as a regular texture to the object they’re placing the PBR material on, prior to applying the PBR material. While this is an extra step in content creation, and complicates things somewhat, if you wish for your content to be appreciated by all, it’s worth considering adding this extra step to your workflow. People designing PBR materials for distribution and sale might also consider offering a “Diffuse Only fallback” texture to accompany the PBR material specifically for people who cannot see the PBR content.

{{KBcaution|Once a PBR Material is applied, the Blinn-Phong textures cannot be updated. To remedy this, remove the PBR Material, then make changes to the Blinn-Phong textures and then reapply the PBR Material.}}

== Understanding and Assisting the New Reflections System ==
Those creators that work at house-scale, or produce items that can be walked through, can gain additional control over the lighting in their creations by taking the time to fully understand the new toolkit that influences environmental reflections. There is a new type of volume that can be created and appended to object linksets specifically for scenes with these kinds of spaces. These volumes define a custom area where reflections are calculated, overriding the default solution. So-called “Reflection Probes” should be placed in a manner such that ''the fewest number of probes fills the largest amount of space possible with minimal overlap''. One probe per room is a good reference point for a general living space like a house. If multiple probes exist in a given area they can cause visual artifacts and negatively impact performance (also known as viewer lag). '''''Do not affix reflection probes to small creations such as furniture or decor.''''' Small items such as tables, chairs, musical instruments, candle sticks etc should use the reflection sample volume in the space in which they are placed. They should not have one appended. It is '''strongly''' recommended that any object that contains a reflection sample probe be left as “modify”, so the positioning of the probe can be adjusted or even removed by the owner of the item should they wish.

{{Enote|Reflection probes '''are not''' intended for use with planar mirrors, and will look incorrect when being used to do so. Planar mirrors have been flagged for future work, but are not directly in the scope of the PBR project.}}


== When is it Recommended to Create a Reflection Probe? ==
Manually placed probes are good for cleaning up undesirable noise and lighting from automatically placed probes that may be visually disruptive or confusing. If you look in the image of the room in a house, on the left hand side of it, you can see a blue tint on the floor, which is the reflected blue light from the sky. The probe filling half the room blocks this, and when it is extended to completely fill the room and just slightly beyond the thickness of the walls, (lower copy of the image) the problem is solved. The probe does not need to be a part of the linkset for the rest of the room in order to function; however, once you have them placed it’s possible to add them into linksets like any other prim.

=== Constructing a Reflection Sample Volume ( aka Reflection Probe ) ===
Start off in the Build Menu ''(Ctrl+3)'' by rezzing a basic prim. Under the <code>Features</code> tab, at the bottom check the box labelled <code>Reflection Probe</code>.
[[File:ProbeUI.jpg | thumb | none | Manual Probe Creation UI.]]

* <code>Reflection Probe</code>: Enabling this creates a Reflection Sampling Volume within the bounding box of the prim.
* <code>Box / Sphere Drop-down</code>: Choose whether you want this sample to project reflections within a box shaped volume or a spherical one.
* <code>Dynamic</code>: Allow skinned objects (e.g. Avatars, animesh, etc.) to be captured in the reflection.
* <code>Ambiance</code>: Affects how much objects within the volume are lit as if they have bounced light hitting them from faked indirect illumination. ''See [[PBR_Materials#Fine-Tuning_Reflection_Sample_Volumes|"Fine-Tuning Reflection Sample Volumes"]] for more info.
* <code>Near Clip</code>: Sometimes, there will be a large obstruction in the center of the volume you wish to use as a reflection probe. For example, suppose that there is a large architectural supporting structure in the middle of the room, such as a column. If the probe gets placed internally inside this, it will reflect the internal surface of the column instead of the room in which it is placed. Increasing Near Clip will make the sampling volume exclude objects n meters from the center so they don’t get included in the reflection. ''See [[PBR_Materials#Fine-Tuning_Reflection_Sample_Volumes|"Fine-Tuning Reflection Sample Volumes"]] for more info.

Select an appropriate probe shape for your scene. For example, if you want to create a reflection probe that covers a room, select a <code>Box</code> shape, or for other objects a <code>Sphere</code> shape is recommended.

Move the reflection probe and resize it as necessary to fit your desired purpose. For the room example, resize the box so the probe just touches the walls, ceiling and floor of the room.

Naming your probes is also recommended, so other people ( or yourself later on ) will remember why there’s a large transparent prim in the middle of your build.

If you wish to come back and edit the reflection probe later on, enable both <code>Show Reflection Probe Volumes</code> and <code>Select Reflection Probes</code> under <code>Build > Options</code>.

=== Fine-Tuning Reflection Sample Volumes ===
{{KBwarning|Sample volumes do not react to prim parameter changes. Options such as “Hollow” or “Taper” or “Shear” do not change how the sampling area behaves.}}

That said, it may be helpful to visualize <code>Near Clip</code> as the hollowing out of your reflection sample volume, but the hollow and near-clip are not in any way linked and doing so is purely a convenience. Reflection probe sample volumes only respond to changes in scale and position; however, different probe volumes behave differently when resized.
* <code>Box</code> Probes: These are affected by position and non-uniform scale.
Example: If I create a box reflection probe and scale it to 10m,30m,10m size, the full volume will be affected by the probe.
* <code>Sphere</code> Probes: These are affected by position and '''uniform''' scale only, otherwise the smallest dimension is used.
Example: If I create a spherical probe and scale it to 10m,30m, and 10m size , the probe will sample a 10 meter diameter spherical volume at the center of the probe. However, a 30m,30m,30m sphere will create a sampling volume of a 30 meter diameter sphere.
[[File:SphereProbeErrror.jpg | thumb | none | A diagram of how spherical probes function (or, don't function as you may expect) while non-uniformly-scaled.]]

<code>Reflection Probe Ambiance</code> controls how ambient light (Found in your [[Environmental_Enhancement_Project#EEP_Settings_Objects|environment preset]]) affects, or does not affect, the contents of the reflection probe, and the intensity of indirect lighting (aka Irradiance).
This value is influenced by the <code>Reflection Probe Ambiance</code> value found in the user's [[Environmental_Enhancement_Project#EEP_Settings_Objects|environment preset]], wherein if the Ambiance value given in the [[Environmental_Enhancement_Project#EEP_Settings_Objects|environment preset]] is higher than the value defined by the probe itself, it inherits the ambiance value of the [[Environmental_Enhancement_Project#EEP_Settings_Objects|environment preset]], or alternately if the ambiance value defined by the probe is higher, the probe's value is used.

There are a few operation modes that are set with the <code>Reflection Probe Ambiance</code> value, in tandem with above:
{| class="wikitable"
|+ Probe Ambiance behavior
! Value !! Description
|-
| 0.00 || Ambient color from the environment applies at full intensity. '''Default for pre-PBR skies.'''
|-
| 0.01 .. 0.99 || Blends ambiance with indirect lighting (sun + emissive or illuminated surfaces) within the probe.
|-
| 1.00 || Indirect light applies at full intensity, without ambient color. '''Default for PBR skies.'''
|-
| 1.01 .. 4.00 || Multiplier for indirect light, makes everything brighter within the probe.
|-
| 4.01 .. 100.00 || Multiplier for indirect light, but only further affects light from the sun. (Local lights are capped to 4.)
|}

=== Complex Reflection Probe placement ===

At times, you may wish to place a reflection probe in an area where the reflection probe types (Sphere or Box) do not conform to the shape of the area. For example, a Box probe in a loft room has a triangular shape, which results in "probe bleed" wherein the influence volume affects an area larger than what is needed, and thus bleeds out onto the exterior roof, which is undesirable.

In these cases, you may need to place multiple probes in order to blend together the sample volumes to achieve the desired result. In the loft room example, it's best to start with 3 box probes, which cover the floor, and each side of the roof. Then, use an additional box probe as "fill" to cover the gap inbetween the 3 probes. The main fill probe may need to be rotated at an angle to get the most coverage possible. If it is not possible to fill the gap between the 3 probes with this fill probe, you may wish to add more box probes to act as "secondary fill".

[TODO: Put photo examples of the above here!]

Alternately, Sphere probes may be used to achieve the same result. Sphere probes have considerably softer blending than box probes, so this may give you the best results in severe bleed conditions.

=== Unsupported use-cases ===
{{KBwarning|Do not attempt to do anything listed below. These uses are liable to either intentionally be disabled, or stop working in future updates.}}
You may be tempted to use reflection probes in the following ways, however these use-cases are either intentionally disabled or result in undefined behavior, and may work now but may not in future. '''You have been warned.'''

'''Under any circumstances, you should NOT:'''
* Wear a reflection probe. This intentionally does not work. (Reflection probes are a property of the scene, not an individual object / avatar)
* Attach a reflection probe to a physics-enabled object, e.g. vehicles. This intentionally does not work. (As above, the reflection probes are part of the scene; not part of an individual object. Reflection probes by design do not update in real-time, thus the object would always have incorrect reflections anyway.)

== PBR Material Composition ==
PBR-defined values are measured by optical sensors and other capture tools and recorded in databases. These parameters are then put into commercial software to be used by content creators. Using software designed to create PBR content is always recommended; however, understanding how PBR materials are assembled can assist with editing and compiling them. Having a direct understanding of what each individual color channel contributes is essential for editing PBR textures without relying upon some of the more advanced toolkits available.

All PBR Values are listed from 0 to 1.0, though in an actual image, the values range from 0 - 255.
PBR Materials are composed of a set of four specifically designed textures; they are as follows:

===Base Color [ RGB ] + Transparency [ A ]===
[RGB]: This is the unlit color of the surface. This differs from the “Diffuse” texture that Second Life uses. Diffuse textures often include faked reflection and specular information as well as added Ambient Occlusion shadows. Base Color textures do not get any of this added information. For metals ( as defined by the metalness value ), Base Color also determines specular reflection color, whereas, in non-PBR systems, this is defined by the Specular texture and tint. In certain PBR texturing applications, Base Color is sometimes also referred to as “Albedo”.
 [ A ]: Alpha Channel, dictates the transparency of the entire material overall.

The Base color texture should be devoid of lighting information.

===Occlusion [R] / Roughness [G] / Metalness [B]===
This texture is composed of 3 unrelated grayscale images stored in 3 different color channels of an RGB texture.
 [R]: (Ambient) Occlusion is lighting data, '''removing''' the need to bake down shadows on to the Base Color map. Note that ''white'' (<1,1,1>) means no occlusion is applied, and ''black'' (<0,0,0>) applies full occlusion.
 [G]: Roughness data ranges from 0 to 1.0, but the actual range of physical surfaces ranges from approximately 0.05 to 0.985. No surface is perfectly smooth or completely rough. The rougher a surface is the less mirror-like it behaves.
 [B]: Metalness values are mostly black or white. Either the material is a conductive metal like copper, or it’s a non-metal like fabric. 0.0 is Non-Metallic, 1.0 is Metallic. There are almost no materials with gray metalness values.
 The alpha channel is ignored, as per the [https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#additional-textures glTF 2.0 specification].

{{Enote|The Occlusion map '''is not''' controlled by the "Screen Space Ambient Occlusion" toggle in the Advanced Graphics Settings. '''The Occlusion map is ''always'' enabled.'''}}

===Emissive [ RGB ]===
This determines the amount and the color of unlit (ignores ambient light conditions) areas of your material. When giving an object a white emissive map, the object will act as if the Blinn-Phong "Fullbright" option was checked. This map is useful for items which are expected to emit light, e.g. a table lamp, where the lamp shade would appear to glow when the lamp is turned on. If you wish to toggle the lamp on and off, it's recommended to change the Emissive Tint value to black (functionally disabling the emissive map, thus turning the lamp off), and then changing the tint back to your desired color to turn the lamp back on. Leaving the Emissive slot empty is recommended when it’s unused.

Note that glow (The postprocessing effect), is controlled by a separate parameter in the build floater and is intentionally not part of the PBR material window. Glow is modulated by the emissive map, so black areas of an object's emissive map will not glow, similar to how Blinn-Phong emissive maps and glow work.

As per the [https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#additional-textures glTF 2.0 specification], the alpha channel is ignored.

===Normal [ RGB ]===
The normal maps generated by your baking application / normal map generation toolkit should be compatible with Second Life in most cases. The most common pitfall is using normal maps generated with “inverted” Green channels, such as those that are used for Direct3D and Unreal Engine. Normal texture data redirects light in a different direction based on the vectors indicated by the color, so if the green channel is backward, it’ll seem to be “pointing the wrong way”. To phrase the problem a different way, all the things that should be bumps look like dents, and vice versa. If this occurs, double check that your settings aren’t for Direct3D and try re-generating it. Also, taking it into image editing software and inverting the green channel only sometimes is a sufficient fix.

Normal map tangent spaces are an extremely technical subject that most users need not be concerned with as most modern applications default to the correct setting. However, if your normal maps look drastically different inside Second Life, compared to your source application, and you’ve already confirmed it’s not an inverted green channel, then checking which tangent space settings are being used is the next step. PBR Normals use Mikkelsen Tangent Space. (Often abbreviated MikkT) If you are unsure what this means, use similar workflows and settings for Second Life PBR as those that are generally recommended for the Godot 4 game engine.

As per the [https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#additional-textures glTF 2.0 specification], the blue channel of a normal map is only allowed to contain values above 0.5 to a max of 1 (255).

As per the [https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#additional-textures glTF 2.0 specification], the alpha channel is ignored.

== Material Reference Libraries ==
As PBR is ''Physically Based'', you may wish to know how to recreate a real-life material in PBR form. What color should you use? What metalness value should it have?

Fortunately, reference libraries exist which can tell you how to recreate a given material in a PBR workflow.

=== List of Reference Color Palettes & libraries ===
*'''[https://physicallybased.info/ Physically Based]'''
** Select the ''Godot'' Engine, with the Color Space as ''sRGB Linear'' and Color Representation as ''0-1'' (Depending on what you are doing, you may need to convert the value into gamma-corrected sRGB space, which can be done [https://davengrace.com/dave/cspace/ here.] Enter the value on the 3rd row.)
*'''[https://www.youtube.com/watch?v=TcTh-1X2FsQ Grzegorz Baran Library]'''
**Available on [https://www.youtube.com/watch?v=TcTh-1X2FsQ YouTube (video format, older)], or [https://gbar.gumroad.com/l/cbwkvo PDF (most up-to-date)].
*'''[https://seblagarde.wordpress.com/2014/04/14/dontnod-physically-based-rendering-chart-for-unreal-engine-4/ Dontnod Entertainment Library]'''
** A very small library, but useful nonetheless.
*'''[https://docs.studio-397.com/developers-guide/general-reference/pbr-an-introduction-authoring-guide Studio 397]'''
** A small collection of various materials.
*'''[http://wiki.polycount.com/wiki/PBR Polycount Wiki]'''
** Not so much a library in itself, but links out to other libraries. '''See the Color Charts section'''.

=== List of PBR asset libraries ===
*'''[https://ambientcg.com/ ambientCG]'''
** Provides CC0 licensed HDRi, Metal-Rough materials and .sbar (Substance Painter material) files.
*'''[https://polyhaven.com/ Poly Haven]'''
** Provides CC0 licensed HDRi, Metal-Rough materials and models.

== Uploading Materials ==
There are two different methods of creating PBR material assets:

=== Method 1 : Direct Upload a glTF File ===
The most convenient method to create an entirely new material is to directly upload a glTF file from your computer.

This is accessible via <code>Build > Upload > Material...</code>
[[File:PBRBuildMenu.jpg | thumb | none | PBR Upload in main build menu. ]]

Select a .GLB or a .GLTF file from your computer and Open it:
This will give the following window:
[[File:PBRMatMenu.jpg | thumb | none| The layout of the PBR material creation and editing interface.]]

All of the editable material properties that most creators are familiar with are integrated into the Material's vertically sizable window on upload.

Clicking “Save” pays the upload fees and creates the Material assets using the local filename. Using "Save As..." provides a window to name all the assets to unique inworld names. There is a 63 char limit for names of inventory assets but the naming floater on this Materials upload has no length restrictions.

Textures will be uploaded to the inventory's default Textures folder (NoMod, NoCopy, Transfer) with an appended "type" added to the given name. (ie. asset name (Base Color), asset name (Normal), asset name (Metallic Roughness). In naming the asset keep in mind that the bracketed appendix is included in the name's 63 character limit. The PBR object is uploaded (Mod, NoCopy, Transfer) to the inventory's Material folder with the appended text (Material). Presently, naming the glTF asset from Save As... will NOT append (Material) to the inventory's name. Saving from the locally named file will.

{{KBcaution|Each individual texture used to compose the Material object is charged a separate upload fee. (ie. If you have 4 textures (Base Color, Metallic Roughness, Emissive, Normal) you are charged 4 times. If you only have a Normal and Metallic-Roughness texture you will be charged for 2, etc.)}}

=== Method 2 : Edit a Blank. Create PBR Materials without a glTF File ===
If you have the necessary textures to compose a PBR material but do not have a glTF file you will need to build a Material from inventory. Make sure your textures are in the correct format, with the correct data in the proper channels. This requires some understanding of how [[PBR_Materials#PBR_Material_Composition:|PBR materials work]]. Once you have that, upload your textures as you normally would.

[[File:PBRMenuUI.jpg | thumb | none | The PBR Materials UI in the Build Floater.]]

* Find the "Materials" folder in your inventory, right click, and select "New Material" from the context menu.
* Name your new material something appropriate (E.g. "Red Bricks" for a red brick wall, etc.)
* Right click on your new material, and select "Open" from the context menu.
* Upload your PBR textures using the standard texture workflow (Usually, under <code>Build > Upload > Image</code>).
* In the material window, select the appropriate maps that you just uploaded in their respective slots.
{{KBwarning|While there may be a temptation to try and place a Blinn-Phong “Diffuse” texture into the “Base Color” slot and a Blinn-Phong “Specular" into the “Metallic/Roughness” slot, doing so will not produce desirable results. However, trying this won’t generate any warnings as there is no way to check that you’ve put the right texture type into the inputs, and the material will save and be applicable to objects. '''Unfortunately, what will be created is not a functional PBR material. Please do not do this.'''}}
* Once done, verify the material parameters are correct (E.g. Base color tint, M/R factor, Emissive tint, etc.)
* Save your new material.
* EITHER: [[PBR Materials#Drag_and_Drop|Drag and drop the material onto a rezzed prim]], OR edit the prim, click the "Blinn-Phong" drop-down, select "PBR Metallic-Roughness", and click "Choose from Inventory", and select your new material.



=== Creating Color Variants ===
After you’ve uploaded your first Material for your project, if you’re a store owner who would like to release more than one color palette for your creation, as many clothing and furniture designers find it useful to do, '''it’s important to not upload a new glTF file for every single variant of your Material'''. Most variant materials, only the base color will change. The Occlusion, Roughness, Metalness, Emissive and Normal map texture slots will remain the same. Since these maps have already been uploaded once, if we upload a second glTF File, they will be duplicated. Having different copies of the same texture, with differing UUID’s means that they will clog up download bandwidth and video card memory (not to mention your inventory as well). This is very bad for Second Life. So, for this reason, it’s recommended that when you create texture variants, you upload the additional copies of the base-color texture separately. Then open your newly uploaded material in edit mode, choose the Base Color texture, and change it out for one of your newly uploaded Base Color textures, and click “Save As”. This will create a second copy of your material that uses all the correct texture maps without needlessly duplicating them and causing additional lag.

{{KBtip| You can also avoid uploading additional textures altogether by uploading a white color variant, then making use of the Base Color Tint parameter!}}

== Double Sided Parameter : Uses and Dangers ==
“Double Sided” is a new property unique to Materials. When “Double Sided” is checked, the surface upon which this material is placed will be drawn twice; once for the outward-facing portion of the surface, and a second time for the inward-facing side of the surface that is normally invisible without a double-sided material. This option should only be used for very specific meshes that were designed to be used with double-sided materials, since placing materials with this parameter checked on normal objects will simply cause the viewer to draw it twice ( and thereby create additional viewer lag ) for no observable change. It is '''very strongly recommended''' that this option be unchecked for any material that is to be distributed for general use. Even more so if the “Modify” permission is revoked. If you wish to distribute a version of a material that has “Double Sided” checked, please include a second copy of the material that has “Double Sided” unchecked as well, with an accompanying explanation to the next user as to why this was done.

Example:
*LeafTextures_DoubleSided
*LeafTextures_SingleSided

When designing mesh content for use with the double-sided material parameter, it is also ''very strongly recommended that you separate the triangles you intend to use the double-sided material upon into a separate mesh “face”'', so as to not unintentionally render the portions of the mesh that already have triangles designed to represent the internal portion of the object a second time.

== LSL Scripting ==

Documentation for the LSL interface with glTF materials can be found on the following pages:
*[[GLTF Overrides]]
*[https://wiki.secondlife.com/wiki/Category:LSL_Material Category:LSL Material]

== Recommended Application Settings ==
The glTF file format is widely adopted and many applications have export functionality for this type of file.
Below is a non-comprehensive list of some of the more popular applications that export glTF files.

{{KBtip|'''The recommended HDRi for use in Second Life content creation is available at [https://github.com/Jenna-Huntsman/Second-Life-Resources/tree/main/PBR/HDRi this Github repository].''' This HDRi will closely match the lighting of objects under the PBR "Midday" environment preset.}}

{{KBcaution|While every effort has been made to ensure the recommended HDRi matches SL as close as possible, you may need to adjust the "Environment Exposure" parameter in your editing program to get 1:1 results with SL.}}
 
----
===[https://www.blender.org/ Blender]===

{{KBwarning|Older Blender versions have bugs in their glTF export tools which make their output incompatible with Second Life. '''Use of Blender versions of 3.3 and above are highly recommended to avoid issues.'''}}
 
{{KBcaution|Please ensure that you correctly set up an HDRi in your viewport, as otherwise the rendering in Blender and in SL will not match. Please see [[PBR Materials#Recommended_Application_Settings|here for a reference HDRi]]. '''Please see [https://www.polygonartists.com/hdri-environment-maps-in-blender/ this tutorial].'''}}

Upon starting your project:

Under: <code>Scene > Render Properties > Color Management</code>:
*{{code|View Transform: Standard}}
*{{code|Sequencer: Linear ACEScg}}

Create your materials within Blender using Principled BSDF Shader Nodes and the glTF Settings node. Export them according to the official '''[https://docs.blender.org/manual/en/3.6/addons/import_export/scene_gltf2.html Blender Documentation.]'''

{{KBcaution|Second Life does not support BSDF Clearcoat, Subsurface, Anisotropy or Transmission parameters at this time.}}

For materials creation, 2 example .blend files are provided, one using separate Occlusion, Roughness and Metallic textures ("Long Form"), and one that handles a pre-packed ORM map ("Short Form")

The below files are intended for use with Blender versions 3.3 and above.

* '''[https://github.com/Jenna-Huntsman/Second-Life-Resources/blob/main/glTF%20Node%20Tree%20-%20Long%20Form.blend glTF Node Tree - Long Form.blend]'''
* '''[https://github.com/Jenna-Huntsman/Second-Life-Resources/blob/main/glTF%20Node%20Tree%20-%20Short%20Form.blend glTF Node Tree - Short Form.blend]'''
 
----
=== [https://www.adobe.com/products/substance3d-painter.html Adobe Substance 3D Painter] ===
{{KBcaution|While Substance Painter is generally considered to be stable, in some (rare) situations Substance may output a malformed glTF which will be rejected by the viewer. If this happens, import your materials into Blender, then export a glTF from Blender - this should be fixed in a future version of Substance.}}
 
{{KBcaution|Please ensure that you correctly set up an HDRi in your viewport, as otherwise the rendering in Substance and in SL will not match. Please see [[PBR Materials#Recommended_Application_Settings|here for a reference HDRi]]. Please see [http://y2u.be/6goXJ2CJzaM this tutorial].}}
When starting your project:

*{{code|Template: PBR - Metallic Roughness Alpha-test (starter_assets)}}

OR

*{{code|Template: PBR - Metallic Roughness Alpha-blend (starter_assets)}}

Verify the following settings:
*{{code|Document Resolution: [Set as desired]}}
*{{code|Normal Map Format: OpenGL (Y+)}}
*{{code|Compute Tangents Per Fragment: YES}}

Under "Color Management":
{{KBtip| For a more in-depth explanation of the below settings, and issues that you may encounter, visit [https://mrlixm.github.io/blog/substance-painter-color-management/#aces-workflow this page].}}
*{{code|Color Management: OpenColorIO}}
*{{code|OpenColorIO Configuration: ACES 1.0.3}}
*{{code|Standard sRGB color space: Utility - sRGB - Texture}}
*{{code|8 bit images: Utility - sRGB - Texture}}
*{{code|16 bit images: Utility - sRGB - Texture}}
*{{code|Material color space default: Utility - sRGB - Texture}}

When exporting:

Settings Tab - Global Settings
*{{code|Output template: glTF PBR Metal Roughness}}
*{{code|Size: Based on each Texture Set's size}}
*{{code|Padding: Dilation + default background color - 8 bit}} '''OR''' {{code|Padding: Dilation infinite}}
{{KBtip|If you encounter color banding (AKA posterization) in your base color texture after export, you may wish to enable dithering.}}
*To enable dithering, open the {{code|Export Textures}} window, under the {{code|Settings}} tab, enable an override for the Base Color texture and swap the output format from {{code|8 bits}} to {{code|8 bits + dithering}}

Settings Tab - Per-Material settings
*{{code|Output maps > Normal Map: 8 bits}}

<li style="display: inline-block;">[[File:Substance_Painter_-_Export_Global_settings.png|thumb|Settings Tab - Global Settings]]</li>
<li style="display: inline-block;">[[File:Substance_Painter_-_Export_Per-Material_settings.png|thumb|Settings Tab - Per-Material settings]]</li>
 
----
=== [https://www.adobe.com/products/substance3d-designer.html Adobe Substance 3D Designer] ===
{{KBcaution|Substance Designer ''does not support glTF output'', unlike Substance Painter.}}

Under preferences, verify the following '''Project''' settings:
*{{code|Color Management: OpenColorIO}}
*{{code|OpenColorIO Configuration: ACES 1.0.3}}
*{{code|8 bit images: Utility - sRGB - Texture}}
*{{code|16 bit images: Utility - sRGB - Texture}}
*{{code|Floating point images: ACES - ACEScg}}
*{{code|2D and 3D View Display Default: sRGB}}

When exporting (Export Outputs):
*{{code|basecolor: Utility - sRGB - Texture}}
*{{code|normal: Utility - Raw}}
*{{code|roughness: Utility - Raw}}
*{{code|metallic: Utility - Raw}}
*{{code|ambientocclusion: Utility - Raw}}

If you use a custom node to output a [[PBR_Materials#Occlusion_.5BR.5D_.2F_Roughness_.5BG.5D_.2F_Metalness_.5BB.5D|pre-compiled ORM map]], this should also be set to Raw.
 
----
=== [https://www.maxon.net/en/cinema-4d Cinema 4D] ===
Please follow the documentation provided in this [https://www.bakedpixels.nl/blog/export-to-gltf-with-cinema-4d blog post].
 
----
===[https://3dcoat.com/ 3DCoat]===
{{KBwarning|As of version "2022-58", 3DCoat is unable to produce a spec-compliant glTF file, and thus should not be used for Second Life. '''Use at your own risk - you ''will'' have issues!}}

glTF export has been implemented since 3DCoat version 2020 and is found in the <code>File >Export > Export to glTF > glTF Separate (gltf + .bin + textures)</code>
 
----
=== [https://quixel.com/mixer Quixel Mixer] ===
Quixel Mixer has no glTF output, however, it does generate the functional textures, though they do need to be edited and combined in photo editing software.
Export them by going to <code>Export Target > Custom</code>

Texture Preset: Metalness Maps

Select:

Albedo , Roughness, Normal, AO , Metalness and ( if need be ) Emissive.

Click “Export to Disk” and open the folder that the files were placed into.

Albedo is the Base Color texture in this case.

AO , Roughness , Metalness get combined into the ORM map as per [[PBR_Materials#PBR_Material_Composition|this explanation.]]

Normal Map : Quixel generates Direct3D Normal Maps. The green channel needs to be inverted as [[PBR_Materials#Normal_.5B_RGB_.5D_|per here.]]

Upload to Second Life using [[PBR_Materials#Method_2_:_Edit_a_Blank._Create_PBR_Materials_without_a_GLTF_File|Method 2.]]
 
----
=== [https://www.autodesk.eu/products/3ds-max/overview Autodesk 3DS Max 2023] ===
Autodesk just added the ability to create glTF files using their new glTF Material and glTF Export functionalities as outlined in '''[https://help.autodesk.com/view/3DSMAX/2023/ENU/?guid=GUID-EFBB037D-C4EB-42D2-9CE1-30FCAD483C31 Autodesk's official documentation]'''. All prior versions of Autodesk software do not have this functionality.
 
----
=== [https://www.materialmaker.org/ Material Maker] ===
While [https://www.materialmaker.org/ Material Maker] does not currently export directly to glTF ([https://github.com/RodZill4/material-maker/issues/479 This may be added in future]), materials created with this program are compatible with Second Life.

Export your materials using the '''Godot 4 ORM''' export preset.

Upload to Second Life using [[PBR_Materials#Method_2_:_Edit_a_Blank._Create_PBR_Materials_without_a_GLTF_File|Method 2.]]
 
----
=== Adobe Photoshop ===
'''While Photoshop is not officially a PBR authoring tool''', the changes to Alpha Blending (changing into Linear space from sRGB) may require you to change your PS settings to get consistent results. Please see [http://www.kiransprojects.com/blog/2014/photoshop-blending-is-broken/ this article] for more information. (See the section titled "A Partial Solution"). Alternatively, [https://www.reddit.com/r/photoshop/comments/61clf8/how_to_fix_photoshops_incorrect_and_ugly_color/ this Reddit post] also gives a few options on how to achieve blending in the correct manner.
 
----
=== GIMP ===
'''While GIMP is not officially a PBR authoring tool''', the changes to Alpha Blending (changing into Linear space from sRGB) in Second Life will make textures created in GIMP display their alphas correctly (GIMP defaults to linear alpha calculation).

== Troubleshooting content ==

If you upload a piece of PBR content which does not match your editor, the advice from Linden Lab is to '''STOP: File a Feedback ticket. Do not attempt to "fix" the content.'''

That said, there are some troubleshooting steps which you can do yourself:
* Check that you are using the PBR Linden Midday preset (called "Midday") ''not "Midday (Legacy)"''. Other environments may not match the reference HDRi, causing some visual differences. (This is intended behaviour, and content should be able to be viewed under any light correctly, but for troubleshooting purposes this may be required).
** At present, there is a bug with the PBR Linden Midday preset which results in an excessive blue sheen, due to the use of an over-saturated (unrealistic) sky color, among some other issues. This has been fixed in the upcoming glTF Maintenance viewer.
* Are you using a reflection probe? If not, does the problem reproduce if a manual reflection probe is placed over the object?
** This is because a common source of the "blue sheen" in interior scenes is the use of an auto-probe. Auto-probes sample their surroundings, and combined with the approximate (and often incorrect) placement this will mean the sky is sampled on all sides, thus meaning the reflected light from the surroundings (which counters the blue light from the sky) is absent, leading to a larger-than-expected level of sky contribution on the object. Auto-probe placement can be worse in skyboxes or sky platforms
* Triple-check the settings used for your editor match the ones given [[PBR_Materials#Recommended_Application_Settings|here]], including the reference HDRi. '''Any''' deviation from these settings may cause visual differences between your editor and in-world.
* Check your content against a glTF reference viewer; such as:
** [https://modelviewer.dev/editor/ Modelviewer.dev]
** [https://github.khronos.org/glTF-Sample-Viewer-Release/ Khronos Sample Viewer]

If the above steps fail, then please '''[https://feedback.secondlife.com/ file some Feedback.]'''

A good Feedback ticket will include:
* An LM to a location where the problem can be examined in-world.
* A copy of the glTF content, attached to the ticket.
* Screenshots of the representation in-world, in a reference viewer, and in-editor.
** You should include screenshots of the object inside a manually placed reflection probe, and outside.

PBR Materials

2026-03-01T07:12:39Z

Wulfie Reanimator: Separated the wall of text a bit. /* What is it and Why is it used? */

{{multi-lang|1=PBR_Materials|2=/en}}
'''Physically Based Rendering'''

{{note|1=This page is being actively updated with new content and links as GLTF PBR Materials and related new features are being released. Contributions to this page may be from Second Life residents and staff members alike.}}

[[Category:glTF]]

== What is it and Why is it used? ==

The term “Physically Based Rendering” or “PBR” is a technical term that may need some defining for most people since its use is unique to composing images in computer software. The term itself is an abbreviation for a collection of complex mathematical algorithms that attempt to accurately represent the ways that light reflects off and interacts with objects in the real world.

In the real world, it is the behavior of light on a piece of metal that allows us, the observer, to recognize “that object is made of metal” without actually reaching out and touching it. The way a metal reflects light differs from that of a polished plastic or some other material, and these differences have been quantified by science.

==== How it applies to Second Life ====
By mimicking real-world physics principles in the virtual world it allows for the creation of more immersive recognizable realistic spaces, but also it helps us relate to fantastical worlds a little better too. While we may not be familiar with what a newly imagined creation is, a metal's inherent metal-ness and aged wood's inherent wood-ness remain constant, making it easier to intuitively understand what we are interacting with in a virtual environment.

Because tying the mathematics to simulate materials in virtual spaces to how they behave in the real-world makes things more immediately recognizable, PBR has become the foundation for creating imagined worlds over the last decade. The metallic shine of exoskeletal armor in superhero movies is driven by a PBR workflow, as is the plastic sheen of toys or the glint of frozen ice in animated classics. Now we are moving to bring this standardized quality to your home in Second Life.

Bringing PBR to Second Life means updating the basic calculations of how light is represented and interacts with the world of Second Life. The goal is to integrate these changes while minimally changing how everything that presently exists in Second Life (designed prior to the introduction of PBR) looks. While the preservation of creative intent and the aesthetic appeal of items users have enjoyed for over two decades of Second Life is always a priority, Second Life is an ever-evolving platform, and to continue to do so, some changes are inevitable.

Lastly, while we are attempting to mimic real-world reflections and material properties, Second Life has to run on a wide variety of devices, so some shortcuts have to be made. Reflections are not mirror-perfect, as has often been a long-standing hope and request from Residents. While the addition of a reflection system does bring dreams of distortion free mirrors for our avatars in Second Life closer to reality, unfortunately, due to the calculation requirements of doing perfect reflections, mirrors are sadly still, for the moment, not practical. Please see the note in the [[#Understanding_and_Assisting_the_New_Reflections_System|section below]] for more info.

== What does this mean for Residents? ==
[[File:PrePostPBR.png | thumb | right | The lamp in this screenshot uses [[PBR_Materials#Nomenclature_changes|Blinn-Phong]] (Classic SL Materials), and was created before PBR's integration into SL; and demonstrates some of the visual differences to existing content. The environment used for the screenshot is the viewer's default Midday preset (Note that the PBR viewer has a new Midday preset).
]]
=== Changes to Existing Content ===
The largest change by far is the addition of an environmental reflection system to Second Life. For most existing items, this change shouldn’t have a drastic immediately observable impact. A few things in your inventory that you already own may appear more reflective with the new graphics configuration and those reflections should feel more realistic and immersive with your current environment. As a general rule: the “shinier” an object was before, the more environment reflections it will pick up and the more visual difference there will be.

Another notable change is the addition of [https://en.wikipedia.org/wiki/Tone_mapping tonemapping] to the viewer. Tonemapping is a way of representing an image with a higher native dynamic range than the display can support. Tonemapping is a de-facto requirement of PBR pipelines. This means that colors in Second Life will generally appear more saturated with less detail being lost in shadows and highlights. [https://modelviewer.dev/examples/color.html Click here for some additional reading on the subject.]

The tonemapping method used is called '''Academy Color Encoding System ('''aka '''"ACES")''', and can be read about [https://www.oscars.org/science-technology/sci-tech-projects/aces here] and [https://docs.nvidia.com/gameworks/index.html#devices/shield-hdr-dev-guide/hdr-dev-guide-nvidia-shield.htm here].

[[PBR_Materials#Nomenclature_changes|Blinn-Phong]] content making use of the Specular parameters may look different if the items were never viewed under local lights, as the PBR viewer allows for the environment (sun ''and'' sky) to contribute to specular reflections. As such, if the object receives blue specular reflections from the sky, these reflections are tinted, and may look odd. This effect is the same as prior viewers, as if the object was lit by a blue local light.

=== Removal of Advanced Lighting Model ( ALM ) Graphics Option ===
There have been changes to the '''Graphics > Advanced Settings...''' Preferences. The most notable of which is the removal of the “Atmospheric Shaders”, "Local lights" and “Advanced Lighting Model” options.

For those users on lower-end hardware who depended heavily upon those options to navigate Second Life with an acceptable framerate, we recommend the following settings:
*{{code|Transparent Water: Disabled}}
*{{code|Screen Space Ambient Occlusion: Disabled}}
*{{code|Shadows: None}}
*{{code|Screen Space Reflections: Disabled}}
*{{code|Reflection Detail: Static Only}}
*{{code|Reflection Coverage: Manual only}}

The {{code|Local Lights}} setting has been superceded by updates made to the '''World > Improve graphics speed...''' "Quality & Speed" slider options. Users on low-end hardware should ensure that their "Quality & Speed" slider is set at an appropriate level for their hardware.

== What does this mean for Creators? ==
=== Nomenclature changes ===
The PBR project represents a large step towards integrating standard rendering techniques used in the games industry. As such, the nomenclature of some items has changed, notably, what was once called '''[[:Category:Materials|Materials]]''' is now referred to as '''Blinn-Phong'''. This does not represent any changes to the underlying rendering techniques (beyond those mentioned above); and as such Blinn-Phong ''is not'' the same as PBR Spec/Gloss workflows, seen in some game engines such as Unity.

=== Importing PBR Materials from External Software: ===
For creators who work with external tools such as Blender, Adobe Substance Painter, Cinema4D, 3D-Coat, or have used the Unreal or Godot game engines, the use of PBR texture sets should already be familiar. In fact, some creators have been using tools that use PBR workflows to create content for Second Life and have then been forced to sacrifice visual quality to convert that information into Second Life’s existing Blinn-Phong materials system.

Second Life is adopting the “Metallic/Roughness” PBR model, and in its ongoing commitment to using Open Source standards whenever it is practical to do so, the glTF 2.0 file format has been chosen as the upload format for PBR Material assets. One of the primary goals of implementing PBR Materials is to have more continuity from content creation applications towards Second Life, and have more consistent content behavior once it’s inworld.

=== Using Imported Materials in Second Life ===
[[File:Editing_Material.jpg|thumb|right|Material Editing]]
For people who build exclusively within Second Life, the addition of PBR also means that there will be a new [[LlGetInventoryType|Inventory Type]] called “Material”. These new Materials can be purchased on the Marketplace and are shareable like any other permitted object in Second Life.

PBR materials come as a bundle of textures. These all travel as a single unit and are applied all at once. If you wish to change tint, transparency, or other similar parameters of the Material you’ll need to modify the Material from the "Editing Material" floater.

{{KBcaution|Meshes uploaded after the PBR release will look slightly different (and more accurate to your editor of choice) due to a change in the way Second Life handles mesh assets (Previously, some data required for accurate tangent generation was discarded at upload time - this is no longer the case). This will mean that a PBR material applied to a mesh uploaded before PBR launched (28th November 2023) might look incorrect; a simple reupload of the mesh will solve this. '''This is not required, but recommended.'''}}

Applying existing materials works similarly to existing textures. You have two means of doing so:

==== Drag and Drop ====
Simply drag and drop onto the face of a prim or a mesh. For example, if you have a tiled floor material and you place it on a selected prim cube face that face will now look like a tile floor and reflect light like a tiled floor would with all the material qualities contained in the material.
[[File:DragAndDrop_Mat_Wiki.png | thumb | none | Drag and Drop Functionality.]]

==== Switch to PBR and select from Inventory ====
Alternatively, select a face on the prim or mesh you want to apply your material to and choose the “Blinn-Phong” drop-down and change it to “PBR Metallic Roughness”, then select “Choose an item from your inventory” and apply.
[[File:PBRSelectorV3.png |left| thumb | none | Menu drop-down demonstration.]][[File:Material_Dropdown.jpg|thumb|none|Dropdown as of v7.0.1.689]]

 

==== Texture Transforms ====
With PBR materials, texture transforms work in a slightly different way to Blinn-Phong transforms. Blinn-Phong (and OpenGL) has the texture origin in the lower left corner of the texture, whereas glTF materials (and Vulkan) has the texture origin in the upper left corner.

This means that PBR materials will react differently (namely, they are inverted in the Y (glTF v) axis) to Blinn-Phong materials.
For a simple solution to convert a Blinn-Phong texture transform to a PBR texture transform, please see [https://community.secondlife.com/forums/topic/507448-lsl-math-for-gltf-transformation/?do=findComment&comment=2678959 this forum thread].

For more information, [https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#images see here] and [https://github.com/KhronosGroup/glTF/tree/main/extensions/2.0/Khronos/KHR_texture_transform here].

=== Media-on-a-Prim ===
Media on a prim will continue to work largely as it has done prior to PBR's launch.

When using MOAP on a face with a PBR texture, it will function as if the media texture has an override to the '''Base Color''' and '''Emissive''' maps. Note that the emissive map is overridden, however the emissive tint is not (so, to disable the emissive map you can set the emissive tint to black <0,0,0>).

== Tools & Tutorials ==
As the PBR system is new, it is expected that existing users may be confused at first on how everything works. As such, Linden Lab and some third parties have provided some tutorials and informational videos:

*'''[https://www.youtube.com/watch?v=JtjGf06B8ZA Second Life University - PBR Materials]'''
*'''[https://www.youtube.com/watch?v=BJ1eRTlWDYk Second Life University - How to create PBR Materials]'''
*'''[https://substance3d.adobe.com/tutorials/courses/pbrguide Allegorithmic (Adobe) PBR Guide]'''

The above tutorials require knowledge and access to Adobe's Substance Painter (subscription based software on Adobe website, or sold as perpetual license with one year of updates on Steam). Below are some open source tools and links found Googling 'Blender', 'glTF' (requiring Blender 3.3)
*'''[https://www.khronos.org/blog/art-pipeline-for-gltf Khronos Art Pipeline tutorial]'''
*'''[https://materialmaker.org Material Maker software]'''
*'''[https://aiaicapta.in/gltf-packer/ glTF Packer software]'''
*'''[https://armorpaint.org Armorpaint software]'''
*'''[https://armorlab.org Armorlab software]'''
*'''[https://youtu.be/KTPdNUGwIGc glTF Blender Tutorial]'''
*'''[https://youtu.be/p7OPRoT6FkY Exporting glTF Alpha Textures tutorial]'''

== PBR Stand-In Textures and Outdated Viewers ==
It is worth mentioning that during the adoption period of a new system, a substantial portion of Second Life Residents view the world through third party viewers and mobile viewer solutions that will not have updated to be able to see the new content. Anyone viewing a PBR Material on a viewer that cannot display it will see the “underlying” non-PBR texture. By default, this is a pine box or a completely blank texture. Those who wish their content to be viewable by as many people as possible, might consider creating a Diffuse texture ( with baked lighting, the kind that is easily generated with tools like Substance Painter's “Baked Lighting Filter” ) and applying it as a regular texture to the object they’re placing the PBR material on, prior to applying the PBR material. While this is an extra step in content creation, and complicates things somewhat, if you wish for your content to be appreciated by all, it’s worth considering adding this extra step to your workflow. People designing PBR materials for distribution and sale might also consider offering a “Diffuse Only fallback” texture to accompany the PBR material specifically for people who cannot see the PBR content.

{{KBcaution|Once a PBR Material is applied, the Blinn-Phong textures cannot be updated. To remedy this, remove the PBR Material, then make changes to the Blinn-Phong textures and then reapply the PBR Material.}}

== Understanding and Assisting the New Reflections System ==
Those creators that work at house-scale, or produce items that can be walked through, can gain additional control over the lighting in their creations by taking the time to fully understand the new toolkit that influences environmental reflections. There is a new type of volume that can be created and appended to object linksets specifically for scenes with these kinds of spaces. These volumes define a custom area where reflections are calculated, overriding the default solution. So-called “Reflection Probes” should be placed in a manner such that ''the fewest number of probes fills the largest amount of space possible with minimal overlap''. One probe per room is a good reference point for a general living space like a house. If multiple probes exist in a given area they can cause visual artifacts and negatively impact performance (also known as viewer lag). '''''Do not affix reflection probes to small creations such as furniture or decor.''''' Small items such as tables, chairs, musical instruments, candle sticks etc should use the reflection sample volume in the space in which they are placed. They should not have one appended. It is '''strongly''' recommended that any object that contains a reflection sample probe be left as “modify”, so the positioning of the probe can be adjusted or even removed by the owner of the item should they wish.

{{Enote|Reflection probes '''are not''' intended for use with planar mirrors, and will look incorrect when being used to do so. Planar mirrors have been flagged for future work, but are not directly in the scope of the PBR project.}}


== When is it Recommended to Create a Reflection Probe? ==
Manually placed probes are good for cleaning up undesirable noise and lighting from automatically placed probes that may be visually disruptive or confusing. If you look in the image of the room in a house, on the left hand side of it, you can see a blue tint on the floor, which is the reflected blue light from the sky. The probe filling half the room blocks this, and when it is extended to completely fill the room and just slightly beyond the thickness of the walls, (lower copy of the image) the problem is solved. The probe does not need to be a part of the linkset for the rest of the room in order to function; however, once you have them placed it’s possible to add them into linksets like any other prim.

=== Constructing a Reflection Sample Volume ( aka Reflection Probe ) ===
Start off in the Build Menu ''(Ctrl+3)'' by rezzing a basic prim. Under the <code>Features</code> tab, at the bottom check the box labelled <code>Reflection Probe</code>.
[[File:ProbeUI.jpg | thumb | none | Manual Probe Creation UI.]]

* <code>Reflection Probe</code>: Enabling this creates a Reflection Sampling Volume within the bounding box of the prim.
* <code>Box / Sphere Drop-down</code>: Choose whether you want this sample to project reflections within a box shaped volume or a spherical one.
* <code>Dynamic</code>: Allow skinned objects (e.g. Avatars, animesh, etc.) to be captured in the reflection.
* <code>Ambiance</code>: Affects how much objects within the volume are lit as if they have bounced light hitting them from faked indirect illumination. ''See [[PBR_Materials#Fine-Tuning_Reflection_Sample_Volumes|"Fine-Tuning Reflection Sample Volumes"]] for more info.
* <code>Near Clip</code>: Sometimes, there will be a large obstruction in the center of the volume you wish to use as a reflection probe. For example, suppose that there is a large architectural supporting structure in the middle of the room, such as a column. If the probe gets placed internally inside this, it will reflect the internal surface of the column instead of the room in which it is placed. Increasing Near Clip will make the sampling volume exclude objects n meters from the center so they don’t get included in the reflection. ''See [[PBR_Materials#Fine-Tuning_Reflection_Sample_Volumes|"Fine-Tuning Reflection Sample Volumes"]] for more info.

Select an appropriate probe shape for your scene. For example, if you want to create a reflection probe that covers a room, select a <code>Box</code> shape, or for other objects a <code>Sphere</code> shape is recommended.

Move the reflection probe and resize it as necessary to fit your desired purpose. For the room example, resize the box so the probe just touches the walls, ceiling and floor of the room.

Naming your probes is also recommended, so other people ( or yourself later on ) will remember why there’s a large transparent prim in the middle of your build.

If you wish to come back and edit the reflection probe later on, enable both <code>Show Reflection Probe Volumes</code> and <code>Select Reflection Probes</code> under <code>Build > Options</code>.

=== Fine-Tuning Reflection Sample Volumes ===
{{KBwarning|Sample volumes do not react to prim parameter changes. Options such as “Hollow” or “Taper” or “Shear” do not change how the sampling area behaves.}}

That said, it may be helpful to visualize <code>Near Clip</code> as the hollowing out of your reflection sample volume, but the hollow and near-clip are not in any way linked and doing so is purely a convenience. Reflection probe sample volumes only respond to changes in scale and position; however, different probe volumes behave differently when resized.
* <code>Box</code> Probes: These are affected by position and non-uniform scale.
Example: If I create a box reflection probe and scale it to 10m,30m,10m size, the full volume will be affected by the probe.
* <code>Sphere</code> Probes: These are affected by position and '''uniform''' scale only, otherwise the smallest dimension is used.
Example: If I create a spherical probe and scale it to 10m,30m, and 10m size , the probe will sample a 10 meter diameter spherical volume at the center of the probe. However, a 30m,30m,30m sphere will create a sampling volume of a 30 meter diameter sphere.
[[File:SphereProbeErrror.jpg | thumb | none | A diagram of how spherical probes function (or, don't function as you may expect) while non-uniformly-scaled.]]

<code>Reflection Probe Ambiance</code> controls how ambient light (Found in your [[Environmental_Enhancement_Project#EEP_Settings_Objects|environment preset]]) affects, or does not affect, the contents of the reflection probe, and the intensity of indirect lighting (aka Irradiance).
This value is influenced by the <code>Reflection Probe Ambiance</code> value found in the user's [[Environmental_Enhancement_Project#EEP_Settings_Objects|environment preset]], wherein if the Ambiance value given in the [[Environmental_Enhancement_Project#EEP_Settings_Objects|environment preset]] is higher than the value defined by the probe itself, it inherits the ambiance value of the [[Environmental_Enhancement_Project#EEP_Settings_Objects|environment preset]], or alternately if the ambiance value defined by the probe is higher, the probe's value is used.

There are a few operation modes that are set with the <code>Reflection Probe Ambiance</code> value, in tandem with above:
{| class="wikitable"
|+ Probe Ambiance behavior
! Value !! Description
|-
| 0.00 || Ambient color from the environment applies at full intensity. '''Default for pre-PBR skies.'''
|-
| 0.01 .. 0.99 || Blends ambiance with indirect lighting (sun + emissive or illuminated surfaces) within the probe.
|-
| 1.00 || Indirect light applies at full intensity, without ambient color. '''Default for PBR skies.'''
|-
| 1.01 .. 4.00 || Multiplier for indirect light, makes everything brighter within the probe.
|-
| 4.01 .. 100.00 || Multiplier for indirect light, but only further affects light from the sun. (Local lights are capped to 4.)
|}

=== Complex Reflection Probe placement ===

At times, you may wish to place a reflection probe in an area where the reflection probe types (Sphere or Box) do not conform to the shape of the area. For example, a Box probe in a loft room has a triangular shape, which results in "probe bleed" wherein the influence volume affects an area larger than what is needed, and thus bleeds out onto the exterior roof, which is undesirable.

In these cases, you may need to place multiple probes in order to blend together the sample volumes to achieve the desired result. In the loft room example, it's best to start with 3 box probes, which cover the floor, and each side of the roof. Then, use an additional box probe as "fill" to cover the gap inbetween the 3 probes. The main fill probe may need to be rotated at an angle to get the most coverage possible. If it is not possible to fill the gap between the 3 probes with this fill probe, you may wish to add more box probes to act as "secondary fill".

[TODO: Put photo examples of the above here!]

Alternately, Sphere probes may be used to achieve the same result. Sphere probes have considerably softer blending than box probes, so this may give you the best results in severe bleed conditions.

=== Unsupported use-cases ===
{{KBwarning|Do not attempt to do anything listed below. These uses are liable to either intentionally be disabled, or stop working in future updates.}}
You may be tempted to use reflection probes in the following ways, however these use-cases are either intentionally disabled or result in undefined behavior, and may work now but may not in future. '''You have been warned.'''

'''Under any circumstances, you should NOT:'''
* Wear a reflection probe. This intentionally does not work. (Reflection probes are a property of the scene, not an individual object / avatar)
* Attach a reflection probe to a physics-enabled object, e.g. vehicles. This intentionally does not work. (As above, the reflection probes are part of the scene; not part of an individual object. Reflection probes by design do not update in real-time, thus the object would always have incorrect reflections anyway.)

== PBR Material Composition ==
PBR-defined values are measured by optical sensors and other capture tools and recorded in databases. These parameters are then put into commercial software to be used by content creators. Using software designed to create PBR content is always recommended; however, understanding how PBR materials are assembled can assist with editing and compiling them. Having a direct understanding of what each individual color channel contributes is essential for editing PBR textures without relying upon some of the more advanced toolkits available.

All PBR Values are listed from 0 to 1.0, though in an actual image, the values range from 0 - 255.
PBR Materials are composed of a set of four specifically designed textures; they are as follows:

===Base Color [ RGB ] + Transparency [ A ]===
[RGB]: This is the unlit color of the surface. This differs from the “Diffuse” texture that Second Life uses. Diffuse textures often include faked reflection and specular information as well as added Ambient Occlusion shadows. Base Color textures do not get any of this added information. For metals ( as defined by the metalness value ), Base Color also determines specular reflection color, whereas, in non-PBR systems, this is defined by the Specular texture and tint. In certain PBR texturing applications, Base Color is sometimes also referred to as “Albedo”.
 [ A ]: Alpha Channel, dictates the transparency of the entire material overall.

The Base color texture should be devoid of lighting information.

===Occlusion [R] / Roughness [G] / Metalness [B]===
This texture is composed of 3 unrelated grayscale images stored in 3 different color channels of an RGB texture.
 [R]: (Ambient) Occlusion is lighting data, '''removing''' the need to bake down shadows on to the Base Color map. Note that ''white'' (<1,1,1>) means no occlusion is applied, and ''black'' (<0,0,0>) applies full occlusion.
 [G]: Roughness data ranges from 0 to 1.0, but the actual range of physical surfaces ranges from approximately 0.05 to 0.985. No surface is perfectly smooth or completely rough. The rougher a surface is the less mirror-like it behaves.
 [B]: Metalness values are mostly black or white. Either the material is a conductive metal like copper, or it’s a non-metal like fabric. 0.0 is Non-Metallic, 1.0 is Metallic. There are almost no materials with gray metalness values.
 The alpha channel is ignored, as per the [https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#additional-textures glTF 2.0 specification].

{{Enote|The Occlusion map '''is not''' controlled by the "Screen Space Ambient Occlusion" toggle in the Advanced Graphics Settings. '''The Occlusion map is ''always'' enabled.'''}}

===Emissive [ RGB ]===
This determines the amount and the color of unlit (ignores ambient light conditions) areas of your material. When giving an object a white emissive map, the object will act as if the Blinn-Phong "Fullbright" option was checked. This map is useful for items which are expected to emit light, e.g. a table lamp, where the lamp shade would appear to glow when the lamp is turned on. If you wish to toggle the lamp on and off, it's recommended to change the Emissive Tint value to black (functionally disabling the emissive map, thus turning the lamp off), and then changing the tint back to your desired color to turn the lamp back on. Leaving the Emissive slot empty is recommended when it’s unused.

Note that glow (The postprocessing effect), is controlled by a separate parameter in the build floater and is intentionally not part of the PBR material window. Glow is modulated by the emissive map, so black areas of an object's emissive map will not glow, similar to how Blinn-Phong emissive maps and glow work.

As per the [https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#additional-textures glTF 2.0 specification], the alpha channel is ignored.

===Normal [ RGB ]===
The normal maps generated by your baking application / normal map generation toolkit should be compatible with Second Life in most cases. The most common pitfall is using normal maps generated with “inverted” Green channels, such as those that are used for Direct3D and Unreal Engine. Normal texture data redirects light in a different direction based on the vectors indicated by the color, so if the green channel is backward, it’ll seem to be “pointing the wrong way”. To phrase the problem a different way, all the things that should be bumps look like dents, and vice versa. If this occurs, double check that your settings aren’t for Direct3D and try re-generating it. Also, taking it into image editing software and inverting the green channel only sometimes is a sufficient fix.

Normal map tangent spaces are an extremely technical subject that most users need not be concerned with as most modern applications default to the correct setting. However, if your normal maps look drastically different inside Second Life, compared to your source application, and you’ve already confirmed it’s not an inverted green channel, then checking which tangent space settings are being used is the next step. PBR Normals use Mikkelsen Tangent Space. (Often abbreviated MikkT) If you are unsure what this means, use similar workflows and settings for Second Life PBR as those that are generally recommended for the Godot 4 game engine.

As per the [https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#additional-textures glTF 2.0 specification], the blue channel of a normal map is only allowed to contain values above 0.5 to a max of 1 (255).

As per the [https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#additional-textures glTF 2.0 specification], the alpha channel is ignored.

== Material Reference Libraries ==
As PBR is ''Physically Based'', you may wish to know how to recreate a real-life material in PBR form. What color should you use? What metalness value should it have?

Fortunately, reference libraries exist which can tell you how to recreate a given material in a PBR workflow.

=== List of Reference Color Palettes & libraries ===
*'''[https://physicallybased.info/ Physically Based]'''
** Select the ''Godot'' Engine, with the Color Space as ''sRGB Linear'' and Color Representation as ''0-1'' (Depending on what you are doing, you may need to convert the value into gamma-corrected sRGB space, which can be done [https://davengrace.com/dave/cspace/ here.] Enter the value on the 3rd row.)
*'''[https://www.youtube.com/watch?v=TcTh-1X2FsQ Grzegorz Baran Library]'''
**Available on [https://www.youtube.com/watch?v=TcTh-1X2FsQ YouTube (video format, older)], or [https://gbar.gumroad.com/l/cbwkvo PDF (most up-to-date)].
*'''[https://seblagarde.wordpress.com/2014/04/14/dontnod-physically-based-rendering-chart-for-unreal-engine-4/ Dontnod Entertainment Library]'''
** A very small library, but useful nonetheless.
*'''[https://docs.studio-397.com/developers-guide/general-reference/pbr-an-introduction-authoring-guide Studio 397]'''
** A small collection of various materials.
*'''[http://wiki.polycount.com/wiki/PBR Polycount Wiki]'''
** Not so much a library in itself, but links out to other libraries. '''See the Color Charts section'''.

=== List of PBR asset libraries ===
*'''[https://ambientcg.com/ ambientCG]'''
** Provides CC0 licensed HDRi, Metal-Rough materials and .sbar (Substance Painter material) files.
*'''[https://polyhaven.com/ Poly Haven]'''
** Provides CC0 licensed HDRi, Metal-Rough materials and models.

== Uploading Materials ==
There are two different methods of creating PBR material assets:

=== Method 1 : Direct Upload a glTF File ===
The most convenient method to create an entirely new material is to directly upload a glTF file from your computer.

This is accessible via <code>Build > Upload > Material...</code>
[[File:PBRBuildMenu.jpg | thumb | none | PBR Upload in main build menu. ]]

Select a .GLB or a .GLTF file from your computer and Open it:
This will give the following window:
[[File:PBRMatMenu.jpg | thumb | none| The layout of the PBR material creation and editing interface.]]

All of the editable material properties that most creators are familiar with are integrated into the Material's vertically sizable window on upload.

Clicking “Save” pays the upload fees and creates the Material assets using the local filename. Using "Save As..." provides a window to name all the assets to unique inworld names. There is a 63 char limit for names of inventory assets but the naming floater on this Materials upload has no length restrictions.

Textures will be uploaded to the inventory's default Textures folder (NoMod, NoCopy, Transfer) with an appended "type" added to the given name. (ie. asset name (Base Color), asset name (Normal), asset name (Metallic Roughness). In naming the asset keep in mind that the bracketed appendix is included in the name's 63 character limit. The PBR object is uploaded (Mod, NoCopy, Transfer) to the inventory's Material folder with the appended text (Material). Presently, naming the glTF asset from Save As... will NOT append (Material) to the inventory's name. Saving from the locally named file will.

{{KBcaution|Each individual texture used to compose the Material object is charged a separate upload fee. (ie. If you have 4 textures (Base Color, Metallic Roughness, Emissive, Normal) you are charged 4 times. If you only have a Normal and Metallic-Roughness texture you will be charged for 2, etc.)}}

=== Method 2 : Edit a Blank. Create PBR Materials without a glTF File ===
If you have the necessary textures to compose a PBR material but do not have a glTF file you will need to build a Material from inventory. Make sure your textures are in the correct format, with the correct data in the proper channels. This requires some understanding of how [[PBR_Materials#PBR_Material_Composition:|PBR materials work]]. Once you have that, upload your textures as you normally would.

[[File:PBRMenuUI.jpg | thumb | none | The PBR Materials UI in the Build Floater.]]

* Find the "Materials" folder in your inventory, right click, and select "New Material" from the context menu.
* Name your new material something appropriate (E.g. "Red Bricks" for a red brick wall, etc.)
* Right click on your new material, and select "Open" from the context menu.
* Upload your PBR textures using the standard texture workflow (Usually, under <code>Build > Upload > Image</code>).
* In the material window, select the appropriate maps that you just uploaded in their respective slots.
{{KBwarning|While there may be a temptation to try and place a Blinn-Phong “Diffuse” texture into the “Base Color” slot and a Blinn-Phong “Specular" into the “Metallic/Roughness” slot, doing so will not produce desirable results. However, trying this won’t generate any warnings as there is no way to check that you’ve put the right texture type into the inputs, and the material will save and be applicable to objects. '''Unfortunately, what will be created is not a functional PBR material. Please do not do this.'''}}
* Once done, verify the material parameters are correct (E.g. Base color tint, M/R factor, Emissive tint, etc.)
* Save your new material.
* EITHER: [[PBR Materials#Drag_and_Drop|Drag and drop the material onto a rezzed prim]], OR edit the prim, click the "Blinn-Phong" drop-down, select "PBR Metallic-Roughness", and click "Choose from Inventory", and select your new material.



=== Creating Color Variants ===
After you’ve uploaded your first Material for your project, if you’re a store owner who would like to release more than one color palette for your creation, as many clothing and furniture designers find it useful to do, '''it’s important to not upload a new glTF file for every single variant of your Material'''. Most variant materials, only the base color will change. The Occlusion, Roughness, Metalness, Emissive and Normal map texture slots will remain the same. Since these maps have already been uploaded once, if we upload a second glTF File, they will be duplicated. Having different copies of the same texture, with differing UUID’s means that they will clog up download bandwidth and video card memory (not to mention your inventory as well). This is very bad for Second Life. So, for this reason, it’s recommended that when you create texture variants, you upload the additional copies of the base-color texture separately. Then open your newly uploaded material in edit mode, choose the Base Color texture, and change it out for one of your newly uploaded Base Color textures, and click “Save As”. This will create a second copy of your material that uses all the correct texture maps without needlessly duplicating them and causing additional lag.

{{KBtip| You can also avoid uploading additional textures altogether by uploading a white color variant, then making use of the Base Color Tint parameter!}}

== Double Sided Parameter : Uses and Dangers ==
“Double Sided” is a new property unique to Materials. When “Double Sided” is checked, the surface upon which this material is placed will be drawn twice; once for the outward-facing portion of the surface, and a second time for the inward-facing side of the surface that is normally invisible without a double-sided material. This option should only be used for very specific meshes that were designed to be used with double-sided materials, since placing materials with this parameter checked on normal objects will simply cause the viewer to draw it twice ( and thereby create additional viewer lag ) for no observable change. It is '''very strongly recommended''' that this option be unchecked for any material that is to be distributed for general use. Even more so if the “Modify” permission is revoked. If you wish to distribute a version of a material that has “Double Sided” checked, please include a second copy of the material that has “Double Sided” unchecked as well, with an accompanying explanation to the next user as to why this was done.

Example:
*LeafTextures_DoubleSided
*LeafTextures_SingleSided

When designing mesh content for use with the double-sided material parameter, it is also ''very strongly recommended that you separate the triangles you intend to use the double-sided material upon into a separate mesh “face”'', so as to not unintentionally render the portions of the mesh that already have triangles designed to represent the internal portion of the object a second time.

== LSL Scripting ==

Documentation for the LSL interface with glTF materials can be found on the following pages:
*[[GLTF Overrides]]
*[https://wiki.secondlife.com/wiki/Category:LSL_Material Category:LSL Material]

== Recommended Application Settings ==
The glTF file format is widely adopted and many applications have export functionality for this type of file.
Below is a non-comprehensive list of some of the more popular applications that export glTF files.

{{KBtip|'''The recommended HDRi for use in Second Life content creation is available at [https://github.com/Jenna-Huntsman/Second-Life-Resources/tree/main/PBR/HDRi this Github repository].''' This HDRi will closely match the lighting of objects under the PBR "Midday" environment preset.}}

{{KBcaution|While every effort has been made to ensure the recommended HDRi matches SL as close as possible, you may need to adjust the "Environment Exposure" parameter in your editing program to get 1:1 results with SL.}}
 
----
===[https://www.blender.org/ Blender]===

{{KBwarning|Older Blender versions have bugs in their glTF export tools which make their output incompatible with Second Life. '''Use of Blender versions of 3.3 and above are highly recommended to avoid issues.'''}}
 
{{KBcaution|Please ensure that you correctly set up an HDRi in your viewport, as otherwise the rendering in Blender and in SL will not match. Please see [[PBR Materials#Recommended_Application_Settings|here for a reference HDRi]]. '''Please see [https://www.polygonartists.com/hdri-environment-maps-in-blender/ this tutorial].'''}}

Upon starting your project:

Under: <code>Scene > Render Properties > Color Management</code>:
*{{code|View Transform: Standard}}
*{{code|Sequencer: Linear ACEScg}}

Create your materials within Blender using Principled BSDF Shader Nodes and the glTF Settings node. Export them according to the official '''[https://docs.blender.org/manual/en/3.6/addons/import_export/scene_gltf2.html Blender Documentation.]'''

{{KBcaution|Second Life does not support BSDF Clearcoat, Subsurface, Anisotropy or Transmission parameters at this time.}}

For materials creation, 2 example .blend files are provided, one using separate Occlusion, Roughness and Metallic textures ("Long Form"), and one that handles a pre-packed ORM map ("Short Form")

The below files are intended for use with Blender versions 3.3 and above.

* '''[https://github.com/Jenna-Huntsman/Second-Life-Resources/blob/main/glTF%20Node%20Tree%20-%20Long%20Form.blend glTF Node Tree - Long Form.blend]'''
* '''[https://github.com/Jenna-Huntsman/Second-Life-Resources/blob/main/glTF%20Node%20Tree%20-%20Short%20Form.blend glTF Node Tree - Short Form.blend]'''
 
----
=== [https://www.adobe.com/products/substance3d-painter.html Adobe Substance 3D Painter] ===
{{KBcaution|While Substance Painter is generally considered to be stable, in some (rare) situations Substance may output a malformed glTF which will be rejected by the viewer. If this happens, import your materials into Blender, then export a glTF from Blender - this should be fixed in a future version of Substance.}}
 
{{KBcaution|Please ensure that you correctly set up an HDRi in your viewport, as otherwise the rendering in Substance and in SL will not match. Please see [[PBR Materials#Recommended_Application_Settings|here for a reference HDRi]]. Please see [http://y2u.be/6goXJ2CJzaM this tutorial].}}
When starting your project:

*{{code|Template: PBR - Metallic Roughness Alpha-test (starter_assets)}}

OR

*{{code|Template: PBR - Metallic Roughness Alpha-blend (starter_assets)}}

Verify the following settings:
*{{code|Document Resolution: [Set as desired]}}
*{{code|Normal Map Format: OpenGL (Y+)}}
*{{code|Compute Tangents Per Fragment: YES}}

Under "Color Management":
{{KBtip| For a more in-depth explanation of the below settings, and issues that you may encounter, visit [https://mrlixm.github.io/blog/substance-painter-color-management/#aces-workflow this page].}}
*{{code|Color Management: OpenColorIO}}
*{{code|OpenColorIO Configuration: ACES 1.0.3}}
*{{code|Standard sRGB color space: Utility - sRGB - Texture}}
*{{code|8 bit images: Utility - sRGB - Texture}}
*{{code|16 bit images: Utility - sRGB - Texture}}
*{{code|Material color space default: Utility - sRGB - Texture}}

When exporting:

Settings Tab - Global Settings
*{{code|Output template: glTF PBR Metal Roughness}}
*{{code|Size: Based on each Texture Set's size}}
*{{code|Padding: Dilation + default background color - 8 bit}} '''OR''' {{code|Padding: Dilation infinite}}
{{KBtip|If you encounter color banding (AKA posterization) in your base color texture after export, you may wish to enable dithering.}}
*To enable dithering, open the {{code|Export Textures}} window, under the {{code|Settings}} tab, enable an override for the Base Color texture and swap the output format from {{code|8 bits}} to {{code|8 bits + dithering}}

Settings Tab - Per-Material settings
*{{code|Output maps > Normal Map: 8 bits}}

<li style="display: inline-block;">[[File:Substance_Painter_-_Export_Global_settings.png|thumb|Settings Tab - Global Settings]]</li>
<li style="display: inline-block;">[[File:Substance_Painter_-_Export_Per-Material_settings.png|thumb|Settings Tab - Per-Material settings]]</li>
 
----
=== [https://www.adobe.com/products/substance3d-designer.html Adobe Substance 3D Designer] ===
{{KBcaution|Substance Designer ''does not support glTF output'', unlike Substance Painter.}}

Under preferences, verify the following '''Project''' settings:
*{{code|Color Management: OpenColorIO}}
*{{code|OpenColorIO Configuration: ACES 1.0.3}}
*{{code|8 bit images: Utility - sRGB - Texture}}
*{{code|16 bit images: Utility - sRGB - Texture}}
*{{code|Floating point images: ACES - ACEScg}}
*{{code|2D and 3D View Display Default: sRGB}}

When exporting (Export Outputs):
*{{code|basecolor: Utility - sRGB - Texture}}
*{{code|normal: Utility - Raw}}
*{{code|roughness: Utility - Raw}}
*{{code|metallic: Utility - Raw}}
*{{code|ambientocclusion: Utility - Raw}}

If you use a custom node to output a [[PBR_Materials#Occlusion_.5BR.5D_.2F_Roughness_.5BG.5D_.2F_Metalness_.5BB.5D|pre-compiled ORM map]], this should also be set to Raw.
 
----
=== [https://www.maxon.net/en/cinema-4d Cinema 4D] ===
Please follow the documentation provided in this [https://www.bakedpixels.nl/blog/export-to-gltf-with-cinema-4d blog post].
 
----
===[https://3dcoat.com/ 3DCoat]===
{{KBwarning|As of version "2022-58", 3DCoat is unable to produce a spec-compliant glTF file, and thus should not be used for Second Life. '''Use at your own risk - you ''will'' have issues!}}

glTF export has been implemented since 3DCoat version 2020 and is found in the <code>File >Export > Export to glTF > glTF Separate (gltf + .bin + textures)</code>
 
----
=== [https://quixel.com/mixer Quixel Mixer] ===
Quixel Mixer has no glTF output, however, it does generate the functional textures, though they do need to be edited and combined in photo editing software.
Export them by going to <code>Export Target > Custom</code>

Texture Preset: Metalness Maps

Select:

Albedo , Roughness, Normal, AO , Metalness and ( if need be ) Emissive.

Click “Export to Disk” and open the folder that the files were placed into.

Albedo is the Base Color texture in this case.

AO , Roughness , Metalness get combined into the ORM map as per [[PBR_Materials#PBR_Material_Composition|this explanation.]]

Normal Map : Quixel generates Direct3D Normal Maps. The green channel needs to be inverted as [[PBR_Materials#Normal_.5B_RGB_.5D_|per here.]]

Upload to Second Life using [[PBR_Materials#Method_2_:_Edit_a_Blank._Create_PBR_Materials_without_a_GLTF_File|Method 2.]]
 
----
=== [https://www.autodesk.eu/products/3ds-max/overview Autodesk 3DS Max 2023] ===
Autodesk just added the ability to create glTF files using their new glTF Material and glTF Export functionalities as outlined in '''[https://help.autodesk.com/view/3DSMAX/2023/ENU/?guid=GUID-EFBB037D-C4EB-42D2-9CE1-30FCAD483C31 Autodesk's official documentation]'''. All prior versions of Autodesk software do not have this functionality.
 
----
=== [https://www.materialmaker.org/ Material Maker] ===
While [https://www.materialmaker.org/ Material Maker] does not currently export directly to glTF ([https://github.com/RodZill4/material-maker/issues/479 This may be added in future]), materials created with this program are compatible with Second Life.

Export your materials using the '''Godot 4 ORM''' export preset.

Upload to Second Life using [[PBR_Materials#Method_2_:_Edit_a_Blank._Create_PBR_Materials_without_a_GLTF_File|Method 2.]]
 
----
=== Adobe Photoshop ===
'''While Photoshop is not officially a PBR authoring tool''', the changes to Alpha Blending (changing into Linear space from sRGB) may require you to change your PS settings to get consistent results. Please see [http://www.kiransprojects.com/blog/2014/photoshop-blending-is-broken/ this article] for more information. (See the section titled "A Partial Solution"). Alternatively, [https://www.reddit.com/r/photoshop/comments/61clf8/how_to_fix_photoshops_incorrect_and_ugly_color/ this Reddit post] also gives a few options on how to achieve blending in the correct manner.
 
----
=== GIMP ===
'''While GIMP is not officially a PBR authoring tool''', the changes to Alpha Blending (changing into Linear space from sRGB) in Second Life will make textures created in GIMP display their alphas correctly (GIMP defaults to linear alpha calculation).

== Troubleshooting content ==

If you upload a piece of PBR content which does not match your editor, the advice from Linden Lab is to '''STOP: File a Feedback ticket. Do not attempt to "fix" the content.'''

That said, there are some troubleshooting steps which you can do yourself:
* Check that you are using the PBR Linden Midday preset (called "Midday") ''not "Midday (Legacy)"''. Other environments may not match the reference HDRi, causing some visual differences. (This is intended behaviour, and content should be able to be viewed under any light correctly, but for troubleshooting purposes this may be required).
** At present, there is a bug with the PBR Linden Midday preset which results in an excessive blue sheen, due to the use of an over-saturated (unrealistic) sky color, among some other issues. This has been fixed in the upcoming glTF Maintenance viewer.
* Are you using a reflection probe? If not, does the problem reproduce if a manual reflection probe is placed over the object?
** This is because a common source of the "blue sheen" in interior scenes is the use of an auto-probe. Auto-probes sample their surroundings, and combined with the approximate (and often incorrect) placement this will mean the sky is sampled on all sides, thus meaning the reflected light from the surroundings (which counters the blue light from the sky) is absent, leading to a larger-than-expected level of sky contribution on the object. Auto-probe placement can be worse in skyboxes or sky platforms
* Triple-check the settings used for your editor match the ones given [[PBR_Materials#Recommended_Application_Settings|here]], including the reference HDRi. '''Any''' deviation from these settings may cause visual differences between your editor and in-world.
* Check your content against a glTF reference viewer; such as:
** [https://modelviewer.dev/editor/ Modelviewer.dev]
** [https://github.khronos.org/glTF-Sample-Viewer-Release/ Khronos Sample Viewer]

If the above steps fail, then please '''[https://feedback.secondlife.com/ file some Feedback.]'''

A good Feedback ticket will include:
* An LM to a location where the problem can be examined in-world.
* A copy of the glTF content, attached to the ticket.
* Screenshots of the representation in-world, in a reference viewer, and in-editor.
** You should include screenshots of the object inside a manually placed reflection probe, and outside.

LlLinksetDataFindKeys

2026-03-01T02:10:17Z

Wulfie Reanimator: Added speculative limits.

{{LSL_Function
|func_sleep=0.0|func_energy=10.0
|func=llLinksetDataFindKeys
|p1_type=string|p1_name=pattern|p1_desc=A regular expression describing which keys to return.
|p2_type=integer|p2_name=start|p2_desc=The first key to return.
|p3_type=integer|p3_name=count|p3_desc=The number of keys to return.
|return_type=list
|return_text=of the keys in the datastore.
|func_footnote
|func_desc=
The '''llLinksetDataFindKeys''' function returns a list of up to {{LSLP|count}} keys from the datastore that match {{LSLP|pattern}}, starting at the one indicated by {{LSLP|start}}. If {{LSLP|count}} is less than 1, then all keys between {{LSLP|start}} and the end which match {{LSLP|pattern}} are returned. If {{LSLP|count}} minus {{LSLP|start}} exceeds the number of matching keys, the returned list will be shorter than {{LSLP|count}}, down to a zero-length list if {{LSLP|start}} equals or exceeds the number of matching keys. The list is ordered alphabetically.
|func_footnote
|spec=
{{LSLP|pattern}} is a [https://en.wikipedia.org/wiki/Regular_expression Regular expression].

|caveats=
*The maximum length for {{LSLP|pattern}} seems to be 800 characters.
*There seems to be a timing restriction. If the time limit is exceeded, the function fails silently.
**Returns an empty list and the script continues execution.
|helpers
|also_functions=
{{LSL DefineRow||[[llLinksetDataAvailable]]|}}
{{LSL DefineRow||[[llLinksetDataCountKeys]]|}}
{{LSL DefineRow||[[llLinksetDataDelete]]|}}
{{LSL DefineRow||[[llLinksetDataDeleteProtected]]|}}
{{LSL DefineRow||[[llLinksetDataListKeys]]|}}
{{LSL DefineRow||[[llLinksetDataRead]]|}}
{{LSL DefineRow||[[llLinksetDataReadProtected]]|}}
{{LSL DefineRow||[[llLinksetDataReset]]|}}
{{LSL DefineRow||[[llLinksetDataWrite]]|}}
{{LSL DefineRow||[[llLinksetDataWriteProtected]]|}}
|also_events
|also_tests
|also_articles
|examples=
When {{LSLP|pattern}} matches multiple keys, {{LSLP|start}} can be used to skip over some of the first matches.
<source lang="lsl2">
default
{
state_entry()
{
llLinksetDataWrite("ThingA_config", "value");
llLinksetDataWrite("ThingA_data", "value");
llLinksetDataWrite("ThingB_config", "value");
llLinksetDataWrite("ThingB_data", "value");
llLinksetDataWrite("ThingC_config", "value");
llLinksetDataWrite("ThingC_data", "value");
list keys;

// Return 1 key starting from the first match.
keys = llLinksetDataFindKeys("Thing", 0, 1);
llOwnerSay(llList2CSV(keys)); // ThingA_config

// Return 1 key after skipping the first 3 matches.
keys = llLinksetDataFindKeys("Thing", 3, 1);
llOwnerSay(llList2CSV(keys)); // ThingB_data

// Return up to 10 keys after skipping the first match.
keys = llLinksetDataFindKeys("_data", 1, 10);
llOwnerSay(llList2CSV(keys)); // ThingB_data, ThingC_data
}
}
</source>

The following regular expression code can be used to find UUID keys. (Such as those use to identify user UUID)
<source lang="lsl2">
list keysFound = llLinksetDataFindKeys("(?i)^[0-9a-f]{8}(-[0-9a-f]{4}){3}-[0-9a-f]{12}$", 0, 0);
</source>
The following code can also be used to find UUID keys in LinksetData memory.
<source lang="lsl2">
list keysFound = llLinksetDataFindKeys("^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$", 0, 0);
</source>
''Warning: Keep track of how many UUIDs will be returned, as too many can overwhelm script memory and cause a stack-heap crash.''

The script below uses llLinksetDataFindKeys for blacklist management.
<source lang="lsl2">
integer gDialogChannel;
integer gDialogHandle;
integer gManagingBlocks;

startDialog(key person)
{
gManagingBlocks = 0;
gDialogHandle = llListen(gDialogChannel, "", person, "");
llDialog(person, "\nSelect action", ["List blocks", "Add block", "Remove block"], gDialogChannel);
llSetTimerEvent(60);
}

stopDialog()
{
llSetTimerEvent(0);
llListenRemove(gDialogHandle);
}

default
{

on_rez(integer sp)
{
llResetScript();
}

state_entry()
{
gDialogChannel = (integer)(llFrand(-10000000)-10000000);
llListen(PUBLIC_CHANNEL, "", NULL_KEY, "");;
}

timer()
{
stopDialog();
}

touch_start(integer nd)
{
key toucherKey = llDetectedKey(0);
if (toucherKey == llGetOwner())
{
startDialog(toucherKey);
}
}

listen(integer channel, string name, key id, string message)
{

if (llGetAgentSize(id) == ZERO_VECTOR)
{
return;
}

if (channel == gDialogChannel)
{
stopDialog();
if (gManagingBlocks)
{
message = llStringTrim(message, STRING_TRIM);
if ((key)message)
{
if (gManagingBlocks == 1)
{
llOwnerSay("Addition request has been sent to the blacklist storage");
llLinksetDataWrite("blocklist:" + message, "1");
}
else
{
llOwnerSay("Removal request has been sent to the blacklist storage.");
llLinksetDataDelete("blocklist:" + message);
}
}
else
{
llOwnerSay("The UUID '" + message + "' appears to be invalid.");
}
startDialog(id);
}
else if (message == "List blocks")
{
list blocks = llLinksetDataFindKeys("^blocklist:", 0, 0);
integer listLength = llGetListLength(blocks);
llOwnerSay("Blacklist items: " + (string)listLength);
integer i;
while (i < listLength)
{
string record = llGetSubString(llList2String(blocks, i), 10, -1);
llOwnerSay("- secondlife:///app/agent/" + record + "/about" + " - " + record);
++i;
}
blocks = [];
startDialog(id);
}
else if (message == "Add block" || message == "Remove block")
{
string label = "add to";
gManagingBlocks = 1;
if (message == "Remove block")
{
gManagingBlocks = 2;
label = "remove from";
}
gDialogHandle = llListen(gDialogChannel, "", id, "");
llTextBox(id, "\nPlease specify one single avatar UUID you'd like to " + label + " the blacklist storage.", gDialogChannel);
llSetTimerEvent(60);
}
return;
}

if (llGetListLength(llLinksetDataFindKeys("blocklist:" + (string)id, 0, 1)) > 0)
{
llRegionSayTo(id, 0, "You're blacklisted.");
return;
}

llRegionSayTo(id, 0, "Hello there, secondlife:///app/agent/" + (string)id + "/about - your message: " + message);

}

linkset_data(integer action, string name, string value)
{
if (action == LINKSETDATA_RESET || action == LINKSETDATA_DELETE || action == LINKSETDATA_UPDATE)
{
llOwnerSay("Blacklist storage modified.");
}
}

}</source>
|notes=
{{LSL Regular Expressions}}
|cat1=Script
|cat2=LinksetData
|cat3
|cat4
}}

Lua Alpha

2026-02-26T03:22:19Z

Wulfie Reanimator: Mention for memory limit.

{{Warning|This functionality is in alpha. Instability is to be expected, and there may be very sharp edges. At this point it is expected that Luau can crash regions and perform other types of undesirable behavior.

'''🚨 PLEASE NOTE Memory and performance characteristics, and API specifics may change! Scripts are currently being run in unoptimized form for development purposes.'''}}

= Second Life Lua (SLua) Alpha =

[[File:Luau.png|720px|thumb|right|Luau logo]]

We're thrilled to announce the launch of the SLua Alpha for Second Life! This significant update introduces the [https://lua.org Lua scripting language], offering creators enhanced performance, improved memory efficiency, higher memory limit (128 KB), and a more versatile scripting environment.

To get started, [[Try SLua|read the instructions here.]]

== What is SLua? ==

SLua is scripting for Second Life based on [https://luau.org Luau], a fast, small, safe, and gradually typed embeddable scripting language derived from Lua. It is designed to be backwards compatible with Lua 5.1, incorporating features from future Lua releases and expanding the feature set with type annotations and a state-of-the-art type inference system. Luau is largely implemented from scratch, with the language runtime being a heavily modified version of the Lua 5.1 runtime, featuring a completely rewritten interpreter and other performance innovations.

== Why Lua? ==

The decision to integrate Lua into Second Life was driven by its ability to meet all the requirements for a scripting engine within the platform. Lua offers a high-quality scripting experience to creators, addressing many of the limitations present in the current LSL (Linden Scripting Language) environment. Its lightweight nature and performance optimizations make it an ideal choice for enhancing the scripting capabilities in Second Life. For more information on why Lua was chosen, please see the [[Lua FAQ]].

== How to Get Started with SLua ==

In order to play with SLua, you'll need to download our Lua project viewer, and either log onto our [https://lindenlab.freshdesk.com/support/solutions/articles/31000156725-accessing-aditi Aditi beta grid] or go to the SLua-enabled beta regions on the main grid.

* Access the latest build of the SLua-enabled Second Life Viewer from [https://releasenotes.secondlife.com/viewer.html here].

SLua-enabled regions on the main grid:
* [secondlife:///secondlife/SLua%20Beta%20Landing/128/128/2 SLua Beta Landing]
* [secondlife:///secondlife/SLua%20Beta%20Porridge/128/128/2 SLua Beta Porridge]
* [secondlife:///secondlife/SLua%20Beta%20Eraserhead/128/128/2 SLua Beta Eraserhead]
* [secondlife:///secondlife/SLua%20Beta%20Glass/128/128/2 SLua Beta Glass]
* [secondlife:///secondlife/SLua%20Beta%20Void/128/128/2 SLua Beta Void]
* [secondlife:///secondlife/SLua%20Beta%20Anderson/128/128/2 SLua Beta Anderson]
* [secondlife:///secondlife/SLua%20Beta%20Snausage/128/128/2 SLua Beta Snausage (Adult)]
* [secondlife:///secondlife/SLua%20Beta%20Nicolse/128/128/2 SLua Beta Nicolse]
* [secondlife:///secondlife/SLua%20Beta%20IsNeat/128/128/2 SLua Beta IsNeat]

SLua-enabled regions on the beta grid:
* [secondlife://Aditi/secondlife/SLua%20Yardang/241/235/27 SLua Yardang]
* [secondlife://Aditi/secondlife/SLua%20Tombolo/241/235/27 SLua Tombolo]
* [secondlife://Aditi/secondlife/SLua%20Mesa/241/235/27 SLua Mesa]
* [secondlife://Aditi/secondlife/SLua%20Tideland/241/235/27 SLua Tideland]

When editing a script in the new Lua project viewer, you'll notice a new '''Compiler''' drop-down near the save button. This drop-down will allow you to select which compiler will be used, as well as which script runtime will be used (LSO2, Mono, Luau).

[[File:Compiler_dropdown.png|Compiler selection dropdown]]

Compiler drop-down options:

* '''LSL: Legacy (LSO2)''' - Scripts written in LSL, to be run on the old LSO2 VM
* '''LSL: Mono'''- Scripts written in LSL, to be run on the Mono VM
* '''Lua''' - Scripts written in Lua, to be run on the SLua VM
* '''LSL: 2025 VM'''- Scripts written in LSL, to be run on the SLua VM

=== Transitioning from LSL to SLua ===
* '''Function Namespacing:'''
** In SLua, Linden Lab functions have been moved under the '''ll''' namespace.
** For example:
*** ''llSay'' becomes ''ll.Say''
*** ''llGetPos'' becomes ''ll.GetPos''
* '''Lists'''
** Lua indexes begin from 1, unlike LSL where indexes begin from 0.
** Lua uses <syntaxhighlight lang="lua" inline>{}</syntaxhighlight> for ''tables'', unlike LSL where <syntaxhighlight lang="lua" inline>[]</syntaxhighlight> is used for ''lists''.
* Types
** SLua doesn't support the usual vector/rotation syntax <syntaxhighlight lang="lua" inline><x, y, z></syntaxhighlight>
*** Instead, these values are created with the functions <syntaxhighlight lang="lua" inline>vector(x, y, z)</syntaxhighlight>, <syntaxhighlight lang="lua" inline>rotation(x, y, z, s)</syntaxhighlight>
*** Similar functions exist for '''uuid''' (key) and '''integer''' (distinct from the built-in '''number''' type)

=== SLua Libraries ===
* '''Coroutines:'''
** SLua supports coroutines, allowing for cooperative multitasking within scripts.
** Key functions include:
*** ''coroutine.create''
*** ''coroutine.status''
*** ''coroutine.resume''
** Refer to the [https://luau.org/library#coroutine-library coroutine library documentation] for more details.
* '''Bitwise Operations:'''
** SLua includes a ''bit32'' library for bitwise operations, enabling more efficient data manipulation.
** Refer to the [https://luau.org/library#bit32-library bit32 library documentation] for more details.
* '''JSON to Table Translation:'''
** SLua includes a modified [https://github.com/openresty/lua-cjson lua-cjson library] that translates tables into JSON objects and arrays and back.
** Vectors and quaternions are converted to strings, which may be changed back using the ''tovector'' and ''toquaternion'' functions, respectfully.
** Buffers are encoded as Base64 strings. They may be decoded using the ''llbase64.decode'' function.
** Functions:
*** <syntaxhighlight lang="lua" inline>json_text = lljson.encode(some_table)</syntaxhighlight>
*** <syntaxhighlight lang="lua" inline>some_table = lljson.decode(json_text)</syntaxhighlight>
* '''Base64 Encoding:'''
** A Base64 library capable of handling SLua strings and binary buffers, unlike classic ''ll'' namespace functions.
** Leveraged by the JSON functionality, but can also be called separately.
** Functions:
*** <syntaxhighlight lang="lua" inline>base64string = llbase64.encode(string_or_buffer)</syntaxhighlight>
*** <syntaxhighlight lang="lua" inline>str = llbase64.decode(base64string)</syntaxhighlight> for strings
*** <syntaxhighlight lang="lua" inline>buf = llbase64.decode(base64string, true)</syntaxhighlight> for buffers
* '''Standard Library:'''
** SLua comes equipped with a standard library of functions designed to manipulate built-in data types.
** Explore the [https://luau.org/library Luau Standard Library] for a comprehensive list of available functions.

== Feedback and Support ==

We encourage all creators to explore the new scripting capabilities and provide feedback. Your insights are invaluable in refining and enhancing this feature. For more information and to share your experiences, please refer to our [[Lua FAQ]].

== Example Scripts ==

To help you get started, we've assembled some example scripts that demonstrate the capabilities of SLua. These scripts cover various functionalities and can serve as a foundation for your own creations. Please feel free to propose changes to these scripts, or modify them to your heart's desire!

=== default_script.lua ===
This script is roughly equivalent to the default "new script" that gets created for LSL.
<syntaxhighlight lang="lua">
function state_entry()
ll.Say(0, "Hello, Avatar!")
end

LLEvents:on("touch_start", function(detected: {DetectedEvent})
ll.Say(0, "Touched.")
end)

-- Simulate the state_entry event
state_entry()
</syntaxhighlight>

=== dialog.lua ===
This script demonstrates how one can interact with dialog menus.
<syntaxhighlight lang="lua">
-- Define the menu buttons and dialog message.
local buttons = {"-", "Red", "Green", "Yellow"}
local dialogInfo = "\nPlease make a choice."

local ToucherID = nil
local dialogChannel = nil
local listenHandle = nil
local timerHandle = nil

-- This function is called when the script first starts.
function state_entry()
-- Get the object's key and compute a dialog channel number.
local key = ll.GetKey()
-- Extract the last 7 characters of the key and convert it from hex.
dialogChannel = -1 - tonumber(string.sub(tostring(key), -7, -1), 16)
end

-- Called when the object is touched.
LLEvents:on("touch_start", function(detected: {DetectedEvent})
ToucherID = detected[1]:getKey()
-- If there is already a listen handle, then remove it
if listenHandle then
ll.ListenRemove(listenHandle)
end
listenHandle = ll.Listen(dialogChannel, "", ToucherID, "")
ll.Dialog(ToucherID, dialogInfo, buttons, dialogChannel)
-- Set a 60-second timer for response.
if timerHandle then
LLTimers:off(timerHandle)
end
timerHandle = LLTimers:once(60,timeoutListen)
end)

-- Called when a dialog response is received.
LLEvents:on("listen", function(channel, name, sender_id, message)
if message == "-" then
-- Redisplay the dialog if the "-" option is selected.
ll.Dialog(ToucherID, dialogInfo, buttons, dialogChannel)
return
end
-- Stop the timer, and stop the listening handler.
ll.ListenRemove(listenHandle)
listenHandle = nil
if timerHandle then
LLTimers:off(timerHandle)
end
-- Let the user know what they selected
ll.Say(0, `You selected {message}`)
end)

-- Called when the timer expires.
function timeoutListen()
-- Stop the timer and clean up the listener.
if listenHandle then
ll.ListenRemove(listenHandle)
ll.Whisper(0, "Sorry. You snooze; you lose.")
end
end

-- Invoke state_entry on startup, since simulator doesn't invoke
-- it like it does in LSL
state_entry()
</syntaxhighlight>

=== user_input_coroutine.lua ===
This script demonstrates [https://www.lua.org/pil/9.html coroutines] and how they can simplify the overarching logic of a script, enabling us to write the bulk of our multi-event code within a centralized function instead of fragmenting across separate event handlers.
<syntaxhighlight lang="lua">
-- Wait for user input mid-function before doing something useful with it.
main = function(toucher)
local handle = ll.Listen(0, "", toucher, "")
local event = touch_start -- save function for later
touch_start = nil -- disable touch_start

ll.RegionSayTo(toucher, 0, "Do you want pants or gloves?")
local clothing = coroutine.yield() -- pause the routine's execution here
ll.RegionSayTo(toucher, 0, "For men or women?")
local gender = coroutine.yield()
ll.RegionSayTo(toucher, 0, "Favorite color?")
local color = coroutine.yield()
ll.RegionSayTo(toucher, 0, "Here's "..color.." "..clothing.." for "..gender)

ll.ListenRemove(handle)
touch_start = event -- restore touch_start
end

LLEvents:on("touch_start",function(detected: {DetectedEvent})
local toucher = detected[1]:getKey()
routine = coroutine.create(main) -- new coroutine
coroutine.resume(routine, toucher) -- run coroutine (with one argument)
end)

-- When the coroutine is suspended, incoming events can be handled
-- and we can resume() execution of the routine
-- and pass any number of arguments to be returned by yield()
LLEvents:on("listen", function(channel, name, id, message)
coroutine.resume(routine, message)
end)
</syntaxhighlight>

=== multi_user_input_coroutine.lua ===
Following from the above example, how can we handle multiple users? This is where coroutines shine.

Instead of disabling touches to prevent others from interacting with the object, we can create new copies of the coroutine each time an avatar touches the object. We can then resume whichever coroutine is needed, based on the avatar, while all of them track their own progress separately and automagically.
<syntaxhighlight lang="lua">
-- Key: avatar uuid; Value: coroutine thread
routines = {}

main = function(toucher)
local handle = ll.Listen(0, "", toucher, "")

ll.RegionSayTo(toucher, 0, "Do you want pants or gloves?")
local clothing = coroutine.yield()
ll.RegionSayTo(toucher, 0, "For men or women?")
local gender = coroutine.yield()
ll.RegionSayTo(toucher, 0, "Favorite color?")
local color = coroutine.yield()
ll.RegionSayTo(toucher, 0, "Here's "..color.." "..clothing.." for "..gender)

ll.ListenRemove(handle)
routines[toucher] = nil -- Remove from collection
end

LLEvents:on("touch_start",function(detected: {DetectedEvent})
local toucher = detected[1]:getKey()
local routine = routines[toucher]
if not routine then -- New user needs new routine
routine = coroutine.create(main)
routines[toucher] = routine -- Add to collection
coroutine.resume(routine, toucher)
end
end)

LLEvents:on("listen", function(channel, name, id, message)
coroutine.resume(routines[id], message) -- Resume a specific coroutine
end)
</syntaxhighlight>

=== More Examples ===

* Find more example scripts at [[Luau Example Scripts]]

* [https://roblox.github.io/lua-style-guide/gotchas/ Lua Gotchas, Footguns and Other Hazards]

[[Category:Lua]]

LlGetUsedMemory

2026-02-18T02:52:24Z

Wulfie Reanimator: GC cite.

{{LSL_Function
|func_id=???|func_sleep=0.0|func_energy=10.0
|func=llGetUsedMemory
|return_type=integer
|func_desc
|Return_text=of the number of bytes of memory currently in use by the script.
|func_footer
|spec=
This function's behavior is dependent upon the VM the script is using. [[#Mono|Mono]] is the new VM, [[#LSO|LSO]] is the old VM. The big difference between Mono and LSO is that Mono scripts run faster and can utilize four times more memory.

===Mono===

In Mono the value returned is the amount of memory currently in use by the script. This is achieved by searching the script's stack and counting all reachable resources. In terms of garbage collection, memory that hasn't been GC'd doesn't count against the script's memory limit when it's no longer reachable.{{Footnote|Explanation given by Harold Linden in the official Discord server.}}

The reason why Mono/[[SLua Alpha|SLua]] implements its memory limits this way is because there's a single VM/GC governing their scripts, and you don't want to "stop the world" to run the garbage collector just to see if you can get a single script back under its limit.

===LSO===

LSO scripts always use 16KiB of memory.

|caveats=
*Scripts compiled to LSO always report 16KB memory used.
*This can be called at any time and does '''not''' require [[llScriptProfiler]]
|constants
|examples=
Calling llGetUsedMemory can look like this:
<source lang="lsl2">
integer used_memory = llGetUsedMemory();
llOwnerSay((string)used_memory + " bytes of memory currently used.");
</source>
|helpers
|also_functions=
{{LSL DefineRow||[[llGetFreeMemory]]|}}
{{LSL DefineRow||[[llSetMemoryLimit]]|}}
{{LSL DefineRow||[[llScriptProfiler]]|}}
|also_events
|also_tests
|also_articles
|notes=The amount of used memory is updated only at the start of a server frame, meaning the values from this function can fluctuate. To ensure stable values, it's possible to wait until the next frame, e.g. [[llSleep]](0.01) before the call to llGetUsedMemory.
|lso
|cat1=Script
|cat2=Memory
|cat3
|cat4
|history = Date of Release [[ Release_Notes/Second_Life_Server/11#11.06.17.233176 | 17/06/2011 ]]
}}

LlGetFreeMemory

2026-02-18T02:47:31Z

Wulfie Reanimator: Citation needed, fixed invisible footnote.

{{LSL_Function
|func_id=225|func_sleep=0.0|func_energy=10.0
|func=llGetFreeMemory
|return_type=integer
|func_desc
|Return_text=of the number of free bytes of memory the script can use.
|func_footer
|spec=
This function's behavior is dependent upon the VM the script is using. [[#Mono|Mono]] is the new VM, [[#LSO|LSO]] is the old VM. The big difference between Mono and LSO is that Mono scripts run faster and can utilize four times more memory.

===Mono===

In Mono the value returned is the amount of free memory available to the script prior to garbage collection being run. This means that memory that is awaiting garbage collection counts against the scripts 64KiB allotment. {{Cn}}

In addition to this, Mono does not enforce the memory restrictions as strictly as the LSO VM did{{Footnote|http://www.langnetsymposium.com/2009/talks/17-JimPurbrick-SecondLife.html}}{{Footnote|In LSO, all types are immutable, every operation results in Heap values being duplicated}}. (With LSO it was impossible to exceed the 16KiB memory cap.)

===LSO===

In LSO, the value returned by this function is the amount of memory that the Stack can use of the Heap has yet to allocate for itself.

The LSL memory space is divided into four sections: Byte-code, Stack, Free Memory, Heap. Free Memory isn't an allocated block of memory, it's just the space between Stack and Heap. The size of all four sections combined is 16384 bytes (16KiB).

[[String]]s, [[list]]s and [[key]]s are stored in the Heap. Heap pointers (for [[string]]s, [[list]]s & [[key]]s), [[integer]]s, [[float]]s, [[vector]]s and [[rotation]]s are all temporarily stored in the stack as the script executes.

As the script executes the Stack grows and shrinks in size depending upon the complexity of the expressions being executed. Likewise the Heap grows as the script executes but unlike the Stack, it never shrinks in size. When there is no free memory left for Stack or Heap to use they collide and a Stack-Heap Collision error is thrown causing the script to crash.

The Heap can become fragmented and blocks of memory in it can become unusable (due to their size). There is no defragment function{{Footnote|Due to the design of the LSO VM, a defragment function is impossible.}} but there are scripting techniques that can be used to reduce fragmentation.
|caveats=
*The number of free bytes the Heap can use may be greater but not less.
*"''the number of free bytes of memory the script can use''" means that if a memory limit is set (via [[llSetMemoryLimit]]), this function will report the free space between the script's current memory usage and the defined memory limit, '''not''' the uncapped memory limit.
|constants
|examples=
Calling [[llGetFreeMemory]] can look like this:
<syntaxhighlight lang="lsl2">
llOwnerSay((string)llGetFreeMemory() + " bytes of free memory available for allocation.");
</syntaxhighlight>
|helpers
|also_functions=
{{LSL DefineRow||[[llGetUsedMemory]]|}}
{{LSL DefineRow||[[llScriptProfiler]]|A more advanced function for analyzing script performance, and can also measure memory usage over time.}}
{{LSL DefineRow||[[llSetMemoryLimit]]|Define a memory limit (lower than the maximum for the appropriate VM).}}
|also_events
|also_tests
|also_articles=
{{LSL DefineRow||[[LSL Errors#Script_run-time_error:_Stack-Heap_Collision|Stack-Heap Collision]]|[[LSL Errors|LSL Error]] caused by the script running out of memory.}}
|notes=The amount of free memory is updated only at the start of a server frame, meaning the values from this function can fluctuate. To ensure stable values, use a single-frame sleep, e.g. [[llSleep]](0.01) before the call to llGetFreeMemory.
|lso=This function does not count free memory, and the name of this function makes this function difficult for people to learn. People say this function may be redefined or superseded by another more useful function when the LSL VM moves to [[Mono]].

We can concisely specify [[llGetFreeMemory]] in the context of the classic Unix model for a parallel task/ thread/ process. Think of the task of the script always holding 16384 bytes (16 KiB). Let the byte code and then stack grow up from the bottom, let the heap grow down from the top. [[llGetFreeMemory]] then returns the "historic lowest heap pointer minus the stack end pointer".

llGetFreeMemory does not count the bytes freed, [[llGetFreeMemory]] instead counts all the bytes never yet used.
|cat1=Script
|cat2=Memory
|cat3
|cat4
}}

LlGetUsedMemory

2026-02-18T02:29:41Z

Wulfie Reanimator:

{{LSL_Function
|func_id=???|func_sleep=0.0|func_energy=10.0
|func=llGetUsedMemory
|return_type=integer
|func_desc
|Return_text=of the number of bytes of memory currently in use by the script.
|func_footer
|spec=
This function's behavior is dependent upon the VM the script is using. [[#Mono|Mono]] is the new VM, [[#LSO|LSO]] is the old VM. The big difference between between Mono and LSO is that Mono scripts run faster and can utilize four times more memory.

===Mono===

In Mono the value returned is the amount of memory currently in use by the script. This is achieved by searching the script's stack and counting all reachable resources. In terms of garbage collection, memory that hasn't been GC'd doesn't count against the script's memory limit when it's no longer reachable.

The reason why Mono/[[SLua Alpha|SLua]] implements its memory limits this way is because there's a single VM/GC governing their scripts, and you don't want to "stop the world" to run the garbage collector just to see if you can get a single script back under its limit.

===LSO===

LSO scripts always use 16KiB of memory.

|caveats=
*Scripts compiled to LSO always report 16KB memory used.
*This can be called at any time and does '''not''' require [[llScriptProfiler]]
|constants
|examples=
Calling llGetUsedMemory can look like this:
<source lang="lsl2">
integer used_memory = llGetUsedMemory();
llOwnerSay((string)used_memory + " bytes of memory currently used.");
</source>
|helpers
|also_functions=
{{LSL DefineRow||[[llGetFreeMemory]]|}}
{{LSL DefineRow||[[llSetMemoryLimit]]|}}
{{LSL DefineRow||[[llScriptProfiler]]|}}
|also_events
|also_tests
|also_articles
|notes=The amount of used memory is updated only at the start of a server frame, meaning the values from this function can fluctuate. To ensure stable values, it's possible to wait until the next frame, e.g. [[llSleep]](0.01) before the call to llGetUsedMemory.
|lso
|cat1=Script
|cat2=Memory
|cat3
|cat4
|history = Date of Release [[ Release_Notes/Second_Life_Server/11#11.06.17.233176 | 17/06/2011 ]]
}}

LlGetUsedMemory

2026-02-18T02:20:06Z

Wulfie Reanimator: GC note.

{{LSL_Function
|func_id=???|func_sleep=0.0|func_energy=10.0
|func=llGetUsedMemory
|return_type=integer
|func_desc
|Return_text=of the number of bytes of memory currently in use by the script.
|func_footer
|spec=
This function's behavior is dependent upon the VM the script is using. [[#Mono|Mono]] is the new VM, [[#LSO|LSO]] is the old VM. The big difference between between Mono and LSO is that Mono scripts run faster and can utilize four times more memory.

===Mono===

In Mono the value returned is the amount of memory currently in use by the script. This is achieved by searching the script's stack and counting all reachable resources. In terms of garbage collection, memory that hasn't been GC'd doesn't count against the script's memory limit when it's no longer reachable.

===LSO===

LSO scripts always use 16KiB of memory.

|caveats=
*Scripts compiled to LSO always report 16KB memory used.
*This can be called at any time and does '''not''' require [[llScriptProfiler]]
|constants
|examples=
Calling llGetUsedMemory can look like this:
<source lang="lsl2">
integer used_memory = llGetUsedMemory();
llOwnerSay((string)used_memory + " bytes of memory currently used.");
</source>
|helpers
|also_functions=
{{LSL DefineRow||[[llGetFreeMemory]]|}}
{{LSL DefineRow||[[llSetMemoryLimit]]|}}
{{LSL DefineRow||[[llScriptProfiler]]|}}
|also_events
|also_tests
|also_articles
|notes=The amount of used memory is updated only at the start of a server frame, meaning the values from this function can fluctuate. To ensure stable values, it's possible to wait until the next frame, e.g. [[llSleep]](0.01) before the call to llGetUsedMemory.
|lso
|cat1=Script
|cat2=Memory
|cat3
|cat4
|history = Date of Release [[ Release_Notes/Second_Life_Server/11#11.06.17.233176 | 17/06/2011 ]]
}}

Server architecture

2026-01-27T21:23:39Z

Wulfie Reanimator: /* Simulator */

{{OSWikiLearnBox}}

This wiki is mainly focused on the viewer, since that is the portion of the system that is open source. However, because the viewer interacts with the Second Life servers in somewhat complicated ways, it is helpful to have an understanding of what components do what on the server side.

Much of what you'll need to understand is actually covered in the [[protocol|protocol documentation]]. In particular, take a look at [[Authentication Flow]], which outlines the process by which the viewer establishes connections with a number of components.

''(obsolete)'' if you want to see what the architecture may look like in the future, or if you would like to help shape it, visit the [[Architecture Working Group]].

== Components ==
=== Login server ===
CGI script running on login.agni.lindenlab.com. Handles verification of user name and password. Determines the login region based on home vs. last location vs. URL specified location. Finds the simulator process running that region and verifies user is allowed to connect there. Alerts the simulator to expect a connection. Informs the viewer of where to connect.

=== Spaceserver ===
Handles routing of messages based on grid x,y locations. Simulator talks to Space Server to *register* and also find who the neighbors are.

=== Dataserver ===
Handles connections to the central database, log database, inventory database(s) and search database(s). Performs queries on behalf of the simulator process.

=== Simulator ===
The primary SL server process. Each simulator process simulates one 256x256 meter region.

There are about 26,000 regions in total in 2026. Each one is hosted on an AWS EC2 instance within an AWS ECS container.

It handles storing object state, land parcel state, and terrain height-map state. It performs visibility calculations on objects and land and transmits the data to the viewer. It transmits texture data in a prioritized queue. Physics simulation is handled with the Havok physics library. Chat and instant messages are processed here. The viewer is handed off from one simulator to another as it moves between regions.

Running at full tilt, a simulator will run at 45 frames/sec. If it can't keep up, it will attempt time dilation without reducing frame rate. More details on work performed during a frame are in [[Simulator Main Loop]].

Simulators communicate with one another using a [[circuit]] via UDP. A "circuit" is a UDP network connection. Circuits are maintained between adjacent simulators.

==== Simulator vs. Viewer ====

It helps to understand the division of labor between the simulator and the viewer, since the split in Second Life is very different than most other virtual environments:

* Simulator's job:
** Runs physics engine
** Collision detection
** keeps track of where everything is
** Sends locations of stuff to viewer
** Sends updates to viewers only when needed (only when collision occurs or other changes in direction, velocity etc.)
* Viewer's job:
** Handle locations of objects
** Gets velocities and other physics information, and does simple physics to keep track of what is moving where
** No collision detection

=== Other servers ===

* Central Backbone
* Agent Database
** Agent DB keeps track of metadata<->item id (UUID) mapping
* Central DB (CDB)
** a list of who owns what, used for billing, etc
* Find DB (replica of Central DB used for search)
* Map server - renders overall map with OpenGL
* RPC server
** API for developers to manupulate Second Life without using the viewer
** Translates XMLRPC server into in-world requests
** Communicates with space server and CDB
* Region Conductor
** Looks for regions that should be running, but are down
** Start those regions on a sim host that has room for it
** Grid Restart Modes
*** Startup Mode: Regions are stuck on the current sim host
*** Normal Mode: Regions are sent to a random sim host

LlSensor

2026-01-04T22:46:56Z

Wulfie Reanimator: Added SCRIPTED caveat.

{{LSL_Function
|inject-2={{LSL_Function/uuid|id|object=*|sim=*}}{{LSL Constants/Sensing|type}}
|func_id=28|func_sleep=0.0|func_energy=10.0
|sort=Sensor|func=llSensor
|func_desc=
Performs a single scan for {{LSLP|name}} and {{LSLP|id}} with {{LSLP|type}} within {{LSLP|radius}} meters and {{LSLP|arc}} radians of forward vector.

Script execution continues immediately. When the scan is completed, a [[sensor]] or [[no_sensor]] event is put in the event queue.
|p1_type=string|p1_name=name|p1_hover=object or avatar name|p1_desc=object or avatar name[[#NameFormat|!]]
|p2_type=key|p2_name=id|p2_desc=
|p3_type=integer|p3_name=type
|p3_desc=[[:Category:LSL_Integer/bit_field|bit field]] ({{#var:AGENT}}, {{#var:AGENT_BY_LEGACY_NAME}}, {{#var:AGENT_BY_USERNAME}}, {{#var:ACTIVE}}, {{#var:PASSIVE}}, and/or {{#var:SCRIPTED}})
|p3_hover=bit field (AGENT, AGENT_BY_LEGACY_NAME, AGENT_BY_USERNAME, ACTIVE, PASSIVE, and/or SCRIPTED)
|p4_type=float|p4_name=radius
|p4_desc=distance in meters from center, {{Interval|gte=0.0|center=radius|lte=96.0}}
|p4_hover=distance in meters from center, {{Interval/Hover|gte=0.0|center=radius|lte=96.0}}
|p5_type=float|p5_name=arc
|p5_desc=the max angle between the object's local X-axis and detectable objects, {{Interval|gte=0.0|lteh=PI|lte={{#var:PI}}|center=arc}}
|p5_hover=the max angle between the object's local X-axis and detectable objects, {{Interval/Hover|gte=0.0|lteh=PI|lte={{#var:PI}}|center=arc}}
|func_footnote=If {{LSLP|name}} and/or {{LSLP|id}} are empty, they are ignored. If {{LSLP|id}} is an invalid key or [[NULL_KEY]] it is treated as empty. Depending upon which AGENT* flag is used determines the format requirements for {{LSLP|name}}

See: [https://web.archive.org/web/20150426032518/http://www.lslwiki.net/lslwiki/wakka.php?wakka=llSensor llSensor] for an excellent explanation of {{LSLP|arc}}.
|return_text
|spec
|caveats=
*AGENT, PASSIVE and ACTIVE behave inclusively. SCRIPTED is '''not''' inclusive and will exclude non-scripted targets (like avatars) from the detected set.
*Objects do not detect themselves, and attachments cannot detect their wearers (this includes HUD attachments).
*Attachments cannot be detected by llSensor.
*For an object to be detected, the center of its root prim (the same point it would report with [[llGetRootPosition]]) must be within the sensor beam.
*For an agent to be detected, a point near the pelvis must be inside the sensor beam (the same as llGetRootPosition would report in a script attached to that avatar). This point is indicated by red crosshairs when Advanced>Character>Display Agent Target is turned on.
**If the agent is sitting on an object, the root prim of the sat upon object becomes a second sensor target for the agent (but not if the avatar is outside the sensor arc, see {{Jira|SVC-5145}}).
*Sensors placed in the root prim of attachments will use the direction the avatar is facing as their forward vector. In mouselook, this means that it will be wherever the avatar is looking, while out of mouselook, this means whichever way the avatar is pointing. This does not include where the avatar's head is pointing, or what animation the avatar is doing, just the direction the avatar would move in if you walked forward. This is the case, regardless of where the object is attached.
*Sensors placed in prims other than the root prim of an attachment will have their forward direction offset relative to the root prim's forward direction, e.g. a sensor in a prim whose +X direction is the reverse of the root +X will look backward.
*llSensor does not detect objects or agents across region boundaries
*If {{LSLP|type}} is zero, the sensor will silently fail, neither [[sensor]] or [[no_sensor]] will be triggered.
*Only 32 objects will be scanned each time. (Increased from 16 with Release 2024-03-18.8333615376 on Tuesday, March 19, 2024)
*DAMAGEABLE is a filter flag; it cannot be used on its own. It must be combined with at least one other flag. For example, AGENT | ACTIVE | PASSIVE | DAMAGEABLE will return all damageable agents and objects, whether physical or not.
|examples=
This sensor scans a 45 degree cone about the x-axis ([[PI]]/2 or [[PI_BY_TWO]] scans a hemisphere; [[PI]] is a spherical scan). Also it will only match an agent with the {{LSLGC|Avatar/Name|legacy name}} "Governor Linden".
<syntaxhighlight lang="lsl2">llSensor( "Governor Linden", NULL_KEY, AGENT_BY_LEGACY_NAME, 96.0, PI/4 );</syntaxhighlight>

This sensor detects all prims and agents with a given name within 15m of the sensor. (AGENT, PASSIVE and ACTIVE behave inclusively. SCRIPTED is not inclusive and will exclude non-scripted targets (like avatars) from the detected set.)
<syntaxhighlight lang="lsl2">llSensor( "", NULL_KEY, ( AGENT | PASSIVE | ACTIVE ), 15.0, PI );</syntaxhighlight>

Basic example script that when touched executes a sensor scan of agents. When the sensor event is processed it spits out messages to the owner of each detected agents' name.
<syntaxhighlight lang="lsl2">
default
{
touch_start(integer total_number)
{
llSensor("", NULL_KEY, AGENT, 30.0, PI);
}

sensor( integer detected )
{
while(detected--)
{
llOwnerSay(llDetectedName(detected));
}
}
}
</syntaxhighlight>

|helpers
|also_functions=
{{LSL DefineRow||[[llSensorRepeat]]| Runs a sensor on a timer}}
{{LSL DefineRow||[[llSensorRemove]]| Stops the llSensorRepeat timer}}
|also_events=
{{LSL DefineRow||[[sensor]]|Triggered when a sensor detects something}}
{{LSL DefineRow||[[no_sensor]]|Triggered when a sensor detects nothing}}
|also_articles
|notes=
{{LSL Tip|You might want to use [[llGetAgentList]] instead of using sensors to get a list of all avatars within the same parcel or region.}}
====Loops & Repetition====
Using [[llSensor]] in a [[for]] loop is a beginners mistake, as events will not interrupt each other (the sensor event will not interrupt whatever event is currently being executed). To perform repeat sensor sweeps, [[llSensorRepeat]] is the better solution. While it is possible to call llSensor from a [[timer]] event, it is less efficient to do so; there is a limit to the number of events that can be processed in a second and using the timer just to call llSensor will result in your script getting less timeslice.
|permission
|negative_index
|cat1=Sensor
|cat2=Detected
|cat3=Username/As A Parameter
|cat4=Legacy Name/As A Parameter
|haiku={{Haiku|The hounds are straining.|Elusive quarry sighted.|The game's afoot!}}
}}
<div id="box">
==Gallery==
<gallery>
File:sensor_pi_by_four.png|arc = PI / 4
File:sensor_pi_by_two.png|arc = PI / 2
File:sensor_pi.png|arc = PI
</gallery>
</div>

Internal Textures

2026-01-04T22:01:46Z

Wulfie Reanimator: Added blank texture variation.

__NOTOC__ {{Multi-lang|category=LSL}}{{LSL Header}}

Various Textures built into the viewer

{| class="sortable" {{prettytable}}
|-{{Hl2}}
!Texture Name
![[UUID]]
!Description
|-
|[[TEXTURE_DEFAULT]]
|89556747-24cb-43ed-920b-47caed15465f
|Default plywood texture
|-
|[[TEXTURE_PLYWOOD]]
|89556747-24cb-43ed-920b-47caed15465f
|Default plywood texture
|-
|[[TEXTURE_BLANK]]
|5748decc-f629-461c-9a36-a35a221fe21f
|Blank, all white texture in the Texture window
|-
|Blank *
|5b53359e-59dd-d8a2-04c3-9e65134da47a
|Neutral normal map, RGB 127,127,255 when the "Blank" button is clicked on the "Normal" texture slot.
|-
|[[TEXTURE_TRANSPARENT]]
|8dcd4a48-2d37-4909-9f78-f7a9eb4ef903
|*Default Transparent Texture
|-
|[[TEXTURE_MEDIA]]
|8b5fec65-8d8d-9dc5-cda8-8fdf2716e361
|Also triggers targeting
|-
|[[Invisiprim]] 1
|38b86f85-2575-52a9-a531-23108d8da837
|Hides alpha textures behind it
|-
|[[Invisiprim]] 2
|e97cf410-8e61-7005-ec06-629eba4cd1fb
|Hides alpha textures behind it
|-
|IMG_USE_BAKED_HEAD
|5a9f4a74-30f2-821c-b88d-70499d3e7183
|Sets face to use specified channel for [https://community.secondlife.com/knowledgebase/english/bakes-on-mesh-r1512/ Bakes on Mesh]
|-
|IMG_USE_BAKED_UPPER
|ae2de45c-d252-50b8-5c6e-19f39ce79317
|Sets face to use specified channel for [https://community.secondlife.com/knowledgebase/english/bakes-on-mesh-r1512/ Bakes on Mesh]
|-
|IMG_USE_BAKED_LOWER
|24daea5f-0539-cfcf-047f-fbc40b2786ba
|Sets face to use specified channel for [https://community.secondlife.com/knowledgebase/english/bakes-on-mesh-r1512/ Bakes on Mesh]
|-
|IMG_USE_BAKED_EYES
|52cc6bb6-2ee5-e632-d3ad-50197b1dcb8a
|Sets face to use specified channel for [https://community.secondlife.com/knowledgebase/english/bakes-on-mesh-r1512/ Bakes on Mesh]
|-
|IMG_USE_BAKED_SKIRT
|43529ce8-7faa-ad92-165a-bc4078371687
|Sets face to use specified channel for [https://community.secondlife.com/knowledgebase/english/bakes-on-mesh-r1512/ Bakes on Mesh]
|-
|IMG_USE_BAKED_HAIR
|09aac1fb-6bce-0bee-7d44-caac6dbb6c63
|Sets face to use specified channel for [https://community.secondlife.com/knowledgebase/english/bakes-on-mesh-r1512/ Bakes on Mesh]
|-
|IMG_USE_BAKED_LEFTARM
|ff62763f-d60a-9855-890b-0c96f8f8cd98
|Sets face to use specified channel for [https://community.secondlife.com/knowledgebase/english/bakes-on-mesh-r1512/ Bakes on Mesh]
|-
|IMG_USE_BAKED_LEFTLEG
|8e915e25-31d1-cc95-ae08-d58a47488251
|Sets face to use specified channel for [https://community.secondlife.com/knowledgebase/english/bakes-on-mesh-r1512/ Bakes on Mesh]
|-
|IMG_USE_BAKED_AUX1
|9742065b-19b5-297c-858a-29711d539043
|Sets face to use specified channel for [https://community.secondlife.com/knowledgebase/english/bakes-on-mesh-r1512/ Bakes on Mesh]
|-
|IMG_USE_BAKED_AUX2
|03642e83-2bd1-4eb9-34b4-4c47ed586d2d
|Sets face to use specified channel for [https://community.secondlife.com/knowledgebase/english/bakes-on-mesh-r1512/ Bakes on Mesh]
|-
|IMG_USE_BAKED_AUX3
|edd51b77-fc10-ce7a-4b3d-011dfc349e4f
|Sets face to use specified channel for [https://community.secondlife.com/knowledgebase/english/bakes-on-mesh-r1512/ Bakes on Mesh]
|}

== Related Articles ==

* [[User:Kizmut_Smit/ClientAssetKeys]]
* [[llSetTexture]]

[[Category:LSL Texture]]

LlParseString2List

2025-12-29T20:25:43Z

Wulfie Reanimator: Added notes about vectors and rotations.

{{LSL_Function
|func_id=214|func_sleep=0.0|func_energy=10.0
|func=llParseString2List|return_type=list
|p1_type=string|p1_name=src|p1_desc=source string
|p2_type=list|p2_name=separators|p2_desc=separators to be discarded
|p3_type=list|p3_name=spacers|p3_desc=spacers to be kept
|func_footnote=In most situations [[llParseStringKeepNulls]] should be used instead. Discarding null values is rarely desired.

When dealing with [[vector]] and [[rotation]] data, consider using [[llCSV2List]] instead, since it can correctly parse them.
|func_desc
|return_text=that is {{LSLP|src}} broken into a list of strings, discarding {{LSLP|separators}}, keeping {{LSLP|spacers}}, discards any null (empty string) values generated.
|spec
|caveats=
*All empty strings (that would arise from a spacer or separator being adjacent to each other or the ends) are removed;
**If you want them (to keep the order of a list, for example) use [[llParseStringKeepNulls]] instead;
*Only the first 8 separators and first 8 spacers supplied will be used. Any beyond that will be ignored. To work around this see [[#Useful Snippets]] section below. The only limit on the number of items in the output is available script memory.
* All separators and spacers must be strings. All other types will be ignored;
* Separators take precedent over spacers. The string is parsed from start to finish. Each position is compared against the separators then spacers before moving onto the next position;
* Duplicate separators and spacers have no ill effects;
* All elements in the list returned by llParseString2List are strings, and must be explicitly typecast if they are to be used as other types. Do not rely upon the implicit typecasting of the other llList2* functions (as they typically return a default value);
* Remember to capture the result of the operation with a variable, unless you are planning to act directly on the results.
|examples=
<source lang="lsl2">default
{
state_entry()
{
// This will say:
// <A><crazy><fox><.><Saw><the><moon><.><.>
string my_string = "A crazy fox. Saw the moon..";
list my_list = llParseString2List(my_string,[" "],["."]);
llOwnerSay("<" + llDumpList2String(my_list,"><") + ">");

// This will say:
// <A><crazy><fox><.><><><Saw><the><moon><.><><.><>
my_list = llParseStringKeepNulls(my_string,[" "],["."]);
llOwnerSay("<" + llDumpList2String(my_list,"><") + ">");
}
}</source>

While LSL does not support lists-in-lists, you can emulate lists-in-lists by making successive calls or you could use {{LSLGC|JSON}}.

In this example some items have additional information supplied.
<source lang="lsl2">
string shoppinglist = "macaroni::pepperoni::bread#wheat::sausage#italian::coffee::syrup::apple::ice cream#strawberry#chocolate#vanilla";

default
{
state_entry()
{
list items = llParseString2List(shoppinglist, ["::"], []);
integer i = 0;
integer j = llGetListLength(items);
for(;i < j; ++i)
{
list desc = llParseString2List(llList2String(items, i), ["#"], []);
if(llGetListLength(desc) > 1)
{
list types = llDeleteSubList(desc,0,0);
llOwnerSay("Item: "+ llList2String(desc, 0) + " Type: " + llList2CSV(llDeleteSubList(types,-2,-1) + llDumpList2String(llList2List(types,-2,-1), " & ")));
} else {
llOwnerSay("Item: "+ (string)desc);
}
}
}
}</source>
|helpers=
'''Examples of processing more than 8 spacers or separators:'''
{{{!}}
{{LSL DefineRow||[[ParseString2List]]|Functions exactly the same as [[llParseString2List]] and [[llParseStringKeepNulls]].}}
{{LSL DefineRow||[[Separate Words|separateWords]]|Functions exactly the same as [[llParseString2List]] unless you violate it's additional preconditions.
Appears to be correct at a glance.}}
{{!}}}
|also_functions={{LSL DefineRow||[[llParseStringKeepNulls]]}}
{{LSL DefineRow||[[llDumpList2String]]}}
{{LSL DefineRow||[[llCSV2List]]}}
{{LSL DefineRow||[[llList2CSV]]}}
|also_events
|also_tests
|also_articles={{LSL DefineRow||[[Separate Words]]}}
{{LSL DefineRow||[[LSL-Editor/Bugs]]}}
|notes=Whenever you need to process the resulting list entries further (eg. typecasting), remember to [[llStringTrim]] any whitespace characters from the string. This can prevent issues such as unexpected values for vectors and rotations.
-----
If you indicate some items as separators, it will split the string where it finds the indicated separators, and strip out the separators.

If instead you indicate some items as spacers, it will split the string where it finds the spacers, but leave the spacers there, including them as separate entries in the result list.

<source lang="lsl2">string myString = "What Are You Looking At?";

llSay(0, llList2CSV( llParseString2List(myString, ["W", "A", "Y", "L"], [] ) ) );
//returns: hat , re , ou , ooking , t?

llSay(0, llList2CSV( llParseString2List(myString, [], ["W", "A", "Y", "L"] ) ) );
//returns: W, hat , A, re , Y, ou , L, ooking , A, t?</source>

Using " " as a separator will parse a sentence into words.

If there is no spacer you care about, just use <code>[]</code> as the spacer.

If an empty string is used as a separator or a spacer, it will have no effect.
|permission
|negative_index
|sort=ParseString2List
|cat1=List
|cat2=String
|cat3=Data Conversion
|cat4
|history={{LSL Added|0.6.0|remote=http://secondlife.wikia.com/wiki/Version_0.6.0}}
}}

LlResetTime

2025-11-30T11:01:48Z

Wulfie Reanimator: Removed inaccurate caveat

{{LSL_Function
|func_id=83|func_sleep=0.0|func_energy=10.0
|func=llResetTime
|func_desc=Resets the script-time timer to zero.
|return_text
|spec
|caveats=
*Script time resets when...
**Script reset (user or [[llResetScript]] or [[llResetOtherScript]])
**Call to either [[llResetTime]] or [[llGetAndResetTime]]
*Script time measures real world time, it is unaffected by time dilation.
|examples=
<source lang="lsl2">
default {
state_entry()
{
llResetTime();
}
touch_start(integer num_touch)
{
float time = llGetTime(); //Instead getting, and then resetting the time, we could use llGetAndReset() to accomplish the same thing.
llResetTime();
llSay(0,(string)time + " seconds have elapsed since the last touch." );
}
}
</source>
|helpers
|also_functions={{LSL DefineRow||[[llGetTime]]|}}
{{LSL DefineRow||[[llGetAndResetTime]]|}}
|also
|notes
|cat1=Time
|cat2=Script
|cat3
|cat4
}}

LlGetAndResetTime

2025-11-30T11:00:12Z

Wulfie Reanimator: Wording

{{Issues/SVC-3293}}{{LSL_Function
|func_id=84
|func_sleep=0.0
|func_energy=10.0
|func=llGetAndResetTime
|sort=GetAndResetTime
|return_type=float
|return_text=that is script time in seconds and then resets the script time to zero.
|func_footnote
|spec=Script time is the amount of time the script has been running since it first started, was most recently reset, or one of the reset functions was called. It is unaffected by time dilation.
|caveats=
*Script time is the amount of real-world time that the script has been in a running state. It is unaffected by time dilation, but it does not count time while the script is suspended, the user is offline (when in an attachment), the object is in inventory rather than rezzed, etc.
*Script time resets when...
**Script reset (user or [[llResetScript]] or [[llResetOtherScript]])
**Call to either [[llResetTime]] or [[llGetAndResetTime]]
* Due to (32 bit) floating point number limitations, the accuracy of this function is 1/32sec up to ~3 days, 1/16sec up to ~6 days, etc... doubling each time, e.g. it's only 1 second at ~194 days. Use [[llResetTime]] or [[llGetAndResetTime]] whenever practical to maintain the accuracy you require.
|examples=<source lang="lsl2">
default
{
touch_start(integer num_touch)
{
// This is equivalent to calling llGetTime(), then llResetTime()
float time = llGetAndResetTime();

llSay(0, (string)time + " seconds have elapsed since the last touch or script start.");
}
}
</source>
|helpers
|also_functions={{LSL DefineRow||[[llResetTime]]|}}
{{LSL DefineRow||[[llGetTime]]|}}
{{LSL DefineRow||[[llGetRegionTimeDilation]]}}
|also
|cat1=Time
|cat2=Script
|cat3
|cat4
}}

Category:Experience Tools

2025-11-20T02:40:45Z

Wulfie Reanimator: /* Experience Persistent Storage */

{{LSL Header|ml=*}}
{{RightToc}}Experience Tools provide a way to request persistent permissions across multiple logins and with multiple objects and scripts. In order to use these functions, you must have an ''experience key''. For further information, see [http://community.secondlife.com/t5/English-Knowledge-Base/Experiences-in-Second-Life/ta-p/2744686 Experiences in Second Life] in the Second Life Knowledge Base.

The Experience Tools API fall into three categories:

== Experience Information ==
{|
{{LSL DefineRow|integer|[[llAgentInExperience]](key agent)}}
{{LSL DefineRow|list|[[llGetExperienceDetails]](key experience_id)}}
|}

== Experience Permissions ==
{|
{{LSL DefineRow|event|[[experience_permissions]](key agent)}}
{{LSL DefineRow|event|[[experience_permissions_denied]](key agent, integer reason)}}
{{LSL DefineRow|void|[[llRequestExperiencePermissions]](key agent, string name)}}
|}

== Experience Persistent Storage==
The persistent storage of experiences can still be used even where the experience is not set up as an allowed experience.

Current limits for Persistent storage:
* Each key may be a maximum of 1011 bytes
* Each value may be a maximum of 4095 bytes
* Total stored data is restricted to 128 MiB

These are all asynchronous functions, they all return a {{LSLGC|Key/handle|handle}} that corresponds to a [[dataserver]] event.

{|
{{LSL DefineRow|key|[[llReadKeyValue]](string k)}}
{{LSL DefineRow|key|[[llCreateKeyValue]](string k, string v)}}
{{LSL DefineRow|key|[[llUpdateKeyValue]](string k, string v, integer checked, string original_value)}}
{{LSL DefineRow|key|[[llDeleteKeyValue]](string k)}}
|}

===Debugging===
{|
{{LSL DefineRow|key|[[llDataSizeKeyValue]]()|Gets the number of bytes used by the experience along with the experience's byte quote}}
{{LSL DefineRow|key|[[llKeysKeyValue]](integer start, integer count)|Gets the names of the keys}}
{{LSL DefineRow|key|[[llKeyCountKeyValue]]()|Gets the number of keys}}
{{LSL DefineRow|string|[[llGetExperienceErrorMessage]](integer value)|Converts an integer error code to a wordy string representation}}
|}
{{LSL Constants/Experience Tools Errors}}

Template:LSL Function/KeyValue

2025-11-17T12:48:10Z

Wulfie Reanimator: Added max memory limit.

<noinclude>{{Multi-lang|category=LSL}}</noinclude>{{LSL Injection Test}}{{#if:

{{#vardefine:p_success_desc|A boolean specifying if the transaction succeeded (1) or not (0).}}
{{#vardefine:p_error_hover|An XP_ERROR_* flag that describes why the operation failed.}}
{{#vardefine:p_error_desc|An {{CAL|LSL Integer/experience_error{{#var:lang}}|XP_ERROR_*}} flag that describes why the operation failed.}}
{{#vardefine:p_cdl_desc|A string that is a comma-deliminated list}}
{{#vardefine:p_components_desc|varies depending upon success or failure of request}}

{{#vardefine:p_{{{d2_name|}}}_hover|{{#var:p_{{{d2_name|}}}_hover}}{{{d2_hover|}}}}}
{{#vardefine:p_{{{d3_name|}}}_hover|{{#var:p_{{{d3_name|}}}_hover}}{{{d3_hover|}}}}}
{{#vardefine:p_{{{d4_name|}}}_hover|{{#var:p_{{{d4_name|}}}_hover}}{{{d4_hover|}}}}}
{{#vardefine:p_{{{dl_name|}}}_hover|{{#var:p_{{{dl_name|}}}_hover}}{{{dl_hover|}}}}}

{{#if:{{{1|}}}<noinclude>*</noinclude>|{{LSL Function/KeyValue/Key|{{{1}}}|dataserver={{{dataserver|}}}}}}}
{{#if:{{{key|}}}|{{LSL Function/KeyValue/Key|{{{key}}}|dataserver={{{dataserver|}}}}}}}
{{#if:{{{2|}}}<noinclude>*</noinclude>|{{LSL Function/KeyValue/Value|{{{2}}}|dataserver={{{dataserver|}}}}}}}
{{#if:{{{value|}}}<noinclude>*</noinclude>|{{LSL Function/KeyValue/Value|{{{value}}}|Note! This value may contain commas.|dataserver={{{dataserver|}}}}}}}

{{#vardefine:p_{{{d2_name|}}}_desc|{{#var:p_{{{d2_name|}}}_desc}}{{{d2_desc|}}}}}
{{#vardefine:p_{{{d3_name|}}}_desc|{{#var:p_{{{d3_name|}}}_desc}}{{{d3_desc|}}}}}
{{#vardefine:p_{{{d4_name|}}}_desc|{{#var:p_{{{d4_name|}}}_desc}}{{{d4_desc|}}}}}
{{#vardefine:p_{{{dl_name|}}}_desc|{{#var:p_{{{dl_name|}}}_desc}}{{{dl_desc|}}}}}

<includeonly>
{{#ifeq:{{#var:article-type}}|event||{{#if:{{#pos:{{#var:moded}}|r}}{{#pos:{{#var:moded}}|u}}||{{#vardefine:hidden-text|{{#var:hidden-text}}
{{LSLC|Dataserver{{#var:lang}}}}{{#if:{{{mode|}}}|{{LSLC|Dataserver/{{{mode}}}{{#var:lang}}}}}}
}}}}}}
</includeonly>

{{#vardefine:table_text|{{PBR}}
The string containing a comma-delimited list ({{LSLPT|cdl}}). <code>llDumpList2String([ [[integer]] {{LSLPT|success}} ] + {{LSLPT|components}});</code>
* {{LSLPT|components}} vary depending upon success or failure of request.
* Failure: <code>{{LSLPT|cdl}} = [[llDumpList2String]]([ 0, [[integer]] {{LSLPT|error}}],",")</code>
* Success: <code>{{LSLPT|cdl}} = [[llDumpList2String]]([ 1{{#if:{{{d2_type|}}}{{{d2_name|}}}|, [[{{{d2_type}}}{{#var:lang}}|{{{d2_type}}}]] {{LSLPT|{{{d2_name}}}}}{{#if:{{{d3_type|}}}{{{d3_name|}}}|, [[{{{d3_type}}}{{#var:lang}}|{{{d3_type}}}]] {{LSLPT|{{{d3_name}}}}}{{#if:{{{d4_type|}}}{{{d4_name|}}}|, [[{{{d4_type}}}{{#var:lang}}|{{{d4_type}}}]] {{LSLPT|{{{d4_name}}}}}}}}}}} ]{{#if:{{{dl_name|}}}| + {{LSLPT|{{{dl_name|}}}}})}},",")</code>
===== String Components =====
{{{!}} style="margin-left:0em;"
{{LSL DefineRow|integer|2={{CAL|LSL Integer/boolean{{#var:lang}}|success}}|3={{#var:p_success_desc}}}}
{{LSL DefineRow|integer|2={{CAL|LSL Integer/experience_error{{#var:lang}}|error}}|3={{#var:p_error_desc}}}}
{{#if:{{{d2_name|}}}{{{d2_type|}}}|{{LSL DefineRow|1={{{d2_type|}}}|2={{#if:{{{d2_subtype|}}}|{{CAL|LSL {{ucfirst:{{{d2_type|}}}}}/{{{d2_subtype|}}}{{#var:lang}}|{{{d2_name|}}}}}|{{LSL_Parameter_Link|{{{d2_name|}}}}}}}|3={{#var:p_{{{d2_name|}}}_desc}}}}
{{#if:{{{d3_name|}}}{{{d3_type|}}}|{{LSL DefineRow|1={{{d3_type|}}}|2={{#if:{{{d3_subtype|}}}|{{CAL|LSL {{ucfirst:{{{d3_type|}}}}}/{{{d3_subtype|}}}{{#var:lang}}|{{{d3_name|}}}}}|{{LSL_Parameter_Link|{{{d3_name|}}}}}}}|3={{#var:p_{{{d3_name|}}}_desc}}}}
{{#if:{{{d4_name|}}}{{{d4_type|}}}|{{LSL DefineRow|1={{{d4_type|}}}|2={{#if:{{{d4_subtype|}}}|{{CAL|LSL {{ucfirst:{{{d4_type|}}}}}/{{{d4_subtype|}}}{{#var:lang}}|{{{d4_name|}}}}}|{{LSL_Parameter_Link|{{{d4_name|}}}}}}}|3={{#var:p_{{{d4_name|}}}_desc}}}}
}}}}}}
{{#if:{{{dl_name|}}}|{{LSL DefineRow|1=list|2={{#if:{{{dl_subtype|}}}|{{CAL|LSL List/{{{dl_subtype|}}}{{#var:lang}}|{{{dl_name|}}}}}|{{LSL_Parameter_Link|{{{dl_name|}}}}}}}|3={{#var:p_{{{dl_name|}}}_desc}}}}}}
{{!}}}
}}

{{#if:{{{dataserver|}}}|
{{#vardefine:p_{{{d2_name|}}}_hover|}}
{{#vardefine:p_{{{d3_name|}}}_hover|}}
{{#vardefine:p_{{{d4_name|}}}_hover|}}
{{#vardefine:p_{{{dl_name|}}}_hover|}}
{{#vardefine:p_{{{d2_name|}}}_desc|}}
{{#vardefine:p_{{{d3_name|}}}_desc|}}
{{#vardefine:p_{{{d4_name|}}}_desc|}}
{{#vardefine:p_{{{dl_name|}}}_desc|}}
|
{{#vardefine:spec|{{#var:spec}}
* Maximum memory storage: 128 MiB
<h4>Dataserver</h4>
The [[dataserver]] callback parameters are:
* A key containing the {{LSLGC|Key/handle|handle}} returned from [[{{#var:name}}]]
* A string containing a comma-delimited list ({{LSLPT|cdl}}). <code>llDumpList2String([ [[integer]] {{LSLPT|success}} ] + {{LSLPT|components}});</code>
** {{LSLPT|components}} vary depending upon success or failure of request.
** Failure: <code>{{LSLPT|cdl}} = [[llDumpList2String]]([ 0, [[integer]] {{LSLPT|error}}],",")</code>
** Success: <code>{{LSLPT|cdl}} = [[llDumpList2String]]([ 1{{#if:{{{d2_type|}}}{{{d2_name|}}}|, [[{{{d2_type}}}{{#var:lang}}|{{{d2_type}}}]] {{LSLPT|{{{d2_name}}}}}{{#if:{{{d3_type|}}}{{{d3_name|}}}|, [[{{{d3_type}}}{{#var:lang}}|{{{d3_type}}}]] {{LSLPT|{{{d3_name}}}}}{{#if:{{{d4_type|}}}{{{d4_name|}}}|, [[{{{d4_type}}}{{#var:lang}}|{{{d4_type}}}]] {{LSLPT|{{{d4_name}}}}}}}}}}} ]{{#if:{{{dl_name|}}}| + {{LSLPT|{{{dl_name|}}}}})}},",")</code>
===== String Components =====
{{{!}} style="margin-left:0em;"
{{LSL DefineRow|integer|2={{CAL|LSL Integer/boolean{{#var:lang}}|success}}|3={{#var:p_success_desc}}}}
{{LSL DefineRow|integer|2={{CAL|LSL Integer/experience_error{{#var:lang}}|error}}|3={{#var:p_error_desc}}}}
{{#if:{{{d2_name|}}}{{{d2_type|}}}|{{LSL DefineRow|1={{{d2_type|}}}|2={{#if:{{{d2_subtype|}}}|{{CAL|LSL {{ucfirst:{{{d2_type|}}}}}/{{{d2_subtype|}}}{{#var:lang}}|{{{d2_name|}}}}}|{{LSL_Parameter_Link|{{{d2_name|}}}}}}}|3={{#var:p_{{{d2_name|}}}_desc}}}}
{{#if:{{{d3_name|}}}{{{d3_type|}}}|{{LSL DefineRow|1={{{d3_type|}}}|2={{#if:{{{d3_subtype|}}}|{{CAL|LSL {{ucfirst:{{{d3_type|}}}}}/{{{d3_subtype|}}}{{#var:lang}}|{{{d3_name|}}}}}|{{LSL_Parameter_Link|{{{d3_name|}}}}}}}|3={{#var:p_{{{d3_name|}}}_desc}}}}
{{#if:{{{d4_name|}}}{{{d4_type|}}}|{{LSL DefineRow|1={{{d4_type|}}}|2={{#if:{{{d4_subtype|}}}|{{CAL|LSL {{ucfirst:{{{d4_type|}}}}}/{{{d4_subtype|}}}{{#var:lang}}|{{{d4_name|}}}}}|{{LSL_Parameter_Link|{{{d4_name|}}}}}}}|3={{#var:p_{{{d4_name|}}}_desc}}}}
}}}}}}
{{#if:{{{dl_name|}}}|{{LSL DefineRow|1=list|2={{#if:{{{dl_subtype|}}}|{{CAL|LSL List/{{{dl_subtype|}}}{{#var:lang}}|{{{dl_name|}}}}}|{{LSL_Parameter_Link|{{{dl_name|}}}}}}}|3={{#var:p_{{{dl_name|}}}_desc}}}}}}
{{!}}}
}}
}}



}}<noinclude>
{| {{Prettytable}}
|-{{Hl2}}
! #var
! value
|-
{{VarPair|p_{{{1}}}_desc}}
|-
{{VarPair|p_{{{2}}}_desc}}
|-
{{VarPair|p_{{{value}}}_desc}}
|-
{{VarPair|spec}}
|-
{{VarPair|caveats}}
|-
{{VarPair|table_text}}
|}
</noinclude>{{#if:{{{dataserver|}}}|{{#var:table_text}}}}

Category:LSL Light

2025-11-17T00:38:58Z

Wulfie Reanimator: Removed outdated technical explanation. There hasn't been a limit of 8 lights for over a decade.

{{LSL Header|ml=*}}{{LSLC|}}{{LSLC|Prim}}
== Properties of light ==

The quality of a [[PRIM_POINT_LIGHT]] cast by an object is determined by five parameters found on the [[Building_Tools#Features_Tab|features tab]] of the [[Building_Tools#Edit_Tool|edit tool]], which can also be set by script commands. The controls appear in the dialog in the same order as used in the script commands (see example below).

The first is a simple '''on/off switch''': either the object is a [[PRIM_POINT_LIGHT]] source (checkbox activated or [[TRUE]]) or it isn't. The light's '''color''' is set by a color picker (dialog) or as an RGB vector (script) as usual. The '''intensity''' of light is a measurement of how strong in absolute terms the light is. This is a floating-point number ranging from 0.0 to 1.0, where 1.0 is fully on and 0.0 is equivalent to "off."

The two remaining settings are trickier, because their effects are quite subtle and they do interact with each other. '''Radius''' is the distance that light will travel from the centre of the object before it blends into and becomes indistinguishable from the scene's natural ambient lighting. This is a floating-point number measured in metres. '''Falloff''' is the extent to which light "decays" as it travels away from the object. This is a floating-point number ranging from 0.01 to 2.0, where 2.0 is an abrupt falling-off of intensity and 0.01 is relatively little change over distance.

To illustrate how these settings work, imagine—or better still: build—a hollow grey cube 8 by 8 by 8 metres on the inside, with a light source hovering in the middle of one end-wall, and yourself standing below the light source looking at the opposite wall. (Hint: if you do actually build this, turn the sun off while you are testing; you may also need to close the curtains and extinguish all lights in the real-life room you're working in.)

While the '''radius''' is less than 4 metres (i.e. under halfway to the opposite wall), it remains fairly dark. Turning the falloff up to 2.0 (maximum decay) makes the room somewhat darker.

As the '''radius''' approaches 8 metres (the distance to the wall), the room is only slightly brighter; at maximum '''falloff''', the room is about as dark as it was when the '''radius''' was 4 metres and '''falloff''' was 0.01.

Only after the '''radius''' is greater than the distance to the opposite wall does it become significantly brighter. The effect of '''falloff''' is greater: when it is 0.01, direct illumination begins to make concentric circles on the wall, centred on the point where it intersects the light's axis; at the maximum of 2.0 the room is again as dark as it was when the '''radius''' was only 4 metres.

== Controlling light sources ==
An example - How to generate, switch and change light from LSL:

<source lang="lsl2">
integer isLightTurnedOn;

default
{
touch_start(integer total_number)
{
// toggle isLightTurnedOn between TRUE and FALSE
isLightTurnedOn = !isLightTurnedOn;

if (isLightTurnedOn)
{
llSetPrimitiveParams([
PRIM_FULLBRIGHT, ALL_SIDES, FALSE,
PRIM_POINT_LIGHT, FALSE, ZERO_VECTOR, 1.0, 10.0, 0.6]);
}
else
{
vector COLOR_ORANGE = <1.000, 0.522, 0.106>;

llSetPrimitiveParams([
PRIM_FULLBRIGHT, ALL_SIDES, TRUE,
PRIM_POINT_LIGHT, TRUE, COLOR_ORANGE, 1.0, 10.0, 0.6]);
}
}
}
</source>

The following example shows how to create a configurable light that turns itself on and off when touched. The light's properties can be edited by changing the values defined at the top of the script. This script illustrates the lighting attributes [[PRIM_POINT_LIGHT]], [[PRIM_FULLBRIGHT]] and [[PRIM_GLOW]].

<source lang="lsl2">
// Touch the object to light it up.
// Lighting is configurable.

integer light_s = TRUE;
vector lightcolor = <1.0, 0.75, 0.5>;
float intensity = 1.0; // 0.0 <= intensity <= 1.0
float radius = 10.0; // 0.1 <= radius <= 20.0
float falloff = 0.01; // 0.01 <= falloff <= 2.0
float glow = 0.05;

toggle()
{
float thisglow = 0.0;
light_s = !light_s;

if (light_s)
thisglow = glow;

llSetPrimitiveParams([
PRIM_POINT_LIGHT, light_s, lightcolor, intensity, radius, falloff,
PRIM_FULLBRIGHT, ALL_SIDES, light_s,
PRIM_GLOW, ALL_SIDES, thisglow
]);
llSetColor(lightcolor, ALL_SIDES);
}

default
{
state_entry()
{
llSetText("Touch for light", <1.0, 1.0, 1.0>, 1.0);
toggle();
}

touch_start(integer total_number)
{
toggle();
}
}
</source>

Limits

2025-11-16T19:06:15Z

Wulfie Reanimator: /* Lighting */

<noinclude>{{KBmaster}}</noinclude>
== Summary ==
{{RightToc}}
The Second Life Viewer and simulators have a division of labor, keeping track of the data that makes Second Life run. The Viewer's job is to:

* Handle locations of objects.
* Get velocities and other physics information, and does simple physics to keep track of what is moving where.

The simulator's job is to:

* Run the physics engine.
* Detect collisions.
* Keep track of where everything is
* Send locations of content to the Viewer along with updates when certain changes occur.

Limits are necessary for all of these components to work together. The list below outlines many of the '''Second Life numerical limits that affect your inworld experience'''. Some of these will likely change over time, so if you spot something incorrect/outdated, please take a moment to update it.

{{KBcaution|1=The scope of this page is focused on Linden Lab's official Viewers, keeping in mind [[Third_Party_Viewer_Directory|3rd-party viewers may differ]]. Cite sources and provide substantiation for limits that aren't provided by Linden Lab. Also, unconfirmed speculation [[Talk:Limits|goes on this discussion page]]. Don't add data without a hard limit, and don't add obscure trivia that doesn't practically affect the general inworld experience.|width=80%}}

== [[Avatar]] ==

* '''Max. # of attachments''' - 38 combined [[HUD]] and body attachments.
** They can be viewed by right-clicking your avatar and choosing '''Edit My Outfit'''.
** With the formal introduction of [[multiple attachments|multiple attachments to a single point]] in Viewer 2.4, you can attach up to 38 total objects, and they can all be attached to a single point.
** With the introduction of the Bento armature, there are 47 attachment points available.
** With the introduction of Animesh, there is a limit of 1 Animesh attachment for Basic & Plus members, 2 for Premium members, and 3 for Premium Plus members.
* '''Max. attachment position''' - 3.5m in a sphere around <0, 0, 0>.
* '''Max. # of clothing layers''' - 60 including alpha, tattoo, shoe base, physics, socks, gloves, undershirt, underpants, shirt, pants, jacket, skirt
** On viewers before Second Life Release 3.7.29.301305, the potential total was still 60, but limited to 5 items of each type.
** In any case, only one each of shape, skin, eyes and hair base may be worn. These 4 basic body parts are in addition to the 60 clothing layers.
* '''Max Clothing Texture''' - 1024x1024 px (except 128x128 px for eyes) - Server Side Appearance (and legacy baking on outside grids) will downsize larger textures*. (Support for 2K textures & Bakes on Mesh is in development but not yet supported)
* '''Max. unassisted fly height''' - Stable hover at current ground elevation ''plus'' 5020m.
** You can easily acquire a flight attachment to fly high. Also see [[flight limit]] and [[Limits#Navigation|the Navigation section]] below.
* '''Common shoe sizes''' - Traditionally, most women's shoes were designed for a size 0 (zero) foot. Men's generally scale up to 14. Newer items (mesh and some sculpted) replace the system feet or conform to the avatar's shape, so adjustments may be necessary.
** You can check this by going to Edit menu > Appearance and clicking on the Shape > Legs tab.

* '''Max. length of avatar name''' - 31 for first name, 31 for last name, 63 in total (including the space).

* '''Max. length of {{LSLGC|Username}}''' - All lower case and a maximum of 63 including the '.'(eg; firstname.lastname)
**Older account user names are a combination of the First and last name in lower case separated by a period(.)(eg; lilmix.pixelmaid)
**Modern user names are a single name(no period)(eg; john1234) - '''Max.''' length is 31 characters
**The {{LSLGC|Legacy Name}}s for modern user names always shows Resident as the last name. So the Max is 40 characters in total for a new avatar's legacy name(including the space and last name 'Resident')
*'''Min. length of [[Display_Names]]''' - At least one script character
*'''Max. length of Display Names''' - 31 characters
**Display Names can include most Unicode script characters, spaces, and some punctuation.

* '''Max. avatar speed''' - 250m/s (with only attachments to assist)
* '''Max. teleport speed''' - 6 teleports per minute

== [[Animation]] ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||Length of animation
| n/a
| {{no|60.0 seconds}}
| Limited by length or Size, whichever is reached first
| n/a
|-
||Size of Animation
| n/a
| {{no|{{HoverText|250,000 bytes|250 KB (decimal), 244 KB (binary)}}}}
| Limited by length or Size, whichever is reached first. Size is after conversion to [[Internal Animation Format|.anim]]. {{KBtip|custom=Tip for Blender users:|1=You can use a built-in function called "''Decimate''" to simplify your animation. See [https://www.youtube.com/watch?v=lScwEYJZy1M this tutorial]}}
| [[Internal Animation Format]]
|-
||Distance an Animation Can Travel
| {{no|-5 meters (per axis)}}
| {{no|+5 meters (per axis)}}
| 10 meters per axis cumulatively (travelling from -5 to +5).
| n/a

|-
||animation priority
| {{no|0}}
| {{no|.bvh: 4, [[Internal Animation Format|.anim]]: 6}}
| [[Internal Animation Format|.anim]] uses per-joint priorities, meaning it's possible to have a mix of joint priorities in the same animation.
| [[Animation_Priority|Animation Priority]]
|-
||Number of unique joints per animation
| n/a
| {{no|216}}
| [[Internal Animation Format|.anim]], unlike .bvh, uses a flat structure, meaning that only the bones animated are stored, and bones which would otherwise be kept by .bvh (to keep hierarchy structure) are deleted.
| n/a
|-
||Number of simultaneous animations playing
| n/a
| {{no|30}}
| n/a
| n/a
|}

== [http://community.secondlife.com/t5/English-Knowledge-Base/Build-Tools/ta-p/700039 Building] ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||[[Prim]] dimensions
| {{no|<0.01, 0.01, 0.01>}}
| {{no|<64.0, 64.0, 64.0>}}
| Used to be <10.0, 10.0, 10.0> prior to Second Life Server version 11.08.17.238770
| [[llSetScale]], [[PRIM_SIZE]] and [[Megaprim]]
|-
||Number of prims in a linkset
| n/a
| {{no|256 prims}}
| Used to be 255 prior to Second Life Server version 1.26
| n/a
|-
||Linking distance
| n/a
| {{no|64 meters}}
| distance has changed on [https://community.secondlife.com/blogs/entry/13626-coming-soon-server-release-202306/ 2023.06 update]. The old max distance was 54 meters.
| n/a
|-
||Local offset (avatars)
| n/a
| {{no|1000 meters per axis}}
| Unlike regular [[Linkability_Rules|Linkability Rules]] for linksets, an avatar sitting on an object may be moved significantly further by scripts.
| [[llSetLinkPrimitiveParams]] with [[PRIM_POS_LOCAL]]
|-
||[[Mesh/Mesh_physics#Physics_Resource_Cost|Physics cost]] for a physical object
| n/a
| {{no|32.0}}
||Additional notes:
* If you try to link more, it'll either say "Can't enable physics for objects with more than 32 primitives" or "Object has too many primitives -- its dynamics have been disabled.".
* On server versions 1.38 and below, each sitting avatar counted as 1 prim. From 1.40.2 the limit is only on actual prims.
| [[OBJECT_PHYSICS_COST]]
|-
||Build or rez height
| n/a
| {{no|4096.0 meters}}
| 768.0 meters for Viewers prior to version 1.20
| n/a
|-
||Prim name length
| n/a
| {{no|63 bytes UTF-8 [[String|string]]}}
| same limit for {{LSLGC|Avatar/Name|avatar names}}, although the character set for avatar names is significantly limited.
| n/a
|-
||Prim description length
| n/a
| {{no|127 bytes UTF-8 [[String|string]]}}
| n/a
| n/a
|-
||Temporary prims' lifetime
| n/a
| {{no|up to around 60 seconds}}
| depends upon when the next garbage collector cycle is
| n/a
|-
||Number of temporary prims
| n/a
| {{no|RegionPrimLimit - NumberOfPrimsInRegion + Minimum(0.5*RegionPrimLimit, 1000)}}
| n/a
| n/a
|-
||Length of hovertext
| n/a
| {{no|254 bytes UTF-8 [[String|string]]}}
| n/a
| [[llSetText]] and [[PRIM_TEXT]]
|}

== [https://community.secondlife.com/knowledgebase/english/lighting-and-shadows-r331/ Lighting] ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||Number of active light sources
| n/a
| {{yes|no limit}}
| Advanced Lighting Model (ALM) was developed around 2011-2013 to remove the hard limit on light sources.
|-
||Number of projectors rendered at full detail
| n/a
| {{no|2}}
| Only the 2 projectors closest to an object will cause it to cast shadows. Additional projectors still affect color.
| [https://community.secondlife.com/knowledgebase/english/lighting-and-shadows-r331/#Projectors Knowledge Base > Lighting > Projectors]
|-
||Number of lights rendered on Alpha Blended surfaces
| n/a
| {{no|8}}
| 8 including the Sun and Moon. The viewer will attempt to select the "most significant" lights to render, however these blended surfaces will look different as a result of these lighting limitations.
| [[Alpha Modes Do's and Don'ts#Alpha_blending|Alpha Blending]]
|}

== [[Communication]] ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||Whisper distance
| n/a
| {{no|10 meters}}
| <code>/whisper</code> as the first few characters in a message can be used in viewer-2-code based viewers in local chat.
| n/a
|-
||Chat distance
| n/a
| {{no|20 meters}}
| text spoken as a "chat" step '''within gestures''' cannot be shouted or whispered. /whisper and /shout ''can'' be used in the "Replace with" field.
| n/a
|-
||Shout distance
| n/a
| {{no|100 meters}}
| <code>/shout</code> as the first few characters in a message can be used in viewer-2-code based viewers in local chat.
| n/a
|-
||Length of a chat message and whether or not it is truncated
| {{no|1 byte or single-byte character}}
| {{no|1024 bytes or single-byte characters}}
| Limit does not apply to instant messages via [[llInstantMessage]] and communication between IM and email, the limit there is 1023 bytes or single-byte characters.
The viewer-to-server communication on ''negative'' channels is truncated to 254 bytes, and on ''positive'' channels, to 1023 bytes. These limits do not affect communication between scripts.
| [[llInstantMessage]]
|-
||Maximum events
| n/a
| {{no|64 events}}
| Events are stored in a 64 bit bitmap. Events happening when the bitmap is full, will get discarded.
| n/a
|-
||Number of offline messages
| n/a
| {{no|Capped at 30 messages for Basic members, 40 for Plus members, 120 for Premium members, and 240 for Premium Plus members.}}
| Number of offline messages (involving [[IM|IMs]], inventory offers, group notices, group invitations) received before messages get capped. Note: If autoAcceptNewInventory (debug setting) is set to TRUE (the default is FALSE), then all inventory offers, even above the cap allowed by membership, go directly to inventory and do not count against the cap on offline messages.
| [[IM]] - [https://community.secondlife.com/blogs/entry/2559-group-limits-update-no-changes-for-basic-members/ Blog Post]
|-
||Length of a properly delivered email reply to an [[IM]]
| n/a
| {{no|1023 bytes or single-byte characters}}
| n/a
| n/a
|-
||Time after which a reply to an [[IM]] can be sent via email.
| {{no|when receiving the IM via email.}}
| {{no|5 days after receiving the offline IM via email.}}
| n/a
| [https://blogs.secondlife.com/community/features/blog/2007/02/06/im-to-e-mail-return-addresses-changing Second Life Blogs]
|-
||Time period for which [[IM|IMs]] are stored within Second Life.
| n/a
| {{no|31 days after receiving the [[IM]]}}
| [[User:Torley_Linden|Torley Linden]] confirmed this with [[User:Kelly_Linden|Kelly Linden]]
| n/a
|-
||Number of [[IM|IMs]] sent by an object within an hour
| n/a
| {{no|5000 per hour}}
| n/a
| n/a
|}

== [[Gesture]]s ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||Shortcut key mappings
| n/a
| {{no|33 unique combinations, since {{K|F2}}–{{K|F12}} can be used with the {{K|Ctrl}} or {{K|Shift}} modifiers.}}
| n/a
| [[All_keyboard_shortcut_keys]] and [http://community.secondlife.com/t5/English-Knowledge-Base/Keyboard-shortcuts/ta-p/1086557 the knowledge base]
|-
||Chat step length
| n/a
| {{no|127 bytes or single-byte characters}}
| n/a
| n/a
|-
||Wait time
| n/a
| {{no|3600 seconds (which is one hour)}}
| n/a
| n/a
|-
| Maximum steps data
| n/a
| {{no|1000 bytes}} of packed data; saving with more data returns the message "Gesture save failed. This gesture has too many steps. Try removing some steps, then save again." Shorter text, for example, will allow more steps.
| n/a
| n/a
|-
||Length of included assets
| n/a
| see sections for [[#Animation|animation]], [[#Sound|sound]]
| n/a
| n/a
|}

== [[Group]]s ==

* '''Maximum number of groups you can belong to:''' 50 for Basic members, 55 for Plus members, 80 for Premium members, 150 for Premium Plus members.
** After downgrading from a higher limit membership to a lower one, you may not join any new groups until you are a member of fewer than your current subscriptions's group limit. For example, if you downgrade from Premium (70 groups allowed) to Basic (42 groups allowed), you can't join any new groups until you're a member of fewer than 42 groups.
** Roles within groups are sort of like sub-groups. In many cases, you can use them instead of creating new groups.
* '''Minimum number of members in a group:''' 2
** A group with only 1 person for 48 hours will be disbanded (cancelled). Unless the group owns land.
* '''Maximum number of roles allowed in a group:''' 10 (including "Owners" and "Everyone", which cannot be deleted)
* '''Maximum Group Name:''' 35 single-byte characters.
* '''Maximum Group Title:''' 20 single-byte characters.
* '''Maximum Length of a Group Notice:''' 512 single-byte characters.
* '''Maximum Age of a Group Notice:''' 14 days.

== [[Inventory]] ==

* '''Maximum number of inventory items that can be sent in a folder:''' 42
** Folders count as items too. This has more to do with packet size limits than cheeky Douglas Adams references.
* '''Maximum number of accounts that an inventory item can be shared with at once:''' The limit is unknown, but tests show that it is more than 35. No documentation has been found. One third-party viewer developer says that the code doesn't seem to look for a limit. It just builds the list and sends it to each avatar individually.
* '''Maximum number of inventory items that can be contained in a prim:''' 10,000
* '''Maximum characters in an inventory item name:''' 63
* '''Maximum notecard line:''' None, but scripts can only read the first 1024 bytes (was 255 bytes before server version [https://releasenotes.secondlife.com/simulator/2021-10-25.565008.html 2021-10-25.565008]).
* '''Maximum notecard size:''' 65,536 bytes

* '''Number of items in the Library:''' 3,500 as of 2019-08-10
** Verified by [[How_does_the_Library_work|hiding the Library]] and counting the difference.
* '''Maximum number of inventory items displayed in a single inventory folder:''' Several thousand. 
** This was discussed during [http://wiki.secondlife.com/wiki/Simulator_User_Group/Transcripts/2011.03.08] "the folder will load up to the limit number of items, and remaining ones won't show up in the viewer. you still own them, they aren't lost, but they will be hidden until the folder size is reduced."
** There is no specified limit for total avatar inventory, very large folders can be split.
** There was discussion in the Third Party Developers' UG (4/10/2015) meeting about new inventory and login problems from having large numbers of items in a single folder. AISv3 ''removed'' server-side limits on the number of items in a folder. Flat inventories are bad. No one is certain at what number of items in a folder cause a login problem. The fix is to clear the inventory cache (not the viewer cache) and log into a deserted, empty region then move inventory items into folders and sub-folders. - The problem appears at different a number of items depending on your computer and connection speed. Hopefully being on an empty region will give one enough edge to get logged in and do some corrective work before being dropped. If not, you will need to contact support for help. They will divide large folders into smaller groups so you can log in.

== [[Land]] ==

* '''Maximum [[Land#Parcel|parcel]] size:''' 65,536 meters²
** Covering a whole region, or square on the World Map.
* '''Minimum parcel size:''' 16 meters²
* '''Maximum parcel name length:''' 63 single-byte characters
* '''Maximum parcel description length:''' 255 characters
* '''Region name length:''' Linden Concierge policy states a minimum of 3 characters, and a maximum of 25 characters (including spaces). See [[Linden Lab Official:Guidelines for Private Region Naming|Guidelines for Private Region Naming]]. However, the technical maximum limit is 35 characters, and exceptions to the concierge policy do exist (e.g [http://maps.secondlife.com/secondlife/Sandbox%20-%20Weapons%20testing%20%28no%20damag/128/128/2 Sandbox - Weapons testing (no damag] and [http://slurl.com/secondlife/X/128/128/24 X])
* '''Ban line height for "no entry" or "pay to access"''' (in other words, "allow public access" is turned off, or "allow group access" is turned on, in the parcel options) is the parcel's ground elevation ''plus'' 50 meters (except, if the region has been set to "Block Parcel Fly Over" in which case the access controls extend to at least 4096 meters). If a user is '''explicitly banned by name''', the height is the parcel's ground elevation ''plus'' 5000 meters. On current viewers this is visible to the full extent.
* '''Maximum prims in a [[Land#Region|region]]:'''
** "Mainland / Full Region" and "Linden Homes / Full Region": 22,500
** Full Regions in private estates: 20,000 with an [https://community.secondlife.com/t5/Featured-News/Upgrade-Your-Full-Private-Region-to-30-000-Land-Impact-Today/ba-p/3086162 option for 30,000]
** Homestead: 5,000
** Openspace : 1,000
:: To check a region's capacity, use <tt>[[llGetEnv]]("region_max_prims")</tt>.
::''(Region types are as found in the General tab of World > About Land, or returned by ''<tt>llGetEnv("region_product_name")</tt>'')''
* '''Maximum auto return value''': Besides {{code|0}} (which means ''never''), {{HoverText|999,999|Almost 23 months}} minutes is the highest auto return value.
* '''Terraforming limits:'''
** Most mainland can be raised/lowered by 4 meters (+/-).
** Some mainland regions cannot be terraformed, including: Bay City regions, Boardman, Brown, De Haro, Horizons, Kama City regions, Nautilus City regions, Nova Albion regions, and Shermerville regions.
** [http://community.secondlife.com/t5/English-Knowledge-Base/Linden-Homes/ta-p/700103 Linden Homes] do not allow terraforming.
** A few, very old mainland Regions like Da Boom have a terraform range of 40 meters (+/-).
** Estate (private island) terraformability is settable to a maximum of 100 meters (+/-) by the estate owner or managers.
* '''Maximum water height:''' 100 meters using inworld controls, 255 meters by using a {{code|*.raw}} file upload.
** Region water height is usually 20 meters, and adjacent regions should have the same water height, or else they will look discontinuous.
* '''Maximum terrain height:''' 255 meters using inworld controls (Region/Estate setting & Edit Terrain tool), 510 meters by using a {{code|*.raw}} file upload.
* '''Miscellaneous estate limits:''' You can have a maximum of 20 estate managers, 500 allowed Residents, 63 allowed groups, and 750 banned Residents.
** See World menu > Region/Estate > Estate tab.
* '''Maximum number of agents'''
** [https://second.life/eventregions Event Regions]: 175 agents
** Full region: 100 basic account users plus 10 additional available to premium accounts. (Typically set to 40 on mainland, 55 on Linden Homes regions, but this does vary. Some meeting areas have this set to 60 and higher.)
*** Recent server performance improvements make regions with 60 agents in them perform quite well.
** [[Land#Homestead|Homestead]]: 20 (plus 5 additional available to premium accounts)
** [[Land#Openspace|Openspace]]: 10 (plus 2 additional available to premium accounts)
* '''Freeze Time:''' Land owners can [[freeze]] other Residents for up to 30 seconds. Members of land-owning groups can also be granted this ability.
* '''Minimum parcel that can be listed in Places or All search:''' 144 meters² 
* '''Minimum parcel that can be listed in Events:''' 512 meters²
* '''Maximum altitude for event listings:''' 768 meters ({{JIRA|WEB-814}})
* '''Maximum heights that objects can be seen on the [[World Map]]:''' 400.005m
* '''Maximum height that avatars will be hidden if 'Avatars on other parcels can see and chat with avatars on this parcel' is checked:''' 50m above the ground (see 'Ban line height' above)

== [[Mesh]] ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||Number of vertices
| n/a
| {{no|65536 vertices per LOD}}
| per [[mesh]] - See [[Talk:Limits#Mesh_Limits|discussion page]]
| n/a
|-
||COLLADA file size
| n/a
| {{no|8 MB}}
| Maximum mesh asset size after compression, roughly equivalent to a 256 MB Raw COLLADA file.
| n/a
|-
||Bone influence weights per vertex
| n/a
| {{no|4}}
| n/a
| n/a
|-
||Bone influence weights per mesh
| n/a
| {{no|110}}
| some folk have reported needing to go as low as about 99 in rare cases
| n/a
|-
||Number of materials per mesh
| n/a
| {{no|8}}
| n/a
| n/a
|-
||Number of materials per face
| n/a
| {{no|1}}
| n/a
| n/a
|-
||Physics weight for a vehicle
| n/a
| {{no|32.0}}
| n/a
| n/a
|-
||Maximum number of triangles for Animesh
| n/a
| {{no|100,000}}
| Server uses estimated triangles (streaming cost calculated), not visual triangles.
| [[Animesh User Guide|Animesh_User_Guide]]
|}

===User Found Temporary Mesh Limits:===
''Because of an apparent bug in the importer stay within these limits.''
* 174,752 triangles, beyond which additional triangles will appear as holes.
* The 64k vertices per material is pre-empted by a limit of 21,844 triangles per material, which is presently reported as {{Jira|BUG-1001}}. (4/2014 - See [[Talk:Limits#Mesh_Limits|discussion page]])

:: The import process will continue making new materials beyond 8 x 21,844 (=174,752) triangles, but the extra triangles then get dropped by the limitation to 8 materials, causing holes in the resulting object. Over the 21,844-triangle limit, the vertex count will start to climb steeply, even with smooth shading, because the materials get highly interspersed. So the same vertices have to appear in multiple material lists. So, the moral of the story is to stay below 21,844 triangles per material, for now, if you want to avoid some unexpected effects.

::Since viewer release 3.8.4, processing of meshes in the Collada file that have faces assigned to more than 8 materials has changed. Instead of simply dropping the extra material faces, the uploader now creates a new object to accommodate them. The result is that the single mesh is divided into multiple objects (prims) in a linkset. Thus, the limitation to 8 materials is removed as far as input is concerned, but still applies to each of the resulting linked objects actually uploaded. As a consequence, it is now possible to upload a mesh with more than 174,752 triangles, although it will be divided into multiple objects.

== Misc. ==

*'''[https://secondlife.com/currency/describe-limits.php Billing and Trading Limits]''' - Includes [https://secondlife.com/whatis/economy-market.php LindeX] currency exchange limits.

== Navigation ==

[[File:Max Alt.jpg|thumb|right|435px|'''Height counter error above 2147483647 meters''']]
* '''Absolute height limit:''' [http://en.wikipedia.org/wiki/2147483647#2147483647_in_computing 2147483647] = 231 − 1 meters, which causes the altitude counter to roll over. Altitudes well below this cause graphics errors probably due to limited floating point number precision.
* '''Highest z-value of an [[SLurl]], that will still teleport you to a positive altitude:''' 4096
** This used to be much higher, but is clamped in late model viewers.

== [[Profile]] ==

Each 7-bit ASCII character is encoded in one byte. International characters might need more bytes. When pasting text instead of typing, you can get in one byte more into each of the below.

* '''2nd Life tab's About field''' - 510 bytes
* '''Picks tab''' - 20 picks with 1022 bytes each
* '''1st Life tab's Info field''' - 253 bytes
* '''Classified tab''' - 100 listings with x bytes each
* '''My Notes''' - 1022 bytes

== [[Lag|Performance]] ==

* '''Healthy Viewer FPS''' - Generally, FPS equal to or above 24 is good. The higher it gets, the smoother'''*'''. You can check via [[Advanced]] menu > Performance Tools > Lag Meter, or for more advanced usage, see Advanced > Performance Tools > Statistics Bar.
* '''Avatar Rendering Cost scores''' - [[Avatar Rendering Cost|Learn all about it!]]

'''*''' Only until your framerate reaches your monitor's refresh rate, after this point there will be very little benefit.

== [[Scripting]] == 

* '''Height at which scripts reactivate on a no-script parcel''' - 50 m above terrain mesh. Scripted objects that take controls will keep running when you fly down or enter a no-script parcel. (If scripts are disabled in the region debug panel, they will not run at any height.)
* '''Maximum height where scripts can run''' - none, as long as the object remains rezzed or attached.
* '''Maximum script source code size''' - 65536 single byte characters (that's a viewer limit and can be changed in the config file 'panel_script_ed.xml').
* '''Maximum script memory size (LSO)''' - 16384 bytes.
* '''Maximum script memory size ([[Mono]])''' - 65536 bytes (the maximum memory available to Mono scripts can be constrained via [[llSetMemoryLimit]]).
* '''Maximum memory for [[:Category:LSL LinksetData|Linkset data]]''' key/value pairs - 128 KiB
* '''Maximum memory for [[:Category:Experience Tools|Experience]]''' key/value pairs- 128 MiB
* '''Maximum active [[llListen|listeners]] per script''' - 65.
** '''Usable channel for each listener''' - ''min.'' -2147483648, ''max.'' 2147483647, including the following special channels: [[PUBLIC_CHANNEL]] ''and'' [[DEBUG_CHANNEL]].
* '''Maximum number of scripts that can be rezzed at once''' – 1,000. (Refer to [https://community.secondlife.com/knowledgebase/english/building-tips-r13/ Building Tips, by Jeremy Linden].)
* For specific scripting limits, look up calls in the '''[[LSL Portal]]'''.

== [[Sound]] ==



{{KBtip|Second Life will accept sounds that are encoded following "[https://en.wikipedia.org/wiki/Compact_Disc_Digital_Audio CD Quality]" encoding presets present in many {{Abbr|DAW|Digital Audio Workstation}}s.}}

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||Sound length
| n/a
| {{no|less than 30 seconds or precisely 1,323,000 samples}}
| The advice is typically to upload sounds less than 30.0 and that 29.99 seconds is fine. However if you do wish to be able upload sounds that are 30 seconds precisely then the .WAV file must have exactly 1,323,000 samples (44,100Hz * 30 seconds). Specifically anything above 1,323,000 samples fails to upload.
| '''[https://community.secondlife.com/knowledgebase/english/uploading-assets-r75/ Uploading Assets]'''
|-
||Bit depth
| n/a
| {{no|16 bit}}
| n/a
| n/a
|-
||Sample rate
| n/a
| {{no|44.100 kHz}}
| n/a
| n/a
|-
||Audio channels
| n/a
| {{no|1 channel (mono)}}
| Channels will be '''merged''' at upload time for dual-channel (stereo) audio.
| n/a
|}

== [[Textures]] ==
* '''[http://en.wikipedia.org/wiki/Aspect_ratio Aspect ratios]''' of profile, place, etc. pictures — all of these were measured at UI size (Edit menu > Preferences > General tab > UI Size) = 1.000:

=== Second Life Viewer 3.6 ===

* '''Search > Classifieds thumbnail''' - ~3:2 (101×69 pixels)
* '''Search > Classifieds expanded''' - ~4:3 (159×120 pixels)
* '''Search > Classifieds expanded > More Info''' - native aspect ratio
* '''Search > Destination Guide thumbnail''' - ~3:2 (101×69 pixels)
* '''Search > Destination Guide expanded''' - ~4:3 (159×120 pixels)
* '''Search > People''' - 1:1 (100×100 pixels)
* '''Search > Places expanded''' ~4:3 (159×120 pixels)
* '''Place Profile''' - ~3:2 (290×197 pixels)
* '''About Land > Options tab''' - ~4:3 (195×150 pixels)
* '''Profile > Picture''' - native aspect ratio; thumbnail cropped to 72×72 pixels; zoomed uncropped up to 300×300 pixels
* '''Profile > Real world picture''' - native aspect ratio; thumbnail cropped to 45×45 pixels; zoomed uncropped up to 300×300 pixels
* '''Profile > Picks thumbnail''' - ~16:9 (~516×~270 pixels as measured on screen; the ratio seems closer to 16:8.5)
* '''Profile > Pick expanded''' - Unknown as of 2022-11-13 (viewer 6.6.7.576223); the Pick image does not expand.

=== 1.x Series Viewers ===
(official Viewer up to 1.23.5, still used by some [[Alternate viewers|Third Party Viewers]])
* '''Search > All for "Classifieds", "People", and "Places"''' - 4:3 (256×192 pixels)<ref>As of {{#time: r|2024-02-26T18:00:00}}, this seems to be one of the very few sizes supported by the [[Picture Service]].</ref>
* '''Search > Places and Classified tabs''' - ~7:5 (398×282 pixels)
* '''Search > Land tab''' - ~7:5 (358×252 pixels)
* '''Profile > 2nd Life tab''' - ~4:3 (178×133 pixels)
* '''Profile > Picks tab''' - 16:9 (288×162 pixels)
* '''Profile > 1st Life tab''' - 1:1 (133×133 pixels)
* '''Profile > Classifieds tab''' - ~3:2 (206×137 pixels)
* '''Profile > Web tab''' - 1:1 (400×400 pixels)
** A scrollbar uses 15 pixels on the right-hand side.
* '''About Land > Options tab''' - ~3:2 (178×117 pixels)
* '''Group Information > General tab's "Group Insignia"''' - 1:1 (126×126 pixels)
** Some of these textures are shared (for example, Search > All place pages, Search > Places, and About Land > Options use the same image), so you should pick a well-balanced ratio and size.
** [[Texture_aspect_ratios|Learn how to get correct texture aspect ratios when editing images.]]

=== All Viewers ===

* '''Maximum texture size''' - 2048×2048 pixels
** All Second Life textures are constrained to [http://en.wikipedia.org/wiki/Power_of_2 powers of 2] (e.g., 128, 256, 512).
** We strongly recommend you use as small textures as possible because larger ones consume more memory and take substantially longer to load.
** Where large textures are being forced by import to only 512×512, lower your ...> Preferences >...> UI Size under 1.0, to increase import size to the max 2048×2048.

* '''Minimum texture size''' - 4×4 pixels
** This means that there are ten possible image dimensions: 4, 8, 16, 32, 64, 128, 256, 512, 1024 & 2048 pixels, either horizontal or vertical.

* '''Texture resizing'''
** Uploaded textures will be resized to the dimensions above.
** Each dimension is resized independently (for instance, a 1024 x 999 image will be resized to 1024 x 1024).
** A dimension that is already a power of two will not be resized.
** The uploader “prefers” to round down rather than up. The threshold for rounding down/up is .75 of the distance between powers of two.
*** For example, given a dimension of x, if x / 512 is larger than 1.75, x will be resized to 1024, else 512.
*** Another example: If x / 256 is larger than 1.75, x will be resized to 512.

[[Category:Creation]] [[Category:Tutorials]] [[Category:Lists]]

=== Notes ===
In general, 1 byte is enough to contain one character.<ref>Except in .NET-based applications, and those related to .NET development — which is the case of the SL viewer — which essentially use UTF-16 everywhere, i.e., every character is encoded in ''two'' bytes, not just one.</ref>

Text using Unicode characters (including, but not limited to, emojis), where supported, will require 1–4 bytes (depending on the encoding).

----
{{References}}

Limits

2025-11-16T19:03:36Z

Wulfie Reanimator: /* Lighting */

<noinclude>{{KBmaster}}</noinclude>
== Summary ==
{{RightToc}}
The Second Life Viewer and simulators have a division of labor, keeping track of the data that makes Second Life run. The Viewer's job is to:

* Handle locations of objects.
* Get velocities and other physics information, and does simple physics to keep track of what is moving where.

The simulator's job is to:

* Run the physics engine.
* Detect collisions.
* Keep track of where everything is
* Send locations of content to the Viewer along with updates when certain changes occur.

Limits are necessary for all of these components to work together. The list below outlines many of the '''Second Life numerical limits that affect your inworld experience'''. Some of these will likely change over time, so if you spot something incorrect/outdated, please take a moment to update it.

{{KBcaution|1=The scope of this page is focused on Linden Lab's official Viewers, keeping in mind [[Third_Party_Viewer_Directory|3rd-party viewers may differ]]. Cite sources and provide substantiation for limits that aren't provided by Linden Lab. Also, unconfirmed speculation [[Talk:Limits|goes on this discussion page]]. Don't add data without a hard limit, and don't add obscure trivia that doesn't practically affect the general inworld experience.|width=80%}}

== [[Avatar]] ==

* '''Max. # of attachments''' - 38 combined [[HUD]] and body attachments.
** They can be viewed by right-clicking your avatar and choosing '''Edit My Outfit'''.
** With the formal introduction of [[multiple attachments|multiple attachments to a single point]] in Viewer 2.4, you can attach up to 38 total objects, and they can all be attached to a single point.
** With the introduction of the Bento armature, there are 47 attachment points available.
** With the introduction of Animesh, there is a limit of 1 Animesh attachment for Basic & Plus members, 2 for Premium members, and 3 for Premium Plus members.
* '''Max. attachment position''' - 3.5m in a sphere around <0, 0, 0>.
* '''Max. # of clothing layers''' - 60 including alpha, tattoo, shoe base, physics, socks, gloves, undershirt, underpants, shirt, pants, jacket, skirt
** On viewers before Second Life Release 3.7.29.301305, the potential total was still 60, but limited to 5 items of each type.
** In any case, only one each of shape, skin, eyes and hair base may be worn. These 4 basic body parts are in addition to the 60 clothing layers.
* '''Max Clothing Texture''' - 1024x1024 px (except 128x128 px for eyes) - Server Side Appearance (and legacy baking on outside grids) will downsize larger textures*. (Support for 2K textures & Bakes on Mesh is in development but not yet supported)
* '''Max. unassisted fly height''' - Stable hover at current ground elevation ''plus'' 5020m.
** You can easily acquire a flight attachment to fly high. Also see [[flight limit]] and [[Limits#Navigation|the Navigation section]] below.
* '''Common shoe sizes''' - Traditionally, most women's shoes were designed for a size 0 (zero) foot. Men's generally scale up to 14. Newer items (mesh and some sculpted) replace the system feet or conform to the avatar's shape, so adjustments may be necessary.
** You can check this by going to Edit menu > Appearance and clicking on the Shape > Legs tab.

* '''Max. length of avatar name''' - 31 for first name, 31 for last name, 63 in total (including the space).

* '''Max. length of {{LSLGC|Username}}''' - All lower case and a maximum of 63 including the '.'(eg; firstname.lastname)
**Older account user names are a combination of the First and last name in lower case separated by a period(.)(eg; lilmix.pixelmaid)
**Modern user names are a single name(no period)(eg; john1234) - '''Max.''' length is 31 characters
**The {{LSLGC|Legacy Name}}s for modern user names always shows Resident as the last name. So the Max is 40 characters in total for a new avatar's legacy name(including the space and last name 'Resident')
*'''Min. length of [[Display_Names]]''' - At least one script character
*'''Max. length of Display Names''' - 31 characters
**Display Names can include most Unicode script characters, spaces, and some punctuation.

* '''Max. avatar speed''' - 250m/s (with only attachments to assist)
* '''Max. teleport speed''' - 6 teleports per minute

== [[Animation]] ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||Length of animation
| n/a
| {{no|60.0 seconds}}
| Limited by length or Size, whichever is reached first
| n/a
|-
||Size of Animation
| n/a
| {{no|{{HoverText|250,000 bytes|250 KB (decimal), 244 KB (binary)}}}}
| Limited by length or Size, whichever is reached first. Size is after conversion to [[Internal Animation Format|.anim]]. {{KBtip|custom=Tip for Blender users:|1=You can use a built-in function called "''Decimate''" to simplify your animation. See [https://www.youtube.com/watch?v=lScwEYJZy1M this tutorial]}}
| [[Internal Animation Format]]
|-
||Distance an Animation Can Travel
| {{no|-5 meters (per axis)}}
| {{no|+5 meters (per axis)}}
| 10 meters per axis cumulatively (travelling from -5 to +5).
| n/a

|-
||animation priority
| {{no|0}}
| {{no|.bvh: 4, [[Internal Animation Format|.anim]]: 6}}
| [[Internal Animation Format|.anim]] uses per-joint priorities, meaning it's possible to have a mix of joint priorities in the same animation.
| [[Animation_Priority|Animation Priority]]
|-
||Number of unique joints per animation
| n/a
| {{no|216}}
| [[Internal Animation Format|.anim]], unlike .bvh, uses a flat structure, meaning that only the bones animated are stored, and bones which would otherwise be kept by .bvh (to keep hierarchy structure) are deleted.
| n/a
|-
||Number of simultaneous animations playing
| n/a
| {{no|30}}
| n/a
| n/a
|}

== [http://community.secondlife.com/t5/English-Knowledge-Base/Build-Tools/ta-p/700039 Building] ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||[[Prim]] dimensions
| {{no|<0.01, 0.01, 0.01>}}
| {{no|<64.0, 64.0, 64.0>}}
| Used to be <10.0, 10.0, 10.0> prior to Second Life Server version 11.08.17.238770
| [[llSetScale]], [[PRIM_SIZE]] and [[Megaprim]]
|-
||Number of prims in a linkset
| n/a
| {{no|256 prims}}
| Used to be 255 prior to Second Life Server version 1.26
| n/a
|-
||Linking distance
| n/a
| {{no|64 meters}}
| distance has changed on [https://community.secondlife.com/blogs/entry/13626-coming-soon-server-release-202306/ 2023.06 update]. The old max distance was 54 meters.
| n/a
|-
||Local offset (avatars)
| n/a
| {{no|1000 meters per axis}}
| Unlike regular [[Linkability_Rules|Linkability Rules]] for linksets, an avatar sitting on an object may be moved significantly further by scripts.
| [[llSetLinkPrimitiveParams]] with [[PRIM_POS_LOCAL]]
|-
||[[Mesh/Mesh_physics#Physics_Resource_Cost|Physics cost]] for a physical object
| n/a
| {{no|32.0}}
||Additional notes:
* If you try to link more, it'll either say "Can't enable physics for objects with more than 32 primitives" or "Object has too many primitives -- its dynamics have been disabled.".
* On server versions 1.38 and below, each sitting avatar counted as 1 prim. From 1.40.2 the limit is only on actual prims.
| [[OBJECT_PHYSICS_COST]]
|-
||Build or rez height
| n/a
| {{no|4096.0 meters}}
| 768.0 meters for Viewers prior to version 1.20
| n/a
|-
||Prim name length
| n/a
| {{no|63 bytes UTF-8 [[String|string]]}}
| same limit for {{LSLGC|Avatar/Name|avatar names}}, although the character set for avatar names is significantly limited.
| n/a
|-
||Prim description length
| n/a
| {{no|127 bytes UTF-8 [[String|string]]}}
| n/a
| n/a
|-
||Temporary prims' lifetime
| n/a
| {{no|up to around 60 seconds}}
| depends upon when the next garbage collector cycle is
| n/a
|-
||Number of temporary prims
| n/a
| {{no|RegionPrimLimit - NumberOfPrimsInRegion + Minimum(0.5*RegionPrimLimit, 1000)}}
| n/a
| n/a
|-
||Length of hovertext
| n/a
| {{no|254 bytes UTF-8 [[String|string]]}}
| n/a
| [[llSetText]] and [[PRIM_TEXT]]
|}

== [https://community.secondlife.com/knowledgebase/english/lighting-and-shadows-r331/ Lighting] ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||Number of active light sources
| n/a
| no limit
| Advanced Lighting Model (ALM) was developed around 2011-2013 to remove the hard limit on light sources.
|-
||Number of projectors rendered at full detail
| n/a
| {{no|2}}
| Only the 2 projectors closest to an object will cause it to cast shadows. Additional projectors still affect color.
| [https://community.secondlife.com/knowledgebase/english/lighting-and-shadows-r331/#Projectors Knowledge Base > Lighting > Projectors]
|-
||Number of lights rendered on Alpha Blended surfaces
| n/a
| {{no|8}}
| 8 including the Sun and Moon. The viewer will attempt to select the "most significant" lights to render, however these blended surfaces will look different as a result of these lighting limitations.
| [[Alpha Modes Do's and Don'ts#Alpha_blending|Alpha Blending]]
|}

== [[Communication]] ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||Whisper distance
| n/a
| {{no|10 meters}}
| <code>/whisper</code> as the first few characters in a message can be used in viewer-2-code based viewers in local chat.
| n/a
|-
||Chat distance
| n/a
| {{no|20 meters}}
| text spoken as a "chat" step '''within gestures''' cannot be shouted or whispered. /whisper and /shout ''can'' be used in the "Replace with" field.
| n/a
|-
||Shout distance
| n/a
| {{no|100 meters}}
| <code>/shout</code> as the first few characters in a message can be used in viewer-2-code based viewers in local chat.
| n/a
|-
||Length of a chat message and whether or not it is truncated
| {{no|1 byte or single-byte character}}
| {{no|1024 bytes or single-byte characters}}
| Limit does not apply to instant messages via [[llInstantMessage]] and communication between IM and email, the limit there is 1023 bytes or single-byte characters.
The viewer-to-server communication on ''negative'' channels is truncated to 254 bytes, and on ''positive'' channels, to 1023 bytes. These limits do not affect communication between scripts.
| [[llInstantMessage]]
|-
||Maximum events
| n/a
| {{no|64 events}}
| Events are stored in a 64 bit bitmap. Events happening when the bitmap is full, will get discarded.
| n/a
|-
||Number of offline messages
| n/a
| {{no|Capped at 30 messages for Basic members, 40 for Plus members, 120 for Premium members, and 240 for Premium Plus members.}}
| Number of offline messages (involving [[IM|IMs]], inventory offers, group notices, group invitations) received before messages get capped. Note: If autoAcceptNewInventory (debug setting) is set to TRUE (the default is FALSE), then all inventory offers, even above the cap allowed by membership, go directly to inventory and do not count against the cap on offline messages.
| [[IM]] - [https://community.secondlife.com/blogs/entry/2559-group-limits-update-no-changes-for-basic-members/ Blog Post]
|-
||Length of a properly delivered email reply to an [[IM]]
| n/a
| {{no|1023 bytes or single-byte characters}}
| n/a
| n/a
|-
||Time after which a reply to an [[IM]] can be sent via email.
| {{no|when receiving the IM via email.}}
| {{no|5 days after receiving the offline IM via email.}}
| n/a
| [https://blogs.secondlife.com/community/features/blog/2007/02/06/im-to-e-mail-return-addresses-changing Second Life Blogs]
|-
||Time period for which [[IM|IMs]] are stored within Second Life.
| n/a
| {{no|31 days after receiving the [[IM]]}}
| [[User:Torley_Linden|Torley Linden]] confirmed this with [[User:Kelly_Linden|Kelly Linden]]
| n/a
|-
||Number of [[IM|IMs]] sent by an object within an hour
| n/a
| {{no|5000 per hour}}
| n/a
| n/a
|}

== [[Gesture]]s ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||Shortcut key mappings
| n/a
| {{no|33 unique combinations, since {{K|F2}}–{{K|F12}} can be used with the {{K|Ctrl}} or {{K|Shift}} modifiers.}}
| n/a
| [[All_keyboard_shortcut_keys]] and [http://community.secondlife.com/t5/English-Knowledge-Base/Keyboard-shortcuts/ta-p/1086557 the knowledge base]
|-
||Chat step length
| n/a
| {{no|127 bytes or single-byte characters}}
| n/a
| n/a
|-
||Wait time
| n/a
| {{no|3600 seconds (which is one hour)}}
| n/a
| n/a
|-
| Maximum steps data
| n/a
| {{no|1000 bytes}} of packed data; saving with more data returns the message "Gesture save failed. This gesture has too many steps. Try removing some steps, then save again." Shorter text, for example, will allow more steps.
| n/a
| n/a
|-
||Length of included assets
| n/a
| see sections for [[#Animation|animation]], [[#Sound|sound]]
| n/a
| n/a
|}

== [[Group]]s ==

* '''Maximum number of groups you can belong to:''' 50 for Basic members, 55 for Plus members, 80 for Premium members, 150 for Premium Plus members.
** After downgrading from a higher limit membership to a lower one, you may not join any new groups until you are a member of fewer than your current subscriptions's group limit. For example, if you downgrade from Premium (70 groups allowed) to Basic (42 groups allowed), you can't join any new groups until you're a member of fewer than 42 groups.
** Roles within groups are sort of like sub-groups. In many cases, you can use them instead of creating new groups.
* '''Minimum number of members in a group:''' 2
** A group with only 1 person for 48 hours will be disbanded (cancelled). Unless the group owns land.
* '''Maximum number of roles allowed in a group:''' 10 (including "Owners" and "Everyone", which cannot be deleted)
* '''Maximum Group Name:''' 35 single-byte characters.
* '''Maximum Group Title:''' 20 single-byte characters.
* '''Maximum Length of a Group Notice:''' 512 single-byte characters.
* '''Maximum Age of a Group Notice:''' 14 days.

== [[Inventory]] ==

* '''Maximum number of inventory items that can be sent in a folder:''' 42
** Folders count as items too. This has more to do with packet size limits than cheeky Douglas Adams references.
* '''Maximum number of accounts that an inventory item can be shared with at once:''' The limit is unknown, but tests show that it is more than 35. No documentation has been found. One third-party viewer developer says that the code doesn't seem to look for a limit. It just builds the list and sends it to each avatar individually.
* '''Maximum number of inventory items that can be contained in a prim:''' 10,000
* '''Maximum characters in an inventory item name:''' 63
* '''Maximum notecard line:''' None, but scripts can only read the first 1024 bytes (was 255 bytes before server version [https://releasenotes.secondlife.com/simulator/2021-10-25.565008.html 2021-10-25.565008]).
* '''Maximum notecard size:''' 65,536 bytes

* '''Number of items in the Library:''' 3,500 as of 2019-08-10
** Verified by [[How_does_the_Library_work|hiding the Library]] and counting the difference.
* '''Maximum number of inventory items displayed in a single inventory folder:''' Several thousand. 
** This was discussed during [http://wiki.secondlife.com/wiki/Simulator_User_Group/Transcripts/2011.03.08] "the folder will load up to the limit number of items, and remaining ones won't show up in the viewer. you still own them, they aren't lost, but they will be hidden until the folder size is reduced."
** There is no specified limit for total avatar inventory, very large folders can be split.
** There was discussion in the Third Party Developers' UG (4/10/2015) meeting about new inventory and login problems from having large numbers of items in a single folder. AISv3 ''removed'' server-side limits on the number of items in a folder. Flat inventories are bad. No one is certain at what number of items in a folder cause a login problem. The fix is to clear the inventory cache (not the viewer cache) and log into a deserted, empty region then move inventory items into folders and sub-folders. - The problem appears at different a number of items depending on your computer and connection speed. Hopefully being on an empty region will give one enough edge to get logged in and do some corrective work before being dropped. If not, you will need to contact support for help. They will divide large folders into smaller groups so you can log in.

== [[Land]] ==

* '''Maximum [[Land#Parcel|parcel]] size:''' 65,536 meters²
** Covering a whole region, or square on the World Map.
* '''Minimum parcel size:''' 16 meters²
* '''Maximum parcel name length:''' 63 single-byte characters
* '''Maximum parcel description length:''' 255 characters
* '''Region name length:''' Linden Concierge policy states a minimum of 3 characters, and a maximum of 25 characters (including spaces). See [[Linden Lab Official:Guidelines for Private Region Naming|Guidelines for Private Region Naming]]. However, the technical maximum limit is 35 characters, and exceptions to the concierge policy do exist (e.g [http://maps.secondlife.com/secondlife/Sandbox%20-%20Weapons%20testing%20%28no%20damag/128/128/2 Sandbox - Weapons testing (no damag] and [http://slurl.com/secondlife/X/128/128/24 X])
* '''Ban line height for "no entry" or "pay to access"''' (in other words, "allow public access" is turned off, or "allow group access" is turned on, in the parcel options) is the parcel's ground elevation ''plus'' 50 meters (except, if the region has been set to "Block Parcel Fly Over" in which case the access controls extend to at least 4096 meters). If a user is '''explicitly banned by name''', the height is the parcel's ground elevation ''plus'' 5000 meters. On current viewers this is visible to the full extent.
* '''Maximum prims in a [[Land#Region|region]]:'''
** "Mainland / Full Region" and "Linden Homes / Full Region": 22,500
** Full Regions in private estates: 20,000 with an [https://community.secondlife.com/t5/Featured-News/Upgrade-Your-Full-Private-Region-to-30-000-Land-Impact-Today/ba-p/3086162 option for 30,000]
** Homestead: 5,000
** Openspace : 1,000
:: To check a region's capacity, use <tt>[[llGetEnv]]("region_max_prims")</tt>.
::''(Region types are as found in the General tab of World > About Land, or returned by ''<tt>llGetEnv("region_product_name")</tt>'')''
* '''Maximum auto return value''': Besides {{code|0}} (which means ''never''), {{HoverText|999,999|Almost 23 months}} minutes is the highest auto return value.
* '''Terraforming limits:'''
** Most mainland can be raised/lowered by 4 meters (+/-).
** Some mainland regions cannot be terraformed, including: Bay City regions, Boardman, Brown, De Haro, Horizons, Kama City regions, Nautilus City regions, Nova Albion regions, and Shermerville regions.
** [http://community.secondlife.com/t5/English-Knowledge-Base/Linden-Homes/ta-p/700103 Linden Homes] do not allow terraforming.
** A few, very old mainland Regions like Da Boom have a terraform range of 40 meters (+/-).
** Estate (private island) terraformability is settable to a maximum of 100 meters (+/-) by the estate owner or managers.
* '''Maximum water height:''' 100 meters using inworld controls, 255 meters by using a {{code|*.raw}} file upload.
** Region water height is usually 20 meters, and adjacent regions should have the same water height, or else they will look discontinuous.
* '''Maximum terrain height:''' 255 meters using inworld controls (Region/Estate setting & Edit Terrain tool), 510 meters by using a {{code|*.raw}} file upload.
* '''Miscellaneous estate limits:''' You can have a maximum of 20 estate managers, 500 allowed Residents, 63 allowed groups, and 750 banned Residents.
** See World menu > Region/Estate > Estate tab.
* '''Maximum number of agents'''
** [https://second.life/eventregions Event Regions]: 175 agents
** Full region: 100 basic account users plus 10 additional available to premium accounts. (Typically set to 40 on mainland, 55 on Linden Homes regions, but this does vary. Some meeting areas have this set to 60 and higher.)
*** Recent server performance improvements make regions with 60 agents in them perform quite well.
** [[Land#Homestead|Homestead]]: 20 (plus 5 additional available to premium accounts)
** [[Land#Openspace|Openspace]]: 10 (plus 2 additional available to premium accounts)
* '''Freeze Time:''' Land owners can [[freeze]] other Residents for up to 30 seconds. Members of land-owning groups can also be granted this ability.
* '''Minimum parcel that can be listed in Places or All search:''' 144 meters² 
* '''Minimum parcel that can be listed in Events:''' 512 meters²
* '''Maximum altitude for event listings:''' 768 meters ({{JIRA|WEB-814}})
* '''Maximum heights that objects can be seen on the [[World Map]]:''' 400.005m
* '''Maximum height that avatars will be hidden if 'Avatars on other parcels can see and chat with avatars on this parcel' is checked:''' 50m above the ground (see 'Ban line height' above)

== [[Mesh]] ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||Number of vertices
| n/a
| {{no|65536 vertices per LOD}}
| per [[mesh]] - See [[Talk:Limits#Mesh_Limits|discussion page]]
| n/a
|-
||COLLADA file size
| n/a
| {{no|8 MB}}
| Maximum mesh asset size after compression, roughly equivalent to a 256 MB Raw COLLADA file.
| n/a
|-
||Bone influence weights per vertex
| n/a
| {{no|4}}
| n/a
| n/a
|-
||Bone influence weights per mesh
| n/a
| {{no|110}}
| some folk have reported needing to go as low as about 99 in rare cases
| n/a
|-
||Number of materials per mesh
| n/a
| {{no|8}}
| n/a
| n/a
|-
||Number of materials per face
| n/a
| {{no|1}}
| n/a
| n/a
|-
||Physics weight for a vehicle
| n/a
| {{no|32.0}}
| n/a
| n/a
|-
||Maximum number of triangles for Animesh
| n/a
| {{no|100,000}}
| Server uses estimated triangles (streaming cost calculated), not visual triangles.
| [[Animesh User Guide|Animesh_User_Guide]]
|}

===User Found Temporary Mesh Limits:===
''Because of an apparent bug in the importer stay within these limits.''
* 174,752 triangles, beyond which additional triangles will appear as holes.
* The 64k vertices per material is pre-empted by a limit of 21,844 triangles per material, which is presently reported as {{Jira|BUG-1001}}. (4/2014 - See [[Talk:Limits#Mesh_Limits|discussion page]])

:: The import process will continue making new materials beyond 8 x 21,844 (=174,752) triangles, but the extra triangles then get dropped by the limitation to 8 materials, causing holes in the resulting object. Over the 21,844-triangle limit, the vertex count will start to climb steeply, even with smooth shading, because the materials get highly interspersed. So the same vertices have to appear in multiple material lists. So, the moral of the story is to stay below 21,844 triangles per material, for now, if you want to avoid some unexpected effects.

::Since viewer release 3.8.4, processing of meshes in the Collada file that have faces assigned to more than 8 materials has changed. Instead of simply dropping the extra material faces, the uploader now creates a new object to accommodate them. The result is that the single mesh is divided into multiple objects (prims) in a linkset. Thus, the limitation to 8 materials is removed as far as input is concerned, but still applies to each of the resulting linked objects actually uploaded. As a consequence, it is now possible to upload a mesh with more than 174,752 triangles, although it will be divided into multiple objects.

== Misc. ==

*'''[https://secondlife.com/currency/describe-limits.php Billing and Trading Limits]''' - Includes [https://secondlife.com/whatis/economy-market.php LindeX] currency exchange limits.

== Navigation ==

[[File:Max Alt.jpg|thumb|right|435px|'''Height counter error above 2147483647 meters''']]
* '''Absolute height limit:''' [http://en.wikipedia.org/wiki/2147483647#2147483647_in_computing 2147483647] = 231 − 1 meters, which causes the altitude counter to roll over. Altitudes well below this cause graphics errors probably due to limited floating point number precision.
* '''Highest z-value of an [[SLurl]], that will still teleport you to a positive altitude:''' 4096
** This used to be much higher, but is clamped in late model viewers.

== [[Profile]] ==

Each 7-bit ASCII character is encoded in one byte. International characters might need more bytes. When pasting text instead of typing, you can get in one byte more into each of the below.

* '''2nd Life tab's About field''' - 510 bytes
* '''Picks tab''' - 20 picks with 1022 bytes each
* '''1st Life tab's Info field''' - 253 bytes
* '''Classified tab''' - 100 listings with x bytes each
* '''My Notes''' - 1022 bytes

== [[Lag|Performance]] ==

* '''Healthy Viewer FPS''' - Generally, FPS equal to or above 24 is good. The higher it gets, the smoother'''*'''. You can check via [[Advanced]] menu > Performance Tools > Lag Meter, or for more advanced usage, see Advanced > Performance Tools > Statistics Bar.
* '''Avatar Rendering Cost scores''' - [[Avatar Rendering Cost|Learn all about it!]]

'''*''' Only until your framerate reaches your monitor's refresh rate, after this point there will be very little benefit.

== [[Scripting]] == 

* '''Height at which scripts reactivate on a no-script parcel''' - 50 m above terrain mesh. Scripted objects that take controls will keep running when you fly down or enter a no-script parcel. (If scripts are disabled in the region debug panel, they will not run at any height.)
* '''Maximum height where scripts can run''' - none, as long as the object remains rezzed or attached.
* '''Maximum script source code size''' - 65536 single byte characters (that's a viewer limit and can be changed in the config file 'panel_script_ed.xml').
* '''Maximum script memory size (LSO)''' - 16384 bytes.
* '''Maximum script memory size ([[Mono]])''' - 65536 bytes (the maximum memory available to Mono scripts can be constrained via [[llSetMemoryLimit]]).
* '''Maximum memory for [[:Category:LSL LinksetData|Linkset data]]''' key/value pairs - 128 KiB
* '''Maximum memory for [[:Category:Experience Tools|Experience]]''' key/value pairs- 128 MiB
* '''Maximum active [[llListen|listeners]] per script''' - 65.
** '''Usable channel for each listener''' - ''min.'' -2147483648, ''max.'' 2147483647, including the following special channels: [[PUBLIC_CHANNEL]] ''and'' [[DEBUG_CHANNEL]].
* '''Maximum number of scripts that can be rezzed at once''' – 1,000. (Refer to [https://community.secondlife.com/knowledgebase/english/building-tips-r13/ Building Tips, by Jeremy Linden].)
* For specific scripting limits, look up calls in the '''[[LSL Portal]]'''.

== [[Sound]] ==



{{KBtip|Second Life will accept sounds that are encoded following "[https://en.wikipedia.org/wiki/Compact_Disc_Digital_Audio CD Quality]" encoding presets present in many {{Abbr|DAW|Digital Audio Workstation}}s.}}

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||Sound length
| n/a
| {{no|less than 30 seconds or precisely 1,323,000 samples}}
| The advice is typically to upload sounds less than 30.0 and that 29.99 seconds is fine. However if you do wish to be able upload sounds that are 30 seconds precisely then the .WAV file must have exactly 1,323,000 samples (44,100Hz * 30 seconds). Specifically anything above 1,323,000 samples fails to upload.
| '''[https://community.secondlife.com/knowledgebase/english/uploading-assets-r75/ Uploading Assets]'''
|-
||Bit depth
| n/a
| {{no|16 bit}}
| n/a
| n/a
|-
||Sample rate
| n/a
| {{no|44.100 kHz}}
| n/a
| n/a
|-
||Audio channels
| n/a
| {{no|1 channel (mono)}}
| Channels will be '''merged''' at upload time for dual-channel (stereo) audio.
| n/a
|}

== [[Textures]] ==
* '''[http://en.wikipedia.org/wiki/Aspect_ratio Aspect ratios]''' of profile, place, etc. pictures — all of these were measured at UI size (Edit menu > Preferences > General tab > UI Size) = 1.000:

=== Second Life Viewer 3.6 ===

* '''Search > Classifieds thumbnail''' - ~3:2 (101×69 pixels)
* '''Search > Classifieds expanded''' - ~4:3 (159×120 pixels)
* '''Search > Classifieds expanded > More Info''' - native aspect ratio
* '''Search > Destination Guide thumbnail''' - ~3:2 (101×69 pixels)
* '''Search > Destination Guide expanded''' - ~4:3 (159×120 pixels)
* '''Search > People''' - 1:1 (100×100 pixels)
* '''Search > Places expanded''' ~4:3 (159×120 pixels)
* '''Place Profile''' - ~3:2 (290×197 pixels)
* '''About Land > Options tab''' - ~4:3 (195×150 pixels)
* '''Profile > Picture''' - native aspect ratio; thumbnail cropped to 72×72 pixels; zoomed uncropped up to 300×300 pixels
* '''Profile > Real world picture''' - native aspect ratio; thumbnail cropped to 45×45 pixels; zoomed uncropped up to 300×300 pixels
* '''Profile > Picks thumbnail''' - ~16:9 (~516×~270 pixels as measured on screen; the ratio seems closer to 16:8.5)
* '''Profile > Pick expanded''' - Unknown as of 2022-11-13 (viewer 6.6.7.576223); the Pick image does not expand.

=== 1.x Series Viewers ===
(official Viewer up to 1.23.5, still used by some [[Alternate viewers|Third Party Viewers]])
* '''Search > All for "Classifieds", "People", and "Places"''' - 4:3 (256×192 pixels)<ref>As of {{#time: r|2024-02-26T18:00:00}}, this seems to be one of the very few sizes supported by the [[Picture Service]].</ref>
* '''Search > Places and Classified tabs''' - ~7:5 (398×282 pixels)
* '''Search > Land tab''' - ~7:5 (358×252 pixels)
* '''Profile > 2nd Life tab''' - ~4:3 (178×133 pixels)
* '''Profile > Picks tab''' - 16:9 (288×162 pixels)
* '''Profile > 1st Life tab''' - 1:1 (133×133 pixels)
* '''Profile > Classifieds tab''' - ~3:2 (206×137 pixels)
* '''Profile > Web tab''' - 1:1 (400×400 pixels)
** A scrollbar uses 15 pixels on the right-hand side.
* '''About Land > Options tab''' - ~3:2 (178×117 pixels)
* '''Group Information > General tab's "Group Insignia"''' - 1:1 (126×126 pixels)
** Some of these textures are shared (for example, Search > All place pages, Search > Places, and About Land > Options use the same image), so you should pick a well-balanced ratio and size.
** [[Texture_aspect_ratios|Learn how to get correct texture aspect ratios when editing images.]]

=== All Viewers ===

* '''Maximum texture size''' - 2048×2048 pixels
** All Second Life textures are constrained to [http://en.wikipedia.org/wiki/Power_of_2 powers of 2] (e.g., 128, 256, 512).
** We strongly recommend you use as small textures as possible because larger ones consume more memory and take substantially longer to load.
** Where large textures are being forced by import to only 512×512, lower your ...> Preferences >...> UI Size under 1.0, to increase import size to the max 2048×2048.

* '''Minimum texture size''' - 4×4 pixels
** This means that there are ten possible image dimensions: 4, 8, 16, 32, 64, 128, 256, 512, 1024 & 2048 pixels, either horizontal or vertical.

* '''Texture resizing'''
** Uploaded textures will be resized to the dimensions above.
** Each dimension is resized independently (for instance, a 1024 x 999 image will be resized to 1024 x 1024).
** A dimension that is already a power of two will not be resized.
** The uploader “prefers” to round down rather than up. The threshold for rounding down/up is .75 of the distance between powers of two.
*** For example, given a dimension of x, if x / 512 is larger than 1.75, x will be resized to 1024, else 512.
*** Another example: If x / 256 is larger than 1.75, x will be resized to 512.

[[Category:Creation]] [[Category:Tutorials]] [[Category:Lists]]

=== Notes ===
In general, 1 byte is enough to contain one character.<ref>Except in .NET-based applications, and those related to .NET development — which is the case of the SL viewer — which essentially use UTF-16 everywhere, i.e., every character is encoded in ''two'' bytes, not just one.</ref>

Text using Unicode characters (including, but not limited to, emojis), where supported, will require 1–4 bytes (depending on the encoding).

----
{{References}}

Viewer URI Name Space

2025-10-27T20:41:34Z

Wulfie Reanimator: Added /mention

{{ProtocolNav}}

== Overview ==

The SL client supports {{Wikipedia|URI|links}} of the format {{mono|<nowiki>secondlife://Region/123/45/67/<region name></nowiki>}}, which have traditionally specified a region name and {{mono|x/y/z}} location. This means "run Second Life viewer and show Region on the world map".

The new {{Wikipedia|URI|URL scheme}} has 3 slashes<ref name="RFC3986">Two slashes for the beginning of the authority section — for HTTP requests, this is the name of the server (optionally with the port) — here it's empty; followed by a third slash, terminating the authority section. See https://www.rfc-editor.org/rfc/rfc3986#section-3.2 . Because Second Life is omitting the 'authority' part, that section is empty, thus the three slashes; note that Second Life is ''not'' the only example of an 'authorityless' communications protocol; there are plenty of other examples.</ref>, and allows direct control of the user interface and login. For example, {{mono|<nowiki>secondlife:///app/login</nowiki>}}

Most {{mono|<nowiki>secondlife:///app</nowiki>}} URLs only work from browser instances running inside Second Life because of a denial-of-service attack using {{mono|<nowiki>secondlife:///app/teleport</nowiki>}} links to force repeated teleports. [[SLURL]]s that work with external browsers include:
* {{mono|<nowiki>secondlife://<region name></nowiki>}}
* {{mono|<nowiki>secondlife:///app/login</nowiki>}}

In chat, dialogs and other user interface elements, these URLs will be highlighted as clickable links, often with custom formatting including icons. The full functionality is available in Viewer 2.0 and up. Clickable links without formatting were available only in older versions' chat and [[Instant Message|IM]] history.

These links also may be known as ''Viewer URL Namespace'', ''SLAPP URLs'' or ''Application [[SLURL]]''.

== Syntax ==

'''<nowiki>secondlife://</nowiki>'''
: '''<region_name>''' log in to this region or, if logged in, show information and offer teleport
:: '''/<local_x>''' optional X position, defaults to 128
::: '''/<local_y>''' optional Y position, defaults to 128
:::: '''/<local_z>''' optional Z position, defaults to 0

: '''/app'''
:: '''/agent'''
::: '''/<agent_id>'''
:::: '''/about''' open agent's profile, with 2nd Life tab selected
:::: '''/inspect''' display info dialog for agent (2.0)
:::: '''/im''' start an IM session with the agent (2.0)
:::: '''/mention''' creates a link for the agent, the agent's viewer may notify them with sound and highlight if they hear the message.
:::: '''/offerteleport''' display teleport offer dialog (2.0)
:::: '''/pay''' display pay resident dialog (2.0)
:::: '''/requestfriend''' display friendship offer dialog (2.0)
:::: '''/mute''' add to block list (2.0)
:::: '''/unmute''' remove from block list (2.0)
:::: '''/completename''' replace the URL with the avatar's display and user names,
:::::e.g., "hmm <nowiki>secondlife:///app/agent/eea40b5a-553d-4a07-b1ca-9f6e2f867814/complete</nowiki> wow" in chat becomes "hmm Cerise (cerise.sorbet) wow" (2.4); see {{LSLGC|Avatar/Name}} for more details.
:::: '''/displayname''' replace the URL with the avatar's display name (2.4)
:::: '''/username''' replace the URL with the avatar's username e.g. "user.name" (2.4)
:: '''/appearance'''
::: '''/show''' display the sidebar appearance tab (2.0)
:: '''/balance'''
::: '''/request''' request a [[L$]] balance update from the server (2.0)
:: '''/chat'''
::: '''/<channel>''' any channel number greater than 0<ref>The public (chat) channel, also written as [[PUBLIC_CHANNEL]]</ref> except [[DEBUG_CHANNEL]].
:::: '''/<text>'''
:: '''/classified'''
::: '''/<classified_id>'''
:::: '''/about''' open floater describing classified
:: '''/event'''
::: '''/<event_id>'''
:::: '''/about''' open floater describing event
:: '''/experience'''
::: '''/<experience_id>'''
:::: '''/profile''' open floater describing experience
:: '''/group'''
::: '''/<group_id>'''
:::: '''/about''' open floater describing group
:::: '''/inspect''' display info dialog for group (2.0)
::: '''/create''' open the create group dialog (1.20)
::: '''/list'''
:::: '''/show''' open the list of groups to which user belongs (1.20)
:: '''/help'''
::: '''/<help_query>''' optional help topic (2.0)
:: '''/inventory'''
::: '''/<inventory_id>'''
:::: '''/select''' inventory offer (2.0)
::: '''/show''' open the inventory sidebar tab (2.0)
:: '''/keybinding'''
::: Movement controls
::: '''/walk_to''' Walk to location mouse cursor points to
::: '''/teleport_to''' Teleport to location mouse cursor points to, but not all locations allow direct teleportation so you might be teleported closer to destination instead
::: '''/push_forward''' Move Forward
::: '''/push_backward''' Move Backward
::: '''/turn_left''' Left
::: '''/turn_right''' Right
::: '''/slide_left''' Strafe left
::: '''/slide_right''' Strafe right
::: '''/jump''' Jump/Up
::: '''/push_down''' Down
::: '''/run_forward''' Run Forward
::: '''/run_backward''' Run Backward
::: '''/run_left''' Run Left
::: '''/run_right''' Run Right
::: '''/toggle_run''' Toggle Run
::: '''/toggle_fly''' Fly/Stop flying
::: '''/toggle_sit''' Sit/Stand
::: '''/stop_moving''' Stop Moving
::: Camera controls
::: '''/look_up Look Up
::: '''/look_down''' Look Down
::: '''/move_forward''' Camera Forward
::: '''/move_backward''' Camera Backward
::: '''/move_forward_fast''' Camera Forward Fast
::: '''/move_backward_fast''' Camera Backward Fast
::: '''/spin_over''' Camera Spin Over
::: '''/spin_under''' Camera Spin Under
::: '''/pan_up''' Camera Pan Up
::: '''/pan_down''' Camera Pan Down
::: '''/pan_left''' Camera Pan Left
::: '''/pan_right''' Camera Pan Right
::: '''/pan_in''' Camera Pan In
::: '''/pan_out''' Camera Pan Out
::: '''/spin_around_ccw''' Camera spin around counterclockwise
::: '''/spin_around_cw''' Camera spin around clockwise
::: '''/move_forward_sitting''' Camera Forward Sitting
::: '''/move_backward_sitting''' Camera Backward Sitting
::: '''/spin_over_sitting''' Camera Spin Over Sitting
::: '''/spin_under_sitting''' Camera Spin Under Sitting
::: '''/spin_around_ccw_sitting''' Camera spin around counterclockwise sitting
::: '''/spin_around_cw_sitting''' Camera spin around clockwise sitting
::: Editing controls
::: '''/edit_avatar_spin_ccw''' Camera spin around avatar counterclockwise
::: '''/edit_avatar_spin_cw''' Camera spin around avatar clockwise
::: '''/edit_avatar_spin_over''' Camera spin over avatar
::: '''/edit_avatar_spin_under''' Camera spin under avatar
::: '''/edit_avatar_move_forward''' Camera Forward
::: '''/edit_avatar_move_backward''' Camera Backward
::: Sound and Media controls
::: '''/toggle_pause_media''' Play/Pause Media
::: '''/toggle_enable_media''' Play/Stop All Media
::: '''/voice_follow_key''' Voice
::: '''/toggle_voice''' Toggle Voice
::: '''/start_chat''' Start Chat
::: '''/start_gesture''' Start Gesture
::: '''/script_trigger_lbutton''' Interact (Script LMB)
:::: Control modes
:::: '''?mode=''' "first_person" or 0, "third_person" or 1, "edit_avatar" or 2, "sitting" or 3. e.g. secondlife:///app/keybinding/push_forward?mode=sitting
:: '''/login''' log in on launch. External and internal browsers.
::: see below for query parameters, of course, values are URL escaped
:: '''/maptrackavatar'''
::: '''/<friend_id>''' find a friend on the world map, requires permission (2.4)
:: '''/objectim'''
::: '''/<object_id>''' display an info dialog for the object sending this message (2.0)
:::: '''?name=<object_name>'''
:::: '''&owner=<owner_id>'''
:::: '''&groupowned=true''' (add if the object is deeded to a group)
:::: '''&slurl=<region>/<x>/<y>/<z>'''
:: '''/openfloater'''
::: '''/<floater_name>''' e.g. "preferences", "people", "places", "picks", "destinations", "profile"
:: '''/parcel'''
::: '''/<parcel_id>'''
:::: '''/about''' open floater describing place
:: '''<strike>/region'''
::: '''/<region_id>'''
:::: '''/about''' information from database about that region? list of parcels? covenant?</strike>
:: '''/search'''
::: '''/<category>''' "all", "people", "places", "events", "groups", "wiki", "destinations", "classifieds"
:::: '''/<search_term>''' open a search floater with matching results (2.0)
:: '''/sharewithavatar'''
::: '''/<agent_id>''' open an inventory share/IM window for agent (2.4)
:: '''/teleport'''
::: '''/<region_name>''' teleport instantly to this region, no dialog
:::: '''/<local_x>''' optional X position, defaults to 128
::::: '''/<local_y>''' optional Y position, defaults to 128
:::::: '''/<local_z>''' optional Z position, defaults to 0
:: '''/voicecallavatar'''
::: '''/<agent_id>''' start a private voice session (2.4)
:: '''/wear_folder'''
::: '''/?folder_id=<inventory_folder_uuid>''' replace outfit with contents of specified folder (2.6)
::: '''/?folder_name=<library_folder_name>''' replace outfit with contents of named Library folder
:: '''/worldmap''' open the map with this destination selected (2.0)
::: '''/<region_name>'''
:::: '''/<local_x>''' optional X position, defaults to 128
::::: '''/<local_y>''' optional Y position, defaults to 128
:::::: '''/<local_z>''' optional Z position, defaults to 0

This could be extended to things like:
: '''/app/event/<event_id>/subscribe''' to register for notifications
: '''/app/parcel/<parcel_id>/teleport''' to teleport to a specific location

== Login Query Parameters ==
{| border="1"
|-
| first || the account first name
|-
| last || the account last name
|-
| session || the secure session id
|-
| location || login location, format TBD, optional
|}

== Second Life Wiki formatting ==

When adding {{mono|<nowiki>secondlife://</nowiki>}} links using the above syntax to a Second Life Wiki page, you can enclose your links in squared brackets (thus turning them into a standard Wiki external link), which also gives you the chance of changing the displayed text. Example:

<kbd><nowiki>[secondlife:///app/objectim/190f571d-fdf1-8f6c-4e9d-973e9b5e0566?name=ObjectName&owner=c93c3129-2250-4c79-a5f7-8c755ca2707e&groupowned=true&slurl=Location/128/128/27 ObjectName]</nowiki></kbd>

will display as

[secondlife:///app/objectim/190f571d-fdf1-8f6c-4e9d-973e9b5e0566?name=ObjectName&owner=c93c3129-2250-4c79-a5f7-8c755ca2707e&groupowned=true&slurl=Location/128/128/27 ObjectName]

In this case you will also need to ensure the object name has been escaped.

Sometimes, having the link clickable (which will attempt to launch the Second Life Viewer to open it), is not desirable. Instead, to display the {{Wikipedia|URI}} itself without making it clickable, surround it with {{mono|<nowiki><nowiki>...</nowiki></nowiki>}}. For example:

<kbd>'''<nowiki><nowiki>secondlife:///app/group/8db35111-979b-14a7-6a74-b47be86ce04f/about</nowiki></nowiki>'''</kbd>

will display as

<nowiki>secondlife:///app/group/8db35111-979b-14a7-6a74-b47be86ce04f/about</nowiki>

whereas

<kbd>'''<nowiki>secondlife:///app/group/8db35111-979b-14a7-6a74-b47be86ce04f/about</nowiki>'''</kbd>

will display the whole link and make it clickable, e.g.:

secondlife:///app/group/8db35111-979b-14a7-6a74-b47be86ce04f/about

== LSL Examples ==

<syntaxhighlight lang="lsl2">
string Who(key id)
{
return "secondlife:///app/agent/" + (string)id + "/inspect";
}

default
{
touch_start(integer num)
{
llSay(0, "Touched by " + Who(llDetectedKey(0)) + "." );
}
}
</syntaxhighlight>

[[Category:Name Spaces]]
[[Category:Search]]
[[Category:LSL Chat]]
[[Category:LSL_Dialog]]

LlWind

2025-10-23T16:01:22Z

Wulfie Reanimator: More testing and observations.

{{LSL_Function
|inject-2={{LSL Function/offset|offset|noZ=*|sim=*}}
|func=llWind
|sort=Wind
|func_id=44
|func_sleep=0.0
|func_energy=10.0
|return_type=vector
|p1_type=vector
|p1_name=offset
|func_footnote
|return_text=that is the wind velocity at the prim's [[llGetPos|position]] + {{LSLPT|offset}}
|spec
|caveats
|notes=
* Each region simulates its own wind with a random seed value, and chaos is scaled by the region's sun position.
** While the simulation is performed on a 16x16 grid, the wind has perfect resolution anywhere between those cells. (interpolated)
** This low resolution tends to result in smooth gradients of wind, however sudden and strong changes in wind speed and direction are possible.
** Vortexes and are also possible, sometimes multiple in the same region.
* Neighboring regions influence each other at the connecting border, which may lead to cascading changes for either region.
* Regions without neighbors exhibit very uniform wind across the whole region.
** Wind will occasionally change direction over time, but eventually stabilizes toward the new direction.
* Maximum wind speed can reach at least 20m/s.
|examples=
<syntaxhighlight lang="lsl2">
default
{
touch_start(integer num)
{
llSay(0, "Wind velocity: " + (string)llWind(ZERO_VECTOR));
}
}
</syntaxhighlight>
<syntaxhighlight lang="lsl2">
// wind interpretation as angle and speed
default
{
state_entry()
{
vector windVector = llWind( ZERO_VECTOR);
float windSpeed = llVecMag( windVector);
float windDirection = llAtan2( windVector.y, windVector.x);
integer compassWind = ( 450 - (integer)( RAD_TO_DEG*windDirection))%360;
llOwnerSay( "\nWind direction: "+(string)compassWind+"°\nWind speed: "+(string)windSpeed+" m/S");
}
}
</syntaxhighlight>
|helpers
|also_functions={{LSL DefineRow||[[llCloud]]}}
|also_articles={{LSL DefineRow||{{LSLGC|Weather}}|SL Weather information}}
{{LSL DefineRow||[[User:Dora_Gustafson/moderated_world_wind|Moderated in-world wind]]}}
|notes
|issues={{Issue/V1|SVC-3131|llWind() and viewer wind effects do not match}}
|haiku={{Haiku|Softly blowing breeze|Calmly rustling through the tree|A gentle whisper}}
|cat1=Region
|cat2=Weather
|cat3
|cat4
}}

LlWind

2025-10-23T13:50:42Z

Wulfie Reanimator: Added notes from testing.

{{LSL_Function
|inject-2={{LSL Function/offset|offset|noZ=*|sim=*}}
|func=llWind
|sort=Wind
|func_id=44
|func_sleep=0.0
|func_energy=10.0
|return_type=vector
|p1_type=vector
|p1_name=offset
|func_footnote
|return_text=that is the wind velocity at the prim's [[llGetPos|position]] + {{LSLPT|offset}}
|spec
|caveats
|notes=
* Each region simulates its own wind with a random seed value, and chaos is scaled by the region's sun position.
** While the simulation is performed on a 16x16 grid, the wind has perfect resolution anywhere between those cells. (interpolated)
* Neighboring regions influence each other at the connecting border, which may lead to cascading changes for either region.
* Regions without neighbors exhibit very uniform wind across the whole region.
** Wind will occasionally change direction over time, but eventually stabilizes toward the new direction.
|examples=
<syntaxhighlight lang="lsl2">
default
{
touch_start(integer num)
{
llSay(0, "Wind velocity: " + (string)llWind(ZERO_VECTOR));
}
}
</syntaxhighlight>
<syntaxhighlight lang="lsl2">
// wind interpretation as angle and speed
default
{
state_entry()
{
vector windVector = llWind( ZERO_VECTOR);
float windSpeed = llVecMag( windVector);
float windDirection = llAtan2( windVector.y, windVector.x);
integer compassWind = ( 450 - (integer)( RAD_TO_DEG*windDirection))%360;
llOwnerSay( "\nWind direction: "+(string)compassWind+"°\nWind speed: "+(string)windSpeed+" m/S");
}
}
</syntaxhighlight>
|helpers
|also_functions={{LSL DefineRow||[[llCloud]]}}
|also_articles={{LSL DefineRow||{{LSLGC|Weather}}|SL Weather information}}
{{LSL DefineRow||[[User:Dora_Gustafson/moderated_world_wind|Moderated in-world wind]]}}
|notes
|issues={{Issue/V1|SVC-3131|llWind() and viewer wind effects do not match}}
|haiku={{Haiku|Softly blowing breeze|Calmly rustling through the tree|A gentle whisper}}
|cat1=Region
|cat2=Weather
|cat3
|cat4
}}

NULL KEY

2025-10-18T17:10:38Z

Wulfie Reanimator:

{{Issues/SVC-5772}}{{LSL_Constant/string}}{{LSL Constant
|name=NULL_KEY
|type=string
|value="00000000-0000-0000-0000-000000000000"
|desc='''NULL_KEY is a [[string]].''' However it is only really useful as a [[key]].

For {{LSLGC|Conditional}} tests, NULL_KEY evaluates to '''TRUE''' like other strings.

For list search (like [[llListFindList]]), NULL_KEY won't match null keys whose type is '''key''' without typecasting.
|examples=
<source lang="lsl2">
// Returns 2 for valid keys, 1 for NULL_KEY, 0 for invalid keys.
integer isKey(key input)
{
if (input) return 2;
return (input == NULL_KEY);
}
</source>
<source lang="lsl2">
default
{
state_entry()
{
// NULL_KEY itself is evaluated as FALSE only when typecast to key.
if (NULL_KEY) { llOwnerSay("NULL_KEY is TRUE"); } // Correct.
else { llOwnerSay("NULL_KEY is FALSE"); } // Never.

if ((key) NULL_KEY) { llOwnerSay("Casted NULL_KEY is TRUE"); } // Never.
else { llOwnerSay("Casted NULL_KEY is FALSE"); } // Correct.

// NULL_KEY won't match keys in lists without typecasting.
// The following list contains a null key because avatars don't have creators:
list details = llGetObjectDetails(llGetOwner(), [OBJECT_CREATOR]);
integer index = llListFindList(details, [NULL_KEY]);
if (index >= 0) { llOwnerSay("NULL_KEY was found in list"); } // Never.
else { llOwnerSay("NULL_KEY was NOT found in list"); } // Correct.
}
}
</source>
|notes=In most situations NULL_KEY isn't needed; an empty string ("") will suffice. To take advantage of this certain practices have to be avoided. In many applications keys are checked against NULL_KEY to determine if they are valid; this is bad practice.

LSL makes it easy to check if a key is valid. Simply use the key as the parameter for a conditional.

That is, instead of <code>if(uuid != NULL_KEY)</code>, use <code>if(uuid)</code>. <code>if(uuid)</code> will only return [[TRUE]] if it is a valid key that is also not a null key.
|functions=
{{LSL DefineRow||[[llAvatarOnSitTarget]]|}}
{{LSL DefineRow||[[llDetectedKey]]|}}
{{LSL DefineRow||[[llGetNotecardLine]]|}}
{{LSL DefineRow||[[llGetLandOwnerAt]]|}}
{{LSL DefineRow||[[llGetPermissionsKey]]|}}
{{LSL DefineRow||[[llGetTexture]]|}}
{{LSL DefineRow||[[llListen]]|}}
|events=
{{LSL DefineRow||[[attach]]|}}
|haiku={{Haiku|My hopes for nothing|but for thirty two zeros,|have been dashed, four times.}}
|cat1=Key
|cat2
|cat3
|cat4
}}

NULL KEY

2025-10-18T17:09:13Z

Wulfie Reanimator: Corrected information about evaluation and typing.

{{Issues/SVC-5772}}{{LSL_Constant/string}}{{LSL Constant
|name=NULL_KEY
|type=string
|value="00000000-0000-0000-0000-000000000000"
|desc='''NULL_KEY is a [[string]].''' However it is only really useful as a [[key]].

For {{LSLGC|Conditional}} tests, NULL_KEY evaluates to '''TRUE''' like other strings.
For list search (like {{llListFindList}}), NULL_KEY won't match null keys whose type is '''key'''.
|examples=
<source lang="lsl2">
// Returns 2 for valid keys, 1 for NULL_KEY, 0 for invalid keys.
integer isKey(key input)
{
if (input) return 2;
return (input == NULL_KEY);
}
</source>
<source lang="lsl2">
default
{
state_entry()
{
// NULL_KEY itself is evaluated as FALSE only when typecast to key.
if (NULL_KEY) { llOwnerSay("NULL_KEY is TRUE"); } // Correct.
else { llOwnerSay("NULL_KEY is FALSE"); } // Never.

if ((key) NULL_KEY) { llOwnerSay("Casted NULL_KEY is TRUE"); } // Never.
else { llOwnerSay("Casted NULL_KEY is FALSE"); } // Correct.

// NULL_KEY won't match keys in lists without typecasting.
// The following list contains a null key because avatars don't have creators:
list details = llGetObjectDetails(llGetOwner(), [OBJECT_CREATOR]);
integer index = llListFindList(details, [NULL_KEY]);
if (index >= 0) { llOwnerSay("NULL_KEY was found in list"); } // Never.
else { llOwnerSay("NULL_KEY was NOT found in list"); } // Correct.
}
}
</source>
|notes=In most situations NULL_KEY isn't needed; an empty string ("") will suffice. To take advantage of this certain practices have to be avoided. In many applications keys are checked against NULL_KEY to determine if they are valid; this is bad practice.

LSL makes it easy to check if a key is valid. Simply use the key as the parameter for a conditional.

That is, instead of <code>if(uuid != NULL_KEY)</code>, use <code>if(uuid)</code>. <code>if(uuid)</code> will only return [[TRUE]] if it is a valid key that is also not a null key.
|functions=
{{LSL DefineRow||[[llAvatarOnSitTarget]]|}}
{{LSL DefineRow||[[llDetectedKey]]|}}
{{LSL DefineRow||[[llGetNotecardLine]]|}}
{{LSL DefineRow||[[llGetLandOwnerAt]]|}}
{{LSL DefineRow||[[llGetPermissionsKey]]|}}
{{LSL DefineRow||[[llGetTexture]]|}}
{{LSL DefineRow||[[llListen]]|}}
|events=
{{LSL DefineRow||[[attach]]|}}
|haiku={{Haiku|My hopes for nothing|but for thirty two zeros,|have been dashed, four times.}}
|cat1=Key
|cat2
|cat3
|cat4
}}

LlIsFriend

2025-08-02T15:21:15Z

Wulfie Reanimator: Removed bug caveat, fixed over a year ago.

{{LSL Function
|inject-2={{LSL Function/uuid|uuid|sim=*}}
|func=llIsFriend
|sort=IsFriend
|func_id=0|func_sleep=0.0|func_energy=10.0
|return_type=integer
|return_subtype=boolean
|p1_type=key|p1_name=agent_id
|func_desc=
|return_text=that is [[TRUE]] if {{LSLP|agent_id}} and the owner of the [[prim]] the [[script]] is in are friends, otherwise [[FALSE]].
|func_footnote
|spec=

* If the prim is owned by a group this function behaves identically to [[llSameGroup]]
* This function will return [[FALSE]] under the following edge cases:
** If neither the owner, nor the target agent are in the region.
** If the agent_id does not specify an agent.

|caveats=
* You are not your own friend.

|constants
|examples=
<syntaxhighlight lang="lsl2">
default
{
state_entry()
{
llSensorRepeat("", NULL_KEY, AGENT, 95, PI, 10);
}

sensor(integer count)
{
integer index;
for (index = 0; index < count; ++index)
{
string is_is_not = " is NOT ";
if (llIsFriend(llDetectedKey(index)))
{
is_is_not = " is ";
}
llSay(0, llDetectedName(index) + is_is_not + "a friend.");
}
}
}

</syntaxhighlight>
|helpers
|also_functions=
{{LSL DefineRow||[[llDetectedGroup]]}}
{{LSL DefineRow||[[llSameGroup]]}}
|also_tests
|also_events
|also_articles
|notes
|cat1=Avatar
|cat2=Group
|haiku
|cat3
|cat4
}}

LlAddToLandBanList

2025-07-25T18:16:23Z

Wulfie Reanimator: Updated description based on Github lsl_definitions.yaml

{{LSL_Function
|inject-2={{Issues/SVC-1911}}{{LSL_Function/avatar|avatar}}
|func_id=310|func_sleep=0.1|func_energy=10.0
|func=llAddToLandBanList|sort=AddToLandBanList
|p1_type=key|p1_name=avatar|p2_type=float|p2_name=hours
|func_footnote
|func_desc=Add {{LSLP|avatar}} to the parcel ban list for the specified number of {{LSLP|hours}}.

A value of 0 for {{LSLP|hours}} will add the agent indefinitely. The smallest value that {{LSLP|hours}} will accept is 0.01; anything smaller will be seen as 0.

Residents teleporting to a parcel where they are banned will be redirected to a neighboring parcel.
|return_text
|spec
|caveats=
* Must be owned by the land owner.
* When values below 1 are used, it seems the function bans in approximately 30 second increments. (Probably 36 second increments, as 0.01 of an hour is 36 seconds)
|constants
|examples=<source lang="lsl2">// This is not a complete solution, requires full avatar names to work - even for unbanning someone!
// This is meant only as an example of the land ban and pass management functions.
// free to copy, use, modify, distribute - just don't ask me to debug your modified code. ;-)
//
// Commands are:
// /5 ban:full_avatar_name
// /5 tempban:full_avatar_name
// /5 unban:full_avatar_name
// /5 pass:full_avatar_name
// /5 unpass:full_avatar_name
// /5 clearban
// /5 clearpass

string command;

default
{
state_entry()
{
llListen(5, "", llGetOwner(), "");
}

on_rez(integer param)
{
llResetScript();
}

listen(integer chan, string name, key id, string message)
{
if (command != "")
{
llOwnerSay("Sorry, still processing last command, try again in a second.");
}

list args = llParseString2List(message,[":"],[]);
command = llToLower(llList2String(args,0));

if (command == "clearbans")
{
llResetLandBanList();
}
if (command == "clearpass")
{
llResetLandPassList();
}
else
{
llSensor(llList2String(args,1),NULL_KEY,AGENT,96,PI);
}
}

no_sensor()
{
command = "";
}

sensor(integer num)
{
integer i = 0;
for (; i < num; ++i)
{
if (command == "ban")
{
// Ban indefinetely
llAddToLandBanList(llDetectedKey(i),0.0);
}
if (command == "tempban")
{
// Ban for 1 hour.
llAddToLandBanList(llDetectedKey(i),1.0);
}
if (command == "unban")
{
llRemoveFromLandBanList(llDetectedKey(i));
}
if (command == "pass")
{
// Add to land pass list for 1 hour
llAddToLandPassList(llDetectedKey(i),1.0);
}
if (command == "unpass")
{
llRemoveFromLandPassList(llDetectedKey(i));
}
}
command = "";
}
}</source>
|helpers
|also_functions=
{{LSL DefineRow||[[llAddToLandPassList]]|}}
{{LSL DefineRow||[[llRemoveFromLandBanList]]|}}
{{LSL DefineRow||[[llRemoveFromLandPassList]]|}}
{{LSL DefineRow||[[llResetLandBanList]]|}}
{{LSL DefineRow||[[llResetLandPassList]]|}}
|also_tests
|also_events
|also_articles
|issues
|haiku=
{{Haiku|All are welcome here|except for the following|who have annoyed me}}
|cat1=Security
|cat2=Parcel
|cat3
|cat4
}}

LlSetGroundTexture

2025-07-25T14:25:55Z

Wulfie Reanimator: Added return type

{{LSL_Function
|inject-2
|func_id=|func_sleep=0.0|func_energy=10.0
|sort=SetGroundTexture
|func=llSetGroundTexture|sort=SetGroundTexture
|return_type=integer
|p1_type=list|p1_name=changes|p1_desc=List of changes to apply to ground textures on the region.
|func_desc=
Changes the textures used to paint the terrain of a region. The owner of the script must be able to manage the estate.
|return_text
|spec
|caveats=
* This function must be executed from a script in an object owned by the region owner or an estate manager.
* This function is throttled at 4 calls every 2 minutes.
* PBR terrain is all or nothing. Mixing normal terrain textures with PBR textures will cause the PBR textures to appear gray.
|constants=
{{LSL Constants/GroundTexture}}
|examples
|helpers
|also_functions=
{{LSL DefineRow||[[llModifyLand]]|Modifies terrain contours.}}
|also_tests
|also_events
|also_articles
|notes
|cat1=Ground
|cat2=Region
|cat3
|cat4
}}

LlSetAgentEnvironment

2025-07-25T14:23:23Z

Wulfie Reanimator: Added return type

{{LSL_Function
|func=llSetAgentEnvironment
|return_type=integer
|func_desc=This function sets environment values for an individual agent in an experience. The changes to the environment persist until the agent moves to a new region or llSetAgentEnvironment is called for an agent with an empty list. Passing an empty list in params will strip all environmental settings applied to this agent as part of the experience
|p1_type= key|p1_name= agent_id|p1_desc= The key for an agent in the region. The agent must be in the region and must be participating in the experience.
|p2_type= float|p2_name= transition|p2_desc= The number of seconds over which to transition to the new settings.
|p3_type= list|p3_name= params|p3_desc= A list of parameters to retrieve from the current environment. See table below for details.
|constants=
{{{!}} class="sortable" {{Prettytable|style=margin-top:0;}}
{{!}}+ '''Return Values'''
{{!}}-{{Hl2}}
!Value
!Constant
!Description
{{!}}-
{{!}} {{!!}} 1 {{!!}} The agent has been instructed to change their environment.
{{!}}-
{{!}} ENV_NOT_EXPERIENCE {{!!}} -1 {{!!}}The script is not running as part of an experience with a valid experience key.
{{!}}-
{{!}} ENV_NO_EXPERIENCE_PERMISSION {{!!}} -2 {{!!}} The agent has not granted permission.
{{!}}-
{{!}} ENV_NO_ENVIRONMENT {{!!}} -3 {{!!}} The environment inventory object could not be found.
{{!}}-
{{!}} ENV_INVALID_AGENT {{!!}} -4 {{!!}} Unable to find specified agent.
{{!}}-
{{!}} ENV_INVALID_RULE {{!!}} -5 {{!!}} There was an issue with one of the rules.
{{!}}-
{{!}} ENV_VALIDATION_FAIL {{!!}} -6 {{!!}} Unable to validate values passed.
{{!}}-
{{!}} ENV_NO_EXPERIENCE_LAND {{!!}} -7 {{!!}} The experience has not been enabled or can not run on the land.
{{!}}-
{{!}} ENV_THROTTLE {{!!}} -8 {{!!}} The scripts have exceeded the throttle. Wait and retry the request.
{{!}}}

{{:LSL Constants/llSetEnvironment}}

|caveats=
* The list of valid parameters differs from those available for [[llGetEnvironment]].
* The agent's viewer may choose to ignore this command.
* An environment set locally on the viewer will override any environment set from this function.
|examples=<source lang="lsl2">
float gTransitionTime = 3.0;
list gListEnvironmentParams = [
SKY_CLOUD_TEXTURE, TEXTURE_PLYWOOD,
SKY_GAMMA, 10.0,
WATER_NORMAL_SCALE, <5.0, 5.0, 5.0>
];

default
{
touch_start(integer total_number)
{
key person = llDetectedKey(0);
if (llGetAgentSize(person) != ZERO_VECTOR)
{
llRequestExperiencePermissions(person, "");
}
else
{
llInstantMessage(person, "You need to be in the same region to change environment");
}
}

experience_permissions(key agent_id)
{
integer envTest = llSetAgentEnvironment(agent_id, gTransitionTime, gListEnvironmentParams);
if (envTest == 1)
{
llRegionSayTo(agent_id, 0, "Applying environment for " + (string)agent_id);
}
else
{
llRegionSayTo(agent_id, 0, "Cannot apply environment for " + (string)agent_id + " due to reason id: " + (string)envTest);
}
}

experience_permissions_denied(key agent_id, integer reason)
{
llRegionSayTo(agent_id, 0, "Denied experience permissions for " + (string)agent_id + " due to reason id: " + (string)reason);
}
}
</source>
|helpers
|also_functions={{LSL DefineRow||[[llReplaceAgentEnvironment]]|}}
{{LSL DefineRow||[[llGetEnvironment]]|}}
|notes
|cat1=Experience
|cat2=Permissions/Experience
}}
[[Category:Experience Tools]]

OPT CHARACTER

2025-07-07T12:49:39Z

Wulfie Reanimator: Fixed name.

{{LSL Constant
|name=OPT_CHARACTER
|type=integer
|value=2
|hvalue=
|desc
|examples
|caveats=
|functions={{LSL DefineRow||[[llGetObjectDetails]]|}}
|events=
|cat1
|cat2
|cat3
|cat4
}}

CLICK ACTION DISABLED

2025-07-07T12:27:26Z

Wulfie Reanimator: Fixed name.

{{LSL Constant
|name=CLICK_ACTION_DISABLED
|type=integer
|value=8
|desc
|examples
|functions=
{{LSL DefineRow||[[llSetClickAction]]|}}
{{LSL DefineRow||[[llGetObjectDetails]]|}}
|events
|haiku={{Haiku|Immense horizons|A disabled click touches|into the action}}
|cat1=Click Action
|cat2
|cat3
|cat4
|self
}}

Http request

2025-05-23T23:36:35Z

Wulfie Reanimator:

{{LSL_Event|event_id
|event=http_request|event_id=33|event_delay
|p1_type=key|p1_subtype=handle|p1_name=request_id|p1_desc=HTTP request id for response use, and function response identification.
|p2_type=string|p2_name=method|p2_desc=<code>{{String|GET}}</code>, <code>{{String|POST}}</code>, <code>{{String|PUT}}</code>, <code>{{String|DELETE}}</code>, [[URL_REQUEST_GRANTED]], [[URL_REQUEST_DENIED]]|p2_hover={{String|GET}}, {{String|POST}}, {{String|PUT}}, {{String|DELETE}}, URL_REQUEST_GRANTED, URL_REQUEST_DENIED
|p3_type=string|p3_name=body|p3_desc=Contents of the request.
|event_desc=Triggered when task receives an HTTP request.
|constants=
|spec=See [[LSL_http_server]] for full specification.
|caveats=
* {{LSLP|body}} is [[limit]]ed to 2048 bytes; anything longer will be truncated to 2048 bytes.
** As per the above, this function is unaffected by any values passed to [[llHTTPRequest]] via [[HTTP_BODY_MAXLENGTH]], as they reside on the [[:Category:LSL HTTP#Understanding_LSL_HTTP_Communications | Outgoing]] pipeline, and this function is on the [[:Category:LSL HTTP#Understanding_LSL_HTTP_Communications | Incoming]] pipeline.
* headers (accessed with [[llGetHTTPHeader]]) are limited to 255 bytes.
* There is a limit of 64 pending http_request
** Be mindful of the event queue (64) in general as well. http_request events may be discarded if your script's queue is filled by other events, such as incoming [[listen]] messages.
* {{LSLP|body}} is not sent with the request unless the method is set to <code>{{String|POST}}</code>, <code>{{String|PUT}}</code>, or [[URL_REQUEST_GRANTED]].
* Requests may fail with a [https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#5xx_Server_Error 503 status code] for at least two possible reasons:
** if the returned body is <code>ERROR: The requested URL could not be retrieved</code>, and <code>(111) Connection refused</code>, the problem will normally last only a few minutes - this is th nightly maint & log rotation. It does reliably impact object to object HTTP at that time, and quite probably may impact object to/from web around the same time. The interruption in service is fairly brief, and the precise timing may vary as LL adjust their nightly maint processes, or due to server load.
** this response can also happen if too many requests are received by scripts in the region owned by the same owner. In this case, a Retry-After header is returned with a number of seconds to wait before retrying. Note that if you have many requestors, some of them may have to wait longer. A good general strategy is to wait the suggested number of seconds (possibly with a little randomness added in) before retrying, and if that fails increase how long you wait by multiplying by a small number before retrying again. If all your requestors follow some method like this, eventually they'll get through.
|examples=
See [[LSL_http_server/examples]] for some examples from the feature design phase.
{{LSL Tip|Never ever forget to release a URL again which you have requested! URLs are region resources just like prims. If you take them all you can get into big trouble with the sim owner and/or estate managers.}}
<source lang="lsl2">
string url;
key urlRequestId;
key selfCheckRequestId;

request_url()
{
llReleaseURL(url);
url = "";

urlRequestId = llRequestURL();
}

throw_exception(string inputString)
{
key owner = llGetOwner();
llInstantMessage(owner, inputString);

// yeah, bad way to handle exceptions by restarting.
// However this is just a demo script...

llResetScript();
}

default
{
on_rez(integer start_param)
{
llResetScript();
}

changed(integer change)
{
if (change & (CHANGED_OWNER | CHANGED_INVENTORY))
{
llReleaseURL(url);
url = "";

llResetScript();
}

if (change & (CHANGED_REGION | CHANGED_REGION_START | CHANGED_TELEPORT))
request_url();
}

state_entry()
{
request_url();
}

http_request(key id, string method, string body)
{
integer responseStatus = 400;
string responseBody = "Unsupported method";

if (method == URL_REQUEST_DENIED)
throw_exception("The following error occurred while attempting to get a free URL for this device:\n \n" + body);

else if (method == URL_REQUEST_GRANTED)
{
url = body;
key owner = llGetOwner();
llLoadURL(owner, "Click to visit my URL!", url);

// check every 5 mins for dropped URL
llSetTimerEvent(300.0);
}
else if (method == "GET")
{
responseStatus = 200;
responseBody = "Hello world!";
}
// else if (method == "POST") ...;
// else if (method == "PUT") ...;
// else if (method == "DELETE") { responseStatus = 403; responseBody = "forbidden"; }

llHTTPResponse(id, responseStatus, responseBody);
}

http_response(key id, integer status, list metaData, string body)
{
if (id == selfCheckRequestId)
{
// If you're not usually doing this,
// now is a good time to get used to doing it!
selfCheckRequestId = NULL_KEY;

if (status != 200)
request_url();
}

else if (id == NULL_KEY)
throw_exception("Too many HTTP requests too fast!");
}

timer()
{
selfCheckRequestId = llHTTPRequest(url,
[HTTP_METHOD, "GET",
HTTP_VERBOSE_THROTTLE, FALSE,
HTTP_BODY_MAXLENGTH, 16384],
"");
}
}
</source>
|helpers
|also_articles
|also_events
|also_functions=
{{LSL DefineRow||[[llRequestURL]]|Request a new LSL Server public URL}}
{{LSL DefineRow||[[llRequestSecureURL]]|Request a new LSL Server public URL}}
{{LSL DefineRow||[[llReleaseURL]]|Release a URL}}
{{LSL DefineRow||[[llHTTPResponse]]|For replying to HTTP requests}}
{{LSL DefineRow||[[llGetHTTPHeader]]|Returns the requested HTTP header's value}}
{{LSL DefineRow||[[llEscapeURL]]}}
{{LSL DefineRow||[[llUnescapeURL]]}}
|also_footer
|notes=
* When triggered by either [[llRequestURL]] or [[llRequestSecureURL]] the method will be either [[URL_REQUEST_GRANTED]] or [[URL_REQUEST_DENIED]]
** If the method is [[URL_REQUEST_GRANTED]] The body will contain the full url, minus the trailing forward slash.
|issues=
{{Issue/V1|SVC-1086|Design: LSL http_server|type=fs|status=ip}}
|cat1=HTTP
|cat2=HTTP/Server
|cat3
|cat4
}}

Http request

2025-05-23T23:32:16Z

Wulfie Reanimator: Note about pending events.

{{LSL_Event|event_id
|event=http_request|event_id=33|event_delay
|p1_type=key|p1_subtype=handle|p1_name=request_id|p1_desc=HTTP request id for response use, and function response identification.
|p2_type=string|p2_name=method|p2_desc=<code>{{String|GET}}</code>, <code>{{String|POST}}</code>, <code>{{String|PUT}}</code>, <code>{{String|DELETE}}</code>, [[URL_REQUEST_GRANTED]], [[URL_REQUEST_DENIED]]|p2_hover={{String|GET}}, {{String|POST}}, {{String|PUT}}, {{String|DELETE}}, URL_REQUEST_GRANTED, URL_REQUEST_DENIED
|p3_type=string|p3_name=body|p3_desc=Contents of the request.
|event_desc=Triggered when task receives an HTTP request.
|constants=
|spec=See [[LSL_http_server]] for full specification.
|caveats=
* {{LSLP|body}} is [[limit]]ed to 2048 bytes; anything longer will be truncated to 2048 bytes.
** As per the above, this function is unaffected by any values passed to [[llHTTPRequest]] via [[HTTP_BODY_MAXLENGTH]], as they reside on the [[:Category:LSL HTTP#Understanding_LSL_HTTP_Communications | Outgoing]] pipeline, and this function is on the [[:Category:LSL HTTP#Understanding_LSL_HTTP_Communications | Incoming]] pipeline.
* headers (accessed with [[llGetHTTPHeader]]) are limited to 255 bytes.
* There is a limit of 64 pending http_request
** Be mindful of the event queue in general as well. http_request events may be discarded if your script's queue is filled by other events, such as incoming [[listen]] messages.
* {{LSLP|body}} is not sent with the request unless the method is set to <code>{{String|POST}}</code>, <code>{{String|PUT}}</code>, or [[URL_REQUEST_GRANTED]].
* Requests may fail with a [https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#5xx_Server_Error 503 status code] for at least two possible reasons:
** if the returned body is <code>ERROR: The requested URL could not be retrieved</code>, and <code>(111) Connection refused</code>, the problem will normally last only a few minutes - this is th nightly maint & log rotation. It does reliably impact object to object HTTP at that time, and quite probably may impact object to/from web around the same time. The interruption in service is fairly brief, and the precise timing may vary as LL adjust their nightly maint processes, or due to server load.
** this response can also happen if too many requests are received by scripts in the region owned by the same owner. In this case, a Retry-After header is returned with a number of seconds to wait before retrying. Note that if you have many requestors, some of them may have to wait longer. A good general strategy is to wait the suggested number of seconds (possibly with a little randomness added in) before retrying, and if that fails increase how long you wait by multiplying by a small number before retrying again. If all your requestors follow some method like this, eventually they'll get through.
|examples=
See [[LSL_http_server/examples]] for some examples from the feature design phase.
{{LSL Tip|Never ever forget to release a URL again which you have requested! URLs are region resources just like prims. If you take them all you can get into big trouble with the sim owner and/or estate managers.}}
<source lang="lsl2">
string url;
key urlRequestId;
key selfCheckRequestId;

request_url()
{
llReleaseURL(url);
url = "";

urlRequestId = llRequestURL();
}

throw_exception(string inputString)
{
key owner = llGetOwner();
llInstantMessage(owner, inputString);

// yeah, bad way to handle exceptions by restarting.
// However this is just a demo script...

llResetScript();
}

default
{
on_rez(integer start_param)
{
llResetScript();
}

changed(integer change)
{
if (change & (CHANGED_OWNER | CHANGED_INVENTORY))
{
llReleaseURL(url);
url = "";

llResetScript();
}

if (change & (CHANGED_REGION | CHANGED_REGION_START | CHANGED_TELEPORT))
request_url();
}

state_entry()
{
request_url();
}

http_request(key id, string method, string body)
{
integer responseStatus = 400;
string responseBody = "Unsupported method";

if (method == URL_REQUEST_DENIED)
throw_exception("The following error occurred while attempting to get a free URL for this device:\n \n" + body);

else if (method == URL_REQUEST_GRANTED)
{
url = body;
key owner = llGetOwner();
llLoadURL(owner, "Click to visit my URL!", url);

// check every 5 mins for dropped URL
llSetTimerEvent(300.0);
}
else if (method == "GET")
{
responseStatus = 200;
responseBody = "Hello world!";
}
// else if (method == "POST") ...;
// else if (method == "PUT") ...;
// else if (method == "DELETE") { responseStatus = 403; responseBody = "forbidden"; }

llHTTPResponse(id, responseStatus, responseBody);
}

http_response(key id, integer status, list metaData, string body)
{
if (id == selfCheckRequestId)
{
// If you're not usually doing this,
// now is a good time to get used to doing it!
selfCheckRequestId = NULL_KEY;

if (status != 200)
request_url();
}

else if (id == NULL_KEY)
throw_exception("Too many HTTP requests too fast!");
}

timer()
{
selfCheckRequestId = llHTTPRequest(url,
[HTTP_METHOD, "GET",
HTTP_VERBOSE_THROTTLE, FALSE,
HTTP_BODY_MAXLENGTH, 16384],
"");
}
}
</source>
|helpers
|also_articles
|also_events
|also_functions=
{{LSL DefineRow||[[llRequestURL]]|Request a new LSL Server public URL}}
{{LSL DefineRow||[[llRequestSecureURL]]|Request a new LSL Server public URL}}
{{LSL DefineRow||[[llReleaseURL]]|Release a URL}}
{{LSL DefineRow||[[llHTTPResponse]]|For replying to HTTP requests}}
{{LSL DefineRow||[[llGetHTTPHeader]]|Returns the requested HTTP header's value}}
{{LSL DefineRow||[[llEscapeURL]]}}
{{LSL DefineRow||[[llUnescapeURL]]}}
|also_footer
|notes=
* When triggered by either [[llRequestURL]] or [[llRequestSecureURL]] the method will be either [[URL_REQUEST_GRANTED]] or [[URL_REQUEST_DENIED]]
** If the method is [[URL_REQUEST_GRANTED]] The body will contain the full url, minus the trailing forward slash.
|issues=
{{Issue/V1|SVC-1086|Design: LSL http_server|type=fs|status=ip}}
|cat1=HTTP
|cat2=HTTP/Server
|cat3
|cat4
}}

PBR Materials

2025-04-18T03:46:46Z

Wulfie Reanimator: Reformatted probe ambiance values into a table. /* Fine-Tuning Reflection Sample Volumes */

{{multi-lang|1=PBR_Materials|2=/en}}
'''Physically Based Rendering'''

{{note|1=This page is being actively updated with new content and links as GLTF PBR Materials and related new features are being released. Contributions to this page may be from Second Life residents and staff members alike.}}

[[Category:glTF]]

== What is it and Why is it used? ==

The term “Physically Based Rendering” or “PBR” is a technical term that may need some defining for most people since its use is unique to composing images in computer software. The term itself is an abbreviation for a collection of complex mathematical algorithms that attempt to accurately represent the ways that light reflects off and interacts with objects in the real world. In the real world, it is the behavior of light on a piece of metal that allows us, the observer, to recognize “that object is made of metal” without actually reaching out and touching it. The way a metal reflects light differs from that of a polished plastic or some other material, and these differences have been quantified by science. By mimicking real-world physics principles in the virtual world it allows for the creation of more immersive recognizable realistic spaces, but also it helps us relate to fantastical worlds a little better too. While we may not be familiar with what a newly imagined creation is, a metal's inherent metal-ness and aged wood's inherent wood-ness remain constant, making it easier to intuitively understand what we are interacting with in a virtual environment.

Because tying the mathematics to simulate materials in virtual spaces to how they behave in the real-world makes things more immediately recognizable, PBR has become the foundation for creating imagined worlds over the last decade. The metallic shine of exoskeletal armor in superhero movies is driven by a PBR workflow, as is the plastic sheen of toys or the glint of frozen ice in animated classics. Now we are moving to bring this standardized quality to your home in Second Life.

Bringing PBR to Second Life means updating the basic calculations of how light is represented and interacts with the world of Second Life. The goal is to integrate these changes while minimally changing how everything that presently exists in Second Life (designed prior to the introduction of PBR) looks. While the preservation of creative intent and the aesthetic appeal of items users have enjoyed for over two decades of Second Life is always a priority, Second Life is an ever-evolving platform, and to continue to do so, some changes are inevitable.

Lastly, while we are attempting to mimic real-world reflections and material properties, Second Life has to run on a wide variety of devices, so some shortcuts have to be made. Reflections are not mirror-perfect, as has often been a long-standing hope and request from Residents. While the addition of a reflection system does bring dreams of distortion free mirrors for our avatars in Second Life closer to reality, unfortunately, due to the calculation requirements of doing perfect reflections, mirrors are sadly still, for the moment, not practical. Please see the note in the [[#Understanding_and_Assisting_the_New_Reflections_System|section below]] for more info.

== What does this mean for Residents? ==
[[File:PrePostPBR.png | thumb | right | The lamp in this screenshot uses [[PBR_Materials#Nomenclature_changes|Blinn-Phong]] (Classic SL Materials), and was created before PBR's integration into SL; and demonstrates some of the visual differences to existing content. The environment used for the screenshot is the viewer's default Midday preset (Note that the PBR viewer has a new Midday preset).
]]
=== Changes to Existing Content ===
The largest change by far is the addition of an environmental reflection system to Second Life. For most existing items, this change shouldn’t have a drastic immediately observable impact. A few things in your inventory that you already own may appear more reflective with the new graphics configuration and those reflections should feel more realistic and immersive with your current environment. As a general rule: the “shinier” an object was before, the more environment reflections it will pick up and the more visual difference there will be.

Another notable change is the addition of [https://en.wikipedia.org/wiki/Tone_mapping tonemapping] to the viewer. Tonemapping is a way of representing an image with a higher native dynamic range than the display can support. Tonemapping is a de-facto requirement of PBR pipelines. This means that colors in Second Life will generally appear more saturated with less detail being lost in shadows and highlights. [https://modelviewer.dev/examples/color.html Click here for some additional reading on the subject.]

The tonemapping method used is called '''Academy Color Encoding System ('''aka '''"ACES")''', and can be read about [https://www.oscars.org/science-technology/sci-tech-projects/aces here] and [https://docs.nvidia.com/gameworks/index.html#devices/shield-hdr-dev-guide/hdr-dev-guide-nvidia-shield.htm here].

[[PBR_Materials#Nomenclature_changes|Blinn-Phong]] content making use of the Specular parameters may look different if the items were never viewed under local lights, as the PBR viewer allows for the environment (sun ''and'' sky) to contribute to specular reflections. As such, if the object receives blue specular reflections from the sky, these reflections are tinted, and may look odd. This effect is the same as prior viewers, as if the object was lit by a blue local light.

=== Removal of Advanced Lighting Model ( ALM ) Graphics Option ===
There have been changes to the '''Graphics > Advanced Settings...''' Preferences. The most notable of which is the removal of the “Atmospheric Shaders”, "Local lights" and “Advanced Lighting Model” options.

For those users on lower-end hardware who depended heavily upon those options to navigate Second Life with an acceptable framerate, we recommend the following settings:
*{{code|Transparent Water: Disabled}}
*{{code|Screen Space Ambient Occlusion: Disabled}}
*{{code|Shadows: None}}
*{{code|Screen Space Reflections: Disabled}}
*{{code|Reflection Detail: Static Only}}
*{{code|Reflection Coverage: Manual only}}

The {{code|Local Lights}} setting has been superceded by updates made to the '''World > Improve graphics speed...''' "Quality & Speed" slider options. Users on low-end hardware should ensure that their "Quality & Speed" slider is set at an appropriate level for their hardware.

== What does this mean for Creators? ==
=== Nomenclature changes ===
The PBR project represents a large step towards integrating standard rendering techniques used in the games industry. As such, the nomenclature of some items has changed, notably, what was once called '''[[:Category:Materials|Materials]]''' is now referred to as '''Blinn-Phong'''. This does not represent any changes to the underlying rendering techniques (beyond those mentioned above); and as such Blinn-Phong ''is not'' the same as PBR Spec/Gloss workflows, seen in some game engines such as Unity.

=== Importing PBR Materials from External Software: ===
For creators who work with external tools such as Blender, Adobe Substance Painter, Cinema4D, 3D-Coat, or have used the Unreal or Godot game engines, the use of PBR texture sets should already be familiar. In fact, some creators have been using tools that use PBR workflows to create content for Second Life and have then been forced to sacrifice visual quality to convert that information into Second Life’s existing Blinn-Phong materials system.

Second Life is adopting the “Metallic/Roughness” PBR model, and in its ongoing commitment to using Open Source standards whenever it is practical to do so, the glTF 2.0 file format has been chosen as the upload format for PBR Material assets. One of the primary goals of implementing PBR Materials is to have more continuity from content creation applications towards Second Life, and have more consistent content behavior once it’s inworld.

=== Using Imported Materials in Second Life ===
[[File:Editing_Material.jpg|thumb|right|Material Editing]]
For people who build exclusively within Second Life, the addition of PBR also means that there will be a new [[LlGetInventoryType|Inventory Type]] called “Material”. These new Materials can be purchased on the Marketplace and are shareable like any other permitted object in Second Life.

PBR materials come as a bundle of textures. These all travel as a single unit and are applied all at once. If you wish to change tint, transparency, or other similar parameters of the Material you’ll need to modify the Material from the "Editing Material" floater.

{{KBcaution|Meshes uploaded after the PBR release will look slightly different (and more accurate to your editor of choice) due to a change in the way Second Life handles mesh assets (Previously, some data required for accurate tangent generation was discarded at upload time - this is no longer the case). This will mean that a PBR material applied to a mesh uploaded before PBR launched (28th November 2023) might look incorrect; a simple reupload of the mesh will solve this. '''This is not required, but recommended.'''}}

Applying existing materials works similarly to existing textures. You have two means of doing so:

==== Drag and Drop ====
Simply drag and drop onto the face of a prim or a mesh. For example, if you have a tiled floor material and you place it on a selected prim cube face that face will now look like a tile floor and reflect light like a tiled floor would with all the material qualities contained in the material.
[[File:DragAndDrop_Mat_Wiki.png | thumb | none | Drag and Drop Functionality.]]

==== Switch to PBR and select from Inventory ====
Alternatively, select a face on the prim or mesh you want to apply your material to and choose the “Blinn-Phong” drop-down and change it to “PBR Metallic Roughness”, then select “Choose an item from your inventory” and apply.
[[File:PBRSelectorV3.png |left| thumb | none | Menu drop-down demonstration.]][[File:Material_Dropdown.jpg|thumb|none|Dropdown as of v7.0.1.689]]

 

==== Texture Transforms ====
With PBR materials, texture transforms work in a slightly different way to Blinn-Phong transforms. Blinn-Phong (and OpenGL) has the texture origin in the lower left corner of the texture, whereas glTF materials (and Vulkan) has the texture origin in the upper left corner.

This means that PBR materials will react differently (namely, they are inverted in the Y (glTF v) axis) to Blinn-Phong materials.
For a simple solution to convert a Blinn-Phong texture transform to a PBR texture transform, please see [https://community.secondlife.com/forums/topic/507448-lsl-math-for-gltf-transformation/?do=findComment&comment=2678959 this forum thread].

For more information, [https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#images see here] and [https://github.com/KhronosGroup/glTF/tree/main/extensions/2.0/Khronos/KHR_texture_transform here].

=== Media-on-a-Prim ===
Media on a prim will continue to work largely as it has done prior to PBR's launch.

When using MOAP on a face with a PBR texture, it will function as if the media texture has an override to the '''Base Color''' and '''Emissive''' maps. Note that the emissive map is overridden, however the emissive tint is not (so, to disable the emissive map you can set the emissive tint to black <0,0,0>).

== Tools & Tutorials ==
As the PBR system is new, it is expected that existing users may be confused at first on how everything works. As such, Linden Lab and some third parties have provided some tutorials and informational videos:

*'''[https://www.youtube.com/watch?v=JtjGf06B8ZA Second Life University - PBR Materials]'''
*'''[https://www.youtube.com/watch?v=BJ1eRTlWDYk Second Life University - How to create PBR Materials]'''
*'''[https://substance3d.adobe.com/tutorials/courses/pbrguide Allegorithmic (Adobe) PBR Guide]'''

The above tutorials require knowledge and access to Adobe's Substance Painter (subscription based software on Adobe website, or sold as perpetual license with one year of updates on Steam). Below are some open source tools and links found Googling 'Blender', 'glTF' (requiring Blender 3.3)
*'''[https://www.khronos.org/blog/art-pipeline-for-gltf Khronos Art Pipeline tutorial]'''
*'''[https://materialmaker.org Material Maker software]'''
*'''[https://aiaicapta.in/gltf-packer/ glTF Packer software]'''
*'''[https://armorpaint.org Armorpaint software]'''
*'''[https://armorlab.org Armorlab software]'''
*'''[https://youtu.be/KTPdNUGwIGc glTF Blender Tutorial]'''
*'''[https://youtu.be/p7OPRoT6FkY Exporting glTF Alpha Textures tutorial]'''

== PBR Stand-In Textures and Outdated Viewers ==
It is worth mentioning that during the adoption period of a new system, a substantial portion of Second Life Residents view the world through third party viewers and mobile viewer solutions that will not have updated to be able to see the new content. Anyone viewing a PBR Material on a viewer that cannot display it will see the “underlying” non-PBR texture. By default, this is a pine box or a completely blank texture. Those who wish their content to be viewable by as many people as possible, might consider creating a Diffuse texture ( with baked lighting, the kind that is easily generated with tools like Substance Painter's “Baked Lighting Filter” ) and applying it as a regular texture to the object they’re placing the PBR material on, prior to applying the PBR material. While this is an extra step in content creation, and complicates things somewhat, if you wish for your content to be appreciated by all, it’s worth considering adding this extra step to your workflow. People designing PBR materials for distribution and sale might also consider offering a “Diffuse Only fallback” texture to accompany the PBR material specifically for people who cannot see the PBR content.

{{KBcaution|Once a PBR Material is applied, the Blinn-Phong textures cannot be updated. To remedy this, remove the PBR Material, then make changes to the Blinn-Phong textures and then reapply the PBR Material.}}

== Understanding and Assisting the New Reflections System ==
Those creators that work at house-scale, or produce items that can be walked through, can gain additional control over the lighting in their creations by taking the time to fully understand the new toolkit that influences environmental reflections. There is a new type of volume that can be created and appended to object linksets specifically for scenes with these kinds of spaces. These volumes define a custom area where reflections are calculated, overriding the default solution. So-called “Reflection Probes” should be placed in a manner such that ''the fewest number of probes fills the largest amount of space possible with minimal overlap''. One probe per room is a good reference point for a general living space like a house. If multiple probes exist in a given area they can cause visual artifacts and negatively impact performance (also known as viewer lag). '''''Do not affix reflection probes to small creations such as furniture or decor.''''' Small items such as tables, chairs, musical instruments, candle sticks etc should use the reflection sample volume in the space in which they are placed. They should not have one appended. It is '''strongly''' recommended that any object that contains a reflection sample probe be left as “modify”, so the positioning of the probe can be adjusted or even removed by the owner of the item should they wish.

{{Enote|Reflection probes '''are not''' intended for use with planar mirrors, and will look incorrect when being used to do so. Planar mirrors have been flagged for future work, but are not directly in the scope of the PBR project.}}


== When is it Recommended to Create a Reflection Probe? ==
Manually placed probes are good for cleaning up undesirable noise and lighting from automatically placed probes that may be visually disruptive or confusing. If you look in the image of the room in a house, on the left hand side of it, you can see a blue tint on the floor, which is the reflected blue light from the sky. The probe filling half the room blocks this, and when it is extended to completely fill the room and just slightly beyond the thickness of the walls, (lower copy of the image) the problem is solved. The probe does not need to be a part of the linkset for the rest of the room in order to function; however, once you have them placed it’s possible to add them into linksets like any other prim.

=== Constructing a Reflection Sample Volume ( aka Reflection Probe ) ===
Start off in the Build Menu ''(Ctrl+3)'' by rezzing a basic prim. Under the <code>Features</code> tab, at the bottom check the box labelled <code>Reflection Probe</code>.
[[File:ProbeUI.jpg | thumb | none | Manual Probe Creation UI.]]

* <code>Reflection Probe</code>: Enabling this creates a Reflection Sampling Volume within the bounding box of the prim.
* <code>Box / Sphere Drop-down</code>: Choose whether you want this sample to project reflections within a box shaped volume or a spherical one.
* <code>Dynamic</code>: Allow skinned objects (e.g. Avatars, animesh, etc.) to be captured in the reflection.
* <code>Ambiance</code>: Affects how much objects within the volume are lit as if they have bounced light hitting them from faked indirect illumination. ''See [[PBR_Materials#Fine-Tuning_Reflection_Sample_Volumes|"Fine-Tuning Reflection Sample Volumes"]] for more info.
* <code>Near Clip</code>: Sometimes, there will be a large obstruction in the center of the volume you wish to use as a reflection probe. For example, suppose that there is a large architectural supporting structure in the middle of the room, such as a column. If the probe gets placed internally inside this, it will reflect the internal surface of the column instead of the room in which it is placed. Increasing Near Clip will make the sampling volume exclude objects n meters from the center so they don’t get included in the reflection. ''See [[PBR_Materials#Fine-Tuning_Reflection_Sample_Volumes|"Fine-Tuning Reflection Sample Volumes"]] for more info.

Select an appropriate probe shape for your scene. For example, if you want to create a reflection probe that covers a room, select a <code>Box</code> shape, or for other objects a <code>Sphere</code> shape is recommended.

Move the reflection probe and resize it as necessary to fit your desired purpose. For the room example, resize the box so the probe just touches the walls, ceiling and floor of the room.

Naming your probes is also recommended, so other people ( or yourself later on ) will remember why there’s a large transparent prim in the middle of your build.

If you wish to come back and edit the reflection probe later on, enable both <code>Show Reflection Probe Volumes</code> and <code>Select Reflection Probes</code> under <code>Build > Options</code>.

=== Fine-Tuning Reflection Sample Volumes ===
{{KBwarning|Sample volumes do not react to prim parameter changes. Options such as “Hollow” or “Taper” or “Shear” do not change how the sampling area behaves.}}

That said, it may be helpful to visualize <code>Near Clip</code> as the hollowing out of your reflection sample volume, but the hollow and near-clip are not in any way linked and doing so is purely a convenience. Reflection probe sample volumes only respond to changes in scale and position; however, different probe volumes behave differently when resized.
* <code>Box</code> Probes: These are affected by position and non-uniform scale.
Example: If I create a box reflection probe and scale it to 10m,30m,10m size, the full volume will be affected by the probe.
* <code>Sphere</code> Probes: These are affected by position and '''uniform''' scale only, otherwise the smallest dimension is used.
Example: If I create a spherical probe and scale it to 10m,30m, and 10m size , the probe will sample a 10 meter diameter spherical volume at the center of the probe. However, a 30m,30m,30m sphere will create a sampling volume of a 30 meter diameter sphere.
[[File:SphereProbeErrror.jpg | thumb | none | A diagram of how spherical probes function (or, don't function as you may expect) while non-uniformly-scaled.]]

<code>Reflection Probe Ambiance</code> controls how ambient light (Found in your [[Environmental_Enhancement_Project#EEP_Settings_Objects|environment preset]]) affects, or does not affect, the contents of the reflection probe, and the intensity of indirect lighting (aka Irradiance).
This value is influenced by the <code>Reflection Probe Ambiance</code> value found in the user's [[Environmental_Enhancement_Project#EEP_Settings_Objects|environment preset]], wherein if the Ambiance value given in the [[Environmental_Enhancement_Project#EEP_Settings_Objects|environment preset]] is higher than the value defined by the probe itself, it inherits the ambiance value of the [[Environmental_Enhancement_Project#EEP_Settings_Objects|environment preset]], or alternately if the ambiance value defined by the probe is higher, the probe's value is used.

There are a few operation modes that are set with the <code>Reflection Probe Ambiance</code> value, in tandem with above:
{| class="wikitable"
|+ Probe Ambiance behavior
! Value !! Description
|-
| 0.00 || Ambient color from the environment applies at full intensity. '''Default for pre-PBR skies.'''
|-
| 0.01 .. 0.99 || Blends ambiance with indirect lighting (sun + emissive or illuminated surfaces) within the probe.
|-
| 1.00 || Indirect light applies at full intensity, without ambient color. '''Default for PBR skies.'''
|-
| 1.01 .. 4.00 || Multiplier for indirect light, makes everything brighter within the probe.
|-
| 4.01 .. 100.00 || Multiplier for indirect light, but only further affects light from the sun. (Local lights are capped to 4.)
|}

=== Complex Reflection Probe placement ===

At times, you may wish to place a reflection probe in an area where the reflection probe types (Sphere or Box) do not conform to the shape of the area. For example, a Box probe in a loft room has a triangular shape, which results in "probe bleed" wherein the influence volume affects an area larger than what is needed, and thus bleeds out onto the exterior roof, which is undesirable.

In these cases, you may need to place multiple probes in order to blend together the sample volumes to achieve the desired result. In the loft room example, it's best to start with 3 box probes, which cover the floor, and each side of the roof. Then, use an additional box probe as "fill" to cover the gap inbetween the 3 probes. The main fill probe may need to be rotated at an angle to get the most coverage possible. If it is not possible to fill the gap between the 3 probes with this fill probe, you may wish to add more box probes to act as "secondary fill".

[TODO: Put photo examples of the above here!]

Alternately, Sphere probes may be used to achieve the same result. Sphere probes have considerably softer blending than box probes, so this may give you the best results in severe bleed conditions.

=== Unsupported use-cases ===
{{KBwarning|Do not attempt to do anything listed below. These uses are liable to either intentionally be disabled, or stop working in future updates.}}
You may be tempted to use reflection probes in the following ways, however these use-cases are either intentionally disabled or result in undefined behavior, and may work now but may not in future. '''You have been warned.'''

'''Under any circumstances, you should NOT:'''
* Wear a reflection probe. This intentionally does not work. (Reflection probes are a property of the scene, not an individual object / avatar)
* Attach a reflection probe to a physics-enabled object, e.g. vehicles. This intentionally does not work. (As above, the reflection probes are part of the scene; not part of an individual object. Reflection probes by design do not update in real-time, thus the object would always have incorrect reflections anyway.)

== PBR Material Composition ==
PBR-defined values are measured by optical sensors and other capture tools and recorded in databases. These parameters are then put into commercial software to be used by content creators. Using software designed to create PBR content is always recommended; however, understanding how PBR materials are assembled can assist with editing and compiling them. Having a direct understanding of what each individual color channel contributes is essential for editing PBR textures without relying upon some of the more advanced toolkits available.

All PBR Values are listed from 0 to 1.0, though in an actual image, the values range from 0 - 255.
PBR Materials are composed of a set of four specifically designed textures; they are as follows:

===Base Color [ RGB ] + Transparency [ A ]===
[RGB]: This is the unlit color of the surface. This differs from the “Diffuse” texture that Second Life uses. Diffuse textures often include faked reflection and specular information as well as added Ambient Occlusion shadows. Base Color textures do not get any of this added information. For metals ( as defined by the metalness value ), Base Color also determines specular reflection color, whereas, in non-PBR systems, this is defined by the Specular texture and tint. In certain PBR texturing applications, Base Color is sometimes also referred to as “Albedo”.
 [ A ]: Alpha Channel, dictates the transparency of the entire material overall.

The Base color texture should be devoid of lighting information.

===Occlusion [R] / Roughness [G] / Metalness [B]===
This texture is composed of 3 unrelated grayscale images stored in 3 different color channels of an RGB texture.
 [R]: (Ambient) Occlusion is lighting data, '''removing''' the need to bake down shadows on to the Base Color map. Note that ''white'' (<1,1,1>) means no occlusion is applied, and ''black'' (<0,0,0>) applies full occlusion.
 [G]: Roughness data ranges from 0 to 1.0, but the actual range of physical surfaces ranges from approximately 0.05 to 0.985. No surface is perfectly smooth or completely rough. The rougher a surface is the less mirror-like it behaves.
 [B]: Metalness values are mostly black or white. Either the material is a conductive metal like copper, or it’s a non-metal like fabric. 0.0 is Non-Metallic, 1.0 is Metallic. There are almost no materials with gray metalness values.
 The alpha channel is ignored, as per the [https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#additional-textures glTF 2.0 specification].

{{Enote|The Occlusion map '''is not''' controlled by the "Screen Space Ambient Occlusion" toggle in the Advanced Graphics Settings. '''The Occlusion map is ''always'' enabled.'''}}

===Emissive [ RGB ]===
This determines the amount and the color of unlit (ignores ambient light conditions) areas of your material. When giving an object a white emissive map, the object will act as if the Blinn-Phong "Fullbright" option was checked. This map is useful for items which are expected to emit light, e.g. a table lamp, where the lamp shade would appear to glow when the lamp is turned on. If you wish to toggle the lamp on and off, it's recommended to change the Emissive Tint value to black (functionally disabling the emissive map, thus turning the lamp off), and then changing the tint back to your desired color to turn the lamp back on. Leaving the Emissive slot empty is recommended when it’s unused.

Note that glow (The postprocessing effect), is controlled by a separate parameter in the build floater and is intentionally not part of the PBR material window. Glow is modulated by the emissive map, so black areas of an object's emissive map will not glow, similar to how Blinn-Phong emissive maps and glow work.

As per the [https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#additional-textures glTF 2.0 specification], the alpha channel is ignored.

===Normal [ RGB ]===
The normal maps generated by your baking application / normal map generation toolkit should be compatible with Second Life in most cases. The most common pitfall is using normal maps generated with “inverted” Green channels, such as those that are used for Direct3D and Unreal Engine. Normal texture data redirects light in a different direction based on the vectors indicated by the color, so if the green channel is backward, it’ll seem to be “pointing the wrong way”. To phrase the problem a different way, all the things that should be bumps look like dents, and vice versa. If this occurs, double check that your settings aren’t for Direct3D and try re-generating it. Also, taking it into image editing software and inverting the green channel only sometimes is a sufficient fix.

Normal map tangent spaces are an extremely technical subject that most users need not be concerned with as most modern applications default to the correct setting. However, if your normal maps look drastically different inside Second Life, compared to your source application, and you’ve already confirmed it’s not an inverted green channel, then checking which tangent space settings are being used is the next step. PBR Normals use Mikkelsen Tangent Space. (Often abbreviated MikkT) If you are unsure what this means, use similar workflows and settings for Second Life PBR as those that are generally recommended for the Godot 4 game engine.

As per the [https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#additional-textures glTF 2.0 specification], the blue channel of a normal map is only allowed to contain values above 0.5 to a max of 1 (255).

As per the [https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#additional-textures glTF 2.0 specification], the alpha channel is ignored.

== Material Reference Libraries ==
As PBR is ''Physically Based'', you may wish to know how to recreate a real-life material in PBR form. What color should you use? What metalness value should it have?

Fortunately, reference libraries exist which can tell you how to recreate a given material in a PBR workflow.

=== List of Reference Color Palettes & libraries ===
*'''[https://physicallybased.info/ Physically Based]'''
** Select the ''Godot'' Engine, with the Color Space as ''sRGB Linear'' and Color Representation as ''0-1'' (Depending on what you are doing, you may need to convert the value into gamma-corrected sRGB space, which can be done [https://davengrace.com/dave/cspace/ here.] Enter the value on the 3rd row.)
*'''[https://www.youtube.com/watch?v=TcTh-1X2FsQ Grzegorz Baran Library]'''
**Available on [https://www.youtube.com/watch?v=TcTh-1X2FsQ YouTube (video format, older)], or [https://gbar.gumroad.com/l/cbwkvo PDF (most up-to-date)].
*'''[https://seblagarde.wordpress.com/2014/04/14/dontnod-physically-based-rendering-chart-for-unreal-engine-4/ Dontnod Entertainment Library]'''
** A very small library, but useful nonetheless.
*'''[https://docs.studio-397.com/developers-guide/general-reference/pbr-an-introduction-authoring-guide Studio 397]'''
** A small collection of various materials.
*'''[http://wiki.polycount.com/wiki/PBR Polycount Wiki]'''
** Not so much a library in itself, but links out to other libraries. '''See the Color Charts section'''.

=== List of PBR asset libraries ===
*'''[https://ambientcg.com/ ambientCG]'''
** Provides CC0 licensed HDRi, Metal-Rough materials and .sbar (Substance Painter material) files.
*'''[https://polyhaven.com/ Poly Haven]'''
** Provides CC0 licensed HDRi, Metal-Rough materials and models.

== Uploading Materials ==
There are two different methods of creating PBR material assets:

=== Method 1 : Direct Upload a glTF File ===
The most convenient method to create an entirely new material is to directly upload a glTF file from your computer.

This is accessible via <code>Build > Upload > Material...</code>
[[File:PBRBuildMenu.jpg | thumb | none | PBR Upload in main build menu. ]]

Select a .GLB or a .GLTF file from your computer and Open it:
This will give the following window:
[[File:PBRMatMenu.jpg | thumb | none| The layout of the PBR material creation and editing interface.]]

All of the editable material properties that most creators are familiar with are integrated into the Material's vertically sizable window on upload.

Clicking “Save” pays the upload fees and creates the Material assets using the local filename. Using "Save As..." provides a window to name all the assets to unique inworld names. There is a 63 char limit for names of inventory assets but the naming floater on this Materials upload has no length restrictions.

Textures will be uploaded to the inventory's default Textures folder (NoMod, NoCopy, Transfer) with an appended "type" added to the given name. (ie. asset name (Base Color), asset name (Normal), asset name (Metallic Roughness). In naming the asset keep in mind that the bracketed appendix is included in the name's 63 character limit. The PBR object is uploaded (Mod, NoCopy, Transfer) to the inventory's Material folder with the appended text (Material). Presently, naming the glTF asset from Save As... will NOT append (Material) to the inventory's name. Saving from the locally named file will.

{{KBcaution|Each individual texture used to compose the Material object is charged a separate upload fee. (ie. If you have 4 textures (Base Color, Metallic Roughness, Emissive, Normal) you are charged 4 times. If you only have a Normal and Metallic-Roughness texture you will be charged for 2, etc.)}}

=== Method 2 : Edit a Blank. Create PBR Materials without a glTF File ===
If you have the necessary textures to compose a PBR material but do not have a glTF file you will need to build a Material from inventory. Make sure your textures are in the correct format, with the correct data in the proper channels. This requires some understanding of how [[PBR_Materials#PBR_Material_Composition:|PBR materials work]]. Once you have that, upload your textures as you normally would.

[[File:PBRMenuUI.jpg | thumb | none | The PBR Materials UI in the Build Floater.]]

* Find the "Materials" folder in your inventory, right click, and select "New Material" from the context menu.
* Name your new material something appropriate (E.g. "Red Bricks" for a red brick wall, etc.)
* Right click on your new material, and select "Open" from the context menu.
* Upload your PBR textures using the standard texture workflow (Usually, under <code>Build > Upload > Image</code>).
* In the material window, select the appropriate maps that you just uploaded in their respective slots.
{{KBwarning|While there may be a temptation to try and place a Blinn-Phong “Diffuse” texture into the “Base Color” slot and a Blinn-Phong “Specular" into the “Metallic/Roughness” slot, doing so will not produce desirable results. However, trying this won’t generate any warnings as there is no way to check that you’ve put the right texture type into the inputs, and the material will save and be applicable to objects. '''Unfortunately, what will be created is not a functional PBR material. Please do not do this.'''}}
* Once done, verify the material parameters are correct (E.g. Base color tint, M/R factor, Emissive tint, etc.)
* Save your new material.
* EITHER: [[PBR Materials#Drag_and_Drop|Drag and drop the material onto a rezzed prim]], OR edit the prim, click the "Blinn-Phong" drop-down, select "PBR Metallic-Roughness", and click "Choose from Inventory", and select your new material.



=== Creating Color Variants ===
After you’ve uploaded your first Material for your project, if you’re a store owner who would like to release more than one color palette for your creation, as many clothing and furniture designers find it useful to do, '''it’s important to not upload a new glTF file for every single variant of your Material'''. Most variant materials, only the base color will change. The Occlusion, Roughness, Metalness, Emissive and Normal map texture slots will remain the same. Since these maps have already been uploaded once, if we upload a second glTF File, they will be duplicated. Having different copies of the same texture, with differing UUID’s means that they will clog up download bandwidth and video card memory (not to mention your inventory as well). This is very bad for Second Life. So, for this reason, it’s recommended that when you create texture variants, you upload the additional copies of the base-color texture separately. Then open your newly uploaded material in edit mode, choose the Base Color texture, and change it out for one of your newly uploaded Base Color textures, and click “Save As”. This will create a second copy of your material that uses all the correct texture maps without needlessly duplicating them and causing additional lag.

{{KBtip| You can also avoid uploading additional textures altogether by uploading a white color variant, then making use of the Base Color Tint parameter!}}

== Double Sided Parameter : Uses and Dangers ==
“Double Sided” is a new property unique to Materials. When “Double Sided” is checked, the surface upon which this material is placed will be drawn twice; once for the outward-facing portion of the surface, and a second time for the inward-facing side of the surface that is normally invisible without a double-sided material. This option should only be used for very specific meshes that were designed to be used with double-sided materials, since placing materials with this parameter checked on normal objects will simply cause the viewer to draw it twice ( and thereby create additional viewer lag ) for no observable change. It is '''very strongly recommended''' that this option be unchecked for any material that is to be distributed for general use. Even more so if the “Modify” permission is revoked. If you wish to distribute a version of a material that has “Double Sided” checked, please include a second copy of the material that has “Double Sided” unchecked as well, with an accompanying explanation to the next user as to why this was done.

Example:
*LeafTextures_DoubleSided
*LeafTextures_SingleSided

When designing mesh content for use with the double-sided material parameter, it is also ''very strongly recommended that you separate the triangles you intend to use the double-sided material upon into a separate mesh “face”'', so as to not unintentionally render the portions of the mesh that already have triangles designed to represent the internal portion of the object a second time.

== LSL Scripting ==

Documentation for the LSL interface with glTF materials can be found on the following pages:
*[[GLTF Overrides]]
*[https://wiki.secondlife.com/wiki/Category:LSL_Material Category:LSL Material]

== Recommended Application Settings ==
The glTF file format is widely adopted and many applications have export functionality for this type of file.
Below is a non-comprehensive list of some of the more popular applications that export glTF files.

{{KBtip|'''The recommended HDRi for use in Second Life content creation is available at [https://github.com/Jenna-Huntsman/Second-Life-Resources/tree/main/PBR/HDRi this Github repository].''' This HDRi will closely match the lighting of objects under the PBR "Midday" environment preset.}}

{{KBcaution|While every effort has been made to ensure the recommended HDRi matches SL as close as possible, you may need to adjust the "Environment Exposure" parameter in your editing program to get 1:1 results with SL.}}
 
----
===[https://www.blender.org/ Blender]===

{{KBwarning|Older Blender versions have bugs in their glTF export tools which make their output incompatible with Second Life. '''Use of Blender versions of 3.3 and above are highly recommended to avoid issues.'''}}
 
{{KBcaution|Please ensure that you correctly set up an HDRi in your viewport, as otherwise the rendering in Blender and in SL will not match. Please see [[PBR Materials#Recommended_Application_Settings|here for a reference HDRi]]. '''Please see [https://www.polygonartists.com/hdri-environment-maps-in-blender/ this tutorial].'''}}

Upon starting your project:

Under: <code>Scene > Render Properties > Color Management</code>:
*{{code|View Transform: Standard}}
*{{code|Sequencer: Linear ACEScg}}

Create your materials within Blender using Principled BSDF Shader Nodes and the glTF Settings node. Export them according to the official '''[https://docs.blender.org/manual/en/3.6/addons/import_export/scene_gltf2.html Blender Documentation.]'''

{{KBcaution|Second Life does not support BSDF Clearcoat, Subsurface, Anisotropy or Transmission parameters at this time.}}

For materials creation, 2 example .blend files are provided, one using separate Occlusion, Roughness and Metallic textures ("Long Form"), and one that handles a pre-packed ORM map ("Short Form")

The below files are intended for use with Blender versions 3.3 and above.

* '''[https://github.com/Jenna-Huntsman/Second-Life-Resources/blob/main/glTF%20Node%20Tree%20-%20Long%20Form.blend glTF Node Tree - Long Form.blend]'''
* '''[https://github.com/Jenna-Huntsman/Second-Life-Resources/blob/main/glTF%20Node%20Tree%20-%20Short%20Form.blend glTF Node Tree - Short Form.blend]'''
 
----
=== [https://www.adobe.com/products/substance3d-painter.html Adobe Substance 3D Painter] ===
{{KBcaution|While Substance Painter is generally considered to be stable, in some (rare) situations Substance may output a malformed glTF which will be rejected by the viewer. If this happens, import your materials into Blender, then export a glTF from Blender - this should be fixed in a future version of Substance.}}
 
{{KBcaution|Please ensure that you correctly set up an HDRi in your viewport, as otherwise the rendering in Substance and in SL will not match. Please see [[PBR Materials#Recommended_Application_Settings|here for a reference HDRi]]. Please see [http://y2u.be/6goXJ2CJzaM this tutorial].}}
When starting your project:

*{{code|Template: PBR - Metallic Roughness Alpha-test (starter_assets)}}

OR

*{{code|Template: PBR - Metallic Roughness Alpha-blend (starter_assets)}}

Verify the following settings:
*{{code|Document Resolution: [Set as desired]}}
*{{code|Normal Map Format: OpenGL (Y+)}}
*{{code|Compute Tangents Per Fragment: YES}}

Under "Color Management":
{{KBtip| For a more in-depth explanation of the below settings, and issues that you may encounter, visit [https://mrlixm.github.io/blog/substance-painter-color-management/#aces-workflow this page].}}
*{{code|Color Management: OpenColorIO}}
*{{code|OpenColorIO Configuration: ACES 1.0.3}}
*{{code|Standard sRGB color space: Utility - sRGB - Texture}}
*{{code|8 bit images: Utility - sRGB - Texture}}
*{{code|16 bit images: Utility - sRGB - Texture}}
*{{code|Material color space default: Utility - sRGB - Texture}}

When exporting:

Settings Tab - Global Settings
*{{code|Output template: glTF PBR Metal Roughness}}
*{{code|Size: Based on each Texture Set's size}}
*{{code|Padding: Dilation + default background color - 8 bit}} '''OR''' {{code|Padding: Dilation infinite}}
{{KBtip|If you encounter color banding (AKA posterization) in your base color texture after export, you may wish to enable dithering.}}
*To enable dithering, open the {{code|Export Textures}} window, under the {{code|Settings}} tab, enable an override for the Base Color texture and swap the output format from {{code|8 bits}} to {{code|8 bits + dithering}}

Settings Tab - Per-Material settings
*{{code|Output maps > Normal Map: 8 bits}}

<li style="display: inline-block;">[[File:Substance_Painter_-_Export_Global_settings.png|thumb|Settings Tab - Global Settings]]</li>
<li style="display: inline-block;">[[File:Substance_Painter_-_Export_Per-Material_settings.png|thumb|Settings Tab - Per-Material settings]]</li>
 
----
=== [https://www.adobe.com/products/substance3d-designer.html Adobe Substance 3D Designer] ===
{{KBcaution|Substance Designer ''does not support glTF output'', unlike Substance Painter.}}

Under preferences, verify the following '''Project''' settings:
*{{code|Color Management: OpenColorIO}}
*{{code|OpenColorIO Configuration: ACES 1.0.3}}
*{{code|8 bit images: Utility - sRGB - Texture}}
*{{code|16 bit images: Utility - sRGB - Texture}}
*{{code|Floating point images: ACES - ACEScg}}
*{{code|2D and 3D View Display Default: sRGB}}

When exporting (Export Outputs):
*{{code|basecolor: Utility - sRGB - Texture}}
*{{code|normal: Utility - Raw}}
*{{code|roughness: Utility - Raw}}
*{{code|metallic: Utility - Raw}}
*{{code|ambientocclusion: Utility - Raw}}

If you use a custom node to output a [[PBR_Materials#Occlusion_.5BR.5D_.2F_Roughness_.5BG.5D_.2F_Metalness_.5BB.5D|pre-compiled ORM map]], this should also be set to Raw.
 
----
=== [https://www.maxon.net/en/cinema-4d Cinema 4D] ===
Please follow the documentation provided in this [https://www.bakedpixels.nl/blog/export-to-gltf-with-cinema-4d blog post].
 
----
===[https://3dcoat.com/ 3DCoat]===
{{KBwarning|As of version "2022-58", 3DCoat is unable to produce a spec-compliant glTF file, and thus should not be used for Second Life. '''Use at your own risk - you ''will'' have issues!}}

glTF export has been implemented since 3DCoat version 2020 and is found in the <code>File >Export > Export to glTF > glTF Separate (gltf + .bin + textures)</code>
 
----
=== [https://quixel.com/mixer Quixel Mixer] ===
Quixel Mixer has no glTF output, however, it does generate the functional textures, though they do need to be edited and combined in photo editing software.
Export them by going to <code>Export Target > Custom</code>

Texture Preset: Metalness Maps

Select:

Albedo , Roughness, Normal, AO , Metalness and ( if need be ) Emissive.

Click “Export to Disk” and open the folder that the files were placed into.

Albedo is the Base Color texture in this case.

AO , Roughness , Metalness get combined into the ORM map as per [[PBR_Materials#PBR_Material_Composition|this explanation.]]

Normal Map : Quixel generates Direct3D Normal Maps. The green channel needs to be inverted as [[PBR_Materials#Normal_.5B_RGB_.5D_|per here.]]

Upload to Second Life using [[PBR_Materials#Method_2_:_Edit_a_Blank._Create_PBR_Materials_without_a_GLTF_File|Method 2.]]
 
----
=== [https://www.autodesk.eu/products/3ds-max/overview Autodesk 3DS Max 2023] ===
Autodesk just added the ability to create glTF files using their new glTF Material and glTF Export functionalities as outlined in '''[https://help.autodesk.com/view/3DSMAX/2023/ENU/?guid=GUID-EFBB037D-C4EB-42D2-9CE1-30FCAD483C31 Autodesk's official documentation]'''. All prior versions of Autodesk software do not have this functionality.
 
----
=== [https://www.materialmaker.org/ Material Maker] ===
While [https://www.materialmaker.org/ Material Maker] does not currently export directly to glTF ([https://github.com/RodZill4/material-maker/issues/479 This may be added in future]), materials created with this program are compatible with Second Life.

Export your materials using the '''Godot 4 ORM''' export preset.

Upload to Second Life using [[PBR_Materials#Method_2_:_Edit_a_Blank._Create_PBR_Materials_without_a_GLTF_File|Method 2.]]
 
----
=== Adobe Photoshop ===
'''While Photoshop is not officially a PBR authoring tool''', the changes to Alpha Blending (changing into Linear space from sRGB) may require you to change your PS settings to get consistent results. Please see [http://www.kiransprojects.com/blog/2014/photoshop-blending-is-broken/ this article] for more information. (See the section titled "A Partial Solution"). Alternatively, [https://www.reddit.com/r/photoshop/comments/61clf8/how_to_fix_photoshops_incorrect_and_ugly_color/ this Reddit post] also gives a few options on how to achieve blending in the correct manner.
 
----
=== GIMP ===
'''While GIMP is not officially a PBR authoring tool''', the changes to Alpha Blending (changing into Linear space from sRGB) in Second Life will make textures created in GIMP display their alphas correctly (GIMP defaults to linear alpha calculation).

== Troubleshooting content ==

If you upload a piece of PBR content which does not match your editor, the advice from Linden Lab is to '''STOP: File a Feedback ticket. Do not attempt to "fix" the content.'''

That said, there are some troubleshooting steps which you can do yourself:
* Check that you are using the PBR Linden Midday preset (called "Midday") ''not "Midday (Legacy)"''. Other environments may not match the reference HDRi, causing some visual differences. (This is intended behaviour, and content should be able to be viewed under any light correctly, but for troubleshooting purposes this may be required).
** At present, there is a bug with the PBR Linden Midday preset which results in an excessive blue sheen, due to the use of an over-saturated (unrealistic) sky color, among some other issues. This has been fixed in the upcoming glTF Maintenance viewer.
* Are you using a reflection probe? If not, does the problem reproduce if a manual reflection probe is placed over the object?
** This is because a common source of the "blue sheen" in interior scenes is the use of an auto-probe. Auto-probes sample their surroundings, and combined with the approximate (and often incorrect) placement this will mean the sky is sampled on all sides, thus meaning the reflected light from the surroundings (which counters the blue light from the sky) is absent, leading to a larger-than-expected level of sky contribution on the object. Auto-probe placement can be worse in skyboxes or sky platforms
* Triple-check the settings used for your editor match the ones given [[PBR_Materials#Recommended_Application_Settings|here]], including the reference HDRi. '''Any''' deviation from these settings may cause visual differences between your editor and in-world.
* Check your content against a glTF reference viewer; such as:
** [https://modelviewer.dev/editor/ Modelviewer.dev]
** [https://github.khronos.org/glTF-Sample-Viewer-Release/ Khronos Sample Viewer]

If the above steps fail, then please '''[https://feedback.secondlife.com/ file some Feedback.]'''

A good Feedback ticket will include:
* An LM to a location where the problem can be examined in-world.
* A copy of the glTF content, attached to the ticket.
* Screenshots of the representation in-world, in a reference viewer, and in-editor.
** You should include screenshots of the object inside a manually placed reflection probe, and outside.

LlSetPayPrice

2025-04-03T19:31:52Z

Wulfie Reanimator: Bug caveat

{{LSL_Function
|inject-2={{Issues/VWR-3048}}{{Issues/VWR-8744}}
|func_id=302|func_sleep=0.0|func_energy=10.0
|func=llSetPayPrice|sort=SetPayPrice
|p1_type=integer|p1_name=price|p1_desc=PAY_* constant or positive value (including zero)
|p2_type=list|p2_name=quick_pay_buttons|p2_desc=Four PAY_* constants and/or positive integer values (zero is not shown)
|func_desc=Suggest default amounts for the pay text field and pay buttons of the appearing dialog when someone chooses to pay this object.
|caveats=*This function should not be trusted to limit the values of money payable to the object; ''always'' verify the amount paid is the amount expected.
* Use only one call to this function in all the scripts on an object to prevent confusion about which values are used. You still need to check in the money event that the amount is as expected.
* This function only works when called from the root prim of an object. Its effect applies to all the prims in the object. Calling it from a child prim has no effect.
** There is currently a [https://feedback.secondlife.com/slua-alpha/p/child-prim-in-linkset-cannot-be-paid-if-previously-a-root-prim-with-llsetpaypric viewer bug] where calls from child prims will '''prevent''' payment to the object.
* Payment to a prim can be blocked by the llSetPayPrice() setting in the prim, which persists even if the script with llSetPayPrice() is removed.
* '''Caution:''' Calling this function will enable payment on the prim (or the whole object if it is the root prim) for the current state, even when this state has no money event.
* Otherwise, the pay option will only be shown in prims having a running script with a [[money]] event (or in all the prims of the object if the root has a running script with a money event).
* The effect seems to persist even if the script is recompiled with out the [[llSetPayPrice]] function, even if the script is replaced with another one which includes a [[money]] event, but not [[llSetPayPrice]].
* Money cannot be paid to an attachment; "Pay" will go directly to the wearer instead.
* If '''quick_pay_buttons''' contains a negative value or zero, the button will not be shown at all.
** However, zero is allowed for '''price''', which is used to set the custom text field's value within the Pay window.

|examples=This will give the user a dialog box without the '''price''' field and only one button with a value of 150.
<source lang="lsl2">llSetPayPrice(PAY_HIDE, [150,PAY_HIDE,PAY_HIDE,PAY_HIDE])</source>

<source lang="lsl2">integer price = 10;

default
{
state_entry()
{
llSetPayPrice(PAY_HIDE, [PAY_HIDE ,PAY_HIDE, PAY_HIDE, PAY_HIDE]);
llRequestPermissions(llGetOwner(), PERMISSION_DEBIT);
}
run_time_permissions(integer perm)
{
if(perm & PERMISSION_DEBIT)
state cash;
}
}

state cash
{
state_entry()
{
llSetPayPrice(price, [price ,PAY_HIDE, PAY_HIDE, PAY_HIDE]);
}
money(key id, integer amount)
{
if(amount != price)
{
llGiveMoney(id, amount);
llInstantMessage(id, "You paid "+(string)amount+", which is the wrong price, the price is: "+(string)price);
}
else
{
//insert your give code here.
llInstantMessage(id, "You paid the right price");
}
}
}</source>
|spec
|constants=
{{{!}}
{{!}}
{{{!}}{{Prettytable|style=margin-top:0;}}
{{!}}-{{Hl2}}
! colspan="2" {{!}} Constant
! {{HoverText|Alt|Alternate}}
! Description
{{!}}-
{{!}} [[PAY_HIDE]]
{{!}} -1
{{!}} <center>0</center>
{{!}} Hides this quick pay button.
{{!}}-
{{!}} [[PAY_DEFAULT]]
{{!}} -2
{{!}}
{{!}} Use the default value for this quick pay button.
{{!}}}
{{!}}
{{{!}} {{Prettytable|style=margin-top:0;}}
{{!}}-{{Hl2}}
! colspan="2" {{!}} Button Order
{{!}}-
{{!}} <center>1</center>
{{!}} <center>2</center>
{{!}}-
{{!}} <center>3</center>
{{!}} <center>4</center>
{{!}}}
{{!}}
{{{!}}{{Prettytable|style=margin-top:0;}}
{{!}}-{{Hl2}}
! colspan="2" {{!}} Defaults
{{!}}-
{{!}}$1
{{!}}$5
{{!}}-
{{!}}$10
{{!}}$20
{{!}}}
{{!}}}
|helpers
|also_functions={{LSL DefineRow||[[llGiveMoney]]|}}
|also_tests={{LSL DefineRow||[[llSetPayPrice Test]]|}}
|also_events={{LSL DefineRow||[[money]]|}}
|also_articles
|notes
|cat1=Money
|cat2=Prim
|cat3=Dialog
|cat4
|issues
}}

LlRotateTexture

2025-04-01T10:44:47Z

Wulfie Reanimator: Rewording

{{LSL_Function
|inject-2={{LSL_Function/face|face}}
{{LSL_Function/angle|angle}}
|func_id=56|func_sleep=0.2|func_energy=10.0
|func=llRotateTexture
|p1_type=float|p1_name=angle
|p2_type=integer|p2_name=face
|func_footnote
|func_desc=Sets the rotation of a texture on the chosen {{LSLP|face}} to {{LSLP|angle}}.
|return_text
|spec
|caveats
|constants
|examples=<source lang="lsl2">
default
{
touch_start(integer total_number) {
// Makes the object's texture rotate a quarter of turn
llRotateTexture(PI_BY_TWO, ALL_SIDES);
}
}
</source>
|helpers
|also_functions={{LSL DefineRow||[[llGetTextureRot]]|Gets the texture rotation}}
{{LSL DefineRow||[[llSetTextureAnim]]|Animates the texture}}
|also_tests
|also_events
|also_articles
|notes=
This function only sets the absolute orientation of the texture. See [[llSetTextureAnim]] for animations.
|cat1=Face
|cat2=Texture
|cat3
|cat4
}}

Luau Examples

2025-03-23T14:50:48Z

Wulfie Reanimator: bugfix vehicle.lua (bit32.btest) and removed unused variables

__TOC__

Example [[Luau Alpha|Luau]] scripts

== vehicle.lua ==
This script demonstrates how one may create their own vehicle scripts, which don’t rely on the underlying LL vehicle system.
<source lang="lua">
-- These two will hold the link numbers for left and right front wheels
local LINK_WHEEL_LEFT = 0
local LINK_WHEEL_RIGHT = 0

-- Integra Type R Engine properties
local Engine = {
rpm = 800, -- current engine RPM (starts at idle)
gear = 0, -- 0 = neutral; -1 = reverse; 1-5 for forward gears
idleRPM = 800, -- idle RPM
maxRPM = 8300, -- redline
throttle = 0.0, -- throttle value (0.0 to 1.0)
gearRatios = { -- Integra Type R gear ratios
[-1] = 3.727, -- reverse gear ratio
[0] = 0, -- neutral
[1] = 3.727,
[2] = 2.256,
[3] = 1.729,
[4] = 1.416,
[5] = 1.194
}
}

local FINAL_DRIVE = 4.1 -- Final drive ratio
local WHEEL_RADIUS = 0.3 -- in meters

-- Vehicle properties (using realistic Integra Type R mass)
local Vehicle = {
speed = 0, -- speed in m/s; negative indicates reverse motion
mass = 1200, -- mass in kg
angle = 0, -- heading angle in radians
steering = 0, -- steering input: -1 (left), 0 (none), 1 (right)
brake = false -- flag indicating if brakes are applied
}

-- Engine constants (using realistic Integra Type R values)
local MAX_TORQUE = 200 -- in Nm

-- Brake force constant (for active braking)
local BRAKE_FORCE = 4000 -- in Newtons

-- Define a torque curve function:
local function torqueCurve(rpm)
local peakRPM = 6000
if rpm < peakRPM then
return 0.8 + 0.2 * ((rpm - Engine.idleRPM) / (peakRPM - Engine.idleRPM))
else
local factor = 1 - 0.5 * ((rpm - peakRPM) / (Engine.maxRPM - peakRPM))
return math.max(0.5, factor)
end
end

-- Engine braking force when throttle is zero in gear.
local ENGINE_BRAKE_FORCE = 2000 -- in Newtons

-- Friction and drag constants
local G = 9.81 -- gravity (m/s^2)
local C_rr_inGear = 0.015 -- rolling resistance coefficient in gear
local C_rr_neutral = 0.05 -- rolling resistance coefficient in neutral

local airDensity = 1.225 -- kg/m^3
local dragCoefficient = 0.3 -- aerodynamic drag coefficient
local frontalArea = 2.2 -- in m^2

local function getAerodynamicDrag(speed)
return 0.5 * airDensity * dragCoefficient * frontalArea * speed * speed
end

-- Compute engine RPM from vehicle speed when in gear.
local function computeEngineRPMFromSpeed()
if Engine.gear == 0 then
return Engine.rpm -- In neutral, RPM is managed independently.
else
local conversionFactor = Engine.gearRatios[Engine.gear] * FINAL_DRIVE * (60 / (2 * math.pi * WHEEL_RADIUS))
local rpm = math.abs(Vehicle.speed) * conversionFactor
if rpm < Engine.idleRPM then rpm = Engine.idleRPM end
return rpm
end
end

-- For neutral, update RPM toward a target based on throttle.
local function updateEngineRPMNeutral()
local targetRPM = Engine.idleRPM + (Engine.maxRPM - Engine.idleRPM) * Engine.throttle
local changeRate = 200 -- RPM per tick
if Engine.rpm < targetRPM then
Engine.rpm = math.min(Engine.rpm + changeRate, targetRPM)
elseif Engine.rpm > targetRPM then
Engine.rpm = math.max(Engine.rpm - changeRate, targetRPM)
end
end

-- Calculate the engine force delivered to the wheels.
local function getEngineForce()
if Engine.gear == 0 then
return 0 -- In neutral, no drive force is transmitted.
else
if Engine.throttle == 0 then
-- Apply engine braking when throttle is released.
return -ENGINE_BRAKE_FORCE
else
local torque = Engine.throttle * MAX_TORQUE * torqueCurve(Engine.rpm)
local force = (torque * Engine.gearRatios[Engine.gear] * FINAL_DRIVE) / WHEEL_RADIUS
return force
end
end
end

-- Starts the engine by setting it to idle RPM.
local function startEngine()
Engine.rpm = Engine.idleRPM
ll.Say(0, "Engine started. RPM: " .. Engine.rpm)
end

-- Shifts the gear if valid.
local function shiftGear(newGear)
if Engine.gearRatios[newGear] then
Engine.gear = newGear
ll.Say(0, "Shifted to gear " .. newGear)
else
ll.Say(0, "Invalid gear: " .. newGear)
end
end

local function findWheels()
local total = ll.GetNumberOfPrims()
for i = 1, total do
local name = ll.GetLinkName(i)
if name == "WHEEL_LF" then
LINK_WHEEL_LEFT = i
elseif name == "WHEEL_RF" then
LINK_WHEEL_RIGHT = i
end
end
end

local castRayCounter = 0
local lastGrounded = false

local function isVehicleOnGround()
castRayCounter = castRayCounter + 1
if castRayCounter >= 5 then
castRayCounter = 0
local pos = ll.GetPos()
local rayDistance = 4.5 -- threshold distance (in meters) to consider as "grounded"
local rayStart = pos
local rayEnd = pos + vector(0, 0, -rayDistance)
local hitResult = ll.CastRay(rayStart, rayEnd, {})
if rawlen(hitResult) == 3 then
lastGrounded = true
else
lastGrounded = false
end
end
return lastGrounded
end

-- Timer event: updates engine, vehicle physics, steering, and rotates the wheels based on steering.
function timer()
local dt = 0.1 -- time step in seconds

-- For neutral, update RPM based on throttle.
if Engine.gear == 0 then
updateEngineRPMNeutral()
end

-- Calculate forces.
local C_rr = (Engine.gear == 0) and C_rr_neutral or C_rr_inGear
local F_roll = Vehicle.mass * G * C_rr
local engineForce = getEngineForce()
local dragForce = getAerodynamicDrag(math.abs(Vehicle.speed))
local netForce = engineForce - (F_roll + dragForce)

-- Apply braking force if brakes are engaged.
if Vehicle.brake then
netForce = netForce - BRAKE_FORCE
end

local acceleration = netForce / Vehicle.mass
local vel = ll.GetVel()
local horizontal_vec = vector(vel.x, vel.y, 0)
Vehicle.speed = (ll.VecMag(horizontal_vec) + acceleration * dt)

-- Limit vehicle speed based on gear.
if Engine.gear ~= 0 then
if Vehicle.speed < 0 then
Vehicle.speed = 0
end
local conversionFactor = Engine.gearRatios[Engine.gear] * FINAL_DRIVE * (60 / (2 * math.pi * WHEEL_RADIUS))
local maxSpeed = Engine.maxRPM / conversionFactor
if Vehicle.speed > maxSpeed then
Vehicle.speed = maxSpeed
end
end

-- When in gear, update RPM based on the new speed.
if Engine.gear ~= 0 then
Engine.rpm = computeEngineRPMFromSpeed()
end

-- Steering update using angular velocity and quaternions:
local STEERING_RATE = math.rad(6) -- desired steering rate per tick (radians)
local yawDelta = Vehicle.steering * STEERING_RATE -- small rotation for this tick

if yawDelta ~= 0 then
local angularSpeed = yawDelta / dt
local angularVelocity = vector(0, 0, angularSpeed)
ll.SetAngularVelocity(angularVelocity, 1)
Vehicle.angle = Vehicle.angle + yawDelta
else
ll.SetAngularVelocity(vector(0, 0, 0), 1)
end

-- Display engine RPM and speed (converted to mph).
local speed_mph = math.abs(Vehicle.speed) * 2.23694
ll.SetText("RPM: " .. math.floor(Engine.rpm) ..
" | Speed: " .. string.format("%.1f", speed_mph) ..
" mph", vector(0,0,0), 1)

-- Only update velocity if the vehicle is near the ground, and we're in gear.
if isVehicleOnGround() and Engine.gear ~= 0 then
local velocityVector
if Engine.gear > 0 then
velocityVector = vector(Vehicle.speed, 0, 0)
else
-- Reverse gear
velocityVector = vector(-Vehicle.speed, 0, 0)
end
ll.SetVelocity(velocityVector, 1)
end

-- Update the wheel rotations to visually match the steering.
local maxWheelTurn = math.rad(30) -- maximum wheel turn angle in radians
local wheelAngle = -Vehicle.steering * maxWheelTurn

if LINK_WHEEL_LEFT > 0 then
ll.SetLinkPrimitiveParamsFast(
LINK_WHEEL_LEFT,
{
PRIM_ROT_LOCAL,
ll.Euler2Rot(vector(-4.71239, -wheelAngle, 0))
}
)
end

if LINK_WHEEL_RIGHT > 0 then
ll.SetLinkPrimitiveParamsFast(
LINK_WHEEL_RIGHT,
{
PRIM_ROT_LOCAL,
ll.Euler2Rot(vector(4.71239, wheelAngle, 0))
}
)
end
end

-- Called when the object is touched: starts engine and simulation.
function touch_start(num)
ll.Say(0, "Touch detected, requesting controls and starting engine.")
ll.RequestPermissions(ll.GetOwner(), PERMISSION_TAKE_CONTROLS)
startEngine()
findWheels()
ll.SetTimerEvent(0.1)
end

-- Called when runtime permissions are granted.
function run_time_permissions(perm)
if bit32.btest(perm, PERMISSION_TAKE_CONTROLS) then
ll.Say(0, "Permissions granted.")
local controlMask = bit32.bor(CONTROL_FWD, CONTROL_BACK, CONTROL_UP, CONTROL_DOWN, CONTROL_LEFT, CONTROL_RIGHT)
ll.TakeControls(controlMask, 1, 1)
end
end

-- Handle control events:
-- • CONTROL_FWD applies throttle.
-- • CONTROL_BACK applies the brakes.
-- • CONTROL_UP and CONTROL_DOWN shift gears.
-- • CONTROL_LEFT and CONTROL_RIGHT steer the vehicle.
function control(avatar_id, level, edge)
local start = bit32.band(level, edge)
local held = bit32.band(level, bit32.bnot(edge))

if bit32.band(held, CONTROL_BACK) ~= 0 then
Vehicle.brake = true
Engine.throttle = 0.0
elseif bit32.band(held, CONTROL_FWD) ~= 0 then
Vehicle.brake = false
Engine.throttle = 1.0
if Engine.gear == 0 then
updateEngineRPMNeutral()
end
else
Vehicle.brake = false
Engine.throttle = 0.0
end

if bit32.band(start, CONTROL_UP) ~= 0 then
shiftGear(Engine.gear + 1)
end

if bit32.band(start, CONTROL_DOWN) ~= 0 then
shiftGear(Engine.gear - 1)
end

local steeringInput = 0
if bit32.band(held, CONTROL_LEFT) ~= 0 then
steeringInput = steeringInput + 1
end
if bit32.band(held, CONTROL_RIGHT) ~= 0 then
steeringInput = steeringInput - 1
end
Vehicle.steering = steeringInput
end
</source>

== weather_box.lua ==
This script demonstrates coroutines, as well as working with a JSON-based web API:
<source lang="lua">
local TEXTBOX_CHANNEL = 323242
-- kludge because we don't have LSL constants in here yet
local HTTP_BODY_MAXLENGTH = integer(2)
local PRIM_TEXT = integer(26)
local PRIM_SIZE = integer(7)

gCityName = ""
gLatLong = nil -- A table of 2 elems when it's populated
gCityRequestTask = nil
gWeatherRequestTask = nil

-----
-- JSON stuff
-----

-- From https://github.com/rxi/json.lua/blob/master/json.lua

local json = {}

local escape_char_map = {
[ "\\" ] = "\\",
[ "\"" ] = "\"",
[ "\b" ] = "b",
[ "\f" ] = "f",
[ "\n" ] = "n",
[ "\r" ] = "r",
[ "\t" ] = "t",
}

local escape_char_map_inv = { [ "/" ] = "/" }
for k, v in pairs(escape_char_map) do
escape_char_map_inv[v] = k
end

local parse

local function create_set(...)
local res = {}
for i = 1, select("#", ...) do
res[ select(i, ...) ] = true
end
return res
end

local space_chars = create_set(" ", "\t", "\r", "\n")
local delim_chars = create_set(" ", "\t", "\r", "\n", "]", "}", ",")
local escape_chars = create_set("\\", "/", '"', "b", "f", "n", "r", "t", "u")
local literals = create_set("true", "false", "null")

local literal_map = {
[ "true" ] = true,
[ "false" ] = false,
[ "null" ] = nil,
}

local function next_char(str, idx, set, negate)
for i = idx, #str do
if set[str:sub(i, i)] ~= negate then
return i
end
end
return #str + 1
end

local function decode_error(str, idx, msg)
local line_count = 1
local col_count = 1
for i = 1, idx - 1 do
col_count = col_count + 1
if str:sub(i, i) == "\n" then
line_count = line_count + 1
col_count = 1
end
end
error( string.format("%s at line %d col %d", msg, line_count, col_count) )
end

local function codepoint_to_utf8(n)
-- http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=iws-appendixa
local f = math.floor
if n <= 0x7f then
return string.char(n)
elseif n <= 0x7ff then
return string.char(f(n / 64) + 192, n % 64 + 128)
elseif n <= 0xffff then
return string.char(f(n / 4096) + 224, f(n % 4096 / 64) + 128, n % 64 + 128)
elseif n <= 0x10ffff then
return string.char(f(n / 262144) + 240, f(n % 262144 / 4096) + 128,
f(n % 4096 / 64) + 128, n % 64 + 128)
end
error( string.format("invalid unicode codepoint '%x'", n) )
end

local function parse_unicode_escape(s)
local n1 = tonumber( s:sub(1, 4), 16 )
local n2 = tonumber( s:sub(7, 10), 16 )
-- Surrogate pair?
if n2 then
return codepoint_to_utf8((n1 - 0xd800) * 0x400 + (n2 - 0xdc00) + 0x10000)
else
return codepoint_to_utf8(n1)
end
end

local function parse_string(str, i)
local res = ""
local j = i + 1
local k = j

while j <= #str do
local x = str:byte(j)

if x < 32 then
decode_error(str, j, "control character in string")

elseif x == 92 then -- `\`: Escape
res = res .. str:sub(k, j - 1)
j = j + 1
local c = str:sub(j, j)
if c == "u" then
local hex = str:match("^[dD][89aAbB]%x%x\\u%x%x%x%x", j + 1)
or str:match("^%x%x%x%x", j + 1)
or decode_error(str, j - 1, "invalid unicode escape in string")
res = res .. parse_unicode_escape(hex)
j = j + #hex
else
if not escape_chars[c] then
decode_error(str, j - 1, "invalid escape char '" .. c .. "' in string")
end
res = res .. escape_char_map_inv[c]
end
k = j + 1

elseif x == 34 then -- `"`: End of string
res = res .. str:sub(k, j - 1)
return res, j + 1
end

j = j + 1
end

decode_error(str, i, "expected closing quote for string")
end

local function parse_number(str, i)
local x = next_char(str, i, delim_chars)
local s = str:sub(i, x - 1)
local n = tonumber(s)
if not n then
decode_error(str, i, "invalid number '" .. s .. "'")
end
return n, x
end

local function parse_literal(str, i)
local x = next_char(str, i, delim_chars)
local word = str:sub(i, x - 1)
if not literals[word] then
decode_error(str, i, "invalid literal '" .. word .. "'")
end
return literal_map[word], x
end

local function parse_array(str, i)
local res = {}
local n = 1
i = i + 1
while 1 do
local x
i = next_char(str, i, space_chars, true)
-- Empty / end of array?
if str:sub(i, i) == "]" then
i = i + 1
break
end
-- Read token
x, i = parse(str, i)
res[n] = x
n = n + 1
-- Next token
i = next_char(str, i, space_chars, true)
local chr = str:sub(i, i)
i = i + 1
if chr == "]" then break end
if chr ~= "," then decode_error(str, i, "expected ']' or ','") end
end
return res, i
end

local function parse_object(str, i)
local res = {}
i = i + 1
while 1 do
local key, val
i = next_char(str, i, space_chars, true)
-- Empty / end of object?
if str:sub(i, i) == "}" then
i = i + 1
break
end
-- Read key
if str:sub(i, i) ~= '"' then
decode_error(str, i, "expected string for key")
end
key, i = parse(str, i)
-- Read ':' delimiter
i = next_char(str, i, space_chars, true)
if str:sub(i, i) ~= ":" then
decode_error(str, i, "expected ':' after key")
end
i = next_char(str, i + 1, space_chars, true)
-- Read value
val, i = parse(str, i)
-- Set
res[key] = val
-- Next token
i = next_char(str, i, space_chars, true)
local chr = str:sub(i, i)
i = i + 1
if chr == "}" then break end
if chr ~= "," then decode_error(str, i, "expected '}' or ','") end
end
return res, i
end

local char_func_map = {
[ '"' ] = parse_string,
[ "0" ] = parse_number,
[ "1" ] = parse_number,
[ "2" ] = parse_number,
[ "3" ] = parse_number,
[ "4" ] = parse_number,
[ "5" ] = parse_number,
[ "6" ] = parse_number,
[ "7" ] = parse_number,
[ "8" ] = parse_number,
[ "9" ] = parse_number,
[ "-" ] = parse_number,
[ "t" ] = parse_literal,
[ "f" ] = parse_literal,
[ "n" ] = parse_literal,
[ "[" ] = parse_array,
[ "{" ] = parse_object,
}

parse = function(str, idx)
local chr = str:sub(idx, idx)
local f = char_func_map[chr]
if f then
return f(str, idx)
end
decode_error(str, idx, "unexpected character '" .. chr .. "'")
end

function json.decode(str)
if type(str) ~= "string" then
error("expected argument of type string, got " .. type(str))
end
local res, idx = parse(str, next_char(str, 1, space_chars, true))
idx = next_char(str, idx, space_chars, true)
if idx <= #str then
decode_error(str, idx, "trailing garbage")
end
return res
end

-----
-- Event Loop
-----

-- A naive little event loop that lets you track running coroutines and dispatches
-- the events they're waiting for to them.

local EventLoop = {
-- Coroutine -> awaited event
_coros = {},
running = false
}

function EventLoop:create_task(func)
local coro = coroutine.create(func)
-- false has no semantic meaning here, we just want to reserve the space for
-- the coroutine in the table without saying we're awaiting anything yet.
self._coros[coro] = false
self:_run_coro(coro)
return coro
end

function EventLoop:kill_task(coro)
self._coros[coro] = nil
if coroutine.status ~= "dead" then
coroutine.close(coro)
end
end

-- (internal) run the event
function EventLoop:_run_coro(coro, ...)
assert(coroutine.status(coro) ~= "dead")
-- assert(not self.running)
local old_running = self.running
self.running = true

-- Since we're running, this isn't currently awaiting anything
self._coros[coro] = false
local success, ret = coroutine.resume(coro, ...)
self.running = old_running

-- If we're not done then ret should be the kind of event we're awaiting.
-- Otherwise it's an error message or something. Who cares.
if not success then
-- Get rid of the coro
if ret then
ll.OwnerSay(`Might have an error: {ret}`)
end
ret = nil
end
self._coros[coro] = ret
end

-- Wake up any tasks that are waiting for this kind of event
function EventLoop:handle_event(name, ...)
-- We may mutate self._coros, so do a clone
local coros = table.clone(self._coros)
ll.OwnerSay(`Handling {name}`)

for coro, awaited_event in coros do
if coroutine.status(coro) == "dead" then
-- Hmm, this coroutine is dead, prune it.
self._coros[coro] = nil
end

if awaited_event == name then
ll.OwnerSay(`Dispatching {name} to {coro}`)
self:_run_coro(coro, ...)
end
end
end

function EventLoop:create_event_catcher(name)
local function catcher(...)
ll.OwnerSay("yay")
EventLoop:handle_event(name, ...)
end
return catcher
end

-- Helper function for waiting and telling the EventLoop what event you want
local function await_event(kind)
-- You had better do this inside a running event loop
assert(EventLoop.running)
-- This will yield, the EventLoop will resume us once it has
-- an event we might be interested in.
return coroutine.yield(kind)
end

-----
-- Script-specific functions
-----

local function hide_children()
for i=2,ll.GetNumberOfPrims() do
-- Hide all the child prims
ll.SetLinkAlpha(i, 0, -1)
ll.SetLinkPrimitiveParamsFast(i, {
PRIM_SIZE, vector(0.5, 0.5, 0.5),
PRIM_TEXT, "", vector(1,1,1), 1
})
end
end

local function send_textbox(avatar_id, message, channel)
ll.TextBox(avatar_id, message, channel)

while true do
local resp_channel, name, id, resp = await_event("listen")
if id ~= avatar_id or channel ~= resp_channel then
-- If this isn't a message we're interested in then wait for the next event
ll.OwnerSay(`{id}, {avatar_id}, {resp_channel}, {channel}`)
continue
end
return resp
end
end

local function make_json_request(url)
local req_id = ll.HTTPRequest(url, {HTTP_BODY_MAXLENGTH, integer(16000)}, "")
while true do
local ev_id, status, metadata, body = await_event("http_response")
if ev_id ~= req_id then
-- Not a response for the HTTP request we were waiting on, wait for the next event.
continue
end
return status, metadata, body
end
end

local function request_weather()
-- And you can use a wrapper like this to make an async function callable within both normal and coroutine contexts.
-- Normally this sort of thing would not be necessary, but here it is since the EventLoop lives in our own code,
-- and isn't a property of the actual script engine.
if gWeatherRequestTask then
EventLoop:kill_task(gWeatherRequestTask)
end

gWeatherRequestTask = EventLoop:create_task(function()
ll.OwnerSay("Requesting weather")
local status, metadata, body = make_json_request(`https://api.open-meteo.com/v1/forecast?latitude={gLatLong[1]}&longitude={gLatLong[2]}&current=temperature_2m&daily=temperature_2m_max`)
if status ~= 200 then
ll.OwnerSay("Error requesting weather")
return
end
local parsed = json.decode(body)

local current = parsed["current"]
ll.OwnerSay(`Temperature is {current["temperature_2m"]}C`)
ll.SetText(`Temperature in {gCityName} is currently {current["temperature_2m"]}C`, vector(1,1,1), 1)

-- Show the highs for each day
local days = parsed["daily"]["temperature_2m_max"]
for i=1,#days do
local link_num = i + 1
-- Higher temps = bigger on Z, negatives are unrepresentable :)
local z_size = (days[i] / 30) * 2
ll.SetLinkAlpha(link_num, 1, -1)
ll.SetLinkPrimitiveParamsFast(link_num, {
PRIM_SIZE, vector(0.5, 0.5, z_size),
PRIM_TEXT, `{days[i]}C`, vector(1,1,1), 1
})
end
end)
end

local function ask_for_city()
local resp = send_textbox(ll.GetOwner(), "What city do you want the weather for?", TEXTBOX_CHANNEL)
if not resp then
ll.OwnerSay("Got no response for city request.")
return
end

ll.OwnerSay(`You want the weather for {resp}.`)
gLatLong = nil
gCityName = resp

hide_children()

-- request the lat and long for this city
local status, metadata, body = make_json_request(`https://nominatim.openstreetmap.org/search.php?city={ll.EscapeURL(resp)}&format=jsonv2`)
local parsed = json.decode(body)
if not #parsed then
ll.OwnerSay(`Got no results for {resp}!`)
return
end

local first_result = parsed[1]
gLatLong = {first_result["lat"], first_result["lon"]}
ll.OwnerSay(`City Lat: {gLatLong[1]}, Long: {gLatLong[2]}`)

request_weather()

-- request weather again in 3 mins
ll.SetTimerEvent(180)
end

-----
-- Event Handlers
-----

-- If we don't care about conventionally dispatched events, we can just set the event handler to directly send
-- event data to the event loop.
http_response = EventLoop:create_event_catcher("http_response")
listen = EventLoop:create_event_catcher("listen")

-- More conventional event handlers work too.
function touch_start(num)
for i=0,num-1 do
if ll.GetOwner() ~= ll.DetectedKey(i) then
-- Go to next loop if it wasn't the owner touching us.
continue
end

if gCityRequestTask then
EventLoop:kill_task(gCityRequestTask)
end

-- Spin up a task to ask the user for their city
gCityRequestTask = EventLoop:create_task(ask_for_city)
break
end
end

function timer()
request_weather()
end

-- Not strictly necessary, but I like having the main function have its own scope.
-- Rather than just have top-level logic.
local function main()
ll.Listen(TEXTBOX_CHANNEL, "", "", "")
ll.SetText("", vector(1,1,1), 1)
hide_children()
ll.OwnerSay("Weatherbox operational!")
end

main()
</source>

== dialog_coroutine.lua ==
This script demonstrates how one could use coroutines to handle dialog responses, with multi-user support.
<source lang="lua">
-------------------------
-- Minimal EventLoop
-------------------------
local EventLoop = {
-- Coroutine -> eventName it’s waiting for
_coros = {},
running = false
}

function EventLoop:create_task(func)
local coro = coroutine.create(func)
self._coros[coro] = false
self:_run_coro(coro)
return coro
end

function EventLoop:kill_task(coro)
self._coros[coro] = nil
if coroutine.status(coro) ~= "dead" then
coroutine.close(coro)
end
end

-- Internal helper: resumes a coroutine
function EventLoop:_run_coro(coro, ...)
if coroutine.status(coro) == "dead" then
return
end

local old_running = self.running
self.running = true

self._coros[coro] = false
local ok, eventAwaited = coroutine.resume(coro, ...)
self.running = old_running

if not ok then
ll.OwnerSay(`Coroutine error: {eventAwaited}`)
self._coros[coro] = nil
return
end

-- If still alive, 'eventAwaited' is the next event it wants
self._coros[coro] = eventAwaited
end

function EventLoop:handle_event(eventName, ...)
ll.OwnerSay(`Handling event {eventName}`)
local snapshot = table.clone(self._coros)
for coro, waitingFor in pairs(snapshot) do
if coroutine.status(coro) == "dead" then
self._coros[coro] = nil
elseif waitingFor == eventName then
ll.OwnerSay(`Dispatching event {eventName} to {coro}`)
self:_run_coro(coro, ...)
end
end
end

-- Coroutines use this to yield until an event
local function await_event(name)
assert(EventLoop.running, "await_event called outside a coroutine!")
return coroutine.yield(name)
end

-------------------------
-- Script Logic
-------------------------
local buttons = {"-", "Red", "Green", "Yellow"}
local dialogInfo = "\nPlease make a choice."

-- Use the chat listener to feed the event-loop
function listen(channel, name, sender_id, message)
-- We handle all 'listen' events via the event-loop
EventLoop:handle_event(`listen_{channel}`, channel, name, sender_id, message)
end

-- Called when the script starts
function state_entry()
-- Seed math.random so each new script run doesn’t repeat the same channels
math.randomseed(ll.GetUnixTime())
ll.OwnerSay("Script started with random channels for each user.")
end

-- A coroutine function for a single user's dialog flow
local function handle_dialog_for_user(userId)
-- Use a random channel
local channel = math.random(0x1, 0xFFFF)
-- Create a listener for that channel
local listenHandle = ll.Listen(channel, "", "", "")

while true do
-- Show the user a dialog
ll.Dialog(userId, dialogInfo, buttons, channel)

-- Wait for the next 'listen' event (channel, name, sender_id, message)
local c, n, sid, msg = await_event(`listen_{channel}`)

-- If this "listen" event isn't for our channel/user, ignore it
if c == channel and sid == userId then
-- If user pressed "-", re-display the menu, else they picked a final color
if msg ~= "-" then
ll.Say(0, `{n} selected {msg}`)
-- Now that they've chosen something else, remove the listener and finish
ll.ListenRemove(listenHandle)
return
end
end
end
end

-- Called when the object is touched
function touch_start(num_detected)
for i=0, num_detected-1 do
local toucherId = ll.DetectedKey(i)
-- Create a separate coroutine for each person who touches
EventLoop:create_task(function()
handle_dialog_for_user(toucherId)
end)
end
end

-- Run state_entry on load:
state_entry()
</source>

Lua Alpha

2025-03-23T14:34:03Z

Wulfie Reanimator: /* default_script.lua */

{{Warning|This functionality is in alpha. Instability is to be expected, and there may be very sharp edges. At this point it is expected that Luau can crash regions and perform other types of undesirable behavior.

'''🚨 PLEASE NOTE Memory and performance characteristics, and API specifics may change! Scripts are currently being run in unoptimized form for development purposes.'''}}

= Second Life Lua (SLua) Alpha =

[[File:Luau.png|720px|thumb|right|Luau logo]]

We're thrilled to announce the launch of the SLua Alpha for Second Life! This significant update introduces the Lua scripting language, offering creators enhanced performance, improved memory efficiency, and a more versatile scripting environment.

To get started, [https://wiki.secondlife.com/wiki/Try_SLua read the instructions here.]

== What is SLua? ==

SLua is scripting for Second Life based on Luau, a fast, small, safe, and gradually typed embeddable scripting language derived from Lua. It is designed to be backwards compatible with Lua 5.1, incorporating features from future Lua releases and expanding the feature set with type annotations and a state-of-the-art type inference system. Luau is largely implemented from scratch, with the language runtime being a heavily modified version of the Lua 5.1 runtime, featuring a completely rewritten interpreter and other performance innovations.

== Why Lua? ==

The decision to integrate Lua into Second Life was driven by its ability to meet all the requirements for a scripting engine within the platform. Lua offers a high-quality scripting experience to creators, addressing many of the limitations present in the current LSL (Linden Scripting Language) environment. Its lightweight nature and performance optimizations make it an ideal choice for enhancing the scripting capabilities in Second Life. For more information on why Lua was chosen, please see the [https://wiki.secondlife.com/wiki/Lua_FAQ Lua FAQ].

== How to Get Started with SLua ==

In order to play with SLua, you'll need to download our Lua project viewer, and log onto our [https://lindenlab.freshdesk.com/support/solutions/articles/31000156725-accessing-aditi Aditi beta grid].

* Access the latest build of the SLua-enabled Second Life Viewer from [https://releasenotes.secondlife.com/viewer/7.1.12.13526902562.html here].

Once you've got the new viewer and have logged onto the beta grid, head over to these SLua-enabled regions:

* [secondlife://Aditi/secondlife/SLua%20Yardang/241/235/27 SLua Yardang]
* [secondlife://Aditi/secondlife/SLua%20Tombolo/241/235/27 SLua Tombolo]
* [secondlife://Aditi/secondlife/SLua%20Mesa/241/235/27 SLua Mesa]
* [secondlife://Aditi/secondlife/SLua%20Tideland/241/235/27 SLua Tideland]

When editing a script in the new Lua project viewer, you'll notice a new '''Compiler''' drop-down near the save button. This drop-down will allow you to select which compiler will be used, as well as which script runtime will be used (LSO2, Mono, Luau).

[[File:Compiler_dropdown.png|Compiler selection dropdown]]

Compiler drop-down options:

* '''LSL: Legacy (LSO2)''' - Scripts written in LSL, to be run on the old LSO2 VM
* '''LSL: Mono'''- Scripts written in LSL, to be run on the Mono VM
* '''Lua''' - Scripts written in Lua, to be run on the SLua VM
* '''LSL/Luau'''- Scripts written in LSL, to be run on the SLua VM

=== Transitioning from LSL to SLua ===
* '''Function Namespacing:'''
** In SLua, Linden Lab functions have been moved under the '''ll''' namespace.
** For example:
*** ''llSay'' becomes ''ll.Say''
*** ''llGetPos'' becomes ''ll.GetPos''
* '''Lists'''
** Lua indexes begin from 1, unlike LSL where indexes begin from 0.
** Lua uses <code>{}</code> for ''tables'', unlike LSL where <code>[]</code> is used for ''lists''.
* Types
** SLua doesn't support the usual vector/rotation syntax <code><x, y, z></code>
*** Instead, these values are created with the functions <code>vector(x, y, z)</code>, <code>rotation(x, y, z, s)</code>
*** Similar functions exist for '''uuid''' (key) and '''integer''' (distinct from the built-in '''number''' type)

=== SLua Libraries ===
* '''Coroutines:'''
** SLua supports coroutines, allowing for cooperative multitasking within scripts.
** Key functions include:
*** ''coroutine.create''
*** ''coroutine.status''
*** ''coroutine.resume''
** Refer to the [https://luau.org/library#coroutine-library coroutine library documentation] for more details.
* '''Bitwise Operations:'''
** SLua includes a ''bit32'' library for bitwise operations, enabling more efficient data manipulation.
** Refer to the [https://luau.org/library#bit32-library bit32 library documentation] for more details.
* '''Standard Library:'''
** SLua comes equipped with a standard library of functions designed to manipulate built-in data types.
** Explore the [https://luau.org/library Luau Standard Library] for a comprehensive list of available functions.

== Feedback and Support ==

We encourage all creators to explore the new scripting capabilities and provide feedback. Your insights are invaluable in refining and enhancing this feature. For more information and to share your experiences, please refer to our [https://wiki.secondlife.com/wiki/Lua_FAQ Lua FAQ].

== Example Scripts ==

To help you get started, we've assembled some example scripts that demonstrate the capabilities of SLua. These scripts cover various functionalities and can serve as a foundation for your own creations. Please feel free to propose changes to these scripts, or modify them to your heart's desire!

=== default_script.lua ===
This script is roughly equivalent to the default "new script" that gets created for LSL.
<source lang="lua">
function state_entry()
ll.Say(0, "Hello, Avatar!")
end

function touch_start(total_number)
ll.Say(0, "Touched.")
end

-- Simulate the state_entry event
state_entry()
</source>

=== dialog.lua ===
This script demonstrates how one can interact with dialog menus.
<source lang="lua">
-- Define the menu buttons and dialog message.
local buttons = {"-", "Red", "Green", "Yellow"}
local dialogInfo = "\nPlease make a choice."

local ToucherID = nil
local dialogChannel = nil
local listenHandle = nil

-- This function is called when the script first starts.
function state_entry()
-- Get the object's key and compute a dialog channel number.
local key = ll.GetKey()
-- Extract the last 7 characters of the key and convert it from hex.
dialogChannel = -1 - tonumber(string.sub(tostring(key), -7, -1), 16)
end

-- Called when the object is touched.
function touch_start(num_detected)
ToucherID = ll.DetectedKey(0)
-- If there is already a listen handle, then remove it
if listenHandle then
ll.ListenRemove(listenHandle)
end
listenHandle = ll.Listen(dialogChannel, "", ToucherID, "")
ll.Dialog(ToucherID, dialogInfo, buttons, dialogChannel)
-- Set a 60-second timer for response.
ll.SetTimerEvent(60.0)
end

-- Called when a dialog response is received.
function listen(channel, name, sender_id, message)
if message == "-" then
-- Redisplay the dialog if the "-" option is selected.
ll.Dialog(ToucherID, dialogInfo, buttons, dialogChannel)
return
end
-- Stop the timer, and stop the listening handler.
ll.ListenRemove(listenHandle)
ll.SetTimerEvent(0)
-- Let the user know what they selected
ll.Say(0, `You selected {message}`)
end

-- Called when the timer expires.
function timer()
-- Stop the timer and clean up the listener.
if listenHandle then
ll.SetTimerEvent(0)
ll.ListenRemove(listenHandle)
ll.Whisper(0, "Sorry. You snooze; you lose.")
end
end

-- Invoke state_entry on startup, since simulator doesn't invoke
-- it like it does in LSL
state_entry()
</source>

=== user_input_coroutine.lua ===
This script demonstrates [https://www.lua.org/pil/9.html coroutines] and how they can simplify the overarching logic of a script, enabling us to write the bulk of our multi-event code within a centralized function instead of fragmenting across separate event handlers.
<source lang="lua">
-- Wait for user input mid-function before doing something useful with it.
main = function(toucher)
local handle = ll.Listen(0, "", toucher, "")
local event = touch_start -- save function for later
touch_start = nil -- disable touch_start

ll.RegionSayTo(toucher, 0, "Do you want pants or gloves?")
local clothing = coroutine.yield() -- pause the routine's execution here
ll.RegionSayTo(toucher, 0, "For men or women?")
local gender = coroutine.yield()
ll.RegionSayTo(toucher, 0, "Favorite color?")
local color = coroutine.yield()
ll.RegionSayTo(toucher, 0, "Here's "..color.." "..clothing.." for "..gender)

ll.ListenRemove(handle)
touch_start = event -- restore touch_start
end

function touch_start(total_num)
local toucher = ll.DetectedKey(0)
routine = coroutine.create(main) -- new coroutine
coroutine.resume(routine, toucher) -- run coroutine (with one argument)
end

-- When the coroutine is suspended, incoming events can be handled
-- and we can resume() execution of the routine
-- and pass any number of arguments to be returned by yield()
function listen(channel, name, id, message)
coroutine.resume(routine, message)
end
</source>

=== multi_user_input_coroutine.lua ===
Following from the above example, how can we handle multiple users? This is where coroutines shine.

Instead of disabling touches to prevent others from interacting with the object, we can create new copies of the coroutine each time an avatar touches the object. We can then resume whichever coroutine is needed, based on the avatar, while all of them track their own progress separately and automagically.
<source lang="lua">
-- Key: avatar uuid; Value: coroutine thread
routines = {}

main = function(toucher)
local handle = ll.Listen(0, "", toucher, "")

ll.RegionSayTo(toucher, 0, "Do you want pants or gloves?")
local clothing = coroutine.yield()
ll.RegionSayTo(toucher, 0, "For men or women?")
local gender = coroutine.yield()
ll.RegionSayTo(toucher, 0, "Favorite color?")
local color = coroutine.yield()
ll.RegionSayTo(toucher, 0, "Here's "..color.." "..clothing.." for "..gender)

ll.ListenRemove(handle)
routines[toucher] = nil -- Remove from collection
end

function touch_start(total_num)
local toucher = ll.DetectedKey(0)
local routine = routines[toucher]
if not routine then -- New user needs new routine
routine = coroutine.create(main)
routines[toucher] = routine -- Add to collection
coroutine.resume(routine, toucher)
end
end

function listen(channel, name, id, message)
coroutine.resume(routines[id], message) -- Resume a specific coroutine
end
</source>

=== More Examples ===

* Find more example scripts at [[Luau Example Scripts]]

* [https://roblox.github.io/lua-style-guide/gotchas/ Lua Gotchas, Footguns and Other Hazards]