Support for generative art projects

[lifofifoX]

Letting NFOs specify variables (vs just referring to traits defined in the base inscription) would open up tons of possibilities to extend this standard for generative art projects.

I deployed a proof of concept collection called Ordrain to demonstrate this. Here's how it works:

Deploy inscription

Deploy inscription includes a new key - variables. This key includes delimiters, which is needed for renderers to substitute the generated output with the variable values specified in NFOs.

This gist shows an example a deploy inscription and the HTML file used for the template trait.
https://gist.github.com/devords/2bba6864cc381357cad97493b4379ee7

{
  "p": "gen-brc-721",
  "op": "deploy",
  ...
  "variables": {
    "delimiters": [ "{{", "}}" ]
  }
}

The relevant part in the HTML is this:

setInterval(draw, 50, "{{seed}}".split(""), {{colors}})

Here, seed and colors are variables. Renderer would be responsible for replacing these with the values from the NFOs, using delimiters and variable key names.

This deploy inscription is live as inscription acc42e0037ab499c8eb8073ac5cebb151aeffa2b6071ee92b093facb8fb6aea4i0 - https://ordinals.com/content/acc42e0037ab499c8eb8073ac5cebb151aeffa2b6071ee92b093facb8fb6aea4i0

Mint inscription

In addition to the standard values required by the GBRC721 , this proposal adds a new key for variable values -v.

{
  "p": "gen-brc-721",
  "op": "mint",
  "s": "ordrain",
  "t_ins": [ "acc42e0037ab499c8eb8073ac5cebb151aeffa2b6071ee92b093facb8fb6aea4i0" ],
  "id": "0",
  "a": [ [ 0, "template" ] ],
  "v": {
    "seed": "Satoshi",
    "colors": "[\"#5667a2\",\"#f99746\",\"#b482e6\",\"#8ebead\",\"#c2b07d\",\"#df0174\"]",
    "fontSize": "10",
    "transparency": "0.06"
  }
}

This mint inscription includes 4 variables inside the key v - seed, colors,fontSize and transparency. Renderer is now responsible for substituting these values in the generated output.

This deploy inscription is live as inscription cf2fb873636b5a92b3083dc39fd83d4a415664d347e6910ce2e964471762687ci0 - https://ordinals.com/content/cf2fb873636b5a92b3083dc39fd83d4a415664d347e6910ce2e964471762687ci0

Demo

A basic implementation of a renderer is available on gist at https://gist.github.com/devords/3039aecd004a5d3b6ca8e1d82e1d7ef6

Here's the function that does the string replacement:

function replaceVariables(body, t_vars, variables) {
  let result = body

  for(const key in variables) {
    result = result.replaceAll(`${t_vars.delimiters[0]}${key}${t_vars.delimiters[1]}`, variables[key])
  }

  return result
}

You can try it out via https://htmlpreview.github.io/?https://gist.githubusercontent.com/devords/3039aecd004a5d3b6ca8e1d82e1d7ef6/raw/0f9968aecc241b9ea2008fd14c891f5832deba6b/preview.html with NFO inscription cf2fb873636b5a92b3083dc39fd83d4a415664d347e6910ce2e964471762687ci0

Questions and concerns

1. This introduces another responsibility for the renderer, which may not be desired.
2. Using plain text strings vs base64. As base64 standard is primarily for binary files, using plain old strings works better. It might be worth considering adding string support for specifying traits as well.

I primarily wanted to open this up for a discussion here. One of the main reasons there aren't any large generative art projects on Ordinals is because they require a large amount of javascript to generate the artwork. Widely used libraries like p5.js can be up to 80kb in size. Including that in every ordinal in the collection is very cost prohibitive. But a standard like this, with support from major explorers and marketplaces, can open up tons of possibilities.

[russanto]

I think widening the applicability of the standard may encourage its adoption. However I have some considerations about the relationship of variables with traits. The benefit of this proposal would be that given an already deployed renderer, each collectible can specify how it should be rendered. Aren't traits the ones specifying how a generated asset looks like ?

In that case, with the aim to reuse already deployed renderers, I think the proposal is still valid, but can't such variables go in the traits definitions ? So there is no need to repeat them for each item and the renderer has the exact same information. In practice, variables provide a conventional way to explain to renderers how to visualize the digital art.

I have a second point. Are renderers unique ? I mean, if renderers are already on-chain and reusable, as a collection creator I may want to render my collection for more than one of them. Then, using variable as the gateway to translate traits to renderers, I may want to provide several traits-to-variable mappings. Maybe several can be embedded in the traits definition.

Third point. If we allow to have several traits-to-variable mapping, why restrict them to the deploy inscription ? The collection creator may want to release more than one in a roadmap, or the community can provide some, or new renderers may come to live and the collection could be rendered there, too. So, I would provide a way to have such mapping externally from the deploy inscription so that any can be added and used, in a standard way, by anyone. In this case we should provide a format for such trait-to-variables inscription.

[offerT]

ordinals/ord#2167 (comment)
Look at this, its update has made it possible to chain up p5.js. We look forward to your release of better testing projects. I minted some orderrain to show support

[offerT]

And I hope the new protocol is still called gen-brc-721,more well-known