Open mbforbes opened 6 years ago
Before this I need to extract blocks (#5).
I don't think parcels are available, but they may not matter. They could be faked by doing some kind of axis- (or block)-aligned voronoi diagram... or could just be fully latent? Ultimately what matters are where buildings are, so generating building bounding boxes would be enough.
Grammar approach ended up not being feasible for the time scale of this project. It turned out that doing a cGAN was, perhaps ironically, simpler. The above are all fun to keep thinking about, though. I'll leave this open for now.
Check out simple grammar approach (e.g., L system paper in other repo) and plan how I'd learn the rules or probabilities.
Cool thing is can go into depth on whatever sub-problem seems the most interesting / fun. There are many sub-problems in procedural city generation.
Possible sub-problems to focus on (ones struck out may still need to be done, but aren't possible as an "interesting" ML approach):
Something to keep in mind is that generating roads first, then parcels, etc.---what you might call a "pipeline" approach---was just done previously in handcrafted rule-based procedural generation, likely because it makes sense logically to computer people. It might not be the best tactic for an ML-based approach... and probably isn't even logically be how towns arise. It seems like functional areas based on geographic regions make the most sense. In fact, I wonder if this is a better project idea...
alt idea:
NOTE: I should really read the "4d cities" paper---and possibly others---more closely to see if they basically gave designers these knobs. If the ideas of the knobs are good, then we can pick them as a representation to learn.
Ideas:
draft 1
maybe even 3d?
random idea: webGL. recent inspiration: [http://demos.littleworkshop.fr/infinitown]
In back of mind: