A recent discussion on IRC has led to the topic of voxel support in doom source ports, and more importantly, how to implement them. The discussion has been done before, but it has been several years since then.

Here's what I know so far: The only port to use voxels is ZDoom, due to the use of BUILD code. Allegedly, Ken Silverman will not change his stance on his BUILD source code, even when informed of the current situation. As it stands, the GPL is incompatible with BUILD License code, meaning only ports using the original Doom Source License can use it. Since ZDoom isn't GPL, this is "legal".

Duke3D source was released under "GPL", but it has not been proven by any means that this is the case. Using said code from Duke3D in a GPL-licensed Doom source port may cause legal issues. Allegedly, Ken Silverman has been fighting the Duke3D community over the use of his code, even when any sensible viability for commercial gain has been lost by now.

GPL source ports have several options: Open yet another discussion with Ken Silverman, or implement an alternative. Since the latter is likely the only path to take, a community discussion on how to do voxel rendering is needed, as the math behind the magic is still extremely complicated, and no reference from the BUILD code can be taken. This way, independent implementations can have a common reference free of any legal ambiguity, and ports can also support a common format.

If one reads up on the KVX voxel format, you'll find that most of the magic is done for you. Each column of voxels has a bit field for which of the 6 faces are visible (for Doom we don't care about the top or bottom face). All you need to do is render the columns that are marked visible based on player's angle. The rest is in theory the same post drawing method used for 2D sprites.

Csonicgo said:
Duke3D source was released under "GPL", but it has not been proven by any means that this is the case. Using said code from Duke3D in a GPL-licensed Doom source port may cause legal issues. Allegedly, Ken Silverman has been fighting the Duke3D community over the use of his code, even when any sensible viability for commercial gain has been lost by now.

The Duke3D game module is GPL, the build engine that it links to is not. The GPL allows the author to grant linking exceptions to use non-free libraries. (Provided all authors agree.)

Nah, voxels will never get independently developped. They're just too hard to do alone, without any support from a genius who cares enough to protect his work in the first place!1 Since he needed to do that, how would you imagine we'd be able to pull off something similar that can be a viable alternative to Build?!?!

It's funny how people "rediscover" voxels from time to time and start daydreaming about a major comeback, a major turn of the 3d graphics and gaming industry towards voxels etc., while ignoring all the technical reasons that made them flop in the first place.

For all effects and purposes, polygon graphics are easier to design, sculpt, model, scale, animate and manipulate in real-time (which is of paramount importance for anything hoping to get used in a modern video game or movie).

schwerpunk said:
You may as well say the same thing about software rendering

Actually no, that's comparing apples to oranges. We're discussing the mathematical/computational models behind a scene visualization technology and the ease of creating content for it, not whether it's performed in hardware or software.

For instance, you can do texture filtering, skeleton animation and polygons in software (guess what: that's what the very first Half Life game did, and most PC titles till 1999 or so had a software renderer as a fallback), or you could do voxels in dedicated hardware, if such a beast ever existed (which I doubt).

But no matter what computer/hardware platform you use, you can't get around the mathematical/computational/memory and content creation limitations of each method, and voxels just have too many of them to be practical. Just the fact that the "state of the art" for creating voxel models utilized modelling tools designed for polygon models, speaks lots about how viable it is. There could never be a 100% "voxel native" graphics industry.

TL;DR schwerpunk trashes against harsh reality, and attempts to invent a fantasy world where every game is delta force outcast, God help us all

Maes said:
Actually no, that's comparing apples to oranges. We're discussing the mathematical/computational models behind a scene visualization technology and the ease of creating content for it, not whether it's performed in hardware or software.

For instance, you can do texture filtering, skeleton animation and polygons in software (guess what: that's what the very first Half Life game did, and most PC titles till 1999 or so had a software renderer as a fallback), or you could do voxels in dedicated hardware, if such a beast ever existed (which I doubt).

I should've known you'd school me on the specifics, and I'm sure you're right. But allow me this ignorant plea: Are the hurdles really so insurmountable? I ask as a genuine -- if hopeful -- noob, because somehow Doom modders were able to translate switches and decorations into voxels. I'm sure it would be a lot more difficult to do the same for levels, but certainly it can't be as impossible as you make it sound... After all, Voxelstein 3D exists*. Perhaps I'm wrong in listing these advances, and they're all a result of pilfered BUILD code, and not original creations, as I thought.

Maybe I'm still not grokking the gulf between these two particular fruits, but my comparison was more of a general one. Re software rendering: when developing a game-engine or sourceport, isn't it a lot easier to put all your graphical tasks onto a video-card, than it is to run them through a CPU? I'm thinking a somewhat similar thing could be said of voxel rendering (whether 100% voxel, or just partially, as in the first link above) - that it's harder than sticking with industry norms, but that people do it anyway, for whatever reasons.

That gives me hope. And hopefully, it isn't misplaced. :/

Maes said:
But no matter what computer/hardware platform you use, you can't get around the mathematical/computational/memory and content creation limitations of each method, and voxels just have too many of them to be practical. Just the fact that the "state of the art" for creating voxel models utilized modelling tools designed for polygon models, speaks lots about how viable it is. There could never be a 100% "voxel native" graphics industry.

No, and I wouldn't wish it either. Voxel rendering, from the outset, has been a niche renderer. But if someone wants to put in the leg-work (or finger-work) into implementing its support in our sourceports, I don't see any reason to stop them. I don't think anyone's thinking they're going to revolutionise the game industry by having a voxel chaingun in Doom, but for our little part of the world, it would be a pretty big, and welcome, advance!

*this is a bit of an aside; I haven't seen anyone seriously proposing making entire Doom levels out of voxels!

...with a lot of manual editing and elbow grease. It's not that it's literally impossible, but that it's very difficult to do in a productively efficient way with existing tools, and there's no incentive for anyone to develop better ones, since it's never going to be better or easier than polygons in ANY area, including content creation, except for very low resolution models.

E.g. search for all those "high rez sprites" thread on DW. See how labor intensive they are (people manage to do a frame or two before giving up). Now blow this up to three dimensions. Not pretty.

schwerpunk said:Voxelstein 3D exists*. Perhaps I'm wrong in listing these advances, and they're all a result of pilfered BUILD code, and not original creations, as I thought.

These resources are of reasonably low resolution and complexity, and certainly their author(s) paid the price in terms of time. It's not a question of engine, it's a question of which poor devil will sit down and painstakingly build all those voxel models "brick by brick".

schwerpunk said:
Re software rendering: when developing a game-engine or sourceport, isn't it a lot easier to put all your graphical tasks onto a video-card, than it is to run them through a CPU?

The answer depends on what the hardware is capable of and what software the developer has at his disposal to make said task easier. You may have ultra-powerful graphics hardware but shitty or no APIs (*cough cough* Atari Jaguar *cough cough*) or just a bunch of powerful CPUs (*cough cough* Sega 32X *cough cough*) or have to account for multiple possible hardware standards (*cough cough* early 3D PC video cards *cough cough*).

It may be easier to leave everything on the CPU for an engine like Doom's (Doom's engine is notoriously difficult to adapt and optimize for 3D APIs), while a game coded from scratch with pure polygons, textures and flashy effects in mind will probably be easier to build around an existing 2D/3D API than come up with your own engine (e.g. Minecraft, pretty much any AAA title).

schwerpunk said:
*this is a bit of an aside; I haven't seen anyone seriously proposing making entire Doom levels out of voxels!

I'm sure someone has done it in Minecraft.

In any case, the viability of the voxel concept (and its limitations) IMO are all plain as day in Minecraft.

Anybody trying to get a linking exception for Doom is probably hard out of luck, so, it's silly to even discuss it IMO. For EE, you would need the permission of some 50 odd people, one of whom we believe may have passed away at some point in the last 10 years (so his copyrights would belong to his heirs, if any exist, and depending on the legal equations around inheritance and wills). Plus, speaking from my personal POV, I wouldn't do that anyway. EE is a pure codebase. Everything in it is either legally GPLv3 or under a compatible license. I'm not gonna fuck that up now after +10 years of development just for some eye candy created by a guy who comes off like a real jerk when you email him a simple question.

I thought there was actually an independent voxel implementation in progress in some port, I want to say it was DelphiDoom. Did anything ever come of that?

The problems with voxels, for anyone actually determined to look into them, are three-fold:

Need code to load the chosen format, which seems to be KVX (this is fairly trivial and can be done 100% de novo with a sufficient description of the file format)

Need code to project in 3D space and "walk through" the voxels to do this columnization process that Blzut is vaguely describing. I dunno how to do that. It's beyond my natural skill set with what little clear info there is on the mathematical specifics.

Need code to make them work with Doom's crazy screenspace clipping algorithm and the vissprites/drawsegs drawing pass.

Quasar said:
Need code to make them work with Doom's crazy screenspace clipping algorithm and the vissprites/drawsegs drawing pass.

Well, there's the workaround of converting them to 3D models in-game (basically a bunch of cubes, isn't that what that voxel-GZDoom fork did?) and let the graphics hardware handle them like any other object), but that will let down a lot of people who wanted to see them in pure software mode (I'm not sure if it's GZDoom-only, someone correct me).

However, just by the fact that the only voxelified objects so far, after 7 years, are pickups and some decorations, that should shatter any illusions anyone has about even a complete monster, let alone all of them, getting voxel models.

Quasar said:
Anybody trying to get a linking exception for Doom is probably hard out of luck, so, it's silly to even discuss it IMO.

I'm guessing you pointed this out just for the record, but the discussion was merely to explain how eduke32 can legally be GPL while the build engine remains non-free. It's not quite as ambiguous as it was being made out to be. Looking at the eduke32 source (or any other duke3d source) you can see that all the build stuff is still labelled as buildlic and only the Duke3D game module is GPL.

Obviously using build code in GPL Doom is a no go since I'm sure id Software has no interest in approving such exception.

Quasar said:
Need code to make them work with Doom's crazy screenspace clipping algorithm and the vissprites/drawsegs drawing pass.

For what it's worth, ZDoom has a lot of quirks with voxels since they're treated just like normal sprites except for how they're rendered. (Although Randy did eventually add a different sorting mode in order to help with some large voxels.)

Blzut3 said:
For what it's worth, ZDoom has a lot of quirks with voxels since they're treated just like normal sprites except for how they're rendered. (Although Randy did eventually add a different sorting mode in order to help with some large voxels.)

I do recall someone's unfortunate attempt at a voxel bridge falling victim to what I think you're talking about. It's not a simple challenge, that's for sure.

I'm not gonna fuck that up now after +10 years of development just for some eye candy created by a guy who comes off like a real jerk when you email him a simple question.

LOL

Maes:

But no matter what computer/hardware platform you use, you can't get around the mathematical/computational/memory and content creation limitations of each method, and voxels just have too many of them to be practical. Just the fact that the "state of the art" for creating voxel models utilized modelling tools designed for polygon models, speaks lots about how viable it is. There could never be a 100% "voxel native" graphics industry.

Despite existance of computers like the Cray c90 (1991), we still have awful computing hardware based off 486 designs at home. No matter how many TFLOPS our cpu's at home are capable of, they will never achieve their rated numbers since programs are typically larger than cpu cache (cache runs out and main memory is accessed over a seperate bus being shared with pci slots and what not). Ever wonder why programmers had such a hard time with the Sega Saturn? Similar problem here (not enough cache to prevent bus access to main memory). Main memory has to be the cpu cache to sustain rated numbers (like a cray). If we had cpu cache's with 16GB or more space, then we'd be talking. But that's not the case. AMD's K6 cpu's were one of few cpu's that had level 3 cache on the motherboard; why we don't have something like that today (and upgradeable at that) is beyond me. We wouldn't even need video cards with 16GB cache and 16 cpu cores probably.

Out of interest I decided to take a quick look at this and I very much doubt its of any use to a software rendered port (such as Eternity Engine). The reason being that the whole world is comprised of one gigantic voxel model, which, is dynamically converted to cuboids and stored into OpenGL display lists and/or VBOs for rendering. OpenGL's built-in hidden face removal is then relied upon during drawing. In other words, its effectively the same algorithm used by GZDoom.

It will be interesting to see what will happen when/if one day, ALL memory in our computers will be made of the same "stuff" as cache memory or, even better, as CPU registers.

Then, there will be in theory no memory hierarchy, since all memories would be exactly equal (and as fast as possible). Actually, some (older) computer systems using relatively expensive SRAM could have only minor speed differences between their CPU's registers and their main memory, but none considered that a good thing.

The reason it's not done now is cost: a 6-transistor register-grade flip-flop costs WAY more than a transistor + capacitor DRAM flip-flop cell, and it's not possible to fit as many in a given space (plus the power consumption), so it will always be tempting to trade speed for quantity.

However, even if ALL memory was made equal, there would still be the problem of physical separation and data transfer between banks of memory: those further away from the CPU would have longer propagation delays anyway, and would have to slow down. Memory on board of expansions cards would need to pass through buses that, simply by physical laws, could never be fast as the CPU's internal interconnects, so there would be no point in making all memory equally fast.

Even if ALL memory in a system was integrated in the CPU, unless it was in actual registers buried right near the various parts of the CPU that used them directly, it would still need to be a tad slower/delayed, especially if frequencies started going up again.