The voxel system I use for the snow in Snowman Scuffle is no longer maintained. In fact my customized version is probably the most advanced variant of it. This is good and bad. It’s also a pure Marching Cubes approach — a technique that has been somewhat obsoleted by more modern techniques. As such, I’d be quite keen to replace it if I could find a viable (performance, cost & integration time) way to do it. As such, I keep my eye on the forum for mentions of other systems that might fit.
One came up a few months ago by @PawfessorFluff. The tech certainly looks good so, at his/her request I posted my needs for consideration. Here’s a summary of the use of voxels in Snowman Scuffle — both existing and potential future. I’ll probably update this post with clarifications as @PF requests.
Un-maintained software requires the user to fix the bugs (which I’ve done) and extend with any desired new functionality (which I’ve also done).
However the problem is probably one of performance. Here’s a table of performance results with different setups. TerraVol has no LOD facility so these numbers are relatively consistent (depending on camera position).
A quick comment on viewpoint
@PawfessorPuff observed that the SnwScf camera is basically top-down. In case relevant to his understanding, I’ll clarify/correct slightly.
The current camera in SnwScf generally tries to be pointing up the Z-axis pointing down at around 60 degrees. It’s distance if determined by the distance between the camera’s targets (generally players but also certain power-ups, etc). When targets become closer and lie close to similar Z values (i.e. paralleling the X-axis), the camera moves down to present a more side-on view.
The probable single-player mode might use more of a follow-cam approach if it doesn’t confuse players moving between the two modes.
Current voxel usage
The voxels in Snowman Scuffle are currently solely used to represent the snow (not the terrain or obstacles).
At level start the snow is built by one of 3 methods:
- Procedurally using callbacks to an interface I provide — currently giving a pseudo-random Perlin noise based using some parameters to control depth, amplitude, frequencies, etc.
- Loaded heightmap.
- Loaded previously-serialised data.
During gameplay both create and destroy operations are used at present. There are however two complexities:
The first complexity is that, to maintain the appearance of snow, all operations must produce smooth edges across their surface (e.g. a sphere cut from a plane should look like exactly that boolean operation). When I initially implemented, the default approach modified the isovalues to their ‘most outside’ value (-1 in TerraVol) which produced ridges in the sphere. To solve this I apply different isovalue modifications within the sphere (full removal) to on at the surface (linearly interpolated towards the outside). With a little tuning of the sphere overall size, this produced the smooth outlines I wanted.
The second complexity is wishing to know which player destroyed what snow. For some game modes, the amount of snow destroyed factors into scoring. For rolling (described below), it is also used to add health to the snowman. I implemented this as a passed delegate approach where some delegates cascade (if both score and health info are needed) and said delegates can be built at the start of the level to save GC load.
Rockets (called Carrockets in SnwScf), Mines, future flamethowers, human tanks, etc.
A simple one to understand, they currently all do one sphere destroy operation each.
Another simple one, this is one voxel create operation. The value added is tuned to approximate the size of the snowball that has landed. Small snowballs solidify on landing whereas big, rolling snowballs solidify when their velocity drops too low.
Rolling was trickier to implement. For this I wrote a capsule destroy operation. Both sufficiently large snowballs and snowmen with the correct button held can roll. As a snowball/snowman rolls, the snow that has been passed is periodically destroyed along the vector just passed with the radius of the snowball that’s rolling. It had to be the snow ‘just passed’ otherwise the roller would be immediately dropped into the trench it had just cut then stopped or launched into the air by the ramp right in-front of it! The tricky part is tuning this operation so it doesn’t lag too much. It had to be periodically done to make the operation not too heavy on processing. For now, I have it done every certain distance travelled (though janks and bugs can cause long furrows to be cut as the capsule code notices two distant points need connecting!).
I considered a potential future use of ‘smooth’ operation for melting snow. My current voxel system (TerraVol) doesn’t support that so I’d have to write it myself — as such, its low priority meant I chose not to (yet).
In many respects, I would *love* to have the landscape be voxel-based as well. I have destructive weapons (rocket launchers, mines, etc) that would benefit from a bit more effect and it would [hopefully] be easy to tie into the existing operations. Sadly, I believe the performance impact would be too great with my existing voxel approach due to causing too much load. The reason for this is a change I made to TerraVol to allow it to create sufficiently detailed snow models — specifically the size of my smallest-snowballs. To do that, I scale the whole TerraVol system by 0.1. This allows nice shaping of snow blobs but means 10 times as much geometry all round. I did a little optimizing knowing I’d be dealing with only snow (including disabling multiple materials and vertex colours disabling mud/grass/rock distinctions).
Were I to switch to voxel-based terrain, I’d probably want similar approaches as those mentioned by a recent poster saying things like heightmaps of importing from Unity Terrain / MapMagic / Gaia.
Streaming / roaming
I have a single-player mode in early development that allows players to roam. I haven’t determined how viable it is yet. TerraVol allows for on-the-fly generation / destruction at a radius from a specified point (the camera’s target area in my case). I have one nit in my modified version of TerraVol that causes the snow operations to not be played-back properly on the voxel space. They’re stored but it’s not replaying them in the proper place yet — something in the scaling is yet messing it up.
So, there you have a summary of voxel usage by SnwScf. Maybe not stereotypical voxel usage but it does make for some pleasant gameplay possibilities.
Here’s hoping @PawfessorFluff has some awesome voxel powers to make it even better!