[WIP] Using Lights to make any Image using only scripting

[Apjjm]

To answer your question I guess I can just go for the full explanation as to how the approach is done currently:

(Released Part) The decoder & Encoder
This stage, as described in the first post just encodes values according to an alphabet. The "tSize" parameter represents the size of a "token" used per uint (or no. of characters of the alphabet used per uint). For example, if I were to use the hex alphabet
"0123456789ABCDEF" and a tSize of 4, i'd be able to represent the numbers from "0000" to "FFFF". Each UINT will always be stored with a total tSize characters from the input alphabet so that it is actually possible to decode. Ints, Strings and Floats are just stored as UINTS with extra information / a different interpretation.

At this stage we have the decoder and encoder functions as linked in the top post. Ontop of this i have two unreleased c# applications:
Image converter:
This tool lets you load in an image and set a down-sampling factor. This is just a glorified shrinking algorithm - it takes the image, averages out the color of a square (dimensioned specified by the down-size factor) and outputs that as 1 pixel in the new image. It repeats until the new image is a downsized copy of the old one. This is necessary on larger images (but completely optional) to keep the light count under 10k (after which it becomes unbearably slow). To output this image ready for encoding the program will then convert the RGB components of the smaller image into one 32bit UINT:

Code: (Select All)

Bits 0-7: Red
Bits 8-15: Green
Bits 15-24: Blue
This is effectively a normal colour system without the alpha component.

And output a list of them as a file which the command-line encoder can take in. For the purposes of re-constructing the image, width and height are also exported as two UINTS at the top of the file. An Export Might look something like:

Code: (Select All)

U42  <--- Width
U42  <--- Height
U1234 <--- Pixel (0,0)
U0      <--- Pixel (0,1)
U234   <--- Pixel (0,2) etc...

Which is run through...

Command-line encoder:
This tool takes a file of the form

Code: (Select All)

<alphabet>
<tSize>
<Value 1>
<Value 2>
...
<Value n>

And outputs it as an encoded string. This is essentially the encoding routines as linked in the first post ported to c# so it can operate over a whole file and output the string into another. The image is now a string which can just be dumped into the source HPS file like "string x = <long thing representing image>;".

Decoding
Firstly, before any drawing occurs I decode the string into a 2D array of uints, since the first two values decoded by the string are width and height of the image, I use this to initialise the array. I then decode each set of "tSize" characters into the array.

Drawing:
At this stage I have a 2D array containing uints which contain the colours. To the draw the image I iterate through the array and use AddAttachedPropToProp to attach a custom variant of the "block_box" entity containing an additional box light called "light". This creates the light. I then decode the uint for this pixel into 3 floats for the color, and call FadeLightTo(boxname + "_light",...) to set it's color. The arguments for this function specify the width of the box light in the entity used to make box lights, amongst a host of other settings.

This works because I have a huge plane which intersects all the lights to give them something to illuminate in the editor. Each light is currently a standard 1x1x1 cube and drawn along XY (Y-Flipped) - but there is no reason why you couldn't change this.

There is no reason why you couldn't do something else with the pixel array - like compose several pictures together and then draw, or, have an array of pixel arrays for an animation. As i said, this i just an application of the encoding and decoding tools to make an image out of box lights. Unless you want it to output some kind of password (As part of a puzzle or as a save-state for episodic releases) or perform pixel based drawing and manipulation there isn't really much of a reason why you would use it for images.