Voxel Doom Port!

Actually, the quantization of vertex coordinate information inherent in the MD2 format makes it particularly suitable for representing discreet voxel models in an intermediate form. Perhaps the LOD information in the voxel could be adapted also, using the DMD model format (I'd need to look at how it works in the voxel formats so I can't say for sure).

Edit:

1) Open voxel model in Voxel3D and save as OBJ.
2) Convert OBJ to MD2.
3) Load in MD2-supporting port.

Quasar said:

So effectively I'd say you've either guaranteed one of two things:

• Eternity's support for this will end up being irrelevant
  

Well actually I guess that's pretty much it.

And what's the other?

Plus I thought Stroggos was going to be the one working on it...

(Judging from a cursory glance at the specs, writing a loader that converts KVX objects into VOX objects, or vice-versa, seems straightforward enough to do without lifting code from Ken's implementation; at least as long as you ignore mip levels.)

Gez said:

And what's the other?

Plus I thought Stroggos was going to be the one working on it...

(Judging from a cursory glance at the specs, writing a loader that converts KVX objects into VOX objects, or vice-versa, seems straightforward enough to do without lifting code from Ken's implementation; at least as long as you ignore mip levels.)

I suppose, although the only real point of KVX/KV6 is the RLE support. I can load them just fine using the SLAB6 specs, but there's no available reference implementation for how you're supposed to actually step through such a structure for rendering, except for the Build engine. And that is off-limits for us. So yes I can convert them into unpacked arrays, which could potentially use a large amount of memory and offers no speedup.

An additional complication is the fact that not a one of these formats contains any metadata, meaning you cannot support more than one without an additional cache of format information somewhere to tell you what format each lump is in. Otherwise they're impossible to distinguish.

Stroggos has said he wants to work on it. I'm waiting to see how that will progress. If it doesn't, I had intended to try to step in myself, but there's a critical shortage on information for rendering voxel models. You can't swing a cat for finding voxel *terrain* implementations, but only so much of that is of any value to the problem of models, since in a 3D engine you need 6 degrees of freedom, not four. That means all their clever optimization tricks (read also gross hacks) are not applicable.

Anybody can just copypasta a bunch of code from some mathematical genius's game engine and call that progress. I'd be orders of magnitude more impressed if this were an original implementation, or at least one employing some approaches that are fit specifically for the DOOM engine.

There must be references available for a software renderer. Its basically just a classic ray-tracing of a sparse 3d-volume - something which renderers for medical imaging have been doing for decades (think MRI).

Quasar said:

An additional complication is the fact that not a one of these formats contains any metadata, meaning you cannot support more than one without an additional cache of format information somewhere to tell you what format each lump is in. Otherwise they're impossible to distinguish.

That's not quite correct. What you can do is check the file size and see if that matches what the format would be. Since VOX is just an uncompressed three-dimensional array it should be really easy to check if it could be. Otherwise do a few more checks to see if the loaded data matches KVX. I'm quite certain that I can write a loader that can distinguish both.

Yeah, with size checks, range checks, and other such sanity checks, it should be easy enough to distinguish between both. Give me an OpenGL voxel viewer I can plug in SLADE3 and you'll see. :)

Graf Zahl said:

That's not quite correct. What you can do is check the file size and see if that matches what the format would be. Since VOX is just an uncompressed three-dimensional array it should be really easy to check if it could be. Otherwise do a few more checks to see if the loaded data matches KVX. I'm quite certain that I can write a loader that can distinguish both.

At best I think you'll be guessing. The existing tool does put certain size limits on the voxels but I wouldn't want to write a loader that assumes those limits will never be extended by a better tool, as that creates an artificial limitation that will come back and bite us later.

So I suppose probably you're going to end up pre-parsing the entire file to see if the KV6/KVX column offsets make sense, like zdoom does with DOOM patches to distinguish them from linear data. That's all fine and good except it requires twice the work and four times the code. For me it turns something simple that was already finished into something I just about can't be bothered to screw with, given what a headache it's going to turn into.

For a tube with a box around it, the rocket launcher took a surprisingly large amount of time and effort:

Since voxels don't need a rotation number, how about that free space to indicate the format? E.g. TROOAV would be in Vox format, TROOAK would be in Kvx format, and TROOA6 would be in kv6 format. Or any other convention which makes sense. (Could use the full extension, if we're ditching mirroring. TROOAVOX, TROOAKVX, TROOAKV6.)

Advantage? Modders can easily pack both VOX and KVX versions of the same voxel object in a wad file without conflict, engines are free to implement just their favorite format and ignore the others, and the need for format identification code or additional content definition lump is circumvented.

DooMAD said:

For a tube with a box around it, the rocket launcher took a surprisingly large amount of time and effort:

Oh my - love it.
Well done!

Gez said:

Since voxels don't need a rotation number, how about that free space to indicate the format? E.g. TROOAV would be in Vox format, TROOAK would be in Kvx format, and TROOA6 would be in kv6 format. Or any other convention which makes sense. (Could use the full extension, if we're ditching mirroring. TROOAVOX, TROOAKVX, TROOAKV6.)

Advantage? Modders can easily pack both VOX and KVX versions of the same voxel object in a wad file without conflict, engines are free to implement just their favorite format and ignore the others, and the need for format identification code or additional content definition lump is circumvented.

EE was going to do something like that already but esselfortium and CSonicGo were advocating a namespace *instead* of that, for various reasons I'd have to let them explain.

That said, I think it's a good idea. The latter one in particular - the former not as much because TROOA6 looks too much like a normal sprite lump and might cause issues/confusion when extracting lumps from wads. There's plenty of extra space in the lump name to denote the format, space that is otherwise not being used at all.

Of course in zips/pk3's/etc it might make more sense to have them under directories such as vox/ or kvx/ and forego the suffixing.

Gez said:

Since voxels don't need a rotation number, how about that free space to indicate the format? E.g. TROOAV would be in Vox format, TROOAK would be in Kvx format, and TROOA6 would be in kv6 format. Or any other convention which makes sense. (Could use the full extension, if we're ditching mirroring. TROOAVOX, TROOAKVX, TROOAKV6.)

I'm dead set against such nonsense.

Seriously, it's not that hard to validate a KVX file. It works for Doom patches, PCX and TGA in ZDoom - all formats without a decent identifying header. I've never seen a misidentification. The same can be done here. KVX needs to follow certain rules to be valid and if these fail it's either broken or VOX. Now, VOX is a straight 3-dimensional array of data. If the size of the data is to small it's obviously invalid and if the size is too large one can always decide later whether to load it anyway or skip it.

But coding the format into the file name is - forgive me for the harsh words - an utterly harebrained idea that should not under any circumstances be considered! If I have any say in it I'll do anything I can to prevent it from happening.

This has probably been suggested but at the risk of being vomited over:

VOXINFO

Text format mapping lumps to sprites i.e.
LumpName SpriteName Format [optional parameters for format if any i.e. mip level for KVX]

// Comments and blank lines ignored
"VCOL1A0" "COL1A0" VOX
"VCOL2A01" "COL2A0" KVX MIP1
"VCOL2A02" "COL2A0" KVX MIP2

Why?

There's nothing in that file that can't be automated. It's just a needless layer of abstraction. Unlike models you can map voxels 1:1 to sprite frames.

And again: If a file can neither be identified as VOX or KVX there's only 2 possibilities:

1. it's broken
2. it's something else

So any means to specify the format is just an open invitation to avoidable problems.

......This isn't going to be a community effort, is it? Build code? Seriously?

Graf Zahl said:

I'm dead set against such nonsense.

I don't see this as conceptually worse than the good old MS-DOS file extensions...

Mind you, I do prefer testing the data myself, but if Quasar doesn't want to...

Gez said:

but if Quasar doesn't want to...

That's not my problem. I don't share these paranoid concerns. On the contrary, I trust some decently written analyzer code a lot more than expecting the modders to get it right each time. That'd amount to a failure rate of a lot less than 1% to one that's more likely between 10 and 20% and would be a constant source of frustration.

I just added detection of VOX and KVX formats to SLADE3. Guaranteed 0% Build code inside, as it was written using only the specs as reference, and the examples from this thread and the slab6 package as validation.

Alternatively, Randy said that the R_LoadKVX function in ZDoom is written from spec as well, not derived from Build code.

Gez said:

I just added detection of VOX and KVX formats to SLADE3. Guaranteed 0% Build code inside, as it was written using only the specs as reference, and the examples from this thread and the slab6 package as validation.

Alternatively, Randy said that the R_LoadKVX function in ZDoom is written from spec as well, not derived from Build code.

Is Build code still being used to DRAW those voxels? :3c

Quasar said:

• Eternity's support for this will end up being irrelevant
  

Indeed.

I was a little bit disappointed when Graf mentioned that Randy will add voxels to ZDoom. Here was a feature that might give another source port something cool to distinguish itself, a reason for people to try another port and maybe mod for it. But no, the Borg of ZDoom will assimilate all.

I don't blame Randy for adding it. Voxel support has come up many times, so maybe he's gradually decided on implementing it.

Cross-port compatibility is very possible with decorate for both ports, mapinfo and emapinfo, UDMF maps compatible with both ports, and soon with voxel models that can load in both. The Lost Episode was good in providing support for both, and I'm wondering why more map packs don't do the same instead of being ZDoom from the start. ( I guess that's the point, too many people just use ZDoom from the start without considering other options). And then there's Vaporware and other projects utilizing Eternity's features.

andrewj said:

the Borg of ZDoom will assimilate all.

I've been saying this for a while now. ZBorg is ZBorg.

Not knowing a lot about voxel rendering, I'm curious: ingame, will these look effectively like primitive models (i.e. they'll look ingame like they do in DoomAD's shots), or will they essentially look like sprites being drawn with an infinite number of rotations?

Csonicgo said:

Is Build code still being used to DRAW those voxels? :3c

Irrelevant. Once you have the voxel data, you can draw it any way you like. KVX volumes are basically a 3D version of Doom's patch_t structure, describing vertical columns of voxels, so if you've got code to render Doom's sprites and textures, you can use it to draw KVX volumes, with minimal changes.

The one point that is most strongly in favor of KVX over VOX is that this format contains info for offsetting the volume; just like Doom sprites contain offset information. VOX doesn't, so you'd have to assume that the pivot point is always center bottom or something like that; not necessarily reliable if you have asymmetrical shapes.

// Actually, this is just R_DrawColumn with an extra width parameter.

Quasar said:

• Eternity's support for this will end up being irrelevant
  

IMO, that's a pretty strange attitude for a port author to have about their own port. I would have thought Eternity existed and has continued to because yourself wasn't and aren't satisfied with the existing ports.

Graf Zahl said:

Why?

As Gez points out the VOX format doesn't have offset information.

@essel:
They should hopefully look like DooMADs pictures. If you want an example you could perhaps try Blood it has a downloadable demo. IIRC there are voxel gravestones and items on the first level.

4mer said:

As Gez points out the VOX format doesn't have offset information.

Then don't use it when you need them. External definition lumps are always a mess if they need to describe data that should be self contained.

See all the problems that are present with GZDoom's definitions for models and dynamic lights. For the lights it can at least be done directly in DECORATE but it still means that anything that needs external definitions is a bit messy. I'd rather avoid such things here from the start.

Vermil said:

Quasar said:
* Eternity's support for this will end up being irrelevant

IMO, that's a pretty strange attitude for a port author to have about their own port. I would have thought Eternity existed and has continued to because yourself wasn't and aren't satisfied with the existing ports.

Yeah, it's not like there's a cross-port standard for portals, but that's still a feature Eternity benefits from. And no one said you have to use Build code anyway.

Summary of what has happened thus far:

<ZDoom Mapper> Voxels?
<ZDoom Programmers> no, shut up
<ZDoom Mapper> Voxels seriously this time?
<ZDoom Programmers> wtf no it looks like Lego, go away
<Doomworld Poster> Hey, how about voxels?
<ZDoom Programmers> LOL
<Eternity Developer> Sure, why not? I'll begin work on it!
<Doomworld forums> Cool!
<ZDoom Programmers> LOLOL WE VOXEL NOW THE ZDOOM IS BEST DOOM
<Everyone else in the universe> ...What the fuck was that?

Well, I guess voxels don't look like Legos when you're the one ahead in the arms race, eh?

For years many have proposed voxels in Doom only to have hopes shot down by the usual bunch, many who will read this very message ( you know who you are). Then when Quasar actually breaks ground and attempts to get the ball rolling, The same ones who blasted the idea for YEARS suddenly seem quiet, accepting, and willing to work with the idea-- as long as their side is behind it... and for ONLY that reason; to one-up the others simply because someone else started work on something many wanted to implement -- a unique feature people had wanted for quite some time. And I won't let this go quietly!

Now I know why Quasar feels like giving up sometimes. If you wonder why people seem to hate on ZDoom, it's nonsense like this! I have nothing against Randy and his work; I don't think he is exactly up to speed on what exactly has been going on, so I'll give him a pass on this. To the others, however, shame on you!

Csonicgo said:

Summary of what has happened thus far:

<ZDoom Mapper> Voxels?
<ZDoom Programmers> no, shut up
<ZDoom Mapper> Voxels seriously this time?
<ZDoom Programmers> wtf no it looks like Lego, go away
<Doomworld Poster> Hey, how about voxels?
<ZDoom Programmers> LOL
<Eternity Developer> Sure, why not? I'll begin work on it!
<Doomworld forums> Cool!
<ZDoom Programmers> LOLOL WE VOXEL NOW THE ZDOOM IS BEST DOOM
<Everyone else in the universe> ...What the fuck was that?

Well, I guess voxels don't look like Legos when you're the one ahead in the arms race, eh?

Eternity fanboys and their conspiracy throries! :D

I always said that the software renderer is Randy's business - and that was the only reason to discount voxels. I'm still not sold on them but if they get done, they should be done right at least.