Thanks for the advice and the link to the source! Ill do some digging through that to see what I can change/add to mine. I noticed you have AO implemented in there, I was looking to implement my own AO to reduce the framerate cost of dynamic lighting while getting light bouncing in. Ill have to look through all that later today. Thanks!
Both vblanco and I have been scratching our heads on how to do the generation in a separate thread. Do you happen to know how to do that? Also good luck on your implementation of it as well!
Yeah Im still working on cutting back on memory usage. Keep in mind though Im already using far less memory per block than Minecraft does. Im aiming for 32^2 chunks that have 32^2 blocks each visible at once, whereas Minecraft on far only does 16^2 chunks that have 16^2 blocks each. Im not trying to copy Minecraft as far as the scope of my project goes but thats a good starting point for comparing memory usage. Ill also have to look into doing the world generation math on the GPU sometime in the future, Id assume that would be a massive speed increase.
Im helping Ad-Man to refactor the code so it takes multithreading easier, while im taking a look on threading with the UE4 libraries, investigating a bit. The plan is to launch a “generator” thread, that goes its own way generatign the chunks, and when a chunk its generated, its marked with a bool and then, in the tick function of the world generation its checked and if its generated, its vertex array is submited to the engine. I do that in my personal voxel engine, and it works flawless. Before that my engine lagged when chunks generated, wich, in a infinite world voxel environment, every time you moved a bit, it lagged for something like 0.3 seconds, wich is VERY noticeable. I learnt basic C++11 threading myself(my university teacher had no idea). And ran the generator in a different thread, now my engine is smooth as butter generating new chunks.
BrickGame is absolutely fantastic and hugely appreciated as a reference - love the planar mapping trick in particular. Going through the source left me with a couple optimization questions, though:
Why did you decide against using a texture atlas to reduce draw calls? I know the usual reason is to avoid mipmapping seams, and I’ve noticed UE4 doesn’t seem to support Texture Arrays (WebGL/iOS compatibility), but I was under the (possibly mistaken) impression that something like this was a viable solution: http://oliverm-h.blogspot.com/2013/04/how-to-create-ue3udk-texture-atlases.html If not mipmapping issues, is there a more fundamental reason?
Would it be possible to adopt an instanced mesh approach as a further optimization? It seems like this wouldn’t be compatible with your per-vertex ambient occlusion value - would it be possible to circumvent that limitation with a uniform buffer?
Again, massive thanks for making your work on this available - saved me days of headaches while transitioning my voxel code to UE4.
Hi, Amazing work :D. I know how to generate cubes and chunks in unity but I was just wondering how you generated one cube in UE4. I have no idea how to create the verts and triangles, any recommendations?
the gpu isn’t a linear increase because you have to do it in very large blocks to get full speedup, but then you have to store it (and transfer) the data before it’s consumed. I don’t think there is any way around the data/mem use, one approach I took was to have the geometry itself remain as the only source of game information and blowing out the source data… ends up spikey. I’m sure in a few years a 2-3g footprint won’t matter much. I think voxels have a lot of untapped potential, it’s easy to imagine this scaled in 10 years time.
My approach doesn’t use a dedicated thread, I rely on amp concurrency and concurrent containers. A problem I currently have is my geometry construction algorithm needs neighbor information (sides+2 in all d), which severely complicates both the memory requirements and cpu/gpu use as I’m wasting cycles recalculating, and I have to be smart about construction order.
Vblanco and I figured it out and are currently working on multithreading so I think we are content with that, using an extra thread for world generation.
@Jon Langford - The link Ryvar gave you is the same one I learned from. Good luck man
I think you misunderstand me, I’m not using a dedicated additional thread, I’m using many. For what you are doing I would urge you to learn about the parallel and concurrent capabilities of microsoft’s newest compiler/runtime. You can throw loops onto n threads with a few lines, and taking it further with a little setup work you can write normal c++ that runs on the gpu as well. It makes the difference between cpu particles and gpu, and if you don’t want to you don’t have to use anything like opencl or compute shaders, just a more restricted c++. Shame on that professor for not understanding threads, if that was indeed the case.
I think deriving the UVs per-pixel is a good trade-off, and you can even derive a tangent basis from the per-pixel derivatives of the position (I have an abandoned branch doing that in BrickGame). Doing multiple projection planes should work, but the single planar mapping is cheaper, and is good enough for BrickGame!
I don’t think instancing is worthwhile for bricks. You’d save copying a few vertices/indices per brick, but it is mutually exclusive with a bunch of other optimizations like culling internal faces and sharing vertices between adjacent faces (BrickGame doesn’t do this, but it theoretically saves you vertex shader time).
Something I’ve been meaning to do in BrickGame is cull all faces of a certain direction in a chunk that the viewer is behind. The GPU does backface culling, but this is a simple check and should save between 1/3 and 1/2 of draw calls, shaded vertices, and triangles. That should make the burden of a separate draw call for each face direction more palatable.
Interesting … did the same thing with unity then migrated my code to .
Now that UE supports C# i’m tempted to take a crack at a UE version.
The bit that always gets me is the mesh generation.
Any hints on the logic behind fast mesh generation?
Cube meshes are simple enough, i’m thinking more about smooth meshing.
Toying with using the sum of the values of the current voxel and its neighbours in each direction to get a surface point since my voxel weights fall in the range -1 to 1, then generate a mesh from the resulting points.
There has to be a faster way than iterating over a whole chunk of voxels though.
You are a little guy and you can build microbots based on voxel cubes. you can turn mass into a block with an ID, like wood and steel. you have to collect blueprints, and then you can arrange the voxelcubes you own into any configuration you want, house, item, spaceship
Voxels must become aware of their neighbour, so reactions can occure between blocks, like a wheel next to an engine and it works
I am looking for a voxel procedural generation developer and you have the skills!
Could you make procedurally generated planets, where every planet has a different mix of blocks? ( carbon, iron, wood, clay etc)
I wont hog your thread, so here is a thread i made for this project, please help! If you want in&out i can pay once it has revenue, if you think this is cool and you want to be a real team member then i will cut you in on equity.
