Mmmm, I can see the intersection problem, intersection didn’t come to mind as normally things like that wouldn’t pass through each other I had assumed they wouldn’t intersect with your application. Voxels really could be used for combining volumes together well, also if you are only storing on/off for them as well then you can store voxels in a bit per voxel assuming you handle the byte boundries manually (array of bytes, 1 bit per voxel, overflow bits in last byte of array to make byte even) or a byte per voxel when doing it naively or when requiring additional information like specific material. With compression it would be even smaller as RLE is easy to implement and is incredibly efficient with 0/1 data.
Something like what you describe would really only need a compressed flat array of data per volume and combining volumes together would be copying to a new array with a bounds equal to the extents of the two combined (minus the intersection) and then setting empty / full as required per both volumes. The only difficult operation is the mesh to voxel volume creation and that has quite a few third party tools that do it well already.
That being said the storage and combining of volumes for a 0/1 data volume is really easy to implement and I think my plugin would be just a huge mass of overhead / excess features that you wouldn’t need for something like that.
There’s fairly simple way to turn mesh into solid voxel data, as long as the mesh is water tight and does not self-intersect
Just shoot ray grid through it. For every ray, process intersections sorted by distance. Segments between odd numbered and even numbered hits (between 1st and 2nd hit, 3rd and 4th, etc). Will be “inside” the mesh and should be filled.
You could go nuts and scan every individual voxel in turn, too, with similar “inside/outside” test, but that’ll be more time consuming.
There are several simple methods and some complicated ones that handle outlier meshes as well. I would like to play around with conversion algorithms but it is very rarely something that is that useful and when it is it isn’t normally required during run time so it feels like re-inventing the wheel with open source tools already out there. Ray scanning really is elegant though for solid meshes.
If you are iterating an RLE compressed volume linearly as well it can be significantly faster than an uncompressed one, as you don’t have to read memory for every iteration when in the middle of a “run”.
Transparency support is complete, ran into some interesting problems with Physx and multiple materials on simulating components. Uses a second mesh buffer so that it can use a transparency material only for transparent voxel meshes. Any chunk/component with transparent enabled voxels in it will use two draw calls instead of one, if no transparent voxels were found during extraction then it still only uses one draw call.
Think I should probably move status updates to the WIP forum board rather than bumping in here for the future…
Is there anyway we can define how many blocks there are per fracture and If they should be in one piece or multiple blocks?
So here goes a few questions -
Are you using a height maps or exported Terrain from Qubicle?
Do you have any plans to support textures on voxels in your plug in or just simple colors?
What meshing technique are you using to prevent allot of draw calls? Greedy meshing maybe?
Is this plugin VR ready? more than 75fps with less than 20ms of latency
Regarding level design tools -
I am looking at making a “Hand crafted” world using voxels
Here are some suggestions to speed up workflow for Hand Crafted voxel worlds.
The Ability to import voxel objects into an actor blueprint and retain the location, Rotation and Scale of the objects. This way we can drag the actor blueprints around, rapidly block out and develop the game world.
A spline tool that interacts with voxel terrain - So for things such as roads, Pathways, etc.
Adding support in your voxel plugin for Unreal’s Procedural Foliage toolset would also speed up things. (Link)
A “Voxel subtractive volume” for terrain would be great due to the fact that it could be used to make drainage trenches, Tunnels, etc.
I have space partitioning that I will expose for the fracturing to define styles of fracturing and density (generation of the clumping points around different configurations generates very different fracture patterns). Also Fracturing will have a “simple fracture” setting that skips the clumping entirely and just spawns single cube physics objects instead to save on processing or to get a less intense effect.
The terrain there is generated with a noise library and sampling before and after a final noise pass to offset the color from the height (a very simple noise function for testing). I intend to implement the noise library fully in blueprints but don’t have a clean interface yet (threw out an initial attempt). Imported Height maps are easy to implement and I could add support for them at will, hasn’t been something I’ve moved into working on yet though as I’m still using the procedural height mapping while working on the core features.
Textures are supported just fine as you can assign voxels IDs to textures in the material, I just need to make the pipeline for using them cleaner (different functions for setting voxels when using textures or something of the sort to make it more abstract). I already have several voxel storage types with different memory footprints for simple colors or textures (though no easy way to set them besides altering a config .h file). I had several older videos with textured voxels and colored voxels in the same volume.
Greedymeshing yes (default on, but can be turned off), but I also have the option to merge mesh chunks into larger mesh chunks to reduce draw calls further in the terrains (not currently in the actors). This requires significantly more data to be sent to the GPU when updating an actor component (chunk) so it is slower to extract but it saves greatly on draw time. That being said it is defaulted off and performs quite well without it so far.
Workflow
Voxel actors are already implemented (and importable from three file types), I have it on my list to add a button in the editor for “paste actor” that will paste the voxel data of a selected voxel actor/s directly onto the terrain volume they are within. Also the editor mode I intend to support copy / paste / drag functions with a brush.
As in a voxel spline? That is something to consider.
That is a “wishlist” item i have, wouldn’t be an immediate concern or task
Another “wishlist” item, although a little harder to implement if not generating the entire terrain with MC.
Wishlist items are things that aren’t entirely required to finish the plugin but I would love to get working in the future. Some of them are very…wishful.
Well I sold my DK2 as I intend to buy a CV1, but my original reason for playing around with voxels in UE4 was for VR. Granted latency isn’t going to be up to my plugin and the FPS depends on what you are doing. An early demo of mine was kind of terifying to use as the fracturing exploded into your face.
I’m a fan, lots of possibilities open up with this. I was curious if for the effects/explosions if it’s hooked into the particle system or you’re rolling your own?
Got the noise generation pipeline done and just clearing up bugs and the minor TODO stuff now. I also added the ability to preview the noise map from the pipeline in the editor / generate a UTexture2D from it to use as a minimap base or w/e.
I am looking to release some sort of demo version for testing and sampling soon?
Here is a SS showing some of the noise generation nodes and a UTexture rendered from them.
The noise library is getting there, also added a third mesh buffer for Water since it has no collision. All of the three mesh buffers implemented so far only uses a draw call if it actually has any vertex data in it.
(
