Author Topic: Voxel data 'layers'  (Read 1012 times)

JSwigart

  • Newbie
  • *
  • Posts: 16
    • View Profile
Voxel data 'layers'
« on: November 27, 2018, 03:04:42 PM »
This is an idea we've wanted to do in our voxel engine for quite some time that would be a powerful way to extend the voxel world/simulation. We haven't got around to implementing it yet, in part because our engine has become unwieldy, but it would be a huge draw for customers if VP supported something like this.

The idea is this, things like water/fluid generally take up some number of bits of the same voxel data that other solid block types exist in, meaning a voxel in a world cannot "be" both regular block types and fluid block types, even though many blocks aesthetically look like they should be able to, and more importantly, many block types would provide heaps of new functional capabilities if fluids could pass through them, such as when a door is open, etc.

The implementation approach I would use is to have supplementary voxel layers that can be instantiated for the world/chunks whose sole responsibility would be secondary simulation based data. The primary voxel world would still be the authority for the 'solid' voxel definitions of the world, however, things like the fluid simulation would effectively be a separate voxel set, and be very sparsely represented in the data. Since the fluids would be simulated and stored in their own voxel data layer, they could be allowed to directionally flow through the blocks of the solid voxel set, even conditionally, such as when doors are open, or when pump/drain objects are active. It opens up a world of possibilities for gameplay functionality, on top of improving the aesthetics and behavior of the fluid sim with respect to other voxels in the world. These types of secondary simulation layers tend to be far more sparse than the normal voxel layers, so the added data should not be significant.

On top of that, with generalized support for layered voxel data, it should be possible to extend the system further in ways that are not destructive to the base voxel layer, and don't have to compete with bits in that voxel data.

As an example, suppose I want to add a steam to my game to facilitate a suite of features for power generation. Steam builds pressure, pressure can be used in various ways. Steam could be generated off the top of fluid volumes, or where fluid touches lava, etc, and I would  have a simulation that updates the 'steam' layer similarly to the fluid layer, where the steam propagates upwards and outwards to lower pressure voxels on its layer. Obviously it would still have to respect the boundaries of the base solid voxel layer, and the traversability of those voxels that may or may not allow fluids to pass through. I could create this layer as 1-2 byte byte voxel value in its own layer, where the voxel data is representative of the steam pressure. It wouldn't be possible to add this kind of system onto a voxel game where all you had were the base voxel data sizes and the competing interest for those values(at least not without bloating up the voxel data size universally to provide the storage). With this implementation, my 'steam simulation' is entirely divorced from the base system and data, so noone pays for that functionality unless they use it, and with the sparse nature of data like this, it would ultimately be much easier on memory than bloating up the singular voxel data size to add a feature like this(and lose the functionality that these separate layers can overlap and act as flow control between them)

Fluids are the first obvious example of what should use this sort of system, and with that system in place, the normal voxel definition can be extended to support maybe 3 bools that designate whether a voxel supports fluid pass through along each axis, and 3 runtime bits to make it toggleable in-game(with valves state, door state, etc). Water could flow 'through' all the non solid voxels you would expect it to(plants, bushes, etc)

This implementation approach is about the best way I can think of to extend a voxel system, and although there is a non trivial effort on the part of the fluid simulation, or steam simulation, in terms of doing its logic and cross talking to the base voxel layer, it isn't that difficult, and the data in these layers will be pretty sparse. It also fixes a whole suite of ugly issues inherent to the default approach, such as when you place a bush in water, the water seemingly magically walls itself off from that voxel. It opens up a whole new level of fidelity. The fluid simulation could utilize a simple 'fluid permeability' value on any voxel type that allows it to 'seep' through regular blocks, like soil, dirt, sand, etc. Now your farming simulations have a lot more data for creating higher quality growth simulations, etc.
« Last Edit: November 27, 2018, 03:09:45 PM by JSwigart »

Paul

  • Guest
Re: Voxel data 'layers'
« Reply #1 on: November 28, 2018, 09:30:38 PM »
I think this is a fantastic idea! I'd love to see this implemented in VP.

Kronnect

  • Administrator
  • Hero Member
  • *****
  • Posts: 6642
    • View Profile
Re: Voxel data 'layers'
« Reply #2 on: November 28, 2018, 09:42:25 PM »
Nice idea and better described. I really opens a lot of possibilities for sure - I'm also thinking of roads for example.