Current progress on this example included in the BuildR asset. I’ve changed the colours so they are better suited to the style I’m aiming for. I’ve worked on getting the offsetting of buildings working correctly now. I also introduced frame geometry for wall section openings which made a lot of sense for these exposed timber designs.
We have buildings! The BuildR Carcassonne project has come alive and BuildR is now generating building mesh data for all the buildings. There is much to add and improve on, but I’m super happy with how it’s working. This example took less than 10 seconds to generate.
BuildR 2 allows users to create buildings within Unity without the need of external modelling programs. It has a quick and simple workflow to create buildings with ease. You can edit and preview everything within the Unity editor. Generate full interiors, curve facades and have overhanging sections. After 4 years, I’ve taken all the great feedback and knowledge, rebuilt this asset from the ground up, to create something that is flexible and powerful.
I’d like to officially announce that BuildR 2.x is in production!
I’m currently building a new version from the ground up. Over the years I’ve received some amazing feedback from you guys and while I’ve striven and successfully added a lot of your requests, there is a lot that can be added that was either just a lot of work or just impossible with the current BuildR code architecture.
BuildR started out as a way to generate simple buildings to fill your levels. I didn’t want to just create square buildings like some programs, I wanted complex shapes supported. Over the years – and it’s been over three already! – interiors, stairwells, custom windows, Substance textures, runtime generation, and many more things were added. But I’ve now reached the point where we need to start again, picking the best bits of BuildR 1.x and creating something that can support some of the things you’ve requested over the years.
Here is a list that I’m committed to doing. They may not all appear in 2.x but I currently have no reason to believe these won’t make the final build.
- Curved facades
- Interior generation including walls, doors
- Overhanging sections
- Overhanging roofs
- Deep support for custom geometry
- Strong support for procedural runtime generation
I’ve been on the store for over 5 years now and a Unity developer for much longer so there are many things I would like to implement for this. There will also be significantly tighter integration with the Unity editor, expect a lot more drag and dropping and simple ways to create buildings.
Price wise it’s probably going to be a $100 asset with an upgrade path from 1.x for about $10 though I’m still weighing all these options right now and this could change. ETA is maybe an early beta by the end of August for people who want to try it out and test it for me. Hit me up on my email with your BuildR invoice number if you’re interested.
I have recently released the latest version of Track BuildR which has been christened the “Stunt Update“. This version comes with support to create circuits with loops, jumps and twists after rebuilding the track cant implementation.
It also includes Substance texture support, FBX, OBJ and XML export, track extrusion and some minor bug fixes. I’m very proud of the fact that Track BuildR since release has had only one bug!
The update did come at a slight cost – 1.0 tracks are not supported… With the new undo system that Unity 4.3 implemented along with the hell that is using ScriptableObjects, I needed to change the base implementation of Track BuildR to Monobehaviour. The problem is it breaks backward compatibility… I do have a plan for users needing the upgrade. It involves exporting the 1.0 track to XML (with some re) and importing it into a fresh 1.1 track. This method was used to bring the Spa Francorchamps track to 1.1 and it’s pretty easy.
I hope it’s well received! You can check out videos, demos and further information.
I’ll admit that I just had a really geeky weekend. I spent most of it coding away and I thought I should share what I’ve learnt. My mini weekend project was rebuilding the low detail model generator in BuildR. It was working fine but for what it does, however it was a little too slow and I felt I should spend some time working out why.
The output needed to be a low poly, single textured version of the high poly model that BuildR outputs. Generating the simplified mesh is super simple. Turning facades into planes and stripping some detail from the roof brought the polycount from 3813 down to 875 in the Paris example above. It was transforming the facade details and textures into a single atlased image that proved time-consuming.
The whole generation process clocked in at about 8000 milliseconds on Saturday morning. This was a little too long, even for doing things in the Unity3D editor. Right now I’ve got it down to 600 without cutting the quality significantly. There is definitely some more research I can do in this area (use RenderTextures maybe?) to reduce it further and 600ms is still far too high for this to be used at runtime.
The key to the problem lay in the powerful function in Texture2D called PackTextures. For most things, this is an awesome, magic function – you just throw your textures in and a single packed texture comes out. Simple right? To do this, PackTextures requires a set of Texture2Ds. That means that BuildR needed to create a new Texture2D object and call Apply for each facade. However, with the large textures that BuildR deals with, these are not only very expensive operations but take up a massive memory footprint.
I figured one way to avoid this would be to use a single Color32 array throughout the whole procedure and use one Texture2D object and Apply call at the end. To do that I needed to build a custom texture packer and texture resize function which I previously allowed Texture2D to handle.
The process I ended up with felt a little backwards at first, but it seemed like the best way. The first thing BuildR now does is build the roof mesh. From this mesh generation, BuildR extracts which textures are used and the world dimensions they occupy so it can atlas an appropriately sized version. The data goes straight into the custom texture packer along with basic facade data.
The texture packer actually only generates bounding rectangles for all the textures and does no actual image manipulation It sorts the textures by width, stacking texture bounds on top of one another. If they don’t fit, they are added to the right creating a new column. There is also no limit at this stage to the size, but the overall dimensions are kept within a square shape as the output would be a power of two.
Once all the rectangle bounds are generated, the whole thing is scaled down to the nearest power of two size and BuildR begins generating facade textures. This involves filling the main colour array with values based on the texture bounds that the texture packer generates.
BuildR needs to resize textures so that they fit the output image size. I ended up implementing a nearest neighbour algorithm to tackle this. This simple algorithm down samples the image into a smaller size giving BuildR reasonable results. I feel there is a lot more research that could be done here, but this ends up being a fairly expensive operation.
At this point it’s worth mentioning a problem with using Texture2D.PackTextures padding. You can specify an amount of padding in this function, but the colour of the background is black. The buildings end up with some nasty black lines along some of the facade edges (as above) and it is only worse with lower mipmaps. To solve this, facades need to have their own padding that reflects the edges of the textures.
I’ve attached the RectanglePack.cs class but I’ll do a separate blog post on texture resizing algorithms.
TL:DR – By dumping multiple instances of Texture2D, calls to Apply, performance is dramatically improved. This necessitated dumping a couple of useful Texture2D functions Resize and PackTextures.
Today I released my second product on the Unity3D Asset Store. It’s very much based off the work I have been doing on Redacted though it’s pursuing a different direction (realistic external rather than abstract/internal building generation). With BuildR you can create external building models within the Unity3D IDE without a 3D modeling program. I’ve worked hard to create a simple system that gives the user as much control over the building as I could imagine. At the moment you can export your model into the OBJ format although I’m working on an FBX export option too (a little trickier as I’m having to reverse engineer the file format – fun!).
I’m releasing it as a beta and at a reduced price to begin with. I’m not sure how many bugs people will find as there is only so much testing a few people can do. I also feel like there might be additions to the workflow as some people will want it to use BuildR in ways I have not yet imagined. At the moment it’s not really set up to run at runtime, there’s little support to link into other code or is it ready for full procedural generation. I’m confident this will all be included in the future though. As the codebase matures and more features make it to the release, I will increase the price.
I’d like to give a big thanks Sergio, Aidan, Jerome who very kindly had a go on some of the early alpha/beta releases and weeded out some bugs, smoothed some edges and made it a better product.