[sldev] Packing alogrithm behind LAND_LAYER_CODE part of aLayerData message

Douglas Soo doug at lindenlab.com
Wed Mar 14 23:42:20 PDT 2007


As it turns out, we used to use send multiple levels of detail for the 
terrain, to get the terrain to rez in faster.  At some point a long time 
ago (pre-beta?) I ripped it out, as I discovered that we were actually 
taking a fairly substantial CPU hit on the client unpacking the heightfield 
multiple times - and transmitting the terrain at the highest quality level 
seemed fast enough.

- Doug

--On Thursday, March 15, 2007 5:56 AM +0800 Adam Frisby <adam at gwala.net> 
wrote:

> OK, the basic format is fairly simple, essentially:
>
> GROUP HEADER
> repeat {
> 	BLOCK HEADER
> 	"RLE"-style encoded BLOCK
> }
>
> "BLOCK" is usually a 16x16 DCT-encoded cell with a fairly quick encoding
> scheme over the top, basically you use the BLOCK HEADER to determine
> which patch this block is for and how long it runs for, and then decode
> and inverse DCT the result and place it in your main 256x256 heightmap
> array.
>
> However, it is possible to encode a larger or smaller cell than 16x16
> through the use of a seperate encoding path, we've never actually seen
> this used, but it is theoretically possible. (Possibly intended to encode
> a lower-detail version of the heightmap, and send that before the high
> resolution ones)
>
> There's a working encoder and decoder in the TerrainManager of
> libsecondlife, it's a pretty decent implementation (thanks to John)
> that's also being used in OpenSim.
>
> Adam
>
> Jesse Nesbitt wrote:
>
>> I believe that the OpenSim project has a working LayerData encoder, you
>> might want to check with them.
>> I know that John Hurliman and Adam Zaius have done LayerData work, if
>> you're lucky one of them might chime in.
>>
>> On 3/14/07, *Tleiades* <tleiades at hotmail.com
>> <mailto:tleiades at hotmail.com>> wrote:
>>
>>     I decided that maybe I should try to tell what I have already
>>     figured out, and what hunches I have.
>>
>>     This specific subtype of the LayerData message starts with a
>>     GroupHeader,
>>     containing a patch size, a stride and a repetition of the layer
>>     type. I haven't figured the exact purpose of the stride yet, but
>>     believe I have the other two fields pinned down.
>>
>>     Next follows a number of patches, each patch begins with a header.
>>     The only things in the header I have been able to determine is that
>>     quant_wbits (in part) encodes the size of the following numeric
>>     data, and that patchids seems to reference some sort of co-ordinate
>>     system.
>>
>>     Following the patch header is a bitpattern, which depending on bits
>>     turned on or off either idicates zero, negative or positive number,
>>     the size of the numbers are determined by the quant_wbits field. My
>>     guess is that the numbers are height encodings.
>>
>>     In short the message encodes a packed height field, but I really
>>     have no clue on how to combine the individual LayerData messages
>>     into a complete height map.
>>
>>
>>         ----- Original Message -----
>>         *From:* Tleiades <mailto:tleiades at hotmail.com>
>>         *To:* sldev at lists.secondlife.com
>>         <mailto:sldev at lists.secondlife.com>
>>         *Sent:* Wednesday, March 14, 2007 6:46 PM
>>         *Subject:* [sldev] Packing alogrithm behind LAND_LAYER_CODE part
>>         of aLayerData message
>>
>>         Hi
>>
>>         I've been trying to figure out the algorithm behind packing and
>>         decoding the LAND_LAYER_CODE part of a LayerData message. I'd
>>         like to get the broad picture of how that data is encoded, but I
>>         seem to get lost, not seeing the forest, because all the trees
>>         get in the way.
>>
>>         Is there someone who can provide me with an overall picture of
>>         the algorithm or point me to some url's explaining the algorithm?
>>
>>
>>
>>         ----------------------------------------------------------------
>>         --------
>>
>>         _______________________________________________
>>         Click here to unsubscribe or manage your list subscription:
>>         /index.html
>>
>>
>>     _______________________________________________
>>     Click here to unsubscribe or manage your list subscription:
>>     /index.html
>>
>>
>>
>>
>> --
>> --Jesse
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Click here to unsubscribe or manage your list subscription:
>> /index.html
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html



-- 
Douglas Soo
Studio Director
Linden Lab
1100 Sansome
San Francisco, CA 94111
doug at lindenlab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070314/ca54333b/attachment-0001.pgp


More information about the SLDev mailing list