World Building [RELEASED] CScape - advanced building generator

Actually, I'm working on this. a first version of CScape could do this in easy way - just drop a prefab from folder into a scene. But this behaviour had some problems when you use buildings that have attached objects like rooftops, advertisingss or balconies. You can use it in this manner also now, but you will have to cope with some issues that I will explain.
Cscape requires that a Cscape City object is present in a scene. And this will not change (because it gives some flexibility in workflow - having objects organized by their importance, instead of their hierarchy is a best way to have a maximum controll (by simle activating or deactivating a class of objects) of every possible optimization).
right now, as I've mentioned, there are some issues whit drag and dropping prefabs into a scene. This is for some poor coding (poor, because I was concentrated on other functionlity), and if you click on a prefab in a folder,it will create objects in a scene without using correct hierarchy. So, a correct usage to avoid this problem is:
-add a cscape city into a scene
-Drag and drop building prefab into a object Buildings
-Delete all objects generated by Cscape (should be the last ones in scene hierarchy). This will reinitialize al those objects to a correct way of functioning.

Another way of using it as you would like is by using this trick:
-Create Cscape City object.
-go to Cscape randomizer settings and set Number of blocks x and z to 1.
-Set section division to 1.
-Generate city.
-now you will have a single city block, and a single building. and this is enough to start.

-delete a street object if you don't need it.
-select a building to use it as a template.
-go to a menu, scape/layout tools/split x or z.. You will end with two buildings in your scene. move the one that you need to a place where you want it. And customize it.
-Repeat this action by selectiong always a first building that you are using as a temlate.

 

Thanks!

Yes, I was thinking along those lines, wondering what the easiest way to go would be. I appreciate you pointing out option 2, as I didn't realize a section division of 1 would give just one building on the block.

Another variation on the main CScape script might be one where it takes a user-provided list or array of locations and dimensions and uses that during the building placement phase.

 

I have ran into a crazy Bug.The city generated is too small for my game,so I scaled Cscape GameObject Parent to match my game.When I generate the city and streets,all of it is offset incorrectly.Can you please add a variable in the future to set city and street scale before we generate it?

 

This actually shouldn't be considered as a bug, but design decision, and probably won't be "corrected" because of few reasons. I will try to explain:
-a decision to make levels that aren't scaled in a world size (smaller or bigger) should always be avoided in Unity (with CScape or without). Unity is made to work in a world scale, and making it bigger or smaller doesn't help as you can run in floating point issues, physics issues (bugs or having to shange gravity and all physical properties), incompatibility with third party assets (like in this case), impossibility to update your levels for VR, incompatibility with image effects like Post Processing stack - that for example have some distance limits (SSR Reflections can be handled only to a max distance of 150 - 300 meters) and so on. A list is quite long. Also, using scaled objects isn't that great when engine has to optimize a scene. But a list of Cons for having a non world scaled scene in unity is quite longer that this.

-Cscape uses real world scale by design. this makes it compatible with other tools and unity itself. In a future, I plan to add also some material/shader features that are world scale - and having to make them work in scale mode would mean having to make complex shaders that use more instructions and loose their performance. Also, having to manage adittional transformations, would mean that all scripts would loose their performance, as having to do compensation for scale means that you have to use more CPU cycles.

What you can do in your case?
You can easily generate a city before scaling it, and then when it's generated, you can scale it to your needs.

 

Thank You! that works perfectly!

 

amazing asset!
I decided to make some screenshots in support of the dev.
The asset is of superb quality.

Cant wait to see this asset finished!
Some traffic lights and other street details would be a nice addition

Simple scene generated with basic out of the box settings, some bloom, AO, Color Grading, motion blur, chromatic aberration, vignette. thats it, nothing fancy, didnt take the time to create a LUT either.

 

Many new things will come with time
Thanks for your support!

 

A new version was submitted today.
Here is a list of changes:

version 0.9.0
-drastically improoved shading and textures (surface textures now use normal maps)
-fixed bug when streets would change their texture after GI baking
-Added swithch for mobile version of shader
-fixed bug when some of the rooftop or faccade textures would flicker
-added a bonus clouds system
-refactored CDK texture coding laws (now uses less texture channels)


After this version, I think that I will have to drop a support for Unity 5.5 as it has some limits for features that I intend to add. Oldest Unity version would have to be 5.6. Please, let me know if this is a problem for some of you.

 

Can't Wait to try it!!

 

Is this going to work on webgl2?
Also is there a destroyed/damage version for each building?

 

I'm not still sure. For now, I wasn't been able to make 2d Arrays work. I think that they aren't yet available.
No,there aren't destroyed versions of buildings. I'm currently exploring this part - but it will probably be available as a separate pack.

 

New version is available on assetstore. Be sure to check it out
And, as always, let me know what you think, report any bugs, and write a review on assetstore

 

I have already started to work on Re.lighting feature.
What this feature does?
-It can be used for illuminating your night scene without using costly unity lights placed everywhere. It simulates thousands of lights coming from light poles over whole scene without any processing impact.
-it can be used as main lighting for mobile platforms, reducing a cost of performance of light-baking or realtime lights.
-it can be used as a sort of global illumination. With subtle values, in combination with realtime lights, it can produce a nice quasi-GI lightting by adding light contribution.
-It can be used with SEGI for realtime GI.
-It can be used as hybrid solution for lighting your scene. It has a distance falloff that can be used so that it lightens only far objects, while using realtime near lights.
Some results in a scene without any light:

 

I don't know what your solution is, but the idea is wonderful.

 

Lighting the streets and lower levels of buildings seems like it would be so helpful. But now I've got to try to think about how to get the streets in my game, and not just the buildings.

BTW, does it make sense to use GPU instancing on the street light models? IDK to what extent CScape already uses instancing, but it seems like it could be beneficial on the light poles.

 

I'm not using instancing. At the beggining I started sorking on gpu instanced solution - but after few tests I understood that this wasn't a way to go, and that my solution of combining meshes and using atatic batching gives a better result. GPU instancing is limited in many ways.

 

I don't think instancing is useful for less than 150 objects drawn at the same time.

With CScape's LOD, I doubt instancing will improve perf.

 

You are right. All those objects get batched pretty nice, and if you use LOD and Occlusion Culling, GPU instancing will actually slow down things by not knowing what objects are visible and what arent. GPU instancing is good when you have many objects that are close to each other (like parrticle or flock simulations) and are all visible most of the time.

 

Good to know! Thanks.

 

Just started learning CScape tonight, as I had a small interval of time on my hands. While it's clear (as you say in the asset description) that this is an evolving product, I am really impressed with what I was able to spin out in a very short time. Lighting is going to be a performance challenge, as others have discussed, but this asset has serious potential. Nice work.

EDIT: By the way, in my demo scene I replaced the water mesh on your static river with some dynamic water from the new Ultimate Water System asset, and it looks great together.

 

Well, actually, lighting shouldn't be as much challenge if baked. Of course, if you use 100 of shadowed realtime lights,then it could be and will be. But, because of various optimizations, it should be much more performant than any other scene with that scale and that complexity. Daytime realtime shadowed lighting is really fast (due to a low number of drawcalls). Nighttime can be problematicas you have to place many lights. But you have options - you should use occlusion culling baking, nad then you will get a much better performance as those lights that aren't wisible wont be rendered.
Also, right now I'm uploading a new version that uses CScape Re.Lighting feature, and it should boost your lighting with Cscape. This is only a first stage of Re.Lighting feature, as I plan to add more optimizations to it with a time.

 

New version is submitted, and it features new Re-Lighting option.
Features:
-Re.Lighting - simple yet effective and ultraperformant nighttime lighting simulation without using Unity lights
-Another boost in shader quality
-new version corrects issue with Cscape on Unity 2017.2 (and later) where normals wasn't interpreted correctly, resulting in wrong lighting and reflections

Note: this is probably a last version that supports unity 5.5. Next versions will deprecate unity 5.5, and will support only for Unity 5.6 and later. So, if you haven't made a step in using later versions of unity, this is a right time to update. I had to make this decision, as i need some functionality that is available only after 5.6. Also, supporting 5.5 and 2017 requires adittional developement time, and slows down my developement as there are much more differences between 5.5 and 5.6, than ones from 5.6 to 2017.3. I hope that you all understand.

 

Re.Lighting feature in Cscape is a feature that gives you a possibility to light your city scene without using Unity lights. Lights can always impact hardly performance of any game, so this feature was made to optimize lighting solution. This scene doesn't use any realtime or baked light, and actually, lighting here doesn't impact performance in any way.

 

Hi @olix4242 , tried to build my project using Unity 2017.2 and build fails with following error.

Shader error in 'RooftopsShader': Fragment program 'frag_surf': Unrecognized sampler 'samplerunity_lightmap' - does not match any texture and is not a recognized inline name (should contain filter and wrap modes).
(on d3d11)

Compiling Fragment program with DIRECTIONAL LIGHTMAP_ON DIRLIGHTMAP_COMBINED SHADOWS_SHADOWMASK UNITY_SINGLE_PASS_STEREO
Platform defines: UNITY_ENABLE_REFLECTION_BUFFERS UNITY_USE_DITHER_MASK_FOR_ALPHABLENDED_SHADOWS UNITY_PBS_USE_BRDF1 UNITY_SPECCUBE_BOX_PROJECTION UNITY_SPECCUBE_BLENDING UNITY_ENABLE_DETAIL_NORMALMAP SHADER_API_DESKTOP UNITY_LIGHT_PROBE_PROXY_VOLUME

Is this a known issue?

 

This looks awesome!

 

Agreed, but in a scene of that size baking takes a long time, even on my 4.7 GHz CPU.

I wasn't meaning to criticize the asset for the lighting situation -- I agree with you that *any* scene of that complexity is a lighting challenge. My comment really meant to say, "This asset makes it possible to very quickly generate a really large scene, with all the lighting challenges that are intrinsic to that."

All that being said, your ReLighting extension is looking great. I look forward to trying it out.

 

Ehehe, I didn't even thought about thinking that this was criticizing
Are you baking a full lighting maps? Form my experience,there isn't a real need to do it, as long as you do not target lowest possible systems. I'm ususally baking realtime GI, with spacing set to 0.005 texels per unit. This is quite enough for nice GI contribution. Then I keep realtime shadows from sun. With Re.lighting it should be much easier to use realtime lights.

 

thanks for reporting this. I will look into solving this issue. But it looks quite strange as that shader is quite simple, and there isn't much that could do wrong with it. But probably some Unity changes could lead to it. As soon as I'm able to reproduce it and to correct this, I will give you a feedback.

 

@olix4242 - Is the current (store) version incurring more of a penalty related to shadows? CScape's performance is a lot lower in my current project, and I'm trying to figure it out. Shadows seem to be more of a killer than before, but maybe it's something else on my end.

 

This generates some really beautiful looking buildings, so great job! I see this has limitations, but here's an idea to make them less so:


Would it be possible to implement a big brush (with some falloff) to move around and finesse buildings into place more organically -- i.e. like something akin to a paint program?

Also to make the brush system worthwhile, it'd be useful to be able to brush their height displacement too and potentially export that as a grayscale map to affect terrain height through, say, blending with terrain from something from Gaia or MapMagic. Is this doable with your current system?

 

Thanks oli: it’s builds fine with a new project, but not on my original project with VR.

Solution: I created a dummy scene with a cube, attached a new material with RoofTop shader and enabled GPU instancing. Finally added the dummy scene to build.

With above setup, I can now build without that error.

 

Not "full" lighting maps; approximately the same as yours, but my spacing is a lot more detailed than 0.005 texels/unit. I've had artifacts when spacing is too small, but I've never tried going *way* down into that range. I might give that a try just to see what happens.

 

There shouldn't be anything related to shadows. They are managed as before. I would suggest to check if you have a same shadows range. Also, please check if you have some Reflection probles set to realtime/render on every frame. I think that last version got exported wrongly, with river reflection probe set to be updated every frame (instead via scripting or Awake) and this could potetnialy impact your framerate.

 

Yup, I caught the reflection probe early on, and have been fiddling with shadow distance, hard shadows, and imported a shadows plugin to try to get help.

Also, when I add a sky plugin and a horizon plugin - both of which normally have minimal processing - they act as significant weights in the scene when used with CScape. So it's like adding sky, horizon, and shadows each rob 10+ frames from my scene, taking the total frames into the low teens.

Anyway, I don't expect you to solve those problems, I'm just giving some feedback in case it helps.

 

Well, it can help always understanding if there are some issues between plugins. In this case I don't think there are, but untill we don't examine it, it is hard to tell for sure.
I think that you probably are hitting some sort of bottleneck. Sometimes, i'ts enough one single adittional rendering to break things. Let's say that you are running CScape at 60 fps, but your system is able to run it at something more than 60 fps . If you are syncing your scene to every V blank, you have a steady 60 fps. As soon as you add something that might drop you few frames, you will actually get 30fps with vertical sync on. In those cases, I'm ususally debugging by looking at MS values and not on framerate. Also, there are some Editor related behaviours that might impact your framerate. For example, if you select CScape city in editor, it will steal your resources. The same applies also for third party plugins. Also, you might run in some VRAm issues if you hit your max VRAM available size.. in that case you get extreme framerate drop. Sometimes, it could be even some editor spam issues that can drop down performance. Be sure that you don't have any errors in console.
TThere is one lthing that could help you improove your framerate with CScape - be sure to set Anisotropic filtering to OFF or Per Texture (in quality settings). This can give a huge boost on some cards.
I'm just giving you some ideas on how to debug where your problem might bee.

 

Forgot to ask: what are your PASSCALLS values?

 

Hi @olix4242,

size matters I managed to get a megaCity scene to be around 7GB - and Unity stops loading scene over 4GB.

default size of 10 by 10 creates a size of near 300MB scene file. If it's all the procedural meshes within scene file, can we have them saved outside - it would also help with version control that way.

Also my street seems to have this weird black patches - is that a known issue?

 

Unfortunately, there is no way around when working with that large worlds and meshes. Every possible size optimization has it's drawbacks and you end by using larger size files, but add to CPU and GPU, resulting in a (probably significant) performance drop. Possible solutions are as follows:
-generating world on runtime - in theory, you could have almost zero size meshes. But this would require times to generate your world on CPU, and continue to generate it all the time. This also, wouldn't help batching, so you will probably loose too much of performance, below any usability (i already did some tests on smaller worlds, and I can say it isn't a way to go)
-Saving all objects as meshes outside (as sugested by you) - this would actually make things worse speaking in terms of file sizes. Unity already saves scenes with a compression and reduces actual file size. Saving a whole scene, containing all buildings, is much more effcient than saving model per model. This is because of a way compression works. If you have to zip 100 small txt files into one archive, a size will be much smaller than compressing 100 txt files to separate 100 zip files. In a second case, you wouldn't probably even have any significant compression. The same applies here: the larger the scene gets, compression is more efficient. A 9 times bigger scene will give you approximately only two to tree times larger scene file. 9 scenes with 10x10 size will have approx 1.3 giga.. while one scene with 9x9 with a same amount of detail will use only 400 megabytes of disk space.
CScape is made for efficiency, nad this means that it has be tuned to make the most from Unity engine. But, as you know, nothing in computing comes for free - so if you don't pay a price at one point, you have to pay it on another. As RAM and HD space are most affordable parts of every system, it's much more efficient to load them, instead of forcing a CPU or GPU to do unneccesary work. Simply, when doing this type of optimization, if you touch it on one side, you have to touch it also on the other - and in this case, I don't have much space for optimization, without breaking another 10 optimizations.

One important trick on reducing final size:
-before building final app, you should use Strip CS Scripts function. This will delete all CScape related scripts (and their data) on buildings resulting in a smaller file size.
Also, if you don't need some elements (as rooftops) you can delete them after Stripping. Or you can use LOD controller to make them have smaller density (and this will reduce file size as rooftops and advertising panels has a larger impact on mesh sizes).

 

Could you post a screenshot? I think that I know what it is, but this should have been fixed in a latest version that is available on assetstore. Not sure if you are using that one.

 

Hi Oli, thanks for such detailed response. Now about scene efficiency, I would politely disagree, and here is my reasoning.

As version controlling, Git doesn't play well with binary files; as generally recommended, I have unity serialize everything as text, which means there are no compression (I'm almost sure that even typeless data embedded is also not compressed)

Next is the fact that serialization isn't a guaranteed sequence (i.e same scene saved twice might have declaration for the same gameobject at different part of the file; in one scene one item might be the third serialized item and in another save it might be tenth item; I've noticed this behavior even when I haven't moved gameObjects in scene); also with large files gits gets rather slow (not using LFS yet - had some bad experience with it once).
In current setup, even if I change my skybox material, it would save a large uncompressed text file, which may not just be one line diff due to reasons explained above.

PS: My whole argument is based on editor and saving scenes, and not final build.

PS PS: I love playing with CScape - any criticism only comes from a desire to have it even better, and no disrespect is meant.

 

@olix4242 -- just wanted to be sure you didn't overlook my post here...

To summarize:

I need a little more organic placement of the buildings, even if that had to be done manually. A brush-based interface with a controllable falloff where you can smoothly shift groups and masses of buildings around after they were generated would be quite ideal for that. That same system could be used to paint into a heightmap for terrain to raise/lower the buildings too, so something like Gaia and Easy Roads could be used instead of the default road system you have going on there.

 

@olix4242, attached screenshot with weird street texture.

 

Replicated here, also, but I thought it was intentionally done, to resemble water puddles. TBH, I hadn't looked at it as closely as you, and my scene was night-lighting.

 

If you look at the CScape_Streets, you'll notice the MegaCityStreet Shader, in that you have the Smoothness and Puddles textures. Those are what cause the "black patches." They are "oil" stains or "puddles of water". Removing the Noise texture from those will remove the "black patches."

 

Aha, so I wasn't crazy.

 

I understand. Yeah, your problem with GIT is reasonable. But, here you have one option that can be a hassle, but works. I will see if this can be automated in some way.
-make your city
-save it as a prefab for later use in editor. This will save only information for reconstruction without saving any mesh (and it will reduce file sizes drastically). This should be a few megabytes prefab.
-save a scene without CScape included.
-When opening a scene, load your prefab that you have previously saved. It will show a blank object in your scene view.
-After import, click on a button Refrech City in City Randomizer. This will restore your previously made city shape. You will also have to refresh colliders (I will see to reduce this step to a single one).

I can probably implement a smart saving/rebuild menu option for CScape with a simple script that would delete all dynamically generated meshes, save a scene file, and then rebuild a city. This would reduce file sizes when working in editor.
Only drawback that I can see right now is that this would break light baking solution and that you can't use a standard save option in unity. But, then again, ligh baking is a last thing that is usually done.

As I said before, any input is more than welcome, if it can make CScape better and easier to use

 

ScriptableObjects are a great way to do this sort of thing, and they are typically quite small. I have other procedural geometry assets that actually default to not saving their generated meshes, but only the ScriptableObject (as an *.asset file) that contains the random seed and other parametric data to recreate the mesh on scene load. It works well, modulo the point you make about lightmap baking.

Newer Unity versions now have runtime-generated navmeshes as well, so that problem can be automated around with a simple scene manager script.

 

Yeh, that would be neat, but right now, I really don't have any idea how it should work from a user side.

 

The way I'm picturing it, the tool would be disabled until after the buildings are generated the first time. After that, if the user uses the tool, the ability to generate would be disabled unless the tool operation was Undone. Now it would simply shift buildings around on the x,z plane, shifting them less as they get further away from the center of the cursor (using the falloff amount to determine how much and a softness value to determine how quickly).

It would be nothing more than a cursor set to the normal of the 'surface' of the buildings' foundations, and since the foundations are all set at a particular height when generating them, that'd be a breeze to modify. You could get a terrain's mesh (terrain supplied by the user) to use as a reference for the y normal, so that this could work for both terrains and meshes.

The heightmap texture could be nothing more than a simple black/white/greyscale texture (supplied by the user, or eventually Gaia or MapMagic) that would get sent to you from something like Gaia/MapMagic (after generating the terrain mesh) and all you'd do on your end is modify the actual building's Y value to match the heightmap data as the user paints over the buildings, and with the Y axis, there'd be no need for softness/falloff -- just brush size (both horizontal and vertical operations would use separate brushes, but all you'd do on the backend is shift the x,z values based on the brush settings and y based on the heightmap (black/white/grayscale texture) supplied by either the user, Gaia, or MapMagic).

Hope this makes sense!

 

Is the kit for creating more buildings ready yet?