I wanted to bump this thread. I am fairly new to UE4 and have enjoyed playing around with BrickGame but I have been unable to get it to work with 4.5. The BrickGrid Blueprint crashes the editor when I try to open it in 4.5. I have also done what I could to make a new Blueprint and replicate the variables and functions from the original BrickGrid Blueprint with there ending up to be an error in VertexFactory.
Since it seems like Andrew has gotten busy with other things than I was curious if anyone here has had better luck then me to get this working in 4.5?
I wonder if you are still checking this thread but I have a little question. How does the collision with the terrain work? When I activate Physics on the Character, it will just path through it. However, when I move with the floating camera, there seems to be collision.
Hi everybody, sorry for letting this go so long without an update, but I finally updated BrickGame for 4.5. Enjoy!
There were some updates required to the BrickGame code to compile in 4.5. Not sure how you were able to get as far as you did, but once I fixed the compile errors I didn’t have any problems with the BrickGrid blueprint.
That would be cool! Somebody should try it out!
It should have collision with anything (the camera collision is from a CylinderComponent, same as a character would be). What might be happening is that collision components are only created for bricks in a relatively small radius around the viewer to reduce hitches when flying around. Try increasing the BrickGrid’s MaxCollisionDistance.
I imported the Mixamo example Characters. When I use one of their premade Blueprints, Collision works. I giess it is some settings in the original Character BP. Will check that out later. In you original Post you mentioned some midfications you made to UE4.1. Ar those still necessary in your 4.5 ready build to get the best performance. I tried the master of your project on 4.4.3 and was really impressed. Once you tune the visible range of the grid, it loads rather quickly. I wonder if there is some way to determine the progress of the grid generation, so you could display some sort of progress bar.
Yes, most of the effort to make BrickGame work with new engine versions is in integrating my engine changes with Epic’s. BrickGame will compile and mostly work with an unmodified engine, but it will work a little better with the modified engine (https://github/AndrewScheidecker/UnrealEngine):
Epic disabled the material AO output at some point to make room in the GBuffer, and I had to reenable it.
There’s also a change to allow BrickGrids to cull backfaces for entire chunks, which was a pretty big savings in GPU time.
I think you could add a progress bar with some minor changes to the BrickGrid code. Check out UBrickGridComponent::Update. When the level is loaded, it’s called with a very high MaxDesiredUpdateTime, and then it’s called every frame after that with a low update time (from BluePrint). If the function returned an estimate of how much work was remaining, then you could start the game in a state where it shows a progress bar, calls Update every frame with a limit of ~30ms, and uses the estimate of remaining work to update a progress bar.
how hard would this be to turn into a terrain like in planet explorers or 7 days to die where it is actual voxel like terrain but instead its smoothed out so it looks natural?
Although they are also voxel they use a different representation of voxel data. With “bloxel” terrain you have voxel ids for example dirt is represented by an id of 2, rock would be 3, and air is 1 ( just example ids) when using marching cubes (the isosurface extraction algorithm used in those games you need a signed distance field to represent the terrain. This means when you ask for whats at (x,y,z) you get a signed number back (-max_density to +max_density, with 0 representing the boundary between ground and air). A lot of the book Keeping is the same like the chunk management and creation. But the actual voxel data -> mesh is different. If you are interested in these be sure to google “marching cubes paul bourke” he has quite the reference implementation. Another option would be an algorithm called dual contouring. Dual Contouring allows for smooth and sharp edges (through the use of some math that after looking at it for over a year now still makes my want to vomit like a little kid going to take a test). This is the very algorithm used in the now famous Voxel Farm, although they are using OpenCl to do a lot of the heavy lifting. Feel free to contact me with any questions, I most likely will not have the answer, but after reading up on voxels for over a year I might know where to look.
Awesome work. Looks like Minecraft but much much better. And there’s nothing wrong with remaking Minecraft because this time it isn’t in freakin’ Java.
This is nice, one question you have plans to add things like materials by faces, network support, custom meshes, navmesh, prefabs of blocks etc ?
Something like this, but this is for Unity: https://github/AlexSTV/Voxelmetric
I’m not planning to add per-face material support, though there is a pull request for it: /pull/8
Note that that pull request is for storing a different material for each face of each brick in the world. BrickGame already supports the special case of a different material on the top of a brick from the sides and bottom, but that’s obviously not the same as allowing a different material to be applied to each face in the world. That functionality could be easily extended to use yet another material on the bottom.
As for network support: it would be nice, but it’s beyond the scope of BrickGame. I think network syncing is very game-specific, and the components are there that you need to do it yourself, exactly as you want: Unreal provides the network protocol, and you can serialize or deserialize the brick data using BrickGridComponent’s GetData/SetData, or GetBrickMaterialArray/SetBrickMaterialArray (for subregions).
Navmesh is also beyond the scope of BrickGame. I’d consider it higher priority than networking, so I might do it if I have time. I’d have to add something that walks to BrickGame, though!
Prefabs: Do you mean player placed, or as part of the world generator? I doubt I’ll do much here other than maaaybe add trees as an example.
The BrickGame repo on GitHub now supports UE 4.8, and my UnrealEngine repo has a branch of 4.8 with changes for BrickGame. With 4.8, Epic made material ambient occlusion work again if static lighting is disabled in the INI, so it’s no longer necessary to use the modified engine branch to get ambient occlusion. However, there’s still a small change in the engine code to prevent the material ambient occlusion from masking the LPV lighting, so the emissive bricks will work underground. It’s also still necessary to use a modified engine to get the per-component backface culling that helps BrickGame performance greatly. I changed how that code works to be a smaller modification of similar functionality that Epic has since added for Landscape LODs, and submitted a pull request to Epic, so hopefully that can be merged into the official UE4.
Apart from upgrading to 4.8, I made two other changes:
I made the render component initialization use an asynchronous task to avoid blocking the game thread when a render component becomes visible. The initialization task will be kicked off when the render component’s scene proxy is created in the game thread, and the rendering thread will wait for it to finish before creating the RHI resources for the data it initializes (the vertex and index data).
I fixed a bug that was causing the tangent and binormal vectors to be zero on bricks. Normal maps were broken for a long time, and nobody noticed, myself included!
I also spent some time playing with BrickGame combined with NVIDIA’s VXGI. By playing, I do mean playing. It requires a very powerful GPU to get good performance, but it looks much better than the light propagation volumes that BrickGame uses by default. I posted a binary build on GitHub: /releases/tag/v0.9-VXGI
Is this an AMD specific thing, because I would still, even in 2015, consider 290x a “fast GPU”. However, I am getting a solid 4-5 fps in this version. Is this because of the Nvidia tech, or is this like it for everyone?
Might download the source and see if there is some code to comment out, but I am a little worried it would be a deep dive.
Yeah things like houses or trees in the world gen but probably will be good to have in the both sides as prefab to place in the map and as prefab to place in the map by the world gen, with some type of blueprint or something where define different prefabs/structures better in a visual way. (Like Blueprints)
That is sad.