disclaimer: I've been crocheting for less than a week, so my experience is limited

I took a stab at transcribing this youtube video, and here's the result:

Mr. Tassev, have you ever considered making CrochetPARADE a video game?

I'm an indie game designer planning out a cozy life simulation game called Textisle, in which the core mechanic is a real-time, player-controlled crochet simulation. The player executes stitches one at a time using button inputs, and the fabric grows stitch by stitch as they work through a pattern. Players harvest and process fiber, spin it into yarn, then crochet and block wearable, usable, and giftable objects. The goal of the game is to introduce new people to the pleasure of crochet and to allow experienced crocheters to design quickly and without the expense of materials (like CrochetPARADE)! I have attached a simple UI wireframe demonstrating the idea. (Please forgive that the stitches in the upper bar don't make sense with continuing in the round; I wanted non-crocheters to be able visualize that it's pattern-based rather than just have a bunch of plus signs for the SCs.) When I posted it in crochet communities with the game idea, the overwhelming response was, "Where can I playtest this?" which was very exciting.

I found CrochetPARADE while researching and wanted to ask whether the graph.cpp layout algorithm could be adapted for real-time interactive use. My current prototype built in Godot 4 uses pre-made stitch mesh scenes placed on anchor points. It's a purely topological approach where stitch formation is recorded as data and geometry is constructed from known state rather than simulated physically. This works for the prototype, but I'm thinking ahead to what the fabric geometry system needs to look like at scale.

The documentation describes a weighted graph where nodes are stitch-level material points and edge weights encode stitch-scale distances, with geometry reconstructed via shortest-path distances and annealed gradient descent. Does the algorithm require the complete connectivity graph upfront, or can a new node and its edges be appended to an existing solved embedding and relaxed locally?  I'm an experienced crocheter but a beginner developer (my day job is in the legal field), so I'm sorry if my question is obvious or dumb. Any guidance would be appreciated. 

Thank you for building and open-sourcing this. It is so cool and I think I think wrapping it in a free-to-play game could bring it to people who would never find it otherwise!

Attached Files

Thumbnail(s)
   

I am building an English → DSL system for CrochetPARADE, and the first step of course is the dataset.

There is no dataset that pairs natural language instructions with DSL code. From a set of 5000 crochet instructions written in English I took ~300 amigurumi patterns and manually wrote DSL for a few of them, then built a few-shot prompt for Claude Opus to generate the rest. It works well when the new pattern is similar enough to what is in the prompt, but falls apart on anything outside that distribution.

So naturally I tried to add a RAG layer. But naive similarity-based retrieval alone doesn't do a good job here, because it retrieves whole patterns by overall similarity. If I am generating DSL for a bear, it pulls other DSL for bears. But if the bear has a crown, the retrieved examples have nothing useful about crowns, and the model fails on that part.
So I combined both: my original hand-picked few-shot prompt as a stable base, plus a few RAG-retrieved examples on top for whatever the target pattern looks like.
With this I generated the remaining 240 amigurumi patterns. It cost $60, but saved an enormous amount of time on dataset creation.

The problem is that I still have to traverse and fix every DSL file manually. The code compiles, but a lot of translations are imprecise. To handle this, every item in the dataset has a confidence level from 1 to 5, where 1 is "Low" and 5 is "High". This way I can use the high-confidence items immediately and fix the rest gradually in the background. The high-confidence items are the ones I have already checked and that are very close to the English instruction input.

The best results overall come from passing a full few-shot prompt alongside a small portion of a new pattern, like only an arm instruction or only a leg instruction. Opus generates highly reliable output this way, but the cost of generating the full dataset would inflate proportionally.

My next step is to reorganize the dataset into component-level smaller English → DSL examples, since smaller and more focused prompts tend to give more reliable results, and to downgrade from Claude Opus to something smaller and cheaper — for me as a solo developer, generating a dataset with Opus is prohibitively expensive. The ultimate goal of the project is a system that generates CrochetPARADE DSL from a natural-language prompt, not from a full crochet instruction.
I am quite new to this area, so please share your thoughts and ideas!
https://github.com/FrogTravel/CrochetPAR...mi_dataset

Attached Files

Thumbnail(s)
       

Is it possible to recover my pattern? I was working on it when the website froze and reloaded. My latest save was like over a hour ago and I saved it as a GLTF. I'm just started playing with the site today but a little google search doesn't show anyone else with this issue and the website doesn't seem to allow imports. It would suck to loose hours of work. Ty for yalls time.

I would like to start by saying thank you.
I came across your website yesterday, and the simulator is simply amazing.
I’m learning a lot and have already started working on a pattern that I’m currently crocheting.

Now for my question:
Which instruction should I use to close the magic ring?
The model I’m currently getting has an open ring.

I currently have this code:

If I use shorthand notation for repeated rows,

Hi,

I am working on a pattern were I need to stitch two separate components and then work in the round after stitching both together. I've done it in real life and it works really well, but I want to do it in CrochetPARADE to test the shape for the rest of the pattern.

This is my code:

#Instructions originally written in CrochetPARADE 1.0 language.
DEFtart_at=&start_at^A(start):B~A-B::!-skip-A;B-0.0001-A
DOT:inflate=2
ring.R
[6*sc]@R
[6*sc2inc]
[sc2inc,sc],[sc2inc,sc],[sc,sc@[2,4].Z[0],sc.Z[2]],[sc.Z[4],sc@[2,6],sc],[sc2inc,sc],[sc2inc,sc]
start_anew
[ch,[2*ch],ch.Z[3]],turn
[sc.Z[1],3sc],sc3inc,sc@[5,0],sc@[5,1],sc@[5,2],sc@[5,3].Z[5]

#Sewing together
COLOR:magenta
DEFs0=&ss0^:B~::B-0.180000-!
DEFs1=&ss1^A(ss2tog):B~A-B::!-1-A;B-0.180000-A
DEFs1start=&start_at^A(hidden):B~A-B::!-skip-A;B-0.180000-A

#Zips/Caps
(ss1start)@Z[0],(ss0)@Z[1]
(ss1start)@Z[2],(ss0)@Z[3]
(ss1start)@Z[4],(ss0)@Z[5]


I got the Zips code from your video on 3D Model to CrochetPARADE. I wanted to make the zips smaller or practically with a 0 length, but it causes errors. What do you recommend for joining the two pieces above?

Thanks in advance!

Attached Files

Thumbnail(s)
   

Hi All,

I added a new experimental tool to CrochetPARADE that tries to translate plain-English crochet instructions into CrochetPARADE code.

Warning: the generated code can very possibly be wrong even when the tool succeeds, so please check everything carefully. It should be treated as a rough draft, not as reliable output.

A few limitations:

-- it is not AI so it's success depends strongly on the exact phrasing
-- it assumes US crochet stitch names
-- some patterns or rows will fail
-- some will translate only partially
-- some may parse and still produce wrong CrochetPARADE code

So if you use it, use it on one pattern at a time, inspect the result, and use the Debug button when something looks suspicious.

Also, the proper reference for learning CrochetPARADE is still the manual and the examples in the drop-down menu on the main website. This translator is only a convenience feature and is not meant to replace those.

Still, even with these limitations, it may be useful as a starting point for producing a first draft from written crochet instructions.

Hi All,

I few of you have contacted me privately to ask about the internals of the physics engine. The documentation is here (you can also access it from the help menu on CrochetPARADE):

Physics engine algorithm

Periphery extraction


The initial documentation was generated automatically from the code. I then reviewed it for accuracy and added explanations to justify key algorithmic choices.