|
I'm currently working on a realistic building generator. It utilises squarified treemaps and another white paper for the logical construction of it (links below). Currently randomly places doors but each RoomData construct contains a tag along with flags like NOCONNECT(<list>) that will determine what must be connected, what cannot, what needs windows, etc, etc. In the long term I am cooking up actors for different styles of windows, doors and trim, which again will be flagged and placed appropriately. You can already specify wall and floor materials which is nice. Last bit is to have each room contain a list of appropriate items and place them around. This is done by each item actor containing info such as general placement (CENTRE, WALL, CORNER, etc), and a bit of a humanising factor with regards to both rigidity in placement (do you want everything lined up, or have a bed a bit further from the wall than the dresser?) as well as angle wiggle room (because realistically no one places everything at straight angles). That's the long term goal anyway!  Note: Rendering done in UE4 but I intend to eventually make it platform agnostic as far as the data and manipulation structures go. Rendering is a you problem :P Paper Notes: Squarified Treemaps https://www.win.tue.nl/~vanwijk/stm.pdf A Novel Algorithm for Real-time Procedural Generation of Building Floor Plans https://img.fireden.net/tg/image/1509/10/1509102037910.pdf
|
#
¿
Feb 7, 2021 10:41
|
|
|
|
| # ¿ May 2, 2024 01:09 |
|
|
Newf posted:This is cool! One thing you didn't mention is hallways - the lack of a thoroughfare really stands out in this example, but I'll bet it wouldn't be too hard to encourage the algorithm to create (at least) one highly connected 'room'. That's actually addressed in the second paper! Although I am taking a cheat's method. Basically, it takes all vertexes and figure out what rooms need to be connected to the through-corridor. I then find the optimum shift (up or down) and resize the rooms intersecting the corridor. See this:  Yes, you can absolutely create intersections such that the lost area of each room is minimised, creating non-rectangular rooms, and that is in the cards. But right now I am lazy 
|
|
#
¿
Feb 8, 2021 04:13
|
|
|
Hey nerds. I think the last thing I posted in this thread was me working on a procedural floorplan generator. Lotta stuff has happened in my life, but guess what, work has continued. So basically there's some whitepapers that other people here have used to generate floorplans and they work great, using squarified tree maps. I had that project pretty sorted and it was awesome. I then discovered a whitepaper that had some very nice algorithms for realistic layouts and generation of cities, from a top down generation. I was like, hell yeah gonna use that. Then I found out they had made a UE4 demo of the project, so I snagged that. In the process I noticed something. https://github.com/magnificus/Procedural-Cities 118 forks. And if you go through them I think not one of them has had any actual work done. None. Which bodes well, because people forked it thinking "gee whiz, free procedural cities that will make an entire game for me!" like so many people do. Then they see the code and say gently caress this. I ran the demo and was pretty happy with the layout and general design of buildings, and I figured it was a good start. My goal is not to make a game. That's boring. My goal is to first cure boredom by giving myself a project, and second is to create tools that will help actual devs prototype games quickly, giving them a base. So no running off and going "ooh cool, now to add spaceships!" Very focused on the goal. Step one was changing a lot of code. A lot. Basically the UE4 demo provided made some assumptions: 1. It was a demo for a paper, not a product. So the code is justifiably not modular or neat. Or commented much. 2. It is designed to generate during playtime, not beforehand. I however wanted it to be a dev tool, so it needed to be modified to generate in editor so devs can see what they're working with. Those two factors were big. So I've been tweaking and changing things. It now generates in editor, instead of during runtime. The code has been much tidied (although to my shame not really commented because my brain was on fixing) and made more modular, removing dependencies on a lot of weird things. It can now, on my baby laptop, generate cities of up to 300 roads. To give an idea of that, it generated this within a couple minutes on my laptop:  Because of the generation it means every building is able to be entered, filled out, etc. The visuals aren't amazing, obviously, but it does the trick.   Ripping out a bunch of static code has definitely helped the neatness of the whole thing, but there's a bunch to do. Right now my checklist before initial release is: 1. Material pools. Because each building is tagged as a specific type I can create a nice neat container of materials and have each assign a different one to each building. Simple build should very much help with monotony. 2. Incorporate the floorplan generator. The provided code and paper point out that interiors are not well done. They essentially consist of random lines for walls, and they make poor use of space and don't feel realistic. So the floorplan project I made is going to be put in as a way to provide proper interior designs. Other advantages will be that the floorplan treats each room as a separate but simple object, meaning I can quickly assign materials to individual rooms without worrying about the exterior building. I will note though that the floorplan assumes a rectangular shape for the building. The current (temporary) planned workaround is to simply build based on a rectangular container of the building and trim the rooms as needed. This is a poor solution, and purely temporary. Future things to do will be: - Visual improvements. Adding proper surrounds, pillars if needed, etc. Little things to flesh out - Better material designation. Having each building have a (relatively) unique texture is good, but I want to provide the ability to specify ranges for materials to be modified (HSV shifts etc). The idea is if you had several bedrooms they could all use the base painted wall texture, with a specified HSV to provide many different randomised versions on generation with low overhead. Should help with making it more interesting. - Using the individual room objects to take the space and add pre-made actors into it using a set of rules to designate where it would be placed, with fuzziness factors such as rotation and offset to make it a little more humanised. I hate when procedural stuff is all right angles. - Elevation consideration. This is the big one that I'm doing a lot of research into. The generator assumes a 100% flat ground. Which isn't ideal. So the idea is that once a city is generated it will take the elevation at each building and either build up on a base or level down (or both!) so buildings are still sound, but also can be built into elevated ground. So this is what I've been working on! It's amateur and there's probably a billion similar projects that do this better, and that's okay, because this keeps me sane. Thanks for reading! Edit: No one cares but I made updates. I added specific helper components that work as material pools. This lets you specify a material pool for each building type, but right now I'm lazy and it all works off the one. But now you can specify as many materials for each part of the building as you want which is pretty rad. Also not related to the generation itself but I tweaked the visual settings for the project for funsies and to show that it looks far nicer than the previous pics showed haha.   I am becoming quite happy with the progress. Also to note that the old way the materials were handled basically created a new version for each material on each building, which was not great. The new version relies on instanced materials, on the basis that if anything is tweaked it's still far more efficient to use an instance than a completely new material every time. syntaxfunction fucked around with this message at 17:01 on Sep 26, 2021 |
|
#
¿
Sep 18, 2021 06:35
|
|
|
octan3 posted:I've been meaning to reply to your post since I saw it show up but haven't had the time to. Just letting you (and anyone else who cares haha) that I'm working on this again. Part of what I'm doing before incorporating the floorplan module is decoupling a lot more code from the project. For example the current generation method provided by the original designer had mesh placement within room generation which is fair, but also hella static. Rooms themselves are also statically defined which is no good. So the objective for the next couple of days is ripping out the room generator completely and slotting in the floorplan generator instead which will not attempt to add meshes (a separate module for that). I've been looking at the work around as well (assume rectangular and trim) and for now I will be going with it with the added caveat of how rooms are designed. Currently the generator assumes one giant floor for each floor in the building. Which means you don't get individual floor materials. That's fine because essentially the rooms themselves are self contained sitting flush with the building frame. So each room has it's on walls, floor and ceiling inside the story. Because when rooms are trimmed the walls will be removed and just replaced with an inner duplicate of the outer wall I can keep the window slicer function and replicate it inside. So you can have a triangular room flush with the outer wall with an appropriate window and awning etc. Currently I am absolutely assuming "modern" looking buildings, but realistically there should be no reason I can't adapt the code to allow changes to provide older (or futuristic I guess) styles as well. But that's a later problem.
|
|
#
¿
Jan 10, 2022 09:12
|
|
|
I posted ages ago about the city builder I was working on. I ended going back and realising that a lot of what was being done (from the original author's code) was more for getting it done, rather than efficiency. So I have started ripping out a tonne of stuff and rebuilding it to be more versatile. To start with, I am ignoring the plots and buildings, and working on the fundamental layout of the city itself. Things I have addressed: - Inability to modify the city in any reasonable way after creation - Required to have a completely flat city I basically took the generated data and attached custom nodes to beginning and end points, and removed any duplicates. The nodes themselves are movable but more importantly I created a DataNode that pairs with a parent DataNode to send information. This is what gets generated with several hundred roads (my poor laptop taps out around 500+)  You can see the node actors, and they are real-time movable:   The DataNode essentially checks on construction (which in editor is when it is moved) that the transform data given to it by the generator is the same as what it is now. If it isn't then it dispatches a call to the generator which updates it's data. It's handy, because I'm only updated nodes that are actually, like, updating. If you move the nodes vertically it lifts any streets it connects with it, so you can now get vertical movement. It probably doesn't seem like much, but being able to realtime modify the layout easily helps me a lot, and the plan is to get the plot and building generators to modify the affected actors as well.
|
|
#
¿
Oct 17, 2022 10:27
|
|
|
|
| # ¿ May 2, 2024 01:09 |
|
|
octan3 posted:Woo, thanks for the update! I'm still watching along while not spending any time on my own city generator. I have actually migrated to UE5 for a very practical reason, which is Nanite. Basically the original project developed for the master's thesis a cool dude made needed a lot of work. One of the big issues for me is the use of procedural mesh components to produce the buildings. While they worked they became limited and were not a great way to produce a lot of detailed content. I moved because of Nanite because while I have retained a lot of the base algorithms from the project I have essentially started redoing the implementation. The core of it produces streets and plots as well as polygons for building bases within those plots very quickly and realistically, so that has been kept. The actual building generation I'm going in a different direction because the end goal is produce meshes generated statically for each building that can work with nanite. The goal is that once the building is produced with as much detail as possible (every room enterable, with objects within the rooms) that nanite can help keep poly counts in control, hopefully allowing for even higher levels of content for the same cost. There's a lot of other little things I'm changing about the implementation but I plan to talk about them when they're actually getting done haha.
|
|
#
¿
Oct 26, 2022 03:28
|
|