Voxel Doom Port!

Quasar said:

it's a shame he's not opening his source code

Actually, DarkXL will be open-sourced once it reaches beta. That had been the plan for a while now. Same for DaggerXL.

http://www.df-21.net/phpbb/viewtopic.php?t=1569

Voxel Textures must happen for one thing only.

The Icon of Sin :D

Gez said:

Actually, DarkXL will be open-sourced once it reaches beta. That had been the plan for a while now. Same for DaggerXL.

http://www.df-21.net/phpbb/viewtopic.php?t=1569

I am aware, from having read the webpage not too long ago. However, the question for me is "when will that be?" Probably longer than I'd like :P

Your post asking about it was nearly a year ago.

He still plans to do it when it hits beta and from what I've heard, may be released soon.

I just want to clarify that I’ve been saying the Beta will be released around New Years because it may not be released exactly on New Years day. If these tasks take me a little longer I may release a few days after. The goal, though, is to get the Beta released this weekend.

So, I'd expect to see it this month.

Graf Zahl said:

I don't think that will ever work in Doom. Too much of the engine is just not suited for clipping such constructs properly.

its so close you can taste it, i mean its right there, surely there must be a way? altering the source code or something. perhaps make voxeldoom into its own source port. i dunno.

What would be wrong with a bounding box?

Dee said:

its so close you can taste it, i mean its right there, surely there must be a way? altering the source code or something. perhaps make voxeldoom into its own source port. i dunno.

You clearly have no idea what you are talking about.

The biggest problem here is how level geometry is processed. If a wall is not visible it may get skipped at a point long before any voxel volumes are checked. Also, walls can be split which would also make proper processing of texture voxels problematic.

In other words: You can't just add a few simple checks. To ensure that everything works as expected you pretty much need a new renderer.

With the current voxels attached to actors, the entire voxel model is either drawn or not, and parts stuck into a wall don't disappear. For usable voxel textures, each individual voxel would have to be checked to see if it should be drawn, to allow cutoffs at any height or horizontal point of the texture. I don't know if Voxlap/Voxelstein can be referenced, because I think it is full 3D and too different.

EDIT: What graf said too.

Anyway, as posted at ZDoom, Voxelstein in classic 2.25D! 5 items For use with AFADoomer's Wolf3D TC.

http://files.drdteam.org/index.php/files/get/29OOVSqliN/wolfvoxs.zip

phi108 said:

Anyway, as posted at ZDoom, Voxelstein in classic 2.25D! 5 items For use with AFADoomer's Wolf3D TC.

Woudln't that be 2.75D? How can it be further away from 3D than plain old 2.5D vanilla? :p

Also, for those interested, the ZDoom voxel branch just got trunked. :)

Gez said:

Woudln't that be 2.75D? How can it be further away from 3D than plain old 2.5D vanilla? :p

I don't understand how you count.

Voxels are more 3D than sprites. If you change the value (2.5->2.25 here), it doesn't make sense to decrease it; it'd be more logical to increase it (2.5->2.75).

Actually that was just referencing Wolf3D's original 2D level design, with pseudo 3D graphics. Doom has more of a 3rd dimension, so Wolf is 2.25D and Doom 2.5D. I guess voxels might add some hundrenths of a dimension to the total.

Dammit, they're ALL 3-D. the only 2.5-D games were platformers with dual paths in the level at once.

Graf Zahl said:

In other words: You can't just add a few simple checks. To ensure that everything works as expected you pretty much need a new renderer.

thats pretty much what i was saying. make voxeldoom into its own source port. basically a modified version of the zdoom engine that would correct the problem. I mean like I said, there IS a way it can be done, whether or not it has to be a completely new engine or not, but the fact is that its there and its clearly possible. will it ever happen? probably not. can it? possible.

Dee said:

thats pretty much what i was saying. make voxeldoom into its own source port. basically a modified version of the zdoom engine that would correct the problem. I mean like I said, there IS a way it can be done, whether or not it has to be a completely new engine or not, but the fact is that its there and its clearly possible. will it ever happen? probably not. can it? possible.

No, it won't happen because the visibility clipping in the Doom engine can't do it. So you have to throw *everything* over board and come up with a completely new way to check it - one that does not rely on the optimized data structures Doom uses for it - because they are useless.

So the bottom line is, that the likelihood of it ever getting done is close to zero. You have to do pretty much all the research that went in the Doom engine all over again with a signficantly complicated premise.

One of the major assumptions while checking visibility is that walls are flat surfaces which with voxel textures obviously is no longer the case.

In that case it would have to be some entirely separate entity from Doom utlizing an original engine or perhaps something based off an ancient Voxel game. Seems like a pipe dream because I don't know how anxious mappers and coders are to try to recreate the Doom experience on an entirely different engine. Plus, animating voxels is no easy task.

Quasar said:

I am aware, from having read the webpage not too long ago. However, the question for me is "when will that be?" Probably longer than I'd like :P

Your post asking about it was nearly a year ago.

That post was indeed a long time ago, but that's just because the plan has been to release the source code once it reaches Beta for a while now. That still stands and is one of the reasons that I delayed the Beta release until some time later this week (I just ran out of time to get everything ready). Sorry if you don't agree with my stance on the source code, I meant no offense in my statements. The "proliferation of DOOM source ports" does indeed work well for the Doom community, I never meant to imply anything to the contrary.

Edit - I've updated the most recent blog post to talk about the upcoming source code release. As stated in the blog, I'm starting the process and it will be complete this week.

As for voxel rendering, you may be somewhat disappointed in my approach since it is very GPU oriented - it may not be very useful for a software renderer I'm afraid. DarkXL's "Pure Renderer" is designed to have the software rendered look but that is still achieved using the GPU for rendering, though really low end GPU's will still require some CPU assistance.

Oh and the voxels in Wolfenstien look really cool. :)

Graf Zahl said:

So the bottom line is, that the likelihood of it ever getting done is close to zero.

:'( sucks! I wish it could happen!

Graf Zahl said:

One of the major assumptions while checking visibility is that walls are flat surfaces which with voxel textures obviously is no longer the case.

Could it be possible to "cheat" by offsetting a wall by the thickness of its voxture when checking visibility? It'd still be considered flat, but a few units more forward than it actually is.

lucius said:

That post was indeed a long time ago, but that's just because the plan has been to release the source code once it reaches Beta for a while now. That still stands and is one of the reasons that I delayed the Beta release until some time later this week (I just ran out of time to get everything ready). Sorry if you don't agree with my stance on the source code, I meant no offense in my statements. The "proliferation of DOOM source ports" does indeed work well for the Doom community, I never meant to imply anything to the contrary.

Totally understandable. I just get very nervous when I see awesome projects that aren't open source since I've seen so many of them drop off the face of the earth in my time. I am glad to hear you are making progress.

lucius said:

As for voxel rendering, you may be somewhat disappointed in my approach since it is very GPU oriented - it may not be very useful for a software renderer I'm afraid. DarkXL's "Pure Renderer" is designed to have the software rendered look but that is still achieved using the GPU for rendering, though really low end GPU's will still require some CPU assistance.

I'm seriously impressed as I could have fully believed from the screenshots that you were doing plain old software rendering ;) But, the only way I'd be able to tell if your code could help us or not is simply by taking a look at it. The rendering end may not be since you're using hardware, but I am still curious about the process you use to project and step through the data structures derived from KVX files.

It's non-obvious to me as I'm just not that great with 3D stuff and I refuse to examine Ken Silverman's source directly since then I'll probably end up writing something that is indistinguishable aside from different variable names and comments, and I don't want accusations coming up that I've tainted my code with stuff I don't have the rights to use :/

Quasar said:
I'm seriously impressed as I could have fully believed from the screenshots that you were doing plain old software rendering ;) But, the only way I'd be able to tell if your code could help us or not is simply by taking a look at it. The rendering end may not be since you're using hardware, but I am still curious about the process you use to project and step through the data structures derived from KVX files.

It's non-obvious to me as I'm just not that great with 3D stuff and I refuse to examine Ken Silverman's source directly since then I'll probably end up writing something that is indistinguishable aside from different variable names and comments, and I don't want accusations coming up that I've tainted my code with stuff I don't have the rights to use :/ [/B]

Thanks for the compliments. :) You can see the Pure Renderer in motion here: http://www.youtube.com/watch?v=rmPLwkqWP6k&hd=1

I understand your reasons for not using Ken's code as a reference. Though fortunately the KVX format is documented so his code isn't needed. :)

Gez said:

Could it be possible to "cheat" by offsetting a wall by the thickness of its voxture when checking visibility? It'd still be considered flat, but a few units more forward than it actually is.

I wonder if any engine could check if a pixel of the texture would normally be visible, and then just (oops "just") draw that whole row of voxels sticking out from that pixel coordinate. It might show errors in some viewing situations though.

That wouldn't help at all. Doom's visibility clipping algorithm is already designed to process only those parts of walls that can be seen. The problems occur when these are not visible but the voxels extruding from such a position would be.

This is a question of curiosity: how would a "bridge" voxel look when used as a K2 bridge? Would it blend seamlessly enough into the surrounding sector-based structures well?

EarthQuake said:

This is a question of curiosity: how would a "bridge" voxel look when used as a K2 bridge? Would it blend seamlessly enough into the surrounding sector-based structures well?

Somebody already tried this, and material-wise it looked fantastic. However when viewed from certain angles, the structure had significant problems with self-clipping - that is, because it was made of multiple voxel models, some parts overlapped others incorrectly.

Started on the Candleabra, but having problems with my voxel editor of choice again. Voxel3D is being a pig and eating all the memory until the program stops responding. Good interface, but piss-poor memory management. Slab6 has no problems opening it, but has a horrific interface (IMO). Can't seem to find a nice balance between the two.

I'm so glad that I got this idea going again. I love the work that's already been done by DooMAD and others. Keep it up!

Two points, guys:

- There's an upcoming indie game which uses voxels only, it's called Voxatron:
http://www.rockpapershotgun.com/2011/01/05/look-there-go-the-voxels-voxatron/
Maybe you could ask them for advice or something ?

- it's not like you absolutely have to use it with proper voxels, if it's too difficult. Looking at the models(?) you've made, I would love to see them ingame even converted to regular .md3 or whatever is the most convenient format. The keyword here is stylisation, not technical limitation. With a bit of self-discipline, you can achieve similar (not identical) results with ordinary models.


More generally, I think voxels are a perfect reinvigoration for DooM. They are technically more advanced and look somewhat naturally (in that an item looks different from various angles) yet keeps that rough edge of the VGA era.

If anyone was having problems with the recent Strip2Voxel update outputting jumbled voxels, Scott_AW has released a fix, downloadable here.

Scott_AW said:

I didn't realize I was setting the reading ranges with the wrong variables, so even though it worked fine with wide objects, tall objects got spliced and diced. Should be working now.

Still haven't setup any method of a custom transparent color, and it's still recommened to use 16-bit color mode for your display to ensure 100% accurate color copying.

I'm also planning on eventually having a method that will allow you to combine a basic image and a heightmap to create models, but been a little preoccupied doing my TC of duke3d.