Sigil source data

[casey]

This is sort of a follow-up to #64. I've been working with sigils, and a lot of what I'd like to do requires a higher-level data model of sigils, above that present in the JSON source data.

The JSON source data mirrors the SVGs, and so it's very low level. I was wondering if it would be possible to release, in some form, really any form, the higher level algorithm/data that generated the sigils.

In particular, I'm looking for ways to understand the repeated components that sigils are composed of, and where they appear in other sigils. This is hard to do from the JSON SVG-model data, because I'm interested in things like "Which visual components appear in this sigil?" which is hard from the SVG-model data, but would be easy with higher level "semantic" data about the components that comprise each tile.

[tylershuster]

The sigil components aren't algorithmically generated. Someone from tlon may have contradicting information but from what I remember each sigil component is a unique "sigil" (in the literal sense as a meaning-making shape, but without the pictographic aspects of classic sigils like the ones you're reading now) and not somehow deterministically derived from the underlying number. In other words, the association between number and image is purely arbitrary.

Furthermore, sigils are essentially a tlon "product" albeit open-source. Anyone else could come up with another mapping of base-256-number to image and it would be just as legitimate as these sigils. These are just the ones that get used in tlon products.

[casey]

Sorry if I wasn't clear, let me try to rephrase it:

The sigil tiles aren't deterministically generated. However, from my understanding, they are the product of an algorithm that randomly combined pre-defined components (background shape, lines, dots, etcetera). Then, tiles that were output from this algorithm were manually selected.

What I'm interested in would be the list of predefined components for each sigil. Let's take nem, for example. nem looks like this in index.json:

"nem": {
  "children": [
    {
      "name": "circle",
      "attributes": {
        "cx": "64",
        "cy": "64",
        "r": "64",
        "fill": "@FG",
        "stroke": "@BG",
        "stroke-width": "0.5",
        "dataisgeon": "true"
      },
      "children": []
    },
    {
      "name": "path",
      "attributes": {
        "d": "M-0.00292969 0L127.997 128",
        "stroke": "@BG",
        "stroke-linecap": "square",
        "fill": "none"
      },
      "children": []
    },
    {
      "name": "path",
      "attributes": {
        "d": "M128 64C92.6538 64 64 92.6538 64 128",
        "stroke": "@BG",
        "fill": "none"
      },
      "children": []
    },
    {
      "name": "circle",
      "attributes": {
        "cx": "32",
        "cy": "32",
        "r": "11.5",
        "fill": "@FG",
        "stroke": "@FG"
      },
      "children": []
    },
    {
      "name": "circle",
      "attributes": {
        "cx": "32",
        "cy": "32",
        "r": "9",
        "fill": "@BG",
        "stroke": "@BG",
        "stroke-width": "2"
      },
      "children": []
    }
  ],
  "name": "g",
  "attributes": {
    "fill": "none"
  }
},

What I would be interested in would be a more concise definition based on the repeated components, which might look something like:

nem:
  background: circle
  components:
  - diagonal-line:
    orientation: 1
  - quarter-circle:
    orientation: 3
  - dot:
    position: 5

I know that this might not exist in the form that I'm imagining, and if it doesn't, I was hoping for something closer to the source data, from which I might be able to derive more easily the latter representation.

[galenwp]

@g-a-v-i-n is out this week, but he's the one who can give you more thorough information

[g-a-v-i-n]

The higher level algorithm probably doesn't make sense to you (or anyone) because I decided how all 512 base symbols should look, more or less randomly based on whether or not I thought they looked good. I found it too difficult to 'deterministically' use the phoneme characters to compose interesting looking symbols. Plus, I couldn't rule out that something might need to change, and I didn't want to over-constrain things. But that was back in 2018.

Here are the SVG source files. Representing data like you describe might be a little bit of a chore but it would certainly be more elegant.

https://www.figma.com/community/file/994378786117836789/Sigils%3A-Symbols

It would certainly make the library smaller. One reason I decided not to do this is because the js is delivered to the client in a gzipped state, and it's likely gzip makes the large lib size not such a large problem - https://bundlephobia.com/package/@tlon/sigil-js@1.4.3

Maybe it is still too big.

And just to +1 Tyler's point - there were tons of ideas for sigils so while this is the version we went forward with, there really are infinite ways to make generative/procedural avatars.