Bringing voxels to Xonotic

Although it's April Fools, no, this isn't a joke (I'm not good at making these xD). Last night I seen a bunch of videos about the technologies coming in future game engines... such as the infamous "unlimited detail". On top were voxels with a technology called marching cubes for smoothness. This allows for destructible / constructible terrain like that of Minecraft, and even models which fall apart (realistic player damage... not that I like gore). Voxelstein is an even more useful example:



I've been wondering if / how Xonotic could have breakable voxel walls like that, even without smoothness factor. This can already be done the hard way, by placing a lot of little func_destructible brushes. But I thought of a way in which this could be done more easily, and want opinions and some help on the implementation.

It would consist of two entity types, both brushes: A func_voxel and a func_voxel_filler. The func_voxel is a single voxel, most commonly a cube textured on all sides (you can do other shapes too). The func_voxel_filler is the filling of the wall, textured with a trigger texture. When the map starts, it will be entirely filled with the func_voxel it targets. Now the func_voxel will have some keys... such as the amount of damage needed to fall off, if voxels just disappear or become physical instead, and how long fallen voxels last after being detached (debris).

Long story short, these are the steps a mapper would take to create a voxel wall:

1 - Open netRadiant and make your map as usual, but leave an empty space where the voxel wall will come.

2 - Create a small brush (most commonly a cube) and texture it on all sides with the appropriate texture. It can be placed anywhere in map bounds, since this specific entity will only be used for reference and not appear on the map.

3 - Make the little cube a func_voxel and give it a few keys such as health, and of course a targetname.

4 - Now in the area where you want your voxel wall to appear, create a large brush with the common_trigger texture. You'll want to create it as if that brush is the wall, same way you do normal surfaces.

5 - Make this brush a func_voxel_filler, and set its target to the targetname of the func_voxel. An angle key would specify how the voxel is rotated.

6 - Compile the map and open it in Xonotic. The func_voxel_filler is now filled with copies of the func_voxel. In case that's a pure cube, it will look exactly like a normal wall (probably a bit pixelated due to texture mapping).

7 - Now shoot the wall a few times, preferably with a splash damage weapon. Once each voxel takes enough damage, it will fall off and you can dig through the wall.

Here's an image showing how this would look in a final stage. Observe the entity names as well.



Now this method has several disadvantages, the greatest being performance. The smaller a voxel is, the greater the quality but at the same time, the lower the frame rate. You'll probably want your wall to be about 6 voxels thick at most, voxels representing bricks instead of pixel-sized bits. A voxel wall will also not vis (obviously) so keep this in mind. It will be the mapper's responsibility to use the feature wisely and check performance.

The tricky part is reading each spot on a virtual grid inside the filler brush, that grid consisting of the voxel's size and rotation. So no matter how it's rotated, each voxel neighbors the other one perfectly. Spawning the voxels will use a for loop. I will require some help with this formula, so if anyone knows how to do it please tell me. For getting the voxel's size, self.mins and self.maxs should work.

Please let me know what you think. If you believe this implementation has an issue, tell me what to correct or post your own idea. I want to hear suggestions and get an ok from the admins before starting this, so my work won't get lost and I won't have to beg for a merge Also wanna know who else wants this and if I'm doing it for a reason, or I'm the only one into this whole voxel thing.

Your image breaks the template, makes your post unreadable.

Your image breaks the template, makes your post unreadable.

Sorry, I thought the forum automatically resizes large images. Will fix.

Xoncraft? Sounds beyond awesome, maybe it could be a mutator.

Xoncraft? Sounds beyond awesome, maybe it could be a mutator.

It would be difficult to achieve voxel terrain like that of Minecraft, because there wouldn't be a randomness factor and a seed. A mutator wouldn't make sense either, since the mapper places the entities. But something a little similar to MC could be squeezed out on a small scale, if someone wants to for fun The purpose will be realistic destructible walls that which player can dig through.

Dude, this is an awesome idea. This could give people HUGE fps boosts while making the game look better. It might even be on technology sites and it could create a storm if it's handled well. Seems like a lot of work though. Oh and please refrain from using so many question marks!

EDIT
I've just realised - the commas are replaced by question marks... Hahaha APRIL FOOLS!

This an April Fool's joke? Because to my understanding voxels are a real pain in the ass to work with and are VERY taxing if properly animated.

EDIT
I see what you did there (looks at mods) nice lol

A few thoughts on it:

Having destructible terrain could be really cool on some maps, but a major headache on others. Breaking a straight-line path between bases in a CTF map immediately comes to mind, or creating a void around your team's flag as a defensive strategy. Destroying terrain on a space map could be even more of a headache. Imagine "drilling" holes out from under the spawn points, either going to space or just creating pits to capture victims for use with grenade-style weapons.

This would certainly make mapping more difficult, if you wanted to create destructible and non-destructible terrain mixtures. When is it good to have a wall be destructible? When is it not? Where could it be abused, making the map unbalanced?

What is the potential impact on equipment spawn-points? Would armor or weapons just hover in mid-air, or would they fall? Same question for CTF flags.

Realtime voxels look like crap on current hardware. Well, they might work for people with insatiable 8-bit nostalgia. But to mix them with a game like Xonotic, it's seems just pointless to me.

Though voxel technology is somewhat impressive/promising I cannot see the benefit for Xonotic. Destructable environment makes sense in games like Miner Wars, but it would break Xonotic gameplay if you could just create alternative routes at will.

I don't think creating them is that much of problem if doing so would take a lot of time. I've played Voxelstein 3D and making holes in the wall of your size took a minute or two, unless you used explosives, by that time you could get to other base and back (and on some map maybe several times). Nevermind that I'm talking about crouching holes, so going through them would break the speed, not to mention being a sitting duck, especially while making them. Radically changing landscape for alternate routes is inherently possible, but by regulating speed of destruction, it can become impractical.

Voxels don't make default Xonotic obsolete, but sound like fun "after hours".

A race map with destructible voxels could be fun. Making your own shortcuts as you went! I can't see how it would work for deathmatch though. Deathmatch games normally have to work in some sort of steady state. Imagine after 20 minutes that every map would be the same: just a great big vast expanse with all walls in between having been destroyed.

At the moment, this idea is on hold from my end. That's because I require an implementation which I don't know how to make. Issue is I need to figure out how to detect the volume of a brush and do a for loop at each position using a grid, separating by voxel size in each dimension. I'll require someone to help me with this if they also want the feature.

So for example, if my voxel is a brush at x = 1, y = 2 and z = 1 size (netRadiant units). I tell the filler brush (an entity as well) what rotation the voxel should have using a vector. Now this filler will need a for loop that goes through each possible position inside its brush(es) at a distance of 1 on x, 2 on y and 1 on z. For the voxel's size I can probably use self.mins and self.maxs to get it, but no idea how to make this volume-based loop.

Until then, I might test this by using func_destructible entities on a small map. It would help see how the engine handles voxels, in both terms of performance and looks. Like I said, large voxels should be used only (such as whole bricks) because otherwise performance would probably kill the map. Lightning is also a concern since lightmaps are generated at the position of the entity when netRadiant compiles the map, and voxels would be repetitive copies of the same thing. Since func_door and func_plat have the same issue however, I hope this won't be too visible.

I cannot really see how you will be using the polygon based darkplaces engine for making use of voxel graphics? That's like forfeiting all the performance benefits of a voxel rendering engine while at the same time forfeiting the advantages of polygon rendering?

"... It would help see how the engine handles voxels ..." No it wont, because this is not voxels nor s dp a voxel engine. Having a pile of cubes and having a voxel engine is not the same thing.

If you still feel like messing around with it, you could checkout tzork/modelplanter. it can create such "fake voxel maps". however, it will never be fast enough for anything serious using just small entity based cube models.

I cannot really see how you will be using the polygon based darkplaces engine for making use of voxel graphics? That's like forfeiting all the performance benefits of a voxel rendering engine while at the same time forfeiting the advantages of polygon rendering?

I feel the same.

That'd be "fake voxels" meaning A LOT OF POLYGONS meaning not an FPS boosted but, FPS buried.

I'm not a tech guy so I don't even know why do I respond to this.

PS:

[quote='Halogene' pid='37489' dateline='1333371220']

I don´t think it´s a good idea to mix polygons with voxels. It would be wasting of important time. The Darkplaces engine seems to work pretty well so please don´t add voxels to it!

From my understanding, voxels are surfaces that consist of little blocks which can be broken down individually. But it's true that in this case they would be rather fake voxels, not an engine feature / renderer. I doubt performance would be hurt for using large ones (like the bricks again), but maybe in this case it can be done with func_destructible instead.

The breaking down part s not voxel specific, it just happens voxel based geometry is good for that sort of stuff. And performance would hurt if using this excessively. Not only does darkplaces get slower for every entirety you spawn (regardless of if this ent does anything at all) but you would also need to enable ODE or some custom QC physics for each object when breaking apart since dp cannot do rotated bboxes and does not solve rotation influence on impact (it would look rather daft with a wall falling apart all bricks perfectly aligned x) Add to that that you wont be able to lightmap those ents and its not only slow and moves corny, its also ugly

So as a "interesting project" or for small details (those could be faked as long as they cant block movement when half-broken), its a cool idea. But as a component in Xonotic, without allot of additional engine support, it will likely never really work.