Managing NFT Attributes in Processing

Notebook 3 Minutes

I made it through eight months of working on generative art before I realized that there’s a HUGE part of NFTs that I was missing… attributes[]. Shoot! What a bummer! Nevermind that when I came over from PHP/js only experience I wasn’t using arrays or array lists in Processing. The FIRST THING I should have done was figure out how to track and store attribute data in my work. Well, that’s how I feel now. The journey’s really been about figuring out how to art with code. This would have been a “smarter” way to go about managing the variability/variety/permutations in my art from the get go.

Yes. Attributes are an important part of NFT listings and series–particularly in the generative space. (Looking at you, objkt.io >:-O.) But managing variability is an important part of the generative art process as it stands. Either way, managing attributes/variety can only help improve how you develop and work on your generative art piece.

Screenshot of early project code

When I Started…

my first project I was thinking about a general theme, but also about how I could make things different about each iteration of the algorithm. These days I use my sketch book to write down my initial ideas, but originally I actually used a spreadsheet to track all the different elements of the piece that I wanted to be different. I’m a spreadsheet person, so I actually built out most of the initial variability and modeled it in the spreadsheet.

I took that spreadsheet and started initializing variables, calculating derivative variables, etc. (As you can see above, I wanted to make similar colors that were still pretty random.) While the project progressed I added more and more features and functionality to the program. By the end of it (actually, eight months later when I started using that project to figure out how to mint NFTs) I realized I had no idea which of the variables in this (80 lines of code) mess were key to the variability of the art. Enter my new framework.

From Now On…

I figure we can skip the “How I Dug Attributes Out of My Processing Code” post and go straight to the point. Attributes have the following consistent format in the NFT world:

//array of attributes, stored inside the IPFS JSON metadata:
{
  "attributes": [
    {
      "name": "attribute",
      "value": "some value"
     },
    {
      "name": "integer attribute",
      "value": 4
    }
  ]
}

Hooray for code blocks! One thing: Open Sea uses “trait_type” and OBJKT uses “name”. Until I get to where I feel like I can burn ETH on gas, I’ll be working with XTZ and sticking to “name”.

While Java lets you do things like use a Map object and HashMap, the way that feels the best to me is this (I’ll try to update it if/when this changes and I’m open to feedback! [mayChange]):

1. I create an attributes ArrayList with the type JSONObject.

ArrayLIst<JSONObject> attributes;

2. In Processing I can write two functions that can package the attribute JSON and add it to the ArrayList like this:

void addStringAttribute(String name, String value) {
  JSONObject tempJSON = new JSONObject();
  tempJSON.setString("name",name);
  tempJSON.setString("value",value);
  attributes.add(tempJSON);
}

The tempJSON object this creates then looks something like this:

{
  "name": "attribute_name",
  "value": "attribute_value"
}

3. When I set a variable that will be a project attribute (is key to the variability of the piece), I call my functions to add those strings/integers to the JSONObject array list.

addStringAttribute("attribute_name", attribute);
addIntAttribute("attrubute_name",attribute);

I’m sure this seems pretty simple to the old-hands in art on chain generative art. But this was a great opportunity to push myself into thinking more clearly about NFT attribute management and NFT attribute storage.

Published by adam

Published