Ik doe mijn werk, en op één van de andere monitors is iemand voor mij aan het werken aan mijn ideeën. Hoe gemakkelijk is dat niet zeg?

Dan wil ik een meer realistisch bos dan wat ik had, en dus bedenk ik maar dat we een simulatie moeten doen van bomen die groeien en neervallen en ruimte laten voor andere bomen en dan wordt dat zoiets:

Bedenk ik dat procedureel gegenereerde bomen wil, maak ik dan maar in Blender een catalogus van een reeks gestileerde bomen ter inspiratie:

Moet dat allemaal nog real-time werken ook, en moet dat allemaal gereviewed worden:

En ja natuurlijk gaat dat om de zoveel tijd helemaal om zeep, en zou het dat veel minder doen als ik er veel meer aandacht aan zou schenken — maar ’t is bijna een soort meditatieve screensaver, hoe het nu werkt.

Ik wéét dat het allemaal godgeklaagd schandalig is hoeveel energie het zuipt en hoe erg het eigenlijk één grote plagiaatmachine is en hoe mijn geld alleen maar de verkeerde mensen het nog gemakkelijker maakt om drones aan te sturen om onschuldige kinderen plat te bombarderen, maar het is zo wijs om dit soort dingen te zien als ik een uur ergens anders mee bezig was:

Michel’s pushing back harder than just trunk thickness — he’s saying the trees don’t read as realistic at all, which ties back to the earlier open item about remodeling them later for that elegant 2026-grade isometric look instead of the flat voxel blobs that look like floating cubes rather than foliage. It seems like now’s the time to actually address that.

The right move is probably to actually attempt the remodel now: replace the faceted crown blocks with irregular, smaller, overlapping lobes that read more like foliage, with visible branch structure and better silhouette, while staying mindful of the triangle budget from the 100-tree stress test. Since he’s away, I should just build an improved crown geometry in TreeGrower, regenerate shots, and present before/after for his eye — though I’m weighing whether a fuller remodel should instead draw from the richer Blender vegetation study script rather than the decimated runtime port.

The blockiness traces back to the crown blob being a literal skewed box, so I want to replace that 4-vert prism with a deformed icosahedron-like lobe with heavy vertex jitter, use more smaller lobes per crown for an organic silhouette, and bend normals toward sphere-like directions from the crown center to avoid the hard cube-facet shading.

Triangle cost roughly doubles or triples with this approach, but that’s likely acceptable given chunk build times dominate runtime cost — I should check grow_vegetation.py to confirm how lobes are currently generated before making changes.

My plan: reply acknowledging the trunk width fix and the realism critique, then rework crown geometry with irregular lobe primitives and sphere-normal shading across broadleaf, fir, and willow types, rerun the wood shots, and also reconsider whether the autumn color mix is contributing to the unrealistic look.…
The blocky crowns are the real issue, not trunk width — I’ll tackle the deeper tree remodel now by replacing the box crown primitive with irregular multi-lobed geometry and softer shading in the runtime grower. First I’ll check how the full Blender study handles crowns, since the runtime grower is a decimated port of it.

Comparing the two oak versions, I can see the study’s strength comes from using many small blocks with varied per-face coloring rather than the game’s few oversized uniform blobs, plus a visible branch scaffold connecting trunk to foliage that the game version lacks entirely.

The game’s sparse blobs trace back to a triangle budget decision that decimated the crown too aggressively — I’m now thinking the fix is spending more triangles on smaller, more numerous blobs, maybe scaling from ~25 blobs (300 tris) up to 60-100 blobs (~1200 tris) per veteran tree. But I need to weigh this against the measured 14ms+ chunk build time, since quadrupling leaf triangle count could push build costs significantly higher depending on how chunk building is scheduled and whether it runs async.

I also want to track down the color variation issue — the flat, uniform look in-game versus the varied greens in the study reference likely comes from a combination of flat shading under different normals plus multiple leaf materials across blobs, but the real culprit is probably just the oversized block scale. My plan is to shrink and multiply the lobes substantially (veteran fill from 11 to around 40, with smaller sprays) while keeping the skewed-box primitive shape intact.…
The study oak works because it has many small faceted lobes with visible branch structure between them, while the runtime port failed by scaling blocks up ~10x into giant cubes that read as boxes, not foliage — the fix is more, smaller lobes rather than bigger ones. Before rebalancing, I’ll check the chunk-build time budget behind the 14+3 ms measurement.

Enzoverder, enzovoorts. Heerlijk.

Gruwelijk vies ook, maar ook heerlijk. Een kinderdroom gaat in vervulling.