Wind-Rigged Tree

A wind-rigged tree is a tree grown by code from one starting number, the seed, with leaves on its outer branches. Wind bends each branch at its base, and smaller branches follow the bigger ones, so a bend at the trunk carries the whole crown. Stronger wind moves it further, never faster, so nothing whips.

Also called: Procedural tree in wind, Hierarchical tree sway, Branch rig for wind.

A huge tree on a grassy sea cliff bends hard in a gale, its red leaves streaming far across a teal storm sky while a tiny figure in blue leans into the wind. — Galebough, an invented coastal exploration game. Invented game, image generated with AI.

Paste this to your AI

Copy it into Claude, Cursor or ChatGPT. It already has good values and the usual mistakes in it.

Add "Wind-Rigged Tree" to my game.

What it should do: Trees that move like trees: the trunk sways, the crown follows and twigs tremble. The game works out the movement as it runs, so it needs no ready-made animation, and the tree stays small enough for that.

Use these starting values:
- seed: 7
- trunkLength: 70 units
- trunkWidth: 11 units
- maxDepth: 6
- minLength: 5 units
- lengthScale: 0.7
- widthScale: 0.64
- spread: 0.6
- roots: 4
- leafDensity: 0.6
- leafDepth: 2
- stiffness: 0.0035
- breath: 0.35
- swayRate: 0.45
- gustRate: 0.38

Watch out for these common mistakes:
- The tree whips when the wind changes: Tell your AI: keep the pace of the movement fixed. Wind strength only changes how far the tree moves.
- A trunk that bends like a twig: Tell your AI: let branches bend more the further out they are and less the thicker they are, so the thin outer branches give the most.
- Roots that follow the trunk: Tell your AI: attach roots at the foot of the tree, facing the way the trunk points at rest, and do not let them bend.
- Too many branches: Tell your AI: update the trees less often than the picture, skip trees out of view, and first reduce how often they fork.

Do not change anything else in the game. Do not claim anything without proof: model what it takes, and show me what your solution rests on and how I can see that it works. If you cannot show something, say you do not know. When you are done, tell me in plain words how to try it.

Or skip this and connect the MCP: your AI then finds all of this by itself.Connect the MCP

What it does

Trees that move like trees: the trunk sways, the crown follows and twigs tremble. The game works out the movement as it runs, so it needs no ready-made animation, and the tree stays small enough for that.

Good starting values

Value	Start with	What it changes
seed	7	Picks the tree. The same seed always grows the same tree.
trunkLength	70 units	The size of the whole tree, since every branch takes its size from the trunk.
trunkWidth	11 units	How thick the trunk is at its foot. That sets how thick every branch is, and so how far it bends.
maxDepth	6	How many times the tree forks from the trunk to the outermost twigs. Each extra level means many more branches.
minLength	5 units	Branches shorter than this stop forking.
lengthScale	0.7	How much of its parent's length a branch keeps. That sets how wide the crown spreads.
widthScale	0.64	How much of its parent's thickness a branch keeps.
spread	0.6	How far the arms of a fork open, in radians.
roots	4	How many roots run out from the foot of the tree.
leafDensity	0.6	How many leaves grow per unit of branch length.
leafDepth	2	The first fork level that has leaves, so the trunk and thick branches stay bare.
stiffness	0.0035	How far a branch bends when the wind pulls on it, in radians. Higher makes the whole tree looser.
breath	0.35	How much the tree still sways with no wind, so a calm tree does not freeze.
swayRate	0.45	How fast the slow sway goes, in radians per second.
gustRate	0.38	How fast a gust travels through the tree, in radians per second.

What usually goes wrong

The tree whips when the wind changes

If wind strength also changes the pace of the movement, every change of wind throws all the branches out of step at once, and the tree whips around.

Fix: Tell your AI: keep the pace of the movement fixed. Wind strength only changes how far the tree moves.

A trunk that bends like a twig

With the same bendiness for all branches, the trunk rocks like a reed, or the twigs stand stiff.

Fix: Tell your AI: let branches bend more the further out they are and less the thicker they are, so the thin outer branches give the most.

Roots that follow the trunk

A root attached to the trunk like any branch bends with the trunk, so the ground seems to move.

Fix: Tell your AI: attach roots at the foot of the tree, facing the way the trunk points at rest, and do not let them bend.

Too many branches

Each fork level multiplies the branches, and a whole forest slows the game down.

Fix: Tell your AI: update the trees less often than the picture, skip trees out of view, and first reduce how often they fork.

How to check it works

Pick any seed. Ask the AI to grow the tree twice with its leaves, then once with another seed: The two trees with the same seed are the same, and the other seed gives another tree.
A grown tree. Ask the AI to show you any branch next to its parent: It is one fork further out, no thicker and shorter.
A tree with leaves. Look at any leaf: It sits on a branch at the set fork level or further out, and never on a root.
A tree where only the trunk bends. Ask the AI to show you that: The next branch stays on the tip of the trunk and has moved and turned with it.
A tree where only one twig bends. Ask the AI to show you that: Only that twig and what hangs on it have moved.
A tree in full wind. Watch it for a while: The outer branches move further than the trunk.
A grown tree. Turn the wind up full: Every root stands exactly as it does at rest.
Three wind strengths. Ask the AI to show you the sway at the moments it passes through the middle: The sway is at the middle in all three.
A tree with no wind and the calm sway turned on. Watch it: It moves a little from rest, and there is no gust.
No wind, and the calm sway turned off. Look at the tree at any moment: It stands exactly in its rest pose.

Common questions

what do i tell my ai to make trees move in the wind

Paste this: Build the tree from branches that each know their parent. Move parents first, bend every branch at its base, more towards the twigs, and start it from where its parent is now. Wind strength only changes how far it moves, never the pace.

why do my trees whip when the wind changes

Wind strength is probably changing the pace of the movement, so every change throws all the branches out of step at once. Tell your AI to keep the pace fixed and let wind strength change only how far the tree moves.

should each branch sway on its own

Each bends a little on its own, but it has to start from where its parent is. Otherwise branches slide along the trunk instead of being carried by it.

how do leaves follow branches

A leaf remembers its branch, a point along it and a distance to the side. Its place is worked out from the branch every frame, so it rides along without keeping anything of its own.

Where it comes from

Earliest example we could find: Mikio Shinya and Alain Fournier, "Stochastic Motion—Motion Under the Influence of Wind", Computer Graphics Forum 11(3), pp. 119-128 (Eurographics '92) (1992). Earliest documented wind-driven motion model for tree geometry found in this search. Wind is a stochastic velocity field that feeds a dynamic response stage, which drives a deformation stage applied to the object's geometric model. This covers the wind half of the mechanic only. Just the abstract and later papers' descriptions could be read, so parent-to-child pose inheritance is not confirmed for this work. For the full combination of parts, see the 1995 event.

1992 Mikio Shinya and Alain Fournier, "Stochastic Motion—Motion Under the Influence of Wind", Computer Graphics Forum 11(3), pp. 119-128 (Eurographics '92): Earliest documented wind-driven motion model for tree geometry found in this search. Wind is a stochastic velocity field that feeds a dynamic response stage, which drives a deformation stage applied to the object's geometric model. This covers the wind half of the mechanic only. Just the abstract and later papers' descriptions could be read, so parent-to-child pose inheritance is not confirmed for this work. For the full combination of parts, see the 1995 event. [OpenAlex record with abstract: Stochastic Motion—Motion Under the Influence of Wind][Stam, Stochastic Dynamics (1997), which compares itself to this work and cites it]
1995 Jason Weber and Joseph Penn, "Creation and Rendering of Realistic Trees", SIGGRAPH 95, pp. 119-128: Earliest documented single source found here that joins all parts of this entry, and it was read in full. Stems are generated recursively from parameters, with each child defined relative to its parent. Leaves form the last recursion level, and their density favours the outside of the tree. Section 4.7 adds wind as time-varying rotations between stem segments, and keeping the random seed fixed preserves the tree's identity while its pose changes. The geometry is rebuilt every frame, so children following their parent is a consequence of this construction; the paper does not say so in those words. Bending is spread along each stem's segments rather than applied as one rotation at the base. [Weber and Penn, Creation and Rendering of Realistic Trees (full text, course copy at Duke)][ACM SIGGRAPH History Archives record for the paper]
1997 Jos Stam, "Stochastic Dynamics: Simulating the Effects of Turbulence on Flexible Structures", Eurographics '97, Volume 16 (1997), Number 3: Treats branch motion as a random process. A modal analysis of a tree built from branch elements shapes filtered noise in the Fourier domain, so motion is synthesized directly with no time integration of the dynamics. This reaches swaying branches by another route: branches are coupled through global matrices rather than posed along a parent chain at runtime. Stam sets aside the generation of tree geometry as already covered by others. [Stam, Stochastic Dynamics (author-hosted PDF)]
2003 Shin Ota, Machiko Tamura, Kunihiko Fujita, Tadahiro Fujimoto, Kazunobu Muraoka and Norishige Chiba, "1/fβ noise-based real-time animation of trees swaying in wind fields", Computer Graphics International 2003, pp. 52-59; related journal paper "A hybrid method for real-time animation of trees swaying in wind fields", The Visual Computer 20, pp. 613-623 (2004): Brings tree sway to real time by driving leaves and branches with 1/f^β noise, with a simple spring model added for branches. Both abstracts include the motion of individual leaves. Only abstracts could be read, and they do not say how branch poses are chained. Zioma's 2007 chapter cites the 2003 paper. [Index record with abstract for the Computer Graphics International 2003 paper][Springer abstract page for the 2004 The Visual Computer paper]
2007 Renaldas Zioma, "GPU-Generated Procedural Wind Animations for Trees" (chapter 6), and Tiago Sousa, "Vegetation Procedural Animation and Shading in Crysis" (chapter 16), GPU Gems 3: Zioma's chapter is the closest documented match to this entry's rig: a shallow hierarchy of rigid branches, each rotating at the joint to its parent, where a vertex's final rotation is the concatenation of the rotations along its branch path. The goal is visual plausibility rather than physical accuracy. Sousa's chapter records a cheaper production alternative from Crysis: per-vertex displacement for overall bending and for leaf detail. That chapter's text does not describe a branch hierarchy. The year comes from the reference list of Habel et al. 2009, because the NVIDIA pages show no date. [GPU Gems 3, Chapter 6: GPU-Generated Procedural Wind Animations for Trees][GPU Gems 3, Chapter 16: Vegetation Procedural Animation and Shading in Crysis][Habel et al. 2009, draft PDF, used here for the dated references to both chapters]
2009 Ralf Habel, Alexander Kusternig and Michael Wimmer, "Physically Guided Animation of Trees", Computer Graphics Forum 28(2), pp. 523-532 (Eurographics 2009): Replaces skeletal animation with what the paper calls hierarchical vertex displacement. Each vertex can reach its branch hierarchy data, so the deformations of all parent branches run in the vertex shader, from the trunk down to the vertex's own level, with nothing propagated at runtime. Leaves count as part of the last hierarchy level and take on every parent deformation, with flutter added on top. Branch response to wind comes from a precomputed 2D motion texture. This is the clearest source read here for leaves riding along with parent branches. [Habel et al., Physically Guided Animation of Trees (authors' draft PDF)][TU Wien publication page for the paper]
2026 Heart of the Light: The game this entry's code was cleaned up from, by the project's owner, published under the MIT licence. Its lib/tree.ts grows a bare skeleton from a seed, sets leaves on the outer branches by code, and bends each branch about its base so that children and leaves ride along with the parent's pose. It is the origin of this particular implementation, not of the technique, which the earlier events document. [Heart of the Light (LegoFighter, GitHub repository)][Heart of the Light, MIT licence, copyright 2026]

1) Two different earliest points. The earliest documented work on wind-driven tree motion found here is Shinya and Fournier (1992), known only from its abstract and from later papers. The earliest documented single source found for the whole combination (seeded procedural skeleton, leaves placed by code, wind applied as rotations between stem segments) is Weber and Penn (1995), read in full. The earliest documented point here is 1992, with that narrower scope; a reader who wants the full mechanic should use 1995. 2) Inheritance of parent pose. Explicit statements were found only from 2007 on: Zioma (rotations concatenated along traversed branches) and Habel et al. (leaves inherit all parent deformations). For Weber and Penn the ride-along is an inference from two stated facts: child axes are defined relative to the parent, and the whole tree is rebuilt each frame. For Shinya and Fournier it is unknown; Habel et al. describe that work only as using uniform-thickness beams for tree structures. 3) Claims made by sources. Stam calls Shinya and Fournier the closest model to his own and says their foliage work was improved by Weber and Penn; both are Stam's statements, not ours. Habel et al. group Ota et al., Zioma and Sousa as heuristic approaches that ignore tree physics, and place Shinya and Fournier among full simulations; that sorting is theirs. A text search of the full texts of Weber and Penn, Stam, Habel et al., Zioma and Sousa found no priority claim to being first. 4) Earlier work that could not be ruled in or out. Reeves and Blau (1985) mention trees and a field of grass blowing in the breeze in an abstract, which is an earlier vegetation-in-wind statement, but it concerns grass, gives no mechanism and does not describe moving trees. Oppenheimer (1986) has fractal trees with real-time parameter changes; its abstract does not mention wind and the full text could not be opened. Nothing older than 1992 on wind and trees was found, but the search was limited and full texts from before 1992 were not available, so an earlier source may exist. 5) Procedural skeletons are older than this timeline. Weber and Penn discuss earlier tree models, and Stam points to de Reffye et al. and Prusinkiewicz for tree geometry. This entry does not trace that history. 6) Left out to stay within seven events. Diener et al. (2009): record confirmed, abstract only, a precomputed modal basis rather than a branch rig. SpeedTree: the wind documentation describes branches at each wind level swaying together with their descendants, which matches this mechanic in a commercial tool, but the page carries only a 2023 copyright and a version 9 reference, so it does not show when the feature appeared. 7) Dates. Crossref and OpenAlex date Shinya and Fournier to May 1992, while Stam's reference list gives September 1992; only the year is relied on. GPU Gems 3 is dated from Habel et al.'s references, not from the publisher. 8) Heart of the Light: the game's itch.io page refused automated access, so the event cites the public repository and its licence file instead. 9) Method. PDFs were opened with WebFetch, but its reader could not decode them, so the saved bytes were converted with pdftotext. WebFetch's reader altered several sentences, so every quote below was checked against the raw page, PDF or API text. In the Weber and Penn quotes, the subscripts in sway_x and sway_y appear flattened as swayx and swayy, as in the extracted text. The OpenAlex abstracts are stored as word-position indexes and were rebuilt into plain text, so a reviewer opening those URLs sees the index, not a sentence.

Games are named only as references. Names and marks belong to their owners, and nothing here is endorsed by them.

What was checked

17 tests pass on the reference code.

This is what separates the blueprint from a catalogue entry: the values on this page come from code that runs.

Your AI gets the code

Tested example code comes through the Spielerando connection, so your AI can use it right away. How to connect it