Mandelbrot Explorer: 80-bit x87 FPU, OpenMP Multithreading, and Smooth SSAA
https://redd.it/1rz2fmu
@proceduralgeneration
https://redd.it/1rz2fmu
@proceduralgeneration
This media is not supported in your browser
VIEW IN TELEGRAM
I added a Cloud and Atmosphere Simulation to my Procedural Planets
https://redd.it/1rz92hj
@proceduralgeneration
https://redd.it/1rz92hj
@proceduralgeneration
Procedurally generated voxel art
https://www.shadertoy.com/view/fc23WD
https://redd.it/1s6opy1
@proceduralgeneration
https://www.shadertoy.com/view/fc23WD
https://redd.it/1s6opy1
@proceduralgeneration
Help! I'm trying to simulate stars but can't figure it out
How can I generate positions of stars from a seed? I have a center position and seed but have no idea how ill get the actual positions. To avoid massive distances I thought of generating directions and compressed distances to avoid huge numbers being sent to my shader.
https://redd.it/1s6pa07
@proceduralgeneration
How can I generate positions of stars from a seed? I have a center position and seed but have no idea how ill get the actual positions. To avoid massive distances I thought of generating directions and compressed distances to avoid huge numbers being sent to my shader.
https://redd.it/1s6pa07
@proceduralgeneration
Reddit
From the proceduralgeneration community on Reddit
Explore this post and more from the proceduralgeneration community
Shipping indie tools taught me that “feature complete” is the wrong milestone
I’ve found the hardest part of shipping professional game dev tools as an indie isn’t the algorithm — it’s the *productization*.
When I was building a rule-based scatter system, the core idea was straightforward: biome zones, density modes, and HISM instancing. The real work was everything around that. A tool can be technically impressive and still feel unusable if it doesn’t survive real production pressure.
A few lessons that mattered a lot:
* **Make the first workflow dead simple.** If a user can’t get a result in minutes, they won’t trust the tool.
* **Ship presets, not just systems.** The difference between “here’s a scatter engine” and “here’s 10 built-in presets for common use cases” is huge.
* **Optimize for iteration speed.** I care less about a clever architecture than whether the artist can block out, adjust, and re-run without friction.
* **Document the edge cases.** The weird stuff is what breaks confidence: instancing limits, density conflicts, biome overlap, parameter interactions, etc.
* **Treat stability as a feature.** In production, “it usually works” is not good enough.
One thing I’ve learned the hard way: the best tools don’t just generate content, they reduce decision fatigue. If every parameter feels like a research project, you’ve already lost. The goal is to make the *default path* good enough that people only tweak when they need to.
That’s also why performance numbers matter, but only in context. Saying “100K+ instances per second” is nice; what really matters is whether that speed translates into a fast, confidence-building iteration loop for actual level work.
For indie toolmakers: what’s been harder for you — the underlying tech, or making the tool feel production-ready?
https://redd.it/1s6t7h9
@proceduralgeneration
I’ve found the hardest part of shipping professional game dev tools as an indie isn’t the algorithm — it’s the *productization*.
When I was building a rule-based scatter system, the core idea was straightforward: biome zones, density modes, and HISM instancing. The real work was everything around that. A tool can be technically impressive and still feel unusable if it doesn’t survive real production pressure.
A few lessons that mattered a lot:
* **Make the first workflow dead simple.** If a user can’t get a result in minutes, they won’t trust the tool.
* **Ship presets, not just systems.** The difference between “here’s a scatter engine” and “here’s 10 built-in presets for common use cases” is huge.
* **Optimize for iteration speed.** I care less about a clever architecture than whether the artist can block out, adjust, and re-run without friction.
* **Document the edge cases.** The weird stuff is what breaks confidence: instancing limits, density conflicts, biome overlap, parameter interactions, etc.
* **Treat stability as a feature.** In production, “it usually works” is not good enough.
One thing I’ve learned the hard way: the best tools don’t just generate content, they reduce decision fatigue. If every parameter feels like a research project, you’ve already lost. The goal is to make the *default path* good enough that people only tweak when they need to.
That’s also why performance numbers matter, but only in context. Saying “100K+ instances per second” is nice; what really matters is whether that speed translates into a fast, confidence-building iteration loop for actual level work.
For indie toolmakers: what’s been harder for you — the underlying tech, or making the tool feel production-ready?
https://redd.it/1s6t7h9
@proceduralgeneration
Reddit
From the proceduralgeneration community on Reddit
Explore this post and more from the proceduralgeneration community