Difference between revisions of "LlCloud"

From Second Life Wiki
Jump to navigation Jump to search
Line 2: Line 2:


     * SL features a cellular automata-based weather system.
     * SL features a cellular automata-based weather system.
     * There are 16x16 square cloud "cells" per sim (which means each is 16x16m in size). Does it need to be stated that there are boundry cloud cells in each sim, as is stated on Weather? -MalarthiBehemoth
     * There are 16x16 square cloud "cells" per sim (which means each is 16x16m in size).
     * The cloud density data is sent from the server to the client once every time the agent connects to a simulator via logging in or teleporting into a simulator.
     * The cloud density data is sent from the server to the client once every time the agent connects to a simulator via logging in or teleporting into a simulator.
     * The client attempts to render clouds from the cloud algorithm results sent from the server, which is why different clients can see different cloud formations and de-synchronises cloud view from the server over time.
     * The client attempts to render clouds from the cloud algorithm results sent from the server, which is why different clients can see different cloud formations and de-synchronises cloud view from the server over time.

Revision as of 15:08, 26 January 2007

   Outdated templated used

Please change the template from 'LSLFunctionAll' to 'LSL_Function' (just replace 'LSLFunctionAll' with 'LSL_Function', do this after fixing any other erorr messages.

  Either 'func_desc' or 'return_type' & 'return_text' must be defined

(Please use 'return_text' & 'return_type' or 'func_desc' to summarize the functions actions.)

Summary

Function: float llCloud( vector v );

Returns a float

• vector v

returns the cloud density at the object position + v

Examples

Notes

How clouds work:

   * SL features a cellular automata-based weather system.
   * There are 16x16 square cloud "cells" per sim (which means each is 16x16m in size).
   * The cloud density data is sent from the server to the client once every time the agent connects to a simulator via logging in or teleporting into a simulator.
   * The client attempts to render clouds from the cloud algorithm results sent from the server, which is why different clients can see different cloud formations and de-synchronises cloud view from the server over time.
   * The Z value in the vector is irrelevant (clouds are always between about 180-200m absolute height).
   * It returns a value between 0.0 and 1.0, with 0.0 being no clouds, and 1.0 very dense clouds.
   * Values returned above 1.0 - 2.0 indicate rainfall, but the option for rain is not currently implemented so values are capped at 1.0.
   * Clouds and wind are related. 


The cloud seed/growth/disipation algorithm uses a solenoidal vector field, which is a vector field with zero-divergence: nabla dot v = 0

This condition is satisfied whenever v has a vector potential, because if v = nabla times A then nabla dot v = nabla dot (nabla times A) = 0.

Deep Notes

Search JIRA for related Issues

Signature

function float llCloud( vector v );