RAW files are a pain in the ass
Through my work on SL4B, I’ve become painfully aware of how difficult it is to manage the terrain of a multi-region estate at once. It was decided at a recent meeting to terraform the SL hand logo into the SL4B estate. Completing such a task with any degree of accuracy would be impossible using the in-world tools, and too risky to do with the LSL terraforming functions.
I’ve heard GIMP is capable of editing the RAW files, but the windows install doesn’t come with the required bits out of the box and I didn’t have the time to go tracking it down.
Backhoe runs ass-slow on the G3 iBook I have and didn’t appear to be suitable for terraforming 9 regions at once.
Photoshop seems to be slightly overkill editing terrain, and being a photo editing tool you have to know what you’re doing with the terrain editing or it’ll come out wrong (as my first couple of attempts did :-P )
The original specification
The specification for the RAW file runs into 13 channels some of which make sense (1 pixel per point on the height map), and others don’t (using an entire channel for water when SL currently supports the water table only, pixel per pixel parcel option toggling allowing for conflicting options per parcel). I can also think of very few situations where you’d want to have different baked terrain settings from the default ones- I made the mistake of selecting “revert” and screwing the terrain up :-s
The RAW file is also lacking the ability to set the parcel names, media settings etc.
Aside from the height map, all of the data to control the appearance of a region can be expressed in plain text. Since we’re combining plain text with binary data, and I’m wanting to get this idea adopted by Linden Lab, I’ve come up with a rough draft of a replacement spec that uses LLSD.
The Height map
Editing RAW files generally requires specialised software, or a special plugin for generic software, so for the most part, I’m doing away with RAW file support.
<key>heightfield</key> <map> <key>version</key> <real>2.0</real> <key>data</key> <uri>data:image/png,</uri> </map>
Unless I’ve missed something in the LLSD spec, the binary data type doesn’t allow you to state what kind of data is held, so I’ve taken advantage of the data: URI scheme to include pretty much whatever image format you wish, allowing for forwards compatibility for future versions of the spec and different data formats- a native height map could be specified instead of specifying an image (this would be useful if the terrain ever becomes more malleable- floating islands, caves etc- and a 2D image won’t suffice). To make it easier to read, I haven’t included any example PNG data.
For backwards compatibility, the binary data type should be used to specify a base64 encoded RAW file.
65,536 pixels for data that can only have one possible value ?
Yes, that’s right- even though regions can only currently have 1 water level- the water table level if you will- all 65,536 in the RAW channel for water can be used- using different values would obviously mess with the process
<key>water height</key> <real>253.0</real>
So now there’s only one value to specify the water table. This also allows for some interesting forwards compatibility. Hypothetically speaking, future versions of havok/Second Life in general would allow for physical water- lakes, waterfalls etc. the water height value can be used to specify the water table, and the blue levels in the terrain height map can be used to specify where water flows, allowing people to make under ground rivers, springs, lakes and waterfalls.
By specifying the water table in the LLSD file, this allows us to overcome the 255m cap on water levels.
<key>terraform limit</key> <map> <key>raise</key> <real>100.0</real> <key>lower</key> <real>-100.0</real> </map>
This chunk is pretty much ripped straight from the Region/Estate tools, so I won’t go into too much detail explaining what it’s for- only that it’s a value that should be added as a set-and-forget value if they’re borrowing someone else’s server for demonstration purposes.
I haven’t indicated this in the example document, but the sun key can either accept a boolean, real or uuid data type.
The boolean data type has a dual purpose: If it’s set to true, then this is the equivalent of enabling “Use Estate Sun”. If set to false, this is the equivalent of disabling both “Use Estate Sun” and “Fixed Sun”.
The real data type also has a dual purpose: If used instead of boolean, it sets “Use Estate Sun” to false and specifies the sun phase.
The uuid datatype specifies the UUID of the asset containing the WindLight settings, although it may be rather presumptuous of me to add this into the “spec”, it kinda makes sense. If WindLight settings won’t be made available as assets, then a uri data type should be used- probably specifying something along the lines of data:application/x-gzip, to allow for gzipped settings (and also allow for externally hosted windlight settings, allowing Residents with large estates to sync up the appearance of their regions in a similar manner to editing a single CSS file to change the design of an entire website)
Miscelaneous region settings
<key>terraform</key> <boolean /> <key>flight</key> <boolean /> <key>damage</key> <boolean /> <key>restrict pushing</key> <boolean>1</boolean> <key>allow land resell</key> <boolean /> <key>subdivision</key> <boolean /> <key>agent limit</key> <integer>40</integer> <key>object bonus</key> <real>1.0</real> <key>rating</key> <integer>0</integer> <key>scripts</key> <boolean>1</boolean> <key>collisions</key> <boolean>1</boolean> <key>physics</key> <boolean>1</boolean>
These options toggle the relevant options in the Region and Debug tabs of the Region/Estate window.
<key>textures</key> <array> <uuid>f3d0fbfb-db4c-c6f6-2c0a-5b896b226868</uuid> <uuid>f3d0fbfb-db4c-c6f6-2c0a-5b896b226868</uuid> <uuid>f3d0fbfb-db4c-c6f6-2c0a-5b896b226868</uuid> <uuid>f3d0fbfb-db4c-c6f6-2c0a-5b896b226868</uuid> </array> <key>sw</key> <array> <real>250.0</real> <real>250.0</real> </array> <key>nw</key> <array> <real>250.0</real> <real>250.0</real> </array> <key>se</key> <array> <real>250.0</real> <real>250.0</real> </array> <key>ne</key> <array> <real>250.0</real> <real>250.0</real> </array>
I’ve nabbed these values from the SL4B sim- again, it’s pretty much a verbatim representation of what’s in the Ground Textures tab.
Inclusion of parcel data
You’re quite limited with what you can do with regards to controlling parcels in the RAW file- you can’t automatically put virgin plots up for sale for instance.
Seperating parcel layout
I’ve seperated parcel layout into it’s own image for two reasons:
- It allows SVG to be used as a data format to control the shape of parcels.
- It allows estate managers to control the colour that is used to indicate the owner when in terraforming mode.
<key>parcel layout</key> <uri>data:image/png,</uri>
As with the RAW file, parcels are specified by their colour in the image. This allows non-contiguous parcels to be created- e.g. seperate regions in the image with the same colour.
<key>parcels</key> <array> <map> <key>parcel</key> <integer>0xffcc66</integer>
Each key/integer pair refers to the colour of an area in the parcel layout image. Not sure if LLSD allows hex input for integers, but that’s fairly easy to fix.
If you’re familiar with LLSD and the About Land window, this section is pretty much self explanatory- booleans are used for check boxes for the relevant key option, access and ban lists consist of an array of uuids. You might notice I changed “agent” to Resident in certain places.
Well that’s about it, I’m going to hold off a while to wait for feedback on this before making filing it in JIRA. Any questions/comments/suggestions, leave a comment!
Oh, and if I’ve borked the comments form, IM me in-world.