[sldev] Packing alogrithm behind LAND_LAYER_CODE part of aLayerData message

[Adam Frisby]

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