Redesigning Region Management- RAW files are a pain in the ass

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.

Tools available.

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

Backhoe runs ass-slow on the G3 iBook I have and didn’t appear to be suitable for terraforming 9 regions at once.

Photoshop

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.

My suggestion

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.

Just a quick note- anything that refers to the PG/Mature ratings system is an integer data type; 0 for PG, 1 for Mature, and presumably 2 for Adult.

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.

Terraforming limits

<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.

Sun Values

<key>sun</key>
	<boolean>1</boolean>

I haven’t indicated this in the example document, but the sun key can either accept a boolean, real or uuid data type.

boolean

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”.

real

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.

uuid

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.

Terrain Textures


<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:

  1. It allows SVG to be used as a data format to control the shape of parcels.
  2. 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>

Organising Parcels

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.

Parcel Settings

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.

</end rant>

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.

This entry was posted in How Marv would fix Second Life, Regions, Second Life's 4th Birthday and tagged , , , , , , , . Bookmark the permalink.

3 Responses to Redesigning Region Management- RAW files are a pain in the ass

  1. SignpostMarv Martin says:

    In discussing the PNG/SVG issue with Gwyn, it seems that SVG would probably be more human readable (this parcel is this shape and goes there), but PNG and other binary image formats would probably be more machine readable.

    I’m not aware of how the parcels are calculated internally, but I’m going to guess that using binary image formats will be easier to use in the short-term.

    Also, because parcels are limited to a minimum size of 4m by 4m, images for parcel layouts should be 64 by 64 pixels.

  2. I seriously suspect that LL really uses 256×256 bitmaps internally…

  3. Pingback: SignpostMarv’s SL Blog » Things that are broken about Second Life and how Marv would fix them

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>