[TOOL] UE4 Devlog: Procedural City Generation

[ApoorvaJ]

I'm starting a (hopefully) weekly vlog to document my adventures in UE4. The first, slightly awkward episode is live. Hope I'll get better with time.

UE4 Devlog #1, Voxel-based procedural city generation

[ApoorvaJ]

Episode 2 is up, featuring an overview of how I implemented dynamic polygon-based building generation.

[ApoorvaJ]

Episode 3, in which I discuss per-face meshing:

And episode 4, in which I discuss seamless material tiling across multiple, modular meshes. Should be of interest to anyone who's ever tried making modular buildings.

[Frozenfire]

Hi ApoorvaJ ,

I really like what you did there. I'm really interested in procedural generation in games development. I did a similar system that's currently on the marketplace
https://www.youtube.com/watch?v=C7oaZ7brp4Q

However my approach is very much different that yours. I would like to know more of your philosophy of development and perhaps learn from your
experiences in procedural building.

Some things i'd like to ask :

1) I've considered a method similar to yours for procedural generation, but my concern is the overly large amount of actors and individual meshes
that will eventually be generated in a practical development environment assuming an urban landscape. On top of that would be the high amount of poly.
I've also considered using instances of planes , however this would mean a lot of the shader functions would not be usable with instanced staticmesh.
Given that, do you have any plans to mitigate this issue? or is it a conscious choice of drawback you've accepted?

2) I've thought of another approach which is to scale the planes/mesh instead of spawning them in rows ala grid style
when drawing up the buildings, hence using less mesh and less poly. Have you considered this? If yes what are your thought reasoning of it?

3) I get a little paranoid with lightmap/normalmap seams when tiling planes with each other even precise accuracy. This is
something I've probably carried over from UDK days. Do you find this troubling / have you faced any of such issue in your implementation?


Btw if you do have FB and wouldn't mind me asking you stuff , please drop me a pm of your URL, I'd really love to have a chat with you on this,
perhaps to pick your brain a little on this.

[StevePeters]

Very cool. I'm currently playing with procedural meshes myself and I have a few questions.

- Does your system handle non-rectilinear polygons?
- How did you handle the vertex tangents?
- What are you using for the vertex input in the editor? I'm currently using splines but your way looks cleaner.

Thanks!

[ApoorvaJ]

@Frozenfire:

1) In my system, an entire building is a single actor, with geometry attached as static mesh components. You are correct in pointing out that instanced meshes won't work. This is a conscious decision, and doesn't have as big of an impact as you think. Overall, the geometry density is quite low. I don't think polygon count is an issue at all. For their world size, the buildings are fairly manageable in terms of polygon counts. Because of the roof generation algorithm, the system knows the building in terms of "boxes". I already have a built-in LOD system where I can change the building to only one quad per face. You could use this to render the city from afar.

As far as shader optimization is concerned, I'm going to move the UV calculations to Customized UVs to make them per-vertex instead of per-pixel. Further, the seamless materials are achieved purely through material instances, and so is arguably more efficiently scalable than the traditional modular material approach.

2) I am already scaling meshes instead of repeating them in rows. Check the attached screenshot. You can't get fewer geometry than this without overlapping.

3) Normal maps work flawless, as far as I've tested, and there's no reason why they wouldn't. Lightmaps, though, I'm not so sure. I use fully dynamic lighting. I'll have to give it a try and get back to you. Thanks for pointing this out.

Also, I've added you on FB.


@electricsauce:

1) The system doesn't handle non-rectilinear polygons. Watch vlog #2. The reason for this is that I'd have to procedurally create geometry for the roof, which is tricky, undeveloped and downright painful right now.

2) I don't understand the question. I'm not generating geometry, just placing static meshes in the correct positions.

3) The UPROPERTY meta tag is your friend here. Here's my vertices declaration:
UPROPERTY(Category = "York", EditAnywhere, BlueprintReadWrite, Meta = (MakeEditWidget = true)) TArray<FVector> Vertices;

[Mr_SquarePeg]

Hey ApoorvaJ -

Got a few questions for you -

1. Can the roof system handle holes in it for stairways going up to it, Skylights, etc.? If not is this planned?
2. Can this do Individual floors for buildings that we can go inside?
3. Can we define holes in the floor where stairs and elevators can go?
4. Can this system handle animated meshes for doors and the like?
5. Can this system handle destructible meshes? Like blowing a hole in the wall or kicking down a door?

I am really interested in how this progresses and would like to buy it from the marketplace or Sellify if possible.

Cannot wait to see more of your work,
HeadClot

[Furroy]

I know one of his videos did show internal floors as an option, but there were no stairs or holes in them to actually travel between them yet.

[Mr_SquarePeg]

I know one of his videos did show internal floors as an option, but there were no stairs or holes in them to actually travel between them yet.

I cannot seem to find that video which is why I am asking.

His work is really amazing

EDIT: Found it - 4:52 in the the 3rd devlog.

[ApoorvaJ]

@HeadClot:

1. Can the roof system handle holes in it for stairways going up to it, Skylights, etc.? If not is this planned?

No floor/ceiling holes yet, but it is one of the planned features, but probably will take some time before I get to it.

2. Can this do Individual floors for buildings that we can go inside?

As you found in the video, yes. This is already possible.

3. Can we define holes in the floor where stairs and elevators can go?

More or less, this is the same feature as in point 1.

4. Can this system handle animated meshes for doors and the like?

Not right now, but this feature is very high on my priority list. I'll start implementation as soon as I get some good looking skins in place.

5. Can this system handle destructible meshes? Like blowing a hole in the wall or kicking down a door?

Not a planned feature at this point. When the whole system is done (which will take a while), I will have a look at whether this will be possible.

Because of popular demand, I am considering putting it on the UE4 marketplace at some point. This will take time, though. There are some rough edges in the system right now, and I need to guarantee flexibility as well.

Also, thanks for the kind words.

@Furroy:

Thanks for following my vlogs and pointing it out. I appreciate the support.

[zoombapup]

There was a guy at epic who did a presentation at GDC (might have been around 2007-8) concerning their procedural building generator. They used a facade-rule based model where designers made up rules for facades (a facade in this case being a simple flat stretch of wall/floor) and then each facade was procedurally generated much as AppoorvaJ has demonstrated. The interesting difference is that the facades are defined by generating them from a geometric shape. So basically, you can have polygonal footprints of buildings, where each wall is procedurally generated as a facade and using the various facade rules to generate the actual meshes (things like having no windows if near other buildings etc).

There's a similar system in CryEngine also, and I recently saw a nice version of the same idea in the SnowDrop Engine that massive is doing.

My point being that I think your system could well benefit from looking at how you define the footprint of a building. Generally procedural buildings are generated from lot shapes and facade rules and I think you've almost got what you need to do things that way.

[StevePeters]

Ok, I thought you were generating the meshes in the construction script. I've had some luck with non-planar meshes by modelling in an outside program and parsing the OBJ file to get the correct normals, etc.

Are you encountering any issues with collisions due to non-uniform scaling of static meshes?

[Sitrec]

This looks fantastic! I would definitely buy in a heartbeat this if it allowed me to use my own meshes and materials (prepared for this of course) to procedually generate houses that feature interiors (walls, floors, doors, stairs and the like).

[ApoorvaJ]

@zoombapup: I've seen the video. It would be a rather large undertaking to build a full-fledged rule-based system with UI, and I'd end up spending more time on the UI than the actual tool. My current approach is to implement some common mesh pattern systems (a grid of windows, for example), and make it easy for designers to plug in their own meshes and materials in. If you want to implement your own pattern, though, you'd have to go in and add a little bit of C++ code. I've kept the code neat and decoupled, so you won't have to deal with all the details of the system if you don't want to.

@electrisauce: I haven't implemented collisions yet, but I'm planning to add box components to the stretched walls. All the other components (windows, balconies, etc.) will be uniformly scaled, and shouldn't cause any issues.

@Sitrec: Thanks! You can use your own meshes and materials even now, this early on in the system.

---

In other news, next vlog is up:

[xXxFishAndChipsxXx]

@ApoorvaJ - would be nice to hear if you plan on releasing this on the Marketplace or something. I'm interested. Personally I would prefer to buy something like this as a code library.