Voxel Doom Port!

[DooMAD]

Stroggos said:

The only model I think would be hard would be the Chaingun! But ATM I'm looking and writing little Voxel programmes to test various things.

Yes, had a play with that one but getting confused. I can only fit 4 barrels in, unless I make it wider than it is tall. Also, I'm really not sure what shape the rest of it is supposed to be.

Graf Zahl said:

Picures are nice. But can you post a download link so people can mess around with these thing? Also, do you have some specifications about the format?

I'll have to update both with the box of rockets when it's done, but:

*.vox format
*.v3b format

V3B is a proprietary format used by Voxel3D which is the program I've been using. VOX format is kind of the base standard and I would assume that's what was used in Blood and other such games. You can edit those with Slab6. There's a converter here to turn *.v3b into *.vox format. I have no idea about the specifications of either format. You're probably better off asking on Ken Silverman's forum.

[Stroggos]

If you download his Voxlap engine it has a basic implementation of the VOX format quite simply laid out in the readme documentation.

[Mordeth]

Maes said:
For objects that already have rotations, it could be automated -somewhat, by silhouetting them and "sculpting" their silhouettes into a "marble block" of voxels.

I've posted this before, but the Doom sprites cannot be converted to a voxel model without compromises. Reason being that the different angles of the same pose don't align with eachother. Eg the Imp's front sprite is drawn higher than its back sprite.

printz said:
I'd rather use voxels for creating scenery and stuff like bridges, columns and other detailed objects -- the sort of things that in modern additive FPSs are drawn by modeling not by brushing. Sort off analogous.

This :)

[exl]

DooMAD said:

I have no idea about the specifications of either format. You're probably better off asking on Ken Silverman's forum.

There's a description of the file formats in the slab6 zip's readme. Reading them made me wonder though, which file format is the best for Doom voxels? VOX uses a VGA palette (64 values per channel), which seems a bit limited. KVX has the same palette limitation, but does have mipmapping levels, for what that's worth. KV6 stores 8 bits per channel color values per voxel. Seems to be the more complex format, though.

[Graf Zahl]

Too bad that the format has absolutely no means of proper identification and no anchor point. Which makes it pretty useless without an accompanying definition lump.

KVX looks better but still fails to identify properly. There's absolutely no way to write an engine that can handle both reliably without depending on the file name.

[printz]

Mordeth said:

This :)

The problem I imagine is that voxels being all cubic and that, slanted voxel-made surfaces will look fudged in the game, unlike slanted linedefs, or slopes.

[Maes]

What about a hybrid format that's compatible with existing sprites?

Imagine storing "voxel" sprites as multiple 2D-layers (each of which is still readable as a normal Doom patch.

E.g. imagine coming up with a voxel IMP that's as wide and as large as the original, plus it's e.g. 16 pixels deep (for it's A walking animation).

Instead of 8 rotations from A0-A7, you could store 16 virtual "rotations" from to A0-AF (or with a different naming scheme, e.g. TROOAXyz where "X" would mean "voxel" and yz would be a hex number 0-255 to indicate number of layer.

So for this example we would have TROOAX00-TROOAX0F

Each "slice" would represent a layer of voxels, and their centering/screen offsets would be stored as in normal sprites. Actually, it would even be possible to display those slices as patches (they would look like a "hollow" imp or a TAC scan of an imp, in this case, depending on how you "fill" the interior. Also, it would be possible to define "misaligned" layers in order to save space on large sprites with big gaps. Kind of like extending doom's transparency compressions to the third dimension.

An other big advantage is that layers could be drawn with standard 2D picture/sprite editing tools, and be inspected with existing WAD tools.

[Graf Zahl]

Maes said:

Kind of like extending doom's transparency compressions to the third dimension.

Ugh...

If disk space is a concern I'd rather use zlib than creating such a messed up format.

[printz]

Maes said:

and yz would be a hex number 0-255

That's too fucking limiting.

[Maes]

printz said:

That's too fucking limiting.

As is the usual height limitation for sprites, yet when was the last time you saw tall sprites that were not used as part of jokewad? Unless we're talking hi-res, vanilla doom can't even display stuff over 200 pixels tall in its full detail witout clipping it.

Now, normally sprite and patch width is not inherently limited (but still, when is the last time you saw a sprite so wide as to exceed 255 pixels in "depth" when viewed from the side? Unless you are planning to make a snake/train/airplane/rocket mod, that should not be a problem.

Then again you can forego the X in the filename and store stuff as TROOA000, TROOA001... etc. so when the loader sees "sprites" with three digit codes (theoretical max depth 4096, which should be enough to create fucking voxel TRAIN or JUMBO JET). The only remaining issue would be the same height limitation that affects normal patches -using the DeepSea tall patch format could be a possible workaround.

@Graf: it's just a suggestion. No matter what format you consider, all have their limitations. What I proposed is deliberately close to the existing sprite format (in fact it's just a hack that as far as the original engine goes, should be completely transparent), and would allow even non-3d modelers to take a shot at it using nothing more than MS Paint and some patience.

[printz]

Spiderdemon clones are good candidates for surpassing that stupid byte limit in width. And we're not talking vanilla Doom any more.

[Graf Zahl]

And don't forget scaling for higher resolution.

[andrewj]

printz said:

The problem I imagine is that voxels being all cubic and that, slanted voxel-made surfaces will look fudged in the game, unlike slanted linedefs, or slopes.

I think that could be ameliorated by rendering jagged edges into 45 degree diagonals, at least on the 2D plane (doing this in a fully 3D way might be possible, but considerably more difficult).

[Gez]

Maes said:

As is the usual height limitation for sprites, yet when was the last time you saw tall sprites that were not used as part of jokewad?

Harmony

[Maes]

Seriously, name me one well-known high-res sprite project. AFAIK hi-res, just like HiColor or True Color never took off for Doom, including source ports. Those using 3D Models and OpenGL are workarounds, rather than exceptions.

[kristus]

Maes said:

Seriously, name me one well-known high-res sprite project. AFAIK hi-res, just like HiColor or True Color never took off for Doom, including source ports. Those using 3D Models and OpenGL are workarounds, rather than exceptions.

Gez said:

Harmony

and Foreverhood and Aschuwn Deuwm TOOOUUUU.

[Graf Zahl]

Maes said:

Seriously, name me one well-known high-res sprite project. AFAIK hi-res, just like HiColor or True Color never took off for Doom, including source ports. Those using 3D Models and OpenGL are workarounds, rather than exceptions.

Someone may always need it. A 255 limit is just stupid.

[Spleen]

Maes said:

just like HiColor or True Color never took off for Doom, including source ports.

I'm sure if you ask excellent sprite artists like Eriance or Lazure, they'll tell you that they prefer working in full color.

[Maes]

Graf Zahl said:

Someone may always need it. A 255 limit is just stupid.

Are you referring to the colors or the z-depth here? The 256 color limit is something well-understood and long-accepted when we're dealing with Doom, and some people may even prefer the way it looks, so it's about choice as well as familiarity/relative compatibililty with existing tools and means (OMG, I'm starting to sound like myk here...)

Besides, whenever I hear of truecolor and hi-res in source ports, my mind immediately flies to something like this. Not the most indicative example, but it does strikingly reveal some of the problems one encounters when working with truecolor or hires sprites (the latter is debatable...so let's keep to truecolor).

I have no idea who those sprite artists are or even if they're involved with Doom in any way, but of course if they're supposed to be "excellent" in their field I suppose they'd prefer using the best means possible for their work, aka tablets and full color, rather than MS Paint pixel art with a limited palette.

This does not change the fact that for technical and historical reasons, Doom mods employ 8-bit graphics with The One True Palette Of Doom, and that hi-res and hicolor/truecolor extensions so far have been highly port specific, so none can claim to have set a new standard. I can understand Graf Zahl supporting ZDoom's way of extending it, the authors or prboom or Eternity may have a different one or support different things e.g. true color skyboxes only.

For the z-buffer, as I said, you could adopt a different layer numbering scheme that extends all the way to 4096. Not perfect but more of a reasonable limit, and with a numbering scheme that does not clash with the normal sprites' namespace (actually, it can coexist and even be used as an indicator of the existence of voxel sprites).

It's not perfect, but practically reasonable (unless someone decides to make a 4097 units-wide model out of spite :-p

[Graf Zahl]

Maes said:

and that hi-res and hicolor/truecolor extensions so far have been highly port specific, so none can claim to have set a new standard. I can understand Graf Zahl supporting ZDoom's way of extending it, the authors or prboom or Eternity may have a different one or support different things e.g. true color skyboxes only.

Uh, what?

The specificness of hires is certainly debatable but for truecolor ZDoom uses PNG (and PCX, JPG, TGA) which is as non-port-specific as possible.

[printz]

Why not go all the way and define a voxel format, if they find their use in ports? So as to definitively differentiate pure sprites from voxel models.

[DooMAD]

There are ports for Duke3D that added voxel rendering and their voxels were converted from 3D models, so they were vastly bigger than the ones we're working with here. I would imagine much of the work has been done already, so there's no need to reinvent the wheel. If it's open source, maybe have a peek at that to get started. Found some screenshots here.

[Maes]

DooMAD said:

their voxels were converted from 3D models, so they were vastly bigger than the ones we're working with here.

Then the question at this point is exactly what sort of "voxel port" you're asking for.

• One that emulates the "what if vanilla Doom had voxel sprites" look, with the same dimensions/color paletter/resolution
  
• Something extending them to a whole other direction, like ports using full 3D models.
  

In the former case, by "backwards compatible" voxel format would be ideal, and probably very close to what ID would have implemented back in the day, if they had the option: a format which only implicitly defines voxel models, can be read and edited just like normal sprites. E.g. Certain decorations would be prime candidates for having 1-3 sprites of voxel animation, and come to think about it, a "hollow CAT-scan" layer-based storage for certain sprites would have even been less demanding in terms of space compared to storing 8 full frames per animation.

The latter is a pure source port extension that has nothing to do with vanilla limits per-se, ok, settled that?

It's all a question of what the crowd wants.

[DooMAD]

I'm not a programmer, so perhaps this is a silly assumption, but surely you could have the best of both worlds with a simple parameter for scale? The resolution I'm working on would be the low end of the scale. Then if someone wanted to make some high res ones based on 3D models, they just edit the scale to make them smaller.

[Mordeth]

printz said:
The problem I imagine is that voxels being all cubic and that, slanted voxel-made surfaces will look fudged in the game, unlike slanted linedefs, or slopes.

Well, this switch looks pretty damn nifty to me :)

[VinceDSS]

nobody suggests prboom as a base ?

[Csonicgo]

VinceDSS said:

nobody suggests prboom as a base ?

I think Eternity Engine would be best to use as a base. It seems to fit perfectly with what features it has and what it plans to have. :)

[hervoheebo]

Wasn't the idea pretty much shot down the last time voxels were discussed? From what I understood, voxel support would be too hard to program and maintain.

I don't mean that I dislike voxels, I, for one, am a huge fan of them. Don't know too much about voxel workings, but they seem to be the perfect compromise of 3d depth and classic Doom look. Just looks like that monster sprites would take a huge amount of work.

[DooMAD]

The main objections were regarding OpenGL, as that's more difficult and more resource intensive than a software renderer. There's no reason why it can't be done in a software renderer, aside from apathy. Shadow Warrior, Blood and other such games were doing it years ago, so all it should take is a little effort to do the same in Doom.

[Maes]

Incidentally, if the voxel format used was my "glorified sprite patches" one, it would be trivial to draw voxel sprites just in the same way as regular wall columns -only that they would be moving.

"Hollow" voxel models would be extremely lightweight to blit, too -only the voxels at the edges or near gaps could be drawn (imagine drawing a bunch of dynamic 2-sided linedefs in lieu of a sprite).

To seal off the sides of voxel models, when reading the extended "voxel sprites" from disk, a complementary set of "side layers" could be automatically precomputed, so that they don't look like grilles when looked from the side:-p