How to build a procedural city in WebGL | Hacker News Reader

How to build a procedural city in WebGL

learningthreejs.com

121 pointsjetienne219 comments

I always liked this procedurally generated nighttime cityscape by Shamus Young: http://www.youtube.com/watch?feature=player_embedded&v=-d2-P...

He wrote a whole article series walking you through it, plus source, etc, starting here: http://www.shamusyoung.com/twentysidedtale/?p=2940

I also really liked Shamus's Project Frontier, a detailed walkthrough on generating an entire procedural world. http://www.shamusyoung.com/twentysidedtale/?p=11874

He released the executable at the end of the series, and I'm still sad that, as a non-programmer, I couldn't get it to run on my computer. I would have loved to have a chance to explore the world. Some of his screencaps are mindblowing.

[ETA: Since it's not immediately obvious how to get there from the rest of the articles on Project Frontier, here's the link to the source code: http://www.shamusyoung.com/twentysidedtale/?p=15808]

I really enjoyed that whole series - learned a lot about 3D programming, which is part of the field I've never touched outside of motion planning in college.

beautifull. thanks!

I love practical walkthroughs like this. And in this case, as someone with not much OpenGL or 3D experience, it's good to reach an outcome that I can then go back and tweak. The GLSL Sandbox, behind the Mr Doob demo, I believe(?) is good for this stuff, especially as you can edit in the browser: http://glsl.heroku.com/

Along related lines, I saw a similar tutorial yesterday on creating a synth using the Web Audio API: http://noisehack.com/how-to-build-monotron-synth-web-audio-a...

I'd much rather see such a tutorial about how to do this without Three.js — this high level, you're not /really/ doing anything with WebGL directly. It's like a tutorial for the DOM just going, "so, we're going to use jQuery".

I've got some decent experience with both OpenGL and WebGL. It's simply not worth the effort to learn for 95% of whatever you'll be doing--you end up reinventing a broken subset of what's already there.

Three.js is taking care of a lot for you, and it's not a bad thing. It's doing scene graphs, matrix math, GL setup and teardown code, shader setup and teardown, buffer setup and teardown, camera math, and much more.

Use a bloody engine unless your explicit goal is learning something arcane.

If you want to learn WebGL then you need to use WebGL. Using an engine can be a good decision for a project, but not a good way to learn WebGL.

Quite right--but the utility of actually learning WebGL is questionable.

I guess I'm a bit spoilt, but these days I kind of expect "procedural", in graphics demos, to also imply "infinite in all directions, without repetition, with deterministic results in regard to position, generated in real-time, and without caching anything you're not currently looking at." Maybe I'm too picky...

But it shouldn't be much harder in this case! Layer some octaves of simplex-noise to form a terrain, and then for any non-occluded map region, "grow" a building from the center of each noise feature. Might be possible to only tell the GPU about the terrain-texture, and create the buildings entirely in a shader, actually.

Well, that's NOT the meaning of procedural. That's why Minecraft is infinite AND procedural, because they're different things (often the former requiring the latter).

I agree with you, except the "without caching anything". Realistically, it's nearly impossible to generate a full 1080p screen of high resolution objects and textures without some amount of caching. Possible for some corner cases, yes, but not if you want a realistic world.

> Layer some octaves of simplex-noise to form a terrain, and then for any non-occluded map region, "grow" a building from the center of each noise feature. Might be possible to only tell the GPU about the terrain-texture, and create the buildings entirely in a shader, actually.

It's possible to generate the simplex multi-fractal texture itself on the GPU purely using GLSL via WebGL [1].

Growing buildings from a heightfield texture purely on the GPU though is a bit more tricky, because you don't want to scan the entire hightfield redundantly every frame to extract noise features. In other words, you'll want to cache this feature data, then "grow" the buildings, then cache that. It may be possible to hack OpenGL/WebGL into doing something similar to this on the GPU, but honestly OpenCL/WebCL will make this so much cleaner to implement I shudder to think how ugly this would look in GLSL.

So I would actually use the GPU to generate terrain heightfields (a good use of its massive parallelism), then a special shader to detect features (e.g. even something as simple as a few order derivatives at low resolution) and download them to the CPU. The CPU would then generate and compile a list of building coordinates, upload to the GPU, and use the GPU to perform instanced building rendering from them.

[1] https://github.com/judnich/Kosmos/blob/master/README.md

See Highway 4k (combined 4k winner at Assembly 2013!) for a REALLY SHINY example of what can be done with WebGL shaders:

http://pouet.net/prod.php?which=61668

Buildings of similar height all look the same. I guess adding some variation like 2 or 3 different building textures would make it look like a real city.

There's any number of ways this could be improved. Better layout, better textures, different building types, stochastic city planning/zoning. But this is a nice starting place that shows off a few easy techniques. Probably good enough to use in a JS1K demo.

Well, it uses Three.js (too heavily to easily remove the dependency, I think), so it wouldn't work for js1k.

Well not literally no, but the algorithm is certainly applicable.

That's really cool. The main thing it's missing is roads in between the buildings (or at least space where the roads would go).

That best thing about DSLs is that you don't have to use the current domain.

Reply on news.ycombinator.com