It’d be awesome if the light blocks got “less bright” during the day, or you could play with the exposure settings to compensate for that.
It barely qualifies, but the terrain generation uses large-scale 2D noise functions to determine the amount of moisture and overall erosion and area has. This will give different areas mountains vs hills and grass vs dirt, but there’s a lot more that could be done there.
The terrain generation is in a separate plugin from BrickGrids; you can use it as a starting point, but I expect most folks would want to write their own terrain generation code.
I uploaded a new release here: /releases/tag/v0.9
I’m switching my focus back to my main project (unrelated to games: a programming language), so I haven’t done much work on BrickGame the last week, but I was able to make some optimizations. I made the clouds cheaper by using high-frequency noise to perturb low-frequency noise, instead of using a single noise function with many octaves. I also made the cloud shadowing ignore the perturbing noise. The result is that the sky shader now evaluates 6 total noise octaves (2 transmittance, 2 transmittance perturbation, 2 shadow), down from 12 before (6 transmittance + 6 shadow). The result isn’t exactly the same, but it looks pretty good.
I also made it cull all faces in a brick render chunk for a certain direction if the viewer is behind all the faces of that direction. The BrickGame part of that is pretty simple, but it required some engine changes to allow the primitive to select which static elements will be drawn for a given view or shadow. I made those changes in a branch (https://github/AndrewScheidecker/UnrealEngine/tree/StaticElementCullingChanges), and submitted a pull request to Epic (https://github/EpicGames/UnrealEngine/pull/110). I kept the BrickGame code compiling without those changes, but you’ll get noticeably better performance if you use them.
I created a new branch in my fork of UE4 that I will keep up to date with the version of the engine and any changes BrickGame was meant to be built with: https://github/AndrewScheidecker/UnrealEngine/tree/BrickGame.
Finally, I made the brick rendering share vertices between faces. This increases CPU time to update a chunk, but decreases the GPU time to render each chunk.
Whoops, I missed this post before. I think the light brightnesses are imbalanced, which makes the emissive bricks look too bright during the day. The day lighting (sun+ambient) should just be brighter relative to the night lighting and emissive bricks.
No… don’t abandon BrickGame!!! Symbl can wait 
Dont abandon Brick game!
Also - Would it be possible add biome support and expose them via blueprints? Or would this have to be done strictly via C++?
Things such as biome frequency and the like would also be welcome 
I’m not abandoning it, but I think BrickGame is only valuable as a demonstration of the BrickGrid plugin, which I hope can be useful to other projects. Most things on my task list now are very BrickGame-specific polish, which I consider much lower priority than any change that would be useful to games other than BrickGame. So I’m not stopping work on the project, just waiting for some feedback or ideas for changes that are applicable to games other than BrickGame.
I think terrain generation is something most people will want to write specifically for their game; that’s why the BrickGame terrain generation is done in a separate plugin from BrickGrids. That plugin does expose enough parameters to control large-scale variations in moisture and erosion level, but it’s not exactly what you want for discrete biomes that tie into gameplay.
The terrain generation plugin uses C++ to implement the terrain generation for performance. It’s possible to do it all in BluePrint, but it will almost certainly be slow enough to cause hitches as new regions become visible. The BluePrint currently receives an event when a new region needs to be generated, and passes that on to the C++ terrain generation library with the appropriate terrain generation parameters. You could certainly do more of the work in BluePrint, but it would be very hard to do all of it in BluePrint without sacrificing hitch-free generation of new regions.
This is a very nice game that is oriented toward the style of Minecraft. I hope additional features will be included in the near future! 
That’s great news! Is everything already hitch free? Can you do broader CSG operations with BrickGame? E.g. subtracting a sphere for a crater and such? Do you have liquid grids that flow? So many ideas…
It verks (hitch free) on my machine.
It hitches occasionally on my laptop, but very rarely on my desktop. On my desktop, regions take ~20ms to generate, and chunks take ~15ms to generate render data for, so it’s easy to overshoot 30ms by enough to be noticeable. I should make the BluePrint pass in a lower maximum time to spend on updates (I think it’s something like the previous frame time - 5ms right now).
I’m not sure how to expose general CSG updates; CSG operations on volumetric data are trivial. I forgot to mention this, but the latest build of BrickGame will write to many bricks in a single frame as a result of the player placing bricks. I made it start batching bricks to place while you hold the left mouse button, and only place the bricks when you release the button. This makes it a lot easier to “paint” bricks in, since the new bricks don’t modify where you’re painting. That’s all implemented in the BrickGame MyCharacter blueprint. It shows that the existing blueprint-exposed API to modify a single brick is fast enough to call many times/frame (most of the cost is proportional to how many 32x64x128 chunks of bricks were modified).
It’s something I’ve thought about, but I haven’t figured out a great way to do it yet. They would have to go through an entirely different render path from the static surfaces for low-cost per-frame updates and rendering fractional fluid levels.
I think it would also require some hacking to make the physics work, since PhysicsVolumes are actors rather than components. Volumes should be componentized; I ran into this with PostProcessVolumes as well. I couldn’t give my sky blueprint a component to modify the ambient cubemap parameters, I had to give it a pointer to an actor separately placed in the level.
In case you need more lofty feature inspiration
https://www.kickstarter/projects/1247991467/planets3
://voxelfarm/vfweb/index.html
As a programmer to another, I would think BrickGame would be much more fun then writing another programming language 
My current project won’t be using voxels but hoping to get some time to play with BrickGame in the near future after I wrap this project up
I particularly like the voxelfarm but not really sure what it is… is it just a game engine or is actually a game? the trees in that looks absolutely spectacular for something like a minecraft type survival sandbox game.
Этот проект самый интересный.
I finally had time to update my engine branch with BrickGame-specific changes to 4.3. The merge was very painful, and I feel like I was doing something wrong; this was my first time doing a merge like this in Git/SourceTree, and lots of files I never touched had conflicts. Even after telling SourceTree to resolve with Epic’s version of those files, there were some inexplicable differences from an unmodified copy of the 4.3 source.
Thanks to K1llerFox for submitting the changes necessary to make BrickGame work with UE4.2! There were only some small changes beyond that to make it work in UE4.3.
Anyway, with 4.3 it’s more important to use my branch of the engine (https://github/AndrewScheidecker/UnrealEngine/tree/BrickGame), although it will still work with an unmodified build of the engine. The brick ambient occlusion in particular no longer works in unmodified UE4.3, since the material ambient occlusion output is ignored. I modified my branch to fix that, but at the cost of using a GBuffer channel I assume Epic is reserving for something else.
There’s also an “ensure” assertion failure in the 4.3 Blueprint serialization code that is being triggered by a PostProcessSettings struct, since it has a member that is a static array of another struct (LensFlareTints). I haven’t had a chance to put together a simple repro for Epic yet, and everything still works if you continue past the ensure.
I’m hoping to also get it working with my Oculus DK2 once the engine libovr integration is updated.
Awesome a brick game update!
Awesome to hear that you’ve got the game (mostly) ported to the latest version. Re: oculus support - this would be really cool for something like brickgame, as the feeling of height and scale is one of the more powerful things about VR.
Interesting… just unsure if the Minecraft hype is overused already.
Any idea if your changes for 4.3 will work with 4.4? I’ve got the DK2 and am planning on utilizing your plugin as part of my project (once I’ve updated mine for 4.4).
Thanks for your hard work!
P.S From briefly looking through your code you’ve got an amazing understanding for 3D development. Game Dev Background? I’m envious
Andrew worked at Epic for over 10 years and I hope we at some point can convince him to return instead of devoting time to his programming language
The automatic updater from 4.3 to 4.4 worked just fine. No need to change any code.