a basic explanation of how spore actually stores the creation data in the creation pngs. information comes from this post http://www.rouli.net/2008/08/spores-png-format-illustrated.html, as well as kade on the spore modding community discord
first thing is that creation data is stored in an xml, that defines the creation parts, part scales and morph handles and such, and some other stuff like the creation type and colors. you can see it clearly with kade's png tool
the game compresses this xml data (usually to below 8192 bits), gives it a crc and then pads out the data with zeroes to make it 8192 bits long
also, before the creation xml data, it stores metadata about the creation (which you can see in the asset tool in the png raw data tab, as well as in the png metadata tab), such as its name, author name etc. here is that for alderbrook
then it uses the actual render of the creature as an encryption key, which ensures that the creation render will more or less correspond to the actual creature (though you can also encode creation data in a totally blank png)
the way it creates the creature render is roughly the same thing they used during development to make part thumbnails, paint thumbnails, and planner thumbnails, though those usually dont have creation data stored in them (with the exception of the cell paints in the feb 19 build). most of them are also 128x128, though it also creates 256x256 creation thumbnails with no creation data stored in them (mostly used on the spore website, but for some reason also stored in the game files in EditorSaves.package)
anyway, then it takes the actual creation png and puts the encrypted model bits in there. its a bit confusing, but kade said that it takes the color value of every pixel and encodes the data in there by making every rgba value either even or odd. it makes very little visible effect on the actual creation png and they still manage to store the data in there!
you can see that the rgba values vary by only 1 on any seemingly totally transparent background, and how it manages to store that in areas with color
i will say this post is a little old and uncertain about some things, but you get the gist here
another thing is that the information in pixels is read in bgra order, instead of rgba; this is an image kade shared
so in a sense this is what the game actually "sees" out of the png. kinda interesting
anyway the way the game stores the data explains the noise you can see in the transparency somewhat. you can see the transparent checkerboard easier on dark colors especially
shown with increased contrast on alderbrook
apparently the png format is totally different for adventure pngs, as it doesnt use the image itself to encode any of the information (you can open a transparent adventure png, use the magic wand anywhere on the background and there wont be any of the expected noise). im not sure how this works!
i believe its something to do with actual metadata in the file, which, for example, discord completely strips so you cant just share adventure pngs on discord and expect them to work. something like that??
it possibly also has something to do with the fact that there are long known tools to create custom adventure thumbnails, with graphics that wouldnt otherwse be possible with the normal screenshot tools. i have one saved that puts a note graphic onto the adventure thumbnail, for example
kaledo-art
turnnoffyourmind
blakekathryn
