Voxel Doom Port!

[Graf Zahl]

Maes said:

"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)./B]

Big mistake!

Hollow voxel models can not be optimized by any renderer so much more needs to be processed. Let's be honest: Your ideas don't really make much sense unless a very hacky and useless implementation is the goal. Either do it for real or not at all. The only way to go is to use a proper voxel editor and a proper voxel format.

[Maes]

So drawing a full -and invisible- interior of a voxel model is a more optimized approach?

If I didn't make myself clear, imagine making a map consisting of a single room with a single object made of 16 linedefs intertwined with other 16 linedefs perpendicular to the first, and each of them being textured with middle textures as to create the illusion of voxels.

There you have it, a stationary "sprvoxel" object.

Extending this simple concept to animation and dynamic linedef-like rendering is left as an exercise to the reader.

All this, I repeat again, if you want to make a "vanilla friendly" (on some hypothetical level) voxel system, or take an educated guess of how e.g. ID would have chosen to mix sprites with voxel objects back in the day. For the rest, you can nitpick at the -theoretical- limitations and deficiencies as much as you want, or propose alternatives :-p

Just don't let your blood boil over something that doesn't even exist yet.

P.S.: If anything, this could be used as an interesting way of constructing static volumetric decoration in standard maps...I'm almost tempted to make a demo map ;-)

[Graf Zahl]

Maes said:

So drawing a full -and invisible- interior of a voxel model is a more optimized approach?

Yes, it is! Then the engine can cull all faces that are hidden due to neighboring voxels. With a hollow model that's not possible and the entire inside needs to be processed, too.

Of course, if you are only concerned with your hack implementation it may be of use but ultimately you are shooting yourself in the foot because for a proper voxel engine it would not help.

[Maes]

Graf Zahl said:

Yes, it is! Then the engine can cull all faces that are hidden due to neighboring voxels. With a hollow model that's not possible and the entire inside needs to be processed, too.

OK now I see what you mean, with the difference that the "inside" would be stored just as transparent columns/posts, so skipping form the "top" to the "bottom" of a model would be trivial. But yeah, culling the inside of the model's "skin" on the opposing side would need some actual work -but I don't see how it would be any worse than with a full fledged voxel engine.

And...since when ISN'T any addition to Doom or any of its source ports a hack/compromise? :-p

[Graf Zahl]

Intentionally doing it in a bad way is just... bad. Hacks should be a last resort not the design goal.

[Maes]

Well, if we both finally agree that any voxel engine would need proper culling computations, then I guess the only remaining "dispute" (over a non-existing thing, I remind) is the storage method.

[DooMAD]

For once I'm in agreement with Graf, heh. Not to mention that all of the work done so far has been in voxel format. I certainly don't plan on starting all over again in a new layered sprite format.

Shadow Warrior and Blood used *.kvx format which is, as far as I'm aware, basically the same thing as *.vox format. Slab6 can open/save in either.

[printz]

How do the engines treat voxels completely occluded by boxes, so they're never seen? Is there somewhere an algorithm to flush them out, either at authoring time or run time?

[4mer]

For anyone interested in voxels and hasn't seen this before:

http://voxelstein3d.sourceforge.net/

Requires Windows.

[Per-Scan]

Yup, that's pretty cool! I have seen the future and it is in voxelvision! If that demo ever becomes a proper game I'll be a happy man.

[DooMAD]

Berzerk kit


Pretty much a recolour of the medkit, aside from the weird looking indents on the lid. Although I haven't actually made those 3D yet, heh.

Also updated the zips with new files:

*.vox format
*.v3b format

[_bruce_]

Looks great.

[Mechadon]

Everything is looking good DoomMAD! Keep going :)

[DaniJ]

Static voxel models are of course possible in an GL renderer. I'd bake them to say VBOs. The outer surface of a voxel model can be easily acquired during load through CSG union of a unit-cube model. Then tessellate the result and pack into VBO(s). Ports like Doomsday and GZdoom which already feature 3D model support could potentially implement it all as pre-processing stage and handled like a normal 3D model during render.

The main problem with voxels are the hideous lighting results which would occur without a special-case algorithm.

[Stroggos]

DAMN!!!! I have finally freed myself up to do this thing and now RL calls! Why is this so!
I'll get back to it right after I clear this mess up.

[Quasar]

I have added a voxels module to Eternity and code to load the open-spec .vox format.

How's this going (or not) on the end of drawing the things? Has any actual research been done or is this really all talk at this point?

[DooMAD]

[Per-Scan]

Quasar said:

I have added a voxels module to Eternity and code to load the open-spec .vox format.

How's this going (or not) on the end of drawing the things? Has any actual research been done or is this really all talk at this point?

Wow! Too cool. This is really going to happen, isn't it? :)

[Csonicgo]

Quasar said:

I have added a voxels module to Eternity and code to load the open-spec .vox format.

I agree that an open-spec format is best in cases like this. iirc there will still have to be some consensus on how the voxels will be represented in the PWAD structure. :P

[Gez]

VX_START/VX_END?

(Not just V_ because it's already used by Strife for its voices.)

[esselfortium]

I think VX_START/VX_END is what we settled on after a lengthy discussion in #noteternityenginerelated. I'm not sure what the plan for the individual voxel names is, though; just the sprite name and frame letter (i.e. "TROOA") was one possibility. Easy on the eyes when looking at lots of them, to the point, and short enough to leave room for potential expansion if a new feature could benefit from it someday.

I should let Quasar say for sure, though; I think this is what we agreed on in the end, but I'm not sure how decided all this really was.

[Graf Zahl]

Gez said:

VX_START/VX_END?

(Not just V_ because it's already used by Strife for its voices.)

That was my idea, too. Since Randy just started implementing voxels in ZDoom, too, some proper specs are needed quickly, I think. Especially concerning the voxel formats that should be supported.

ZDoom currently only handles KVX so if Eternity only loads VOX we'd already have an incompatibility.

esselfortium said:

I'm not sure what the plan for the individual voxel names is, though; just the sprite name and frame letter (i.e. "TROOA") was one possibility.

What else should there be? Rotations make no sense with voxels so the only other thing could be something like TROOAB to define a mirrored version, just like the sprites do.

[DooMAD]

When saving in KVX format, Slab6 asks if it should be 1 mip for smaller files or 5 mips for Build Engine. Should I assume 5 mips is the correct one?

[DaniJ]

Unless I'm missing something, I have no idea what Slab6 could be referring to. Are we talking mip as in minification? LOD for discreet voxel models (sounds useless)?

[DooMAD]

I have no idea either. I can only guess that 5 mips would mean higher quality somehow. I suppose it doesn't really matter anyway, I can save copies with both settings, heh.

//EDIT: Says in the readme:

In versions previous to 12/25/2003, SLAB6 saved only the first "mip-map" level. 
This results in a smaller file size. However, if you want to use your voxel object in 
the Build Engine, you must save all 5 mips.

[Graf Zahl]

DooMAD said:

When saving in KVX format, Slab6 asks if it should be 1 mip for smaller files or 5 mips for Build Engine. Should I assume 5 mips is the correct one?

Better ask directly at the ZDoom forum. Randy is using the Build code for voxels so he might be the one who can tell you if the mips are needed. What I can tell you is that if I implement this in GZDoom I'd only use the main level and discard the rest because it's too much maintenance for insufficient gain.

[DaniJ]

Gez said:
VX_START/VX_END?

Sounds fine to me.

We should not bother with mirrored versions of a voxel model, they are unnecessary and imo, not useful anyway as to determine selection it means ray casting... I'd much rather just ignore the way it works with sprites and just have one voxel model per state frame.

[Gez]

DaniJ said:

Unless I'm missing something, I have no idea what Slab6 could be referring to.

Something made by Ken Silverman to edit voxels.
http://www.advsys.net/ken/download.htm?#slab6

Both VOX and KVX formats are documented in the slab6 package, along with a third voxel format for good measure (see slab6.txt).

[DaniJ]

Thanks but I was already aware of Ken's voxel projects. I should have clarified that I was referring to the use of the term "mip" in the context of a voxel model format.

One thing GL ports will need to consider is how to handle the colour information - a decision which is largely dependant on the renderer design.

The easiest method is to use the per-voxel colour for vertex colours in another buffer.

A much nicer method design-wise (imo) would be to bake it into a dynamically constructed 2D texture and uvw map.

EDIT: Actually, there is little point in even implementing voxels in a GL port - all we need is a voxel to MD2 model converter.

[Quasar]

You guys know Eternity cannot use Build engine code and yet you go and start trying to create a situation where "compliance" cannot be achieved without it.

I'm not going to be able to sit down and write mipmapping code at this point in time.

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. Call me back when somebody creates a reference implementation of this stuff that doesn't require me to beg Ken Silverman to quit being a crank with his licensing schemes.