Our goals can be broken down into answering three topics:
- What are NCA? How is NCA different from other NCA?
- What can NCA be used for? Does NCA provide an advantage over other similar architectures?
- How can NCA be improved?
As a result of answering these questions, we aim to produce a research paper.
All of our code for our website and for generating website content is open source and available here! There are two main parts:
- The Training Code: This produces the weights an biases of our neural network. All implemented in PyTorch. There will be multiple versions of this for various experiments.
- The Website: Models are rendered in WebGPU and JavaScript. Output is what you see in front of you!
- Learning WebGPU and creating a platform to share our work
- Built Conway's game of life
- Built Life-like CA, capable of taking input changing the behaviour of the CA
- Built Larger than Life, capable of creating coloured outputs
- Built Continuous, implementing convolutions and live-editable WebGPU code
- Built Growing Neural Cellular Automata
- Developed and trained model
- Ported model weights over to the website in readable format
- Implemented Growing Neural Cellular Automata on website
- Built the about page
- Created basic descriptions of Neural Cellular Automata
- Created advanced resources on Neural Cellular Automata
This project is currently using the Notion platform to document project progress and important information. This Notion workspace will be made public at a later point in time.
However, some useful resources for this project include:
- Understanding Cellular Automata (CA)
- Introduction to Conway's Game of Life
- Explaining CA
- What are "Life-Like" CAs
- Neural Cellular Automata
- Tutorials for Building CAs
- Other
- Noita uses CA to make physics simulation
- "Rule-String" Notation
- CAs and Computational Systems
- Emergent Gardens
- WebGPU Resources
More resources will be made available in this repo as the project progresses.
We will maintain at most 3 types of branches on the repository for this project. How each branch type will be used is detailed in dev cycles. Details on each branch type are elaborated here:
The branch that is always operational. It contains features that have been tested, are fully functional, and are ready to be seen by the public. As such, this branch is to be treated extremely carefully. Main will only branch to dev, and only dev will merge to main. The reason for this is so we can vet and check everything before anything goes up to main. Pushing straight to main should only be done never.
This is the branch that hold all things under development. Every time a feature is finished, it will be merged to dev. On dev we then have the chance to do bug fixing and benchmarking. We do all the necessary test to ensure the stuff we upload is genuinely ready.
These branches are where actual programming occurs. Create a feature branch from main, and name it accordingly. Try to keep it down to one feature per brach, so the git history will clearly outline our development process.
There is a lot of freedom in what you are allowed to do in this branch type, since everything will be vetted when you merge to dev, and more vetting will be done before merging to main. The principle is just try to keep things reasonable and clear.
This project will be done in "dev cycles". That's just an outline how we will conduct development and keep everything organised. The general progression of a dev cycle is as follows.
- Branch a new dev branch from main.
- Create feature branches from dev, and add your new features.
- Upon completion, feature branches merge back to dev.
- Bug testing on dev. These may occur as a result of feature integration.
- After bug testing (and more benchmarking maybe) is complete, Then Dev should be merged back to main.
- Dev is archived, and the Dev cycle is complete.