Doom Voxel Project

[RaVeN-05]

Think: Interpolated voxels with colors, for colors logic needed this - gradient fade from one color to another, this is looks like OpenGL filtering 2d image, but for 3d image (emitate?). Or alltimes convert this to 2d sprite and apply filtering? So this is what i guess, technically, i am don't know how to realize this. But think its possible =0

[Rachael]

I know I could easily implement it myself in ZDoom if ZDoom keeps track of Z-depth for every pixel on the screen - which I do not know if it does. I've written a voxel renderer myself for a hobby project of mine.

If it doesn't, then it's probably buried in the renderer code somewhere that I could find it and get it out. It would be similar to drawing sprites, except that it would be different.

But eh... I just need the motivation to do it... and enough hard drive space to reinstall my compiler...

[randi]

Would this be simpler to implement in the (G)ZDoom engine?

GZDoom: I doubt it would be particularly easy.
ZDoom: The code is already there, in the Build engine. I would just need to adjust it for the different coordinate systems of the two engines. With actual voxel models available, I might even bother, if only because they would make the Blood levels look a little bit better.

[Caligari87]

How would you implement it? Honestly, I never saw the appeal of Lego-model doom, but if the voxel models were simply rendered as pixel points, like sprites, it would be a 100% better.

[phi108]

Great to hear that build's voxels might make it into ZDoom! I would also rather see an option for 1x1 pixel sprites used to represent individual voxels, though I expect that might introduce seams. I guess there are seamless methods of voxel rendering.

[Captain Awesome]

ZDoom: The code is already there, in the Build engine. I would just need to adjust it for the different coordinate systems of the two engines. With actual voxel models available, I might even bother, if only because they would make the Blood levels look a little bit better.

Not to be an ass, but what do you mean by this? I know there are numerous features in Shadow Warrior that can't be just "dropped" into Eduke32, because the engines (while being essentially the same) are too dissimilar.

[InsanityBringer]

Zdoom's renderer does use BUILD code, but I thought it was only for the slopes.

[Gez]

There's more BUILD stuff that just slopes. There's a half-functioning polymost prototype, and there are several general-purpose macros. Plus code to read BUILD-engine game data, of course.

[randi]

Zdoom's renderer does use BUILD code, but I thought it was only for the slopes.

This seems to be a common misconception. Build draws slopes vertically, just like walls, and suffers from some terrible cache thrashing as a result. ZDoom draws them horizontally, just like regular flats. The code is quite different, and ZDoom was drawing slopes before the Build source was ever released. ZDoom even uses Michael Abrash's fdiv trick for doing the perspective divide in parallel with the rendering.

Here's a summary of the Build code in ZDoom that I wrote a few months ago:

The slopes themselves were (and still are) entirely my own code. The part that's from Build is the wall boundary calculations. The way Doom did it was too imprecise for any useful sloping, so I was in the process of rewriting it to use the standard perspective divide equations, then Build's source was released, and I saw I was going in the same direction as it, so I just used its code to save myself some time. Here's a list of Build-touched functions:

• R_AddLine: everything before

  Code: Select all

  backsector = line->backsector

• R_RenderDecal: uses the same projection code as R_AddLine. It's just standard perspective divide stuff.
• wallscan/maskwallscan/transmaskwallscan: multicolumn rasterizers straight from Build
• OWallMost/WallMost: calculate top and bottom edges of walls, also straight from build
• PrepWall/PrepLWall: calculate texture coordinates and scales along a wall, for use with wallscan
• a.asm: everything in here

There might be others, but I'm pretty sure that's all of it. The wallscan and prepwall routines are basically all for splitting up R_RenderSegLoop so that it can draw four columns at a time instead of just one, which can be significantly faster depending on the processor's cache. You could remove those and go back to the old R_RenderSegLoop without affecting slopes, but there will be a performance hit.

Plus code to read BUILD-engine game data, of course.

None of which is from Build, though.

I would also rather see an option for 1x1 pixel sprites used to represent individual voxels

If you really mean to render just one pixel for each voxel, that would look really bad the closer you got to it.

Not to be an ass, but what do you mean by this? I know there are numerous features in Shadow Warrior that can't be just "dropped" into Eduke32, because the engines (while being essentially the same) are too dissimilar.

The core engines (Build) are identical. It's the gameplay code that's bolted on top of it that differs. Anyway, drawing voxels basically amounts to swapping out one sprite drawing function for a different one. It's not a particularly invasive feature.

[Captain Awesome]

I did not know that. That's really neat. Thanks for letting me pick at your brain a bit.

[NeuralStunner]

So this is one feature that would actually be harder in the hardware renderer? Kinda like software's answer to models.

[hitmanx]

i'm confused, just to clarify, we're not able to run build content in zdoom right. I can't just like drag drop a duke3d.grp and it'll work.

Is this a planned feature or something? so much talk of build i must have missed something.

[Ceeb]

You can load the .ART files and .MAP files but support is very limited AFAIK.

There's a ZDuke somewhere around here...

[Gez]

See [wiki]ZDuke[/wiki] and [wiki]supported data formats[/wiki] for info.

[MartinHowe]

Build draws slopes vertically, just like walls, and suffers from some terrible cache thrashing as a result. ZDoom draws them horizontally, just like regular flats.

Well I'll be damned! I always wondered why in ZDoom one has to apply sloping to floors and ceilings instead of walls - totally counter-intuitive because anything that projects out of the floor must intuitively be a wall. Now I know why